Лекция 9. Перевод и интернационализация
Если продукт большой и предназначен для разных языковых сред, то вопрос перевода становится актуальным. В прошлый раз Андрей Черепанов её прекрасно прочел -- координатор перевода кде, но на этот раз он сказал, что изменил свое мнение и перевод этим людям не нужен. Лектор из соображений попробовать все переводит несколько проектов, в частности блюфиш.
Некоторые считают, что чтобы адоптировать английскую программу для русского рынка достаточно перевести все сообщения на русский язык.
Зачем может понадобится вносить исправления в исходный код при адоптации к культурно-языковой среде. Перевод это только одна из подзадач. Дело в том, чтобы с получившимся продуктом стало работать удобнее. Это наша основаная идея -- вводить свойства не что бы они были, а чтобы пользовательские задачи лучше решались.
Перечислим задачи, возникающие в процессе адоптации.
- Текстовый перевод. Причины:
- Человек так устроен, что больщая часть гарантированного взаимодействия между ним и компьютером происходит через текст. Текст формализован, его можно вывалить много.
- Программы изначально писались рассчитывая на ввод и вывод текста. В линуксе целый класс продуктов, которые только этим и занимаются.
- Перевод это ресурсоемкий процесс. Но именно перевод сообщений программы, особенно просто новой версии программы может быть значительно проще.
- Планирование интерфейса и дизайн. Типичный пример -- языки с другим направлением письма. Типичный пример -- радиобаттон. При направлении райт-ту-лефт кнопочки должны быть справа. Ещё проблема -- размер текста может увеличиваться. Английский русский - 100 - 130. В руководстве по локализации для винапи написано -- делайте диалог такого размера, чтобы туда влез любой перевод, если переводы планируются. В дотнете это тоже не поправили. Так что иногда и такие глупости приходится учитывать
- Локаль надо переводить. Локаль это сборник культурных параметров -- даты, денежные единицы, единицы измерения. Всем известен формат представления таблицы цсв. Везде разделяются запятыми, а в русском точкой с запятой, потому что запятыми отделяется дробная часть числа.
- Звуки. И вообше всякая мультимедия.
- Картинки.
- На картинках может встречаться текст.
- На картинках могут встречаться культурные реалии страны изготовителя. Например, полуцилиндрическое красное ведро -- американский почтовый ящик. Или, например, ислам запрещает изображение людей и, кажется, даже животных. И так далее. Культурная аттрибуция очень много значит.
- Сочетание клавиш. Ctrl-X, Ctrl-Z. Нажимаете, а это Ctrl-Ч. Или редактируете текст в хтмле, а обозначение болда. Переводить или не переводить? Уж не говоря о иероглифическом письме. "Для выхода из программы наберите иероглиф недостаточно просвещённый человек"
- Шрифты. Со шрифтами три года назад было печально -- люди помнили, что такое шрифтовой дизайн, сколько на это надо времени, и не брались. Дизайн шрифта это примерно 3 человеко-года. К 2005 году правильных векторных шрифтов практически не было. Но потом сначала редхат начала делать либерейшн, потом появилось и развилось джву. Поэтому проблема не стоит так сильно, за несколькими исключениями
- Если вы хотите делать локализацию на язык, для которого нет начертания.
- Если вы пишите кроссплатформенное приложение -- не вздумайте измерять ширину чего либо в знакоместах, если шрифт не моноширный. Длина виджета, измеренная в количестве букв это издевательство над виджетом. Вы не сможете это проверить, если на целевом компьютере будет подстановка шрифтов.
- Ссылки на внешние ресурсы -- телефоны, урлы. "Приезжайте в Маунтайн-Вью, всё сделаем".
Итого, задачи на 90 процентов не разработческие. Технических задач всего три
- Унифицированность по локализациям
- Программная адаптация -- радиобаттоны ртл.
- Сделать удобства для разработки многоязыковой программы. Чтобы не надо было руками сообщения перевбивать и так далее.
Сопутствуюшие вещи из реального мира -- коробки, книжки, лицензия.
Английское длинное тире. Типографика это жуть с ружьем, она в каждой стране своя. В цифровом контенте чаще всего типографика американская. Кавычки, заваленные интегралы, знаки больше-равно.
Лектор ещё помнит времена доса, когда был такой термин руссификация. Люди брали программы и заменяли английские буквы на русские. Удл вмето Del.
У нас свободное ПО, есть код. Мы можем скопировать код в отдельную папочку и в ней заменить сообшения на русские. Правда, попробуйте потом выпустить вторую, третью, десятую версию программы.
Попробуем по другому. Вместо "вывести строчку "Введите число"" написать "выведите ресурс 34583". В коде вообще не встречается диагностика на разумном языке, а только обращения к подсистеме локализации. Маразм удобен тем, что если мы надрессировали программистов, они вообще не думают над сообщениями и не занимаются литературным трудом. Зато когда вы читаете код, вы вообще не понимаете что там происходит.
Разбиваем задачу на две.
I18n -- internationalization
- Globalization g11n
- Localization l10n
Что из этого списка можно более менее оптимизировать.
Взяли и провели глобализацию -- для каждого ресурса вместо обращения напрямую сделали косвенное. Оптимизировать можно текстовый перевод. С текстовым переводом есть несколько забавных клауз.
- Если у вас есть книжка, и автор выпустил новое издание, то если автор много переписал, то переводчику много переводить. А вот что касается текстовых идентификатров внутри программы -- ситуация может быть лучше. Вряд ли вы переназвали все кнопки внутри программы. Вы могли переставить их местами, или удалить две вставить три, или некоторые переназвать. В любом случае, если есть готовый перевод, то обновление может потребовать меньше работы, чем обновление, скажем, перевода документации. Правда возникают соображения -- все ли текстовые сообшения надо переводить. Мало ли для чего может понадобится const char *. В постфиксе вон в начале каждой функции стоит её описание в строке. Как в питоне докстринг. Типичный пример. "Найдено 18 файлов". Какие проблемы? %d файл, файла, файлов. Словоформ и правил их образования разные количества. Это достаточно легко автоматизируется, но это надо предусмотреть.
- Достаточно легко оптимизировать определение размера виджетов, если об этом задуматься на уровне упаковки виджетов. Если библиотека виджетов задумывается о том, что ширина текстовой метки может быть разной. Но библиотека должна ументь размещать виджеты так, чтобы они друг на друга не наезжали. Gtk и QT это умеют. Можно конечно так надизайнить интерфейс, чтобы было неудобно, но во многих случаях задача решаема.
- Локаль. Библиотека, которая умеет выводить данные с текущей локалью.
- Полуавтоматический вывод картинок.
Перевод -- гораздо более ресурсоемкое занятие. Код модифицируется, а перевод пишется заново. Книжки, сопроводительная документация, учебники. В отличие от программирования, которая суть веши поступательные, перевод это стрельба по движущейся мишени. Хороший пример редактор geany. Небольшой, хорошая документация, и есть учебник на английском.
Когда в 2009-2010 догромыхивало внедрение линукса в школах, деньги разворовали, ничего не внедрили -- вышел дистрибутив, который предполагался обновлением предыдущего пспо -- пспо5. Этот самый пспо5, там было проделано много работы, Inkskape был заменен на Редактор Векторной Графики. И кроме того был переведен учебник по geany. Причем перевод был написан на хтмле. Печальная история.
Непрограммные проблемы. Поведение переводчиков. Перевод это не древнейшая, но древняя профессия - толмач. С серьезными традициями, в том числе и технических. Например серьезный переводчик всегда работает с translation manner??. Сборник уже переведенных предложений. Особенно важно когда ижет промышленный перевод технической документации. Там много текста с малым количеством параметров. К сожалению, страшно далеки они от народа и никто не думае при заточке перевода продукта о реальных переводчиках. Сейчас эта тенденция потихоньку меняется, но и интерес к переводу ослабевает. Информационная связность провоцирует единое информационное пространство с единым языком -- современной латынью, то есть упрощенным английским. Мотивация ослабевает, это видно по тому, какая команда переводила кде3 и какая кде4.
Проблема в том, что среди оставшегося меньшинства идет священная война о том, как это должно переводиться. Например война папок, каталогов и директорий. Сейчас папки победили в силу массовости, несмотря на их странность для технически приближенных людей.
Хорошо ещё, если множества слов не пересекаются. Паттерны-шаблоны-темплейты.
Проблема словаря, не похоже чтобы она с энтузиазмом разрешалась сообществом. enc.com сводный компьютерный словарь. Тенденция у ослабеванию в области перевода наличествует.
Чтобы хорошо переводить внутренности программных продуктов, человек должен хорошо знать и пп, и русский. А таких мало. Поэтому как правило есть координатор, который знает и то, и то. И набор людей, которые знают что-то одно.
Пора переходить к примеру инструментария по переводу.
gettext
Нету падежных форм. С ними вообще все плохо.
Главный принцип -- написана неглобализованная программа. В ней есть строки. Строки являются идентификаторами второго уровня вложенности. \
Бонусы:
- Геттекстизация состоит в расставлении оберток.
- Вы можете взять и одним двидением руки с помощью xgettext вынуть все строки для перевода.
- Если в вашей программе внезапно выяснилось, что строки в разных местах содержат одинаковые значения, то вы это быстро обнаружите и сможете решить хорошо это или нет, а также дать единообразный перевод. Например, пункт меню "отфигачить".
Поддерживаются числовые словоформы в виде правил.
Fuzzy translation
Идет обновление программного продукта. Обновились поля, которые надо переводить. Обновились, но значимо ли? Кнопочка могла переехать из одного файла в другой. Привязка изменилась, а значение осталось тем же. Перевод мог измениться, а мог и не измениться. Есть мозг, который это отслеживает -- ищет похожие строки и сигнализирует о них. Мозг геттекста очень странный. Способность хранить фаззи переводы может работать как translation M. Вдруг удалили перевод, а он потом снова появится. Упрошается также процесс доработки локализации в новых версиях.
Msmegre.
Главный недостаток -- файл должен лежать в опеределенном месте, и если у вас много программ с одинаковым именем, надо позаботиться чтобы файлы лежали в разных местах. Поэтому большие проекты руками перебивают место, где лежит мо-файл.
Другие системы перевода. Уже было сказано, как это устроено в джаве, мозилле, андроиде -- есть идентификатор, по нему находятся строки. Без инструмента не разберешься, но есть и полезные свойства. К сожалению, в свободном софте встречаются и самопальные системы локализации. Люди очень любят в этой области изобретать велосипеды, возможно не представляя всего объема. Чаще всего это приводит к системам, похожим на мозилльные.
Qt linguist
gtranslator
Морды, которые представляют собою текстовый редактор по сообщениям с привязкой к исходным текстам.
Есть несколько средней успешности проектов, в частоноси pootle, для редактирования индексв. Фишка путл в том, что он поддерживает в качестве бэкендов нескоько систем локализации.
omega t -- инструмент для переводчиков. Традициионнно пользуются виндовом trans. Омега т хранит в стандартном формате, которым, правда никто не пользуется.