http://l10n.lrn.ru/wiki/api.php?action=feedcontributions&user=77.121.217.121&feedformat=atoml10n.lrn.ru - Вклад участника [ru]2024-03-28T11:00:27ZВклад участникаMediaWiki 1.23.7http://l10n.lrn.ru/wiki/%D0%9B%D0%BE%D0%BA%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%81%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE_%D0%9F%D0%9E_(%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F)Локализация свободного ПО (лекция)2011-02-14T20:43:27Z<p>77.121.217.121: Very nice post, good luck! ;-)</p>
<hr />
<div>'''Локализация свободного ПО'''<br />
<br />
Лекция в Московском государственном университете<br />
<br />
11 мая 2007 года<br />
<br />
<br />
<nowiki>Автор: Андрей Черепанов <</nowiki>[mailto:cas@altlinux.ru cas@altlinux.ru]><br />
<br />
<br />
<br />
Very nice post, good luck! ;-)<br />
<br />
= Механизмы локализации в свободном ПО =<br />
== GNU gettext ==<br />
=== Описание пакета ===<br />
На сегодня самым распространённым средством локализации свободного ПО является GNU gettext. Это программное обеспечение предоставляет разработчикам, переводчикам и даже простым пользователям интегрированные средства и документацию по локализации приложений. С точки зрения методологии gettext предоставляет:<br />
<br />
* набор соглашений о том, что должна использовать программа, поддерживающая каталоги сообщений;<br />
* формализацию именования каталогов и файлов каталогов сообщений.<br />
<br />
Библиотека gettext предоставляет механизмы подключения каталогов сообщений и получения строк, переведённых в соответствии с локалью.<br />
<br />
Процесс создания ПО, готового к локализации и впоследствии локализованного выглядит следующим образом:<br />
<br />
1. Разработчик заботиться о том, чтобы все текстовые строки, которые будут выводиться в программе (например, названия пунктов меню, подсказки, надписи в диалогах и т.п.) «оборачиваются» в вызовы функций gettext() и ngettext() библиотеки libintl. Как правило, такие вызовы для упрощения оформляются макросами «_()» и «N_()». В KDE, к примеру, строки «оборачиваются в вызовы i18n().<br />
<br />
Перед вызовом функций локализации загружаются каталог сообщений вызовом функции textdomain().<br />
<br />
2. Разработчик использует программу '''xgettext''' для поиска всех вызовов функций gettext() и ngettext() и формирования шаблона каталога сообщений. Обычно эти файлы имеют расширение '''.pot'''.<br />
<br />
3. Локализатор на базе шаблона создаёт или обновляет каталог сообщений, содержащий готовые переводы. Файлы каталогов, как правило, сообщений имеют расширение '''.po'''.<br />
<br />
4. Каталог сообщений направляется разработчику или сборщику пакета и на этапе сборки компилируется программой '''msgfmt''' в бинарный файл с расширением '''.mo''', который размещается в обычное место для файлов локализации. В подавляющем большинстве случаев это каталог <nowiki>/usr/share/locale/<код языка>/LC_MESSAGES/</nowiki>.<br />
<br />
Во время работы программы бинарный файл каталога сообщений подгружается и каждый вызов функций локализации возвращает перевод оригинальной строки.<br />
<br />
=== Содержимое файла каталога сообщений ===<br />
Шаблон каталога сообщений (.pot) и исходный код каталога сообщений (.po) являются обычными тестовыми файлами (как обычно в традициях UNIX), состоящими из строк комментариев, строк оригинальных сообщений и строк перевода сообщений.<br />
<br />
Комментарии начинаются с символа «#» и идут до конца строки.<br />
<br />
Строка оригинального сообщения начинается с ключевого слова '''msgid''' в начале строки и одной или нескольких строк в кавычках ("). Перевод сообщения идёт после msgid и начинается с ключевого слова '''msgstr''' (в начале строки), за которым следует одна или несколько строк в кавычках ("). Количество строк msgid и msgstr должно быть одинаково.<br />
<br />
Первая строка msgid всегда пустая, а в msgstr содержит служебную информацию о файле:<br />
<br />
msgid ""<br />
msgstr ""<br />
"Project-Id-Version: kig\n"<br />
"POT-Creation-Date: 2006-12-11 02:43+0100\n"<br />
"PO-Revision-Date: 2007-01-12 11:04+0300\n"<br />
"Last-Translator: Andrey Cherepanov <sibskull@mail.ru>\n"<br />
"Language-Team: Russian <kde-russian@lists.kde.ru>\n"<br />
"MIME-Version: 1.0\n"<br />
"Content-Type: text/plain; charset=UTF-8\n"<br />
"Content-Transfer-Encoding: 8bit\n"<br />
"X-Generator: KBabel 1.11.4\n"<br />
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>"<br />
"=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"<br />
<br />
В заголовке указываются название программы, даты создания шаблона и последних изменений перевода, последний переводчик, команда локализации, кодировка и прочие сведения.<br />
<br />
Практические все современные программы используют Unicode для работы со строками, поэтому используется кодировка по умолчанию UTF-8. Для приложений KDE и GNOME указание любой другой кодировки является ошибкой.<br />
<br />
Использование текстового формата заметно упрощает работы с этими файлами: к вашим услугам весь богатейший арсенал обработки текста UNIX с историей в несколько десятилетий. Весьма просто автоматизировать работу из скриптов Perl и Python для нетривиальных задач.<br />
<br />
=== Особенность работы с каталогами сообщений ===<br />
Помимо упомянутых программ '''xgettext''' и '''msgfmt''', существует ряд инструментов для работы с каталогами сообщений. Из основных стоит отметить программу '''msgmerge'''<nowiki>, которая позволяет объединять новый шаблон и старые переводы. Например, разработчик изменил ряд строк в программе и добавил новые, а у вас есть каталог сообщений с переводом для старой версии. Не беда: запустите msgmerge <старый файл с переводом> <новый шаблон> > <новый файл с переводом> и получите обновлённый файл с переводом. Программа сверит перевод и шаблон и отметит новые строки. Если найдены похожие строки, которые были переведены, но незначительно исправлены, они помечаются как </nowiki>'''черновые''' (fuzzy).<br />
<br />
Пометка строк как черновых является весьма интересной особенностью gettext. В файле они отмечаются как комментарий вида #, fuzzy перед строкой msgid. После компиляции программа игнорирует этот перевод и выводит оригинальное сообщение, однако переводчики могут оставить эти строки для перевода в будущем, не опасаясь за потерю идей по переводу.<br />
<br />
Ещё одной интересной особенностью gettext является использование множественных форм (plural forms). Этот механизм позволяет на основании заданного числа, который указывается в параметрах функции ngettext() сформировать правильную строку с количеством с учётом языковых особенностей, избавив пользователя от ужасных «... файл(ов)». Если для английского языка множественных форм насчитывается две (1 и всё остальное), то для русского – три (заканчивающиеся на 1, на 2,3,4 и все остальные).<br />
<br />
Кроме того, в сообщениях gettext можно указывать символы подстановки, которые на этапе поиска перевода будут заменены на передаваемые значения аргументов, которые переводить не нужно (например, имена файлов).<br />
<br />
Стоит отметить, что компиляция в бинарные файлы .mo не являются необратимой операцией. Из такого файла можно получить исходный каталог сообщений командой '''msgunfmt'''.<br />
<br />
== Альтернативные механизмы ==<br />
Помимо gettext существуют и альтернативные механизмы локализации программного обеспечения. Мы рассмотрим реализации локализации для некоторых приложений под Linux и Microsoft Windows.<br />
<br />
=== Mozilla и OpenOffice.org ===<br />
Проект OpenOffice.org использует для локализации механизм файлов ресурсов, как в Microsoft Windows. <br />
<br />
Приложения Mozilla основаны на диалекте XML XUL, поэтому локализация их осуществляется посредством упакованных в файл .jar DTD с переводами сущностей и текстовых файлов с переводом свойств по идентификаторам.<br />
<br />
Эти механизмы локализации не получили широкого распространения в силу их негибкости и неудобства для переводчиков. К слову, большинство CMS также используют локализацию строк по идентификатору.<br />
<br />
=== Trolltech Qt ===<br />
Если приложения KDE используют механизм gettext, то остальные приложения, использующие библиотеку Trolltech Qt, используют стандартный для этой библиотеки механизм локализации через вызовы метода tr(). Сообщения сохраняются в текстовых файлах c расширением .ts, которые предоставляют собой файлы формата XML, содержащие информацию о контексте, оригинальные сообщения и их переводы. Также, как и для gettext, есть программы работы с сообщениями файлов lupdate и lrelease и удобная графическая программа локализации Qt Linguist.<br />
<br />
=== Microsoft Windows ===<br />
Изначально локализация приложений Microsoft Windows осуществлялась как перевод строк из файлов ресурсов. К сожалению, использование не оригинальных строк, а их идентификаторов, усложняют процесс поиска контекста. Кроме этого отсутствуют механизмы пометки переводов как черновых. Неудивительно, что локализованных приложений Windows не так уж и много, а локализованные версии выходят гораздо позднее оригиналов. Ранее ресурсы программы распространялись в исполнимом файле, но сейчас механизм MUI позволяет легко распространять локализацию в среде Windows.<br />
<br />
Помимо неудобства работы с файлами ресурсов, в Windows до сих пор не решена проблема с динамическим размещением виджетов в диалогах. В Linux – никаких проблем: и Qt и GTK+ во время исполнения выравнивают элементы в зависимости от текста. Разработчикам Windows рекомендуют оставить между надписью и, к примеру, полем ввода достаточное место, чтобы вместить любой перевод. Теперь вы поняли, почему в диалогах Windows так много пустого места и такие длинные кнопки?<br />
<br />
К счастью, процесс локализации в Windows с переходом на .NET стал гораздо проще и фактически напоминает gettext. Метод String.Format позволяет указывать в качестве идентификатора оригинальную строку.<br />
<br />
Ещё одним серьёзнейшим недостатком локализации Microsoft Windows является полное отсутствие механизма множественных форм. При показе количества элементов в строке состояния удалении вместо ожидаемого (и реализованного в KDE и GNOME «3 элемента» вы увидите режущее русский слух «Элементов: 3». Это не переводчики плохие, это ограничения механизма локализации Windows. <br />
<br />
=== Локализация документации ===<br />
Механизм gettext показал свою жизнеспособность не только для локализации кода, но и оказался подходящим для локализации документации. К примеру, командой KDE были подготовлены две программы: '''xml2pot''' и '''po2xml''', которые позволяют преобразовать весь текст из файла формата Docbook в шаблон каталога сообщений gettext и затем получить переведённый Docbook на базе оригинального файла и каталога сообщений с переводом. Так как Dockbook в современном Linux используется как стандарт документации практически всех современных приложений, этот механизм можно использовать и для локализации документации многих программ.<br />
<br />
Локализация стандартного формата документации UNIX man осуществляются по старинке – построчным переводом оригинальных файлов с сохранением управляющих символов. Скорее всего это вызвано редким изменением текста в этих файлах и малым объёмом документации. Собранные файлы размещаются в подкаталогах /usr/share/man с кодом языка с сохранением оригинальной структуры подкаталогов man.<br />
<br />
== Инструментарий локализатора ==<br />
Для того, чтобы правильно, быстро и непротиворечиво локализовывать ПО мало знаний языка и опыта работы. Существует ряд методологий, которые помогают осуществить качественный перевод.<br />
<br />
Наиболее известна методология «памяти переводов» (translation memory). Она заключается в составлении единого глоссария переводов по определённой тематике (или вообще переводам программ в целом) и жёстком следовании ему. Подобные усилия позволяют унифицировать перевод, использовать одинаковые термины и ускорить сам процесс перевода.<br />
<br />
Также переводчику необходима проверка орфографии, чтобы избежать банальных опечаток в переведённом тексте.<br />
<br />
Для пакетной проверки каталогов сообщений формата gettext (проверка аргументов, множественных форм, пунктуации, длины сообщения и т.п.) полезно использовать gettext-lint.<br />
<br />
Хотя каталоги сообщений gettext можно переводить и в обычном текстовом редакторе (кстати, популярные текстовые редакторы поддерживают как подсветку, так и режимы работы с файлами .po), гораздо удобнее делать это в специализированных инструментах. Безусловным фаворитом в этом направлении является KBabel, приложение локализации, входящее в пакет kdesdk проекта KDE. В нём поддерживаются как компоновка «оригинальное сообщение-перевод», так и редактируемый список сообщений. Также KBabel поддерживает проверку правильности локализации (от проверки орфографии «на лету» до тестов на аргументы, длину и прочие), словари «памяти переводчика» (в том числе и может их формировать самостоятельно на базе существующих переводов), менеджер каталогов сообщений, показывающий статистику по нескольким файлам, выбор символов Unicode и многое другое. Помимо файлов gettext поддерживаются файлы локализации Qt.<br />
<br />
Кроме KBabel используется альтернативный инструмент gtranslator (под GNOME) и poedit (бесплатно распространяемый редактор файлов .po под Windows).<br />
<br />
Помимо редакторов файлов локализации потребуются словари «памяти переводчика» и обычные двуязычные словари (например, тот же StarDict). Крайне важным для локализации специализированных программ является наличие материалов по предметной области или доступ в Интернет.<br />
<br />
== Средства онлайновой локализации ==<br />
При правильной постановке организации локализация может эффективно производиться в рамках совместной работы. Если локальные переводы подталкивают к организации процесса «один файл – один переводчик», то создание средств онлайнового перевода позволило одновременно работать над файлами нескольким переводчикам.<br />
<br />
Из известных на сегодня средств онлайновой локализации ПО наиболее известна Rosetta, используемая для локализации Ubuntu. Кстати, средство это проприетарное. Однако есть и свободные аналоги. Например, проект Pootle, разрабатываемый в рамках Debian. Однако он так и не снискал популярности.<br />
<br />
У онлайновой локализации помимо очевидных достоинств: совместной работы, автоматического глоссария, возможности работы из любого места (достаточно только браузера) и рецензирования есть ряд недостатков.<br />
<br />
Основных недостатков у онлайновых средств локализации два:<br />
<br />
1. С точки зрения проверки локализации можно рассчитывать только на средства, предоставляемые порталом. В случае с локальной локализацией вы можете быстро найти или обработать файлы самостоятельно. В качестве примера можно привести приведение единиц объёма информации к стандарту в переводах KDE. Было написано хитрое регулярное выражение, вычисляющее потенциальные ошибки в переводах и также быстро эти переводы были исправлены.<br />
<br />
2. Доступность локализации для широких масс привело к резкому увеличению числа тех, кто перевёл пару сообщений, не обременив себя чтением глоссария, сверкой консистентности переводов и прочими буднями опытных локализаторов. Это привело к появлению разношёрстных переводов, которые не захотели проверить опытные переводчики и, как следствие, к падению качества перевода в целом.<br />
<br />
Кроме средств перевода есть порталы, посвящённые только раздаче файлов для перевода. Как правило, они формируются вокруг репозиториев крупных проектов: http://i18n.kde.org и [http://i18n.gnome.org/ http://l10n.gnome.org/]. На таких сайтах можно посмотреть статистику по командам перевода, отдельным пакетам или файлам и скачать файл для локального перевода.<br />
<br />
= Организация процесса локализации =<br />
== Помощь сообществу ==<br />
Свободное ПО позволяет любому человеку получить все необходимые материалы и инструменты для перевода. Неудивительно, что свободное ПО переводится на языки, поддержку которых в коммерческом ПО мы никогда не увидим. Например, цыганский или баскский.<br />
<br />
Как и разработка свободного ПО, его локализация требует стойкого желания заниматься этим. Как правило, ничего не получая в материальном плане. Мы, локализаторы на русский язык, увы, не можем претендовать на финансовую помощь, как к примеру в Эстонии, где локализация свободного ПО финансируется государством (и это видно по завершённости перевода KDE на соответствующем сайте). Поэтому любители быстрых денег у нас не задерживаются. В целом это неплохо, так как не возникает расхождений и обид по финансовым вопросам. И опытные переводчики и новички находятся в равных условиях. <br />
<br />
Вы можете спросить – так зачем же переводить, если вам никто не платит денег? Отвечу на этот вопрос. OpenSource – это '''эгоизм''' в чистом виде. Любые усилия, прикладываемые для развития проекта, будь его разработка, документирование, поддержка, локализация или пиар мотивируются желанием сделать или адаптировать продукт для себя, любимого. Любовь к себе сильнее жажды денег. Именно поэтому феномен свободного ПО оказался жизнеспособен и устойчив в развитии.<br />
<br />
'''Поэтому основная причина, по которой я занимаюсь локализацией, является желание видеть любимое ПО под Linux на грамотном великом и могучем русском языке.''' Конечно, есть и благодарственные отзывы пользователей, но они относятся к утешению честолюбия и не являются главным мотивирующим фактором.<br />
<br />
Кстати, при успешном занятии переводами тренируется знание как иностранного, так и родного языка, память. После такой практики вы можете сменить работу и устроиться переводчиком.<br />
<br />
Вопреки бытующему мнению, для локализации совсем необязательно идеально знать язык оригинала. Качества, незаменимые для профессионального перевода: внимательность и хорошее знание родного языка. Текстовая информация должна быть по возможности краткой, но понятной. Классическим примером является перевод фразы «Do you really want to delete this file?». Помните, я говорил про культурные различия? В английском языке, употребляемом в компьютерных интерфейсах диалоговых окон фразы длинные, со всевозможными оборотами. В традициях интерфейса на русском же, фразы чёткие и короткие. Поэтому этот паровоз переводиться просто: «Удалить этот файл?».<br />
<br />
Что вам нужно, если вы решили помочь в локализации какой-либо свободной программы (помимо желания, разумеется)?<br />
<br />
# Взять файл для перевода из распространяемого пакета или репозитория<br />
# Перевести и проверить в работе<br />
# Отправить в репозиторий или разработчику<br />
<br />
== Команды локализации ==<br />
Чем больше проект, тем больший объём переводов требуется для него. Сравните, к примеру, <br />
<br />
* kbfx (альтернативное меню KDE) – 161 сообщение;<br />
* KMyMoney2 (учёт финансов) – 1839 сообщений;<br />
* KDE – 140 тысяч сообщений<br />
<br />
И это всё – не считая документации. Одному человеку такое уже не под силу. Поэтому переводчики объединяются в команды, заводят список рассылки по обсуждению переводов, регистрируются в крупных проектах.<br />
<br />
В любой человеческой группе, чьи усилия направлены на достижения цели, требуется руководство и субординация. Команды перевода – не исключение. Каждый принимает на себя столько ответственности, сколь может потянуть. Типичная иерархия организации команды перевода состоит из:<br />
<br />
* руководитель команды (он отвечает за работу сайта, рассылки, взаимодействие с головным проектом и т.п.);<br />
* координаторы пакетов (люди, отвечающие за готовность перевода пакетов, включающих в себя несколько программ. Координаторы, как правило, имеют доступ на запись в репозиторий, проверяют переводы рядовых членов и выкладывают их в репозиторий);<br />
* ответственный за работу с новичками (в его зоне ответственности – разъяснение нюансов перевода, особенностей работы в команде и проверка );<br />
* рядовые члены.<br />
<br />
Несмотря на то, что текучка кадров на низовом уровне в открытых проектах очень сильная, костяк остаётся без изменения на протяжении нескольких лет. Для команд перевода GNOME и KDE это порядка десятка человек.<br />
<br />
== Взаимодействие команд ==<br />
Команды перевода разных проектов не могут существовать в информационной изоляции друг от друга. У нас есть общие проблемы:<br />
<br />
* составление единого глоссария для непротиворечивого перевода разных программ;<br />
* перевод трудных слов и оборотов<br />
* обмен готовыми переводами<br />
* единая типографика<br />
* обмен опытом и инструментарием<br />
<br />
Крупные переводчики подписаны на списки рассылки разных команд и активно участвуют в переводах вне рамок своей команды.<br />
<br />
Такая конвергенция позволяет облегчить работу локализатора свободного ПО. Да и благотворно сказывается на личных взаимоотношениях: нас ведь так мало и при разрозненности будет совсем ничтожное число. А так мне, переводчику KDE, приятно встретится вживую с переводчиками GNOME. Да и для работы полезно.<br />
<br />
Я являюсь координатором перевода пакета KOffice. Но прикладную область работы с графикой для приложения Krita знаю гораздо хуже, чем переводчик команды GNOME Александр Прокудин. И он внёс неоценимый вклад в перевод этого пакета. Так и я, будучи экономистом по образованию, участвовал в переводе калькулятора GNOME в части функций расчёта амортизации и прочих финансовых операций.<br />
<br />
Ещё одним интересным примером конвергенции является принятие проектами Mozilla, GNOME и KDE соглашения об обязательном использовании типографских кавычек-ёлочек в переводах, где должны использоваться двойные кавычки. Первопроходцами в этом начинании были мои коллеги из команды перевода GNOME. А после обращения к нам переводчиков Mozilla в середине марта этого года подобное решение было принято и у переводчиков KDE.<br />
<br />
== Нынешнее состояние локализации на русский язык ==<br />
Если крупные пакеты (типа GNOME, KDE, Mozilla, OpenOffice.org) переведены практически полностью, достаточно качественно и эти переводы поддерживаются в актуальном состоянии, то ситуация с небольшими проектами неважная. Одиночки пытаются перевести их, но желания поддерживать перевод не хватает. При обновлении программ переводы дробятся, их актуальность теряется. И эта реальная проблема требует решения, так как плохой или неполный перевод даже редкой программы может вызвать у пользователя разочарование в Linux в целом.<br />
<br />
Другой проблемой остаётся перевод документации. Во-первых, объём переводимых текстов возрастает в разы, во-вторых, требует от переводчика очень хорошего владения литературным русским, что в наше непростое время мата и жаргона весьма непросто.<br />
<br />
== Перспективы развития локализации ==<br />
Однако не всё так плохо. Для координации перевода, создания собственного единого глоссария и онлайнового портала по переводу был создан сайт [http://l10n.lrn.ru/ http://l10n.lrn.ru]. Этот ресурс весьма полезен новичкам, которые ещё не определились с командой, в который хотели бы принять участие, а на сайте можно найти самый актуальный на сегодня перечень команд с их координатами. Есть Wiki и форум, позволяющие фиксировать идеи и обмениваться мыслями. В команды приходят новые люди, а это наш главный ресурс.<br />
<br />
Совершенствуются инструменты. Недавно было объявлено, что Sun выпустит под открытой лицензией инструмент онлайновой локализации. Развиваются свободные приложения не только орфографической, но и грамматической проверки, что весьма актуально, так как литературных редакторов у нас крайне мало.<br />
<br />
Растёт количество языков, на которые переводятся свободные программы. Например, KDE на сегодня переведён на 91 язык мира, что '''в разы''' больше, чем количество поддерживаемых языков в коммерческих программах.<br />
<br />
В общем процесс локализации свободных программ как в мире, так и в России развивается и мы будем очень рады увидеть вас в наших рядах. Неважно, хотите ли вы постоянно участвовать в переводе, пришлёте одноразовый перевод или просто сообщили об опечатке – мы рады принять любую помощь.</div>77.121.217.121