Локализация свободного ПО (лекция)

Локализация свободного ПО

Лекция в Московском государственном университете

11 мая 2007 года

Автор: Андрей Черепанов <cas@altlinux.ru>

Very nice post, good luck! ;-)

Механизмы локализации в свободном ПО

GNU gettext

Описание пакета

На сегодня самым распространённым средством локализации свободного ПО является GNU gettext. Это программное обеспечение предоставляет разработчикам, переводчикам и даже простым пользователям интегрированные средства и документацию по локализации приложений. С точки зрения методологии gettext предоставляет:

• набор соглашений о том, что должна использовать программа, поддерживающая каталоги сообщений;
• формализацию именования каталогов и файлов каталогов сообщений.

Библиотека gettext предоставляет механизмы подключения каталогов сообщений и получения строк, переведённых в соответствии с локалью.

Процесс создания ПО, готового к локализации и впоследствии локализованного выглядит следующим образом:

1. Разработчик заботиться о том, чтобы все текстовые строки, которые будут выводиться в программе (например, названия пунктов меню, подсказки, надписи в диалогах и т.п.) «оборачиваются» в вызовы функций gettext() и ngettext() библиотеки libintl. Как правило, такие вызовы для упрощения оформляются макросами «_()» и «N_()». В KDE, к примеру, строки «оборачиваются в вызовы i18n().

Перед вызовом функций локализации загружаются каталог сообщений вызовом функции textdomain().

2. Разработчик использует программу xgettext для поиска всех вызовов функций gettext() и ngettext() и формирования шаблона каталога сообщений. Обычно эти файлы имеют расширение .pot.

3. Локализатор на базе шаблона создаёт или обновляет каталог сообщений, содержащий готовые переводы. Файлы каталогов, как правило, сообщений имеют расширение .po.

4. Каталог сообщений направляется разработчику или сборщику пакета и на этапе сборки компилируется программой msgfmt в бинарный файл с расширением .mo, который размещается в обычное место для файлов локализации. В подавляющем большинстве случаев это каталог /usr/share/locale/<код языка>/LC_MESSAGES/.

Во время работы программы бинарный файл каталога сообщений подгружается и каждый вызов функций локализации возвращает перевод оригинальной строки.

Содержимое файла каталога сообщений

Шаблон каталога сообщений (.pot) и исходный код каталога сообщений (.po) являются обычными тестовыми файлами (как обычно в традициях UNIX), состоящими из строк комментариев, строк оригинальных сообщений и строк перевода сообщений.

Комментарии начинаются с символа «#» и идут до конца строки.

Строка оригинального сообщения начинается с ключевого слова msgid в начале строки и одной или нескольких строк в кавычках ("). Перевод сообщения идёт после msgid и начинается с ключевого слова msgstr (в начале строки), за которым следует одна или несколько строк в кавычках ("). Количество строк msgid и msgstr должно быть одинаково.

Первая строка msgid всегда пустая, а в msgstr содержит служебную информацию о файле:

msgid ""
msgstr ""
"Project-Id-Version: kig\n"
"POT-Creation-Date: 2006-12-11 02:43+0100\n"
"PO-Revision-Date: 2007-01-12 11:04+0300\n"
"Last-Translator: Andrey Cherepanov <sibskull@mail.ru>\n"
"Language-Team: Russian <kde-russian@lists.kde.ru>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>"
"=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

В заголовке указываются название программы, даты создания шаблона и последних изменений перевода, последний переводчик, команда локализации, кодировка и прочие сведения.

Практические все современные программы используют Unicode для работы со строками, поэтому используется кодировка по умолчанию UTF-8. Для приложений KDE и GNOME указание любой другой кодировки является ошибкой.

Использование текстового формата заметно упрощает работы с этими файлами: к вашим услугам весь богатейший арсенал обработки текста UNIX с историей в несколько десятилетий. Весьма просто автоматизировать работу из скриптов Perl и Python для нетривиальных задач.

Особенность работы с каталогами сообщений

Помимо упомянутых программ xgettext и msgfmt, существует ряд инструментов для работы с каталогами сообщений. Из основных стоит отметить программу msgmerge, которая позволяет объединять новый шаблон и старые переводы. Например, разработчик изменил ряд строк в программе и добавил новые, а у вас есть каталог сообщений с переводом для старой версии. Не беда: запустите msgmerge <старый файл с переводом> <новый шаблон> > <новый файл с переводом> и получите обновлённый файл с переводом. Программа сверит перевод и шаблон и отметит новые строки. Если найдены похожие строки, которые были переведены, но незначительно исправлены, они помечаются как черновые (fuzzy).

Пометка строк как черновых является весьма интересной особенностью gettext. В файле они отмечаются как комментарий вида #, fuzzy перед строкой msgid. После компиляции программа игнорирует этот перевод и выводит оригинальное сообщение, однако переводчики могут оставить эти строки для перевода в будущем, не опасаясь за потерю идей по переводу.

Ещё одной интересной особенностью gettext является использование множественных форм (plural forms). Этот механизм позволяет на основании заданного числа, который указывается в параметрах функции ngettext() сформировать правильную строку с количеством с учётом языковых особенностей, избавив пользователя от ужасных «... файл(ов)». Если для английского языка множественных форм насчитывается две (1 и всё остальное), то для русского – три (заканчивающиеся на 1, на 2,3,4 и все остальные).

Кроме того, в сообщениях gettext можно указывать символы подстановки, которые на этапе поиска перевода будут заменены на передаваемые значения аргументов, которые переводить не нужно (например, имена файлов).

Стоит отметить, что компиляция в бинарные файлы .mo не являются необратимой операцией. Из такого файла можно получить исходный каталог сообщений командой msgunfmt.

Альтернативные механизмы

Помимо gettext существуют и альтернативные механизмы локализации программного обеспечения. Мы рассмотрим реализации локализации для некоторых приложений под Linux и Microsoft Windows.

Mozilla и OpenOffice.org

Проект OpenOffice.org использует для локализации механизм файлов ресурсов, как в Microsoft Windows.

Приложения Mozilla основаны на диалекте XML XUL, поэтому локализация их осуществляется посредством упакованных в файл .jar DTD с переводами сущностей и текстовых файлов с переводом свойств по идентификаторам.

Эти механизмы локализации не получили широкого распространения в силу их негибкости и неудобства для переводчиков. К слову, большинство CMS также используют локализацию строк по идентификатору.

Trolltech Qt

Если приложения KDE используют механизм gettext, то остальные приложения, использующие библиотеку Trolltech Qt, используют стандартный для этой библиотеки механизм локализации через вызовы метода tr(). Сообщения сохраняются в текстовых файлах c расширением .ts, которые предоставляют собой файлы формата XML, содержащие информацию о контексте, оригинальные сообщения и их переводы. Также, как и для gettext, есть программы работы с сообщениями файлов lupdate и lrelease и удобная графическая программа локализации Qt Linguist.

Microsoft Windows

Изначально локализация приложений Microsoft Windows осуществлялась как перевод строк из файлов ресурсов. К сожалению, использование не оригинальных строк, а их идентификаторов, усложняют процесс поиска контекста. Кроме этого отсутствуют механизмы пометки переводов как черновых. Неудивительно, что локализованных приложений Windows не так уж и много, а локализованные версии выходят гораздо позднее оригиналов. Ранее ресурсы программы распространялись в исполнимом файле, но сейчас механизм MUI позволяет легко распространять локализацию в среде Windows.

Помимо неудобства работы с файлами ресурсов, в Windows до сих пор не решена проблема с динамическим размещением виджетов в диалогах. В Linux – никаких проблем: и Qt и GTK+ во время исполнения выравнивают элементы в зависимости от текста. Разработчикам Windows рекомендуют оставить между надписью и, к примеру, полем ввода достаточное место, чтобы вместить любой перевод. Теперь вы поняли, почему в диалогах Windows так много пустого места и такие длинные кнопки?

К счастью, процесс локализации в Windows с переходом на .NET стал гораздо проще и фактически напоминает gettext. Метод String.Format позволяет указывать в качестве идентификатора оригинальную строку.

Ещё одним серьёзнейшим недостатком локализации Microsoft Windows является полное отсутствие механизма множественных форм. При показе количества элементов в строке состояния удалении вместо ожидаемого (и реализованного в KDE и GNOME «3 элемента» вы увидите режущее русский слух «Элементов: 3». Это не переводчики плохие, это ограничения механизма локализации Windows.

Локализация документации

Механизм gettext показал свою жизнеспособность не только для локализации кода, но и оказался подходящим для локализации документации. К примеру, командой KDE были подготовлены две программы: xml2pot и po2xml, которые позволяют преобразовать весь текст из файла формата Docbook в шаблон каталога сообщений gettext и затем получить переведённый Docbook на базе оригинального файла и каталога сообщений с переводом. Так как Dockbook в современном Linux используется как стандарт документации практически всех современных приложений, этот механизм можно использовать и для локализации документации многих программ.

Локализация стандартного формата документации UNIX man осуществляются по старинке – построчным переводом оригинальных файлов с сохранением управляющих символов. Скорее всего это вызвано редким изменением текста в этих файлах и малым объёмом документации. Собранные файлы размещаются в подкаталогах /usr/share/man с кодом языка с сохранением оригинальной структуры подкаталогов man.

Инструментарий локализатора

Для того, чтобы правильно, быстро и непротиворечиво локализовывать ПО мало знаний языка и опыта работы. Существует ряд методологий, которые помогают осуществить качественный перевод.

Наиболее известна методология «памяти переводов» (translation memory). Она заключается в составлении единого глоссария переводов по определённой тематике (или вообще переводам программ в целом) и жёстком следовании ему. Подобные усилия позволяют унифицировать перевод, использовать одинаковые термины и ускорить сам процесс перевода.

Также переводчику необходима проверка орфографии, чтобы избежать банальных опечаток в переведённом тексте.

Для пакетной проверки каталогов сообщений формата gettext (проверка аргументов, множественных форм, пунктуации, длины сообщения и т.п.) полезно использовать gettext-lint.

Хотя каталоги сообщений gettext можно переводить и в обычном текстовом редакторе (кстати, популярные текстовые редакторы поддерживают как подсветку, так и режимы работы с файлами .po), гораздо удобнее делать это в специализированных инструментах. Безусловным фаворитом в этом направлении является KBabel, приложение локализации, входящее в пакет kdesdk проекта KDE. В нём поддерживаются как компоновка «оригинальное сообщение-перевод», так и редактируемый список сообщений. Также KBabel поддерживает проверку правильности локализации (от проверки орфографии «на лету» до тестов на аргументы, длину и прочие), словари «памяти переводчика» (в том числе и может их формировать самостоятельно на базе существующих переводов), менеджер каталогов сообщений, показывающий статистику по нескольким файлам, выбор символов Unicode и многое другое. Помимо файлов gettext поддерживаются файлы локализации Qt.

Кроме KBabel используется альтернативный инструмент gtranslator (под GNOME) и poedit (бесплатно распространяемый редактор файлов .po под Windows).

Помимо редакторов файлов локализации потребуются словари «памяти переводчика» и обычные двуязычные словари (например, тот же StarDict). Крайне важным для локализации специализированных программ является наличие материалов по предметной области или доступ в Интернет.

Средства онлайновой локализации

При правильной постановке организации локализация может эффективно производиться в рамках совместной работы. Если локальные переводы подталкивают к организации процесса «один файл – один переводчик», то создание средств онлайнового перевода позволило одновременно работать над файлами нескольким переводчикам.

Из известных на сегодня средств онлайновой локализации ПО наиболее известна Rosetta, используемая для локализации Ubuntu. Кстати, средство это проприетарное. Однако есть и свободные аналоги. Например, проект Pootle, разрабатываемый в рамках Debian. Однако он так и не снискал популярности.

У онлайновой локализации помимо очевидных достоинств: совместной работы, автоматического глоссария, возможности работы из любого места (достаточно только браузера) и рецензирования есть ряд недостатков.

Основных недостатков у онлайновых средств локализации два:

1. С точки зрения проверки локализации можно рассчитывать только на средства, предоставляемые порталом. В случае с локальной локализацией вы можете быстро найти или обработать файлы самостоятельно. В качестве примера можно привести приведение единиц объёма информации к стандарту в переводах KDE. Было написано хитрое регулярное выражение, вычисляющее потенциальные ошибки в переводах и также быстро эти переводы были исправлены.

2. Доступность локализации для широких масс привело к резкому увеличению числа тех, кто перевёл пару сообщений, не обременив себя чтением глоссария, сверкой консистентности переводов и прочими буднями опытных локализаторов. Это привело к появлению разношёрстных переводов, которые не захотели проверить опытные переводчики и, как следствие, к падению качества перевода в целом.

Кроме средств перевода есть порталы, посвящённые только раздаче файлов для перевода. Как правило, они формируются вокруг репозиториев крупных проектов: http://i18n.kde.org и http://l10n.gnome.org/. На таких сайтах можно посмотреть статистику по командам перевода, отдельным пакетам или файлам и скачать файл для локального перевода.

Организация процесса локализации

Помощь сообществу

Свободное ПО позволяет любому человеку получить все необходимые материалы и инструменты для перевода. Неудивительно, что свободное ПО переводится на языки, поддержку которых в коммерческом ПО мы никогда не увидим. Например, цыганский или баскский.

Как и разработка свободного ПО, его локализация требует стойкого желания заниматься этим. Как правило, ничего не получая в материальном плане. Мы, локализаторы на русский язык, увы, не можем претендовать на финансовую помощь, как к примеру в Эстонии, где локализация свободного ПО финансируется государством (и это видно по завершённости перевода KDE на соответствующем сайте). Поэтому любители быстрых денег у нас не задерживаются. В целом это неплохо, так как не возникает расхождений и обид по финансовым вопросам. И опытные переводчики и новички находятся в равных условиях.

Вы можете спросить – так зачем же переводить, если вам никто не платит денег? Отвечу на этот вопрос. OpenSource – это эгоизм в чистом виде. Любые усилия, прикладываемые для развития проекта, будь его разработка, документирование, поддержка, локализация или пиар мотивируются желанием сделать или адаптировать продукт для себя, любимого. Любовь к себе сильнее жажды денег. Именно поэтому феномен свободного ПО оказался жизнеспособен и устойчив в развитии.

Поэтому основная причина, по которой я занимаюсь локализацией, является желание видеть любимое ПО под Linux на грамотном великом и могучем русском языке. Конечно, есть и благодарственные отзывы пользователей, но они относятся к утешению честолюбия и не являются главным мотивирующим фактором.

Кстати, при успешном занятии переводами тренируется знание как иностранного, так и родного языка, память. После такой практики вы можете сменить работу и устроиться переводчиком.

Вопреки бытующему мнению, для локализации совсем необязательно идеально знать язык оригинала. Качества, незаменимые для профессионального перевода: внимательность и хорошее знание родного языка. Текстовая информация должна быть по возможности краткой, но понятной. Классическим примером является перевод фразы «Do you really want to delete this file?». Помните, я говорил про культурные различия? В английском языке, употребляемом в компьютерных интерфейсах диалоговых окон фразы длинные, со всевозможными оборотами. В традициях интерфейса на русском же, фразы чёткие и короткие. Поэтому этот паровоз переводиться просто: «Удалить этот файл?».

Что вам нужно, если вы решили помочь в локализации какой-либо свободной программы (помимо желания, разумеется)?

1. Взять файл для перевода из распространяемого пакета или репозитория
2. Перевести и проверить в работе
3. Отправить в репозиторий или разработчику

Команды локализации

Чем больше проект, тем больший объём переводов требуется для него. Сравните, к примеру,

• kbfx (альтернативное меню KDE) – 161 сообщение;
• KMyMoney2 (учёт финансов) – 1839 сообщений;
• KDE – 140 тысяч сообщений

И это всё – не считая документации. Одному человеку такое уже не под силу. Поэтому переводчики объединяются в команды, заводят список рассылки по обсуждению переводов, регистрируются в крупных проектах.

В любой человеческой группе, чьи усилия направлены на достижения цели, требуется руководство и субординация. Команды перевода – не исключение. Каждый принимает на себя столько ответственности, сколь может потянуть. Типичная иерархия организации команды перевода состоит из:

• руководитель команды (он отвечает за работу сайта, рассылки, взаимодействие с головным проектом и т.п.);
• координаторы пакетов (люди, отвечающие за готовность перевода пакетов, включающих в себя несколько программ. Координаторы, как правило, имеют доступ на запись в репозиторий, проверяют переводы рядовых членов и выкладывают их в репозиторий);
• ответственный за работу с новичками (в его зоне ответственности – разъяснение нюансов перевода, особенностей работы в команде и проверка );
• рядовые члены.

Несмотря на то, что текучка кадров на низовом уровне в открытых проектах очень сильная, костяк остаётся без изменения на протяжении нескольких лет. Для команд перевода GNOME и KDE это порядка десятка человек.

Взаимодействие команд

Команды перевода разных проектов не могут существовать в информационной изоляции друг от друга. У нас есть общие проблемы:

• составление единого глоссария для непротиворечивого перевода разных программ;
• перевод трудных слов и оборотов
• обмен готовыми переводами
• единая типографика
• обмен опытом и инструментарием

Крупные переводчики подписаны на списки рассылки разных команд и активно участвуют в переводах вне рамок своей команды.

Такая конвергенция позволяет облегчить работу локализатора свободного ПО. Да и благотворно сказывается на личных взаимоотношениях: нас ведь так мало и при разрозненности будет совсем ничтожное число. А так мне, переводчику KDE, приятно встретится вживую с переводчиками GNOME. Да и для работы полезно.

Я являюсь координатором перевода пакета KOffice. Но прикладную область работы с графикой для приложения Krita знаю гораздо хуже, чем переводчик команды GNOME Александр Прокудин. И он внёс неоценимый вклад в перевод этого пакета. Так и я, будучи экономистом по образованию, участвовал в переводе калькулятора GNOME в части функций расчёта амортизации и прочих финансовых операций.

Ещё одним интересным примером конвергенции является принятие проектами Mozilla, GNOME и KDE соглашения об обязательном использовании типографских кавычек-ёлочек в переводах, где должны использоваться двойные кавычки. Первопроходцами в этом начинании были мои коллеги из команды перевода GNOME. А после обращения к нам переводчиков Mozilla в середине марта этого года подобное решение было принято и у переводчиков KDE.

Нынешнее состояние локализации на русский язык

Если крупные пакеты (типа GNOME, KDE, Mozilla, OpenOffice.org) переведены практически полностью, достаточно качественно и эти переводы поддерживаются в актуальном состоянии, то ситуация с небольшими проектами неважная. Одиночки пытаются перевести их, но желания поддерживать перевод не хватает. При обновлении программ переводы дробятся, их актуальность теряется. И эта реальная проблема требует решения, так как плохой или неполный перевод даже редкой программы может вызвать у пользователя разочарование в Linux в целом.

Другой проблемой остаётся перевод документации. Во-первых, объём переводимых текстов возрастает в разы, во-вторых, требует от переводчика очень хорошего владения литературным русским, что в наше непростое время мата и жаргона весьма непросто.

Перспективы развития локализации

Однако не всё так плохо. Для координации перевода, создания собственного единого глоссария и онлайнового портала по переводу был создан сайт http://l10n.lrn.ru. Этот ресурс весьма полезен новичкам, которые ещё не определились с командой, в который хотели бы принять участие, а на сайте можно найти самый актуальный на сегодня перечень команд с их координатами. Есть Wiki и форум, позволяющие фиксировать идеи и обмениваться мыслями. В команды приходят новые люди, а это наш главный ресурс.

Совершенствуются инструменты. Недавно было объявлено, что Sun выпустит под открытой лицензией инструмент онлайновой локализации. Развиваются свободные приложения не только орфографической, но и грамматической проверки, что весьма актуально, так как литературных редакторов у нас крайне мало.

Растёт количество языков, на которые переводятся свободные программы. Например, KDE на сегодня переведён на 91 язык мира, что в разы больше, чем количество поддерживаемых языков в коммерческих программах.

В общем процесс локализации свободных программ как в мире, так и в России развивается и мы будем очень рады увидеть вас в наших рядах. Неважно, хотите ли вы постоянно участвовать в переводе, пришлёте одноразовый перевод или просто сообщили об опечатке – мы рады принять любую помощь.