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

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

11 мая 2007 года

Автор: Андрей Черепанов <[email protected]>

Что такое локализация?

Интернационализация и локализация

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

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

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

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

Процесс адаптации называется интернационализацией.

Интернационализация (сокращённо i18n [от английского internationalization, i-дальше 18 букв-n]) – набор мероприятий, призванных сделать программный продукт готовым как для международного использования, так и для определённых целевых аудиторий. Готовность к международному использованию (world-readiness) лежит на плечах разработчиков и разделяется на две основные области: глобализацию (globalization) и готовность к локализации (localizability).

Глобализация – процесс разработки программ, архитектура и код которых не завязан на использование только с одним языком или локалью. Глобализованная программа должна поддерживать ввод, вывод на любом языке и обработку информации (например, сортировку или направление письма) по правилам этого языка. В этом определении мы столкнулись с важным термином: локаль – набор переменных программного окружения, указывающих на языковые, региональные и культурные предпочтения пользователя. Например, локаль ru_RU показывает, что пользователь ожидает что программы будут адаптированы на русский язык, использующийся в России (обозначение кодов регионов регламентируется международным стандартом ISO 3166.

Готовность к локализации – проектирование и реализация программных средств таким образом, чтобы локализация ПО на разные языки могла производиться без изменения исходного кода. Такая возможность позволяет распараллелить процесс разработки и собственно локализации.

Фактически разработчики на сегодня имеют готовую среду для создания ПО, готового к международному использованию. Проблему ввода и хранения помогла решить повсеместное использование Unicode как для внутренних кодовых страниц в ПО, так и как кодировки пользователя. Использование популярного средства интернационализации GNU gettext позволяет отделить процесс разработки от локализации и обеспечивает быструю адаптацию ПО на разные языки.

Локализация (сокращённо l10n [от английского localization, l-дальше 10 букв-n]) – перевод ПО и адаптация его к языковым и культурным особенностям определённой аудитории.

То есть интернационализация позволяет любому потенциальному пользователю ПО получить известный в мире продукт на его родном языке и учитывающий его культурные и языковые особенности. Например, пакет OpenOffice.org доступен на русском языке: то есть позволяет вводить и показывать кириллицу, имеет интерфейс и документацию на русском языке, поддерживает перенос слов, проверку орфографии, расстановку правильных кавычек и прочих символов пунктуации, традиционных для русской типографики, символы валюты, формат чисел, дат, времени и многое другое. Любой пользователь, садящийся за этот продукт, чувствует себя в родной языковой среде, хотя программу разрабатывали люди, даже совсем не говорящие на его родном языке.

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

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

Области применения

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

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

Размещение виджетов: К размещению виджетов в графическом интерфейсе предъявляется два основных требования: поддержка разных способов порядка виджетов, соответствующих письму (что особенно актуально для арабского и иврита, где порядок вывода осуществляется справа налево) и показ полных надписей в интерфейсе безотносительно от размеров виджетов. К счастью, как Qt, так и GTK+ поддерживают динамическое изменение размеров виджетов, чтобы вместить текст в них.

Графика и мультимедиа: Одной из основных заповедей разработчика, который хочет получить статус международного для своего творения, является следование культурно-нейтральным символам (помните пример про американский почтовый ящик?). В качестве нейтрального сейчас везде употребляют почтовый конверт, который понятен большинству людей в мире. Также следует избегать надписей на значках. К слову, у меня идёт переписка с разработчиками KMyMoney, которые умудрились вставить в значки своего приложения надпись «LOAN». В отличие от текстовых строк, производить локализацию графических элементов и мультимедиа много сложнее (с точки зрения усилий и жизненного цикла разработки и локализации).

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

Шрифты: Для большинства случаев проблема локализации решается использованием шрифтов с символами Unicode. Однако есть ряд случаев, когда общеупотребительные шрифты не поддерживают нужные символы. Например, для словарей с транскрипцией следует использовать шрифты, поддерживающие полный набор символов Unicode.

Документация: Кроме программ нужно переводить и документацию. Как правило, основная масса документации сегодня пишется в Docbook и существует средства локализации этого формата, о которых я расскажу чуть позже.

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

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

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 <[email protected]>\n"
"Language-Team: Russian <[email protected]>\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?». Помните, я говорил про культурные различия? В английском языке, употребляемом в компьютерных интерфейсах диалоговых окон фразы длинные, со всевозможными оборотами. В традициях интерфейса на русском же, фразы чёткие и короткие. Поэтому этот паровоз переводиться просто: «Удалить этот файл?».

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

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

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

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

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 язык мира, что в разы больше, чем количество поддерживаемых языков в коммерческих программах.

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