Лекция 9. Перевод и интернационализация

Если продукт большой и предназначен для разных языковых сред, то вопрос перевода становится актуальным. В прошлый раз Андрей Черепанов её прекрасно прочел -- координатор перевода кде, но на этот раз он сказал, что изменил свое мнение и перевод этим людям не нужен. Лектор из соображений попробовать все переводит несколько проектов, в частности блюфиш.

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

Зачем может понадобится вносить исправления в исходный код при адоптации к культурно-языковой среде. Перевод это только одна из подзадач. Дело в том, чтобы с получившимся продуктом стало работать удобнее. Это наша основаная идея -- вводить свойства не что бы они были, а чтобы пользовательские задачи лучше решались.

Перечислим задачи, возникающие в процессе адоптации.

  1. Текстовый перевод. Причины:
    1. Человек так устроен, что больщая часть гарантированного взаимодействия между ним и компьютером происходит через текст. Текст формализован, его можно вывалить много.
    2. Программы изначально писались рассчитывая на ввод и вывод текста. В линуксе целый класс продуктов, которые только этим и занимаются.
    3. Перевод это ресурсоемкий процесс. Но именно перевод сообщений программы, особенно просто новой версии программы может быть значительно проще.
    Встает вопрос. Вот у нас есть большая годная программа, в ней много интерфейсных штучек. Все ли кнопочки и менющечки надо переводить? Неизвестно. Можно вообразить ситуацию, когда текстовая строка не нуждается в переводе. Например, перевод на русский язык функций в экселе. Существуют сущности, перевод которых не требуется. Задача перевода осложняется выбором что переводить, а что нет.
  2. Планирование интерфейса и дизайн. Типичный пример -- языки с другим направлением письма. Типичный пример -- радиобаттон. При направлении райт-ту-лефт кнопочки должны быть справа. Ещё проблема -- размер текста может увеличиваться. Английский русский - 100 - 130. В руководстве по локализации для винапи написано -- делайте диалог такого размера, чтобы туда влез любой перевод, если переводы планируются. В дотнете это тоже не поправили. Так что иногда и такие глупости приходится учитывать
  3. Локаль надо переводить. Локаль это сборник культурных параметров -- даты, денежные единицы, единицы измерения. Всем известен формат представления таблицы цсв. Везде разделяются запятыми, а в русском точкой с запятой, потому что запятыми отделяется дробная часть числа.
  4. Звуки. И вообше всякая мультимедия.
  5. Картинки.
    1. На картинках может встречаться текст.
    2. На картинках могут встречаться культурные реалии страны изготовителя. Например, полуцилиндрическое красное ведро -- американский почтовый ящик. Или, например, ислам запрещает изображение людей и, кажется, даже животных. И так далее. Культурная аттрибуция очень много значит.
    3. Сочетание клавиш. Ctrl-X, Ctrl-Z. Нажимаете, а это Ctrl-Ч. Или редактируете текст в хтмле, а обозначение болда. Переводить или не переводить? Уж не говоря о иероглифическом письме. "Для выхода из программы наберите иероглиф недостаточно просвещённый человек"
    4. Шрифты. Со шрифтами три года назад было печально -- люди помнили, что такое шрифтовой дизайн, сколько на это надо времени, и не брались. Дизайн шрифта это примерно 3 человеко-года. К 2005 году правильных векторных шрифтов практически не было. Но потом сначала редхат начала делать либерейшн, потом появилось и развилось джву. Поэтому проблема не стоит так сильно, за несколькими исключениями
      1. Если вы хотите делать локализацию на язык, для которого нет начертания.
      2. Если вы пишите кроссплатформенное приложение -- не вздумайте измерять ширину чего либо в знакоместах, если шрифт не моноширный. Длина виджета, измеренная в количестве букв это издевательство над виджетом. Вы не сможете это проверить, если на целевом компьютере будет подстановка шрифтов.
      3. Ссылки на внешние ресурсы -- телефоны, урлы. "Приезжайте в Маунтайн-Вью, всё сделаем".

Итого, задачи на 90 процентов не разработческие. Технических задач всего три

  1. Унифицированность по локализациям
  2. Программная адаптация -- радиобаттоны ртл.
  3. Сделать удобства для разработки многоязыковой программы. Чтобы не надо было руками сообщения перевбивать и так далее.

Сопутствуюшие вещи из реального мира -- коробки, книжки, лицензия.

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

Лектор ещё помнит времена доса, когда был такой термин руссификация. Люди брали программы и заменяли английские буквы на русские. Удл вмето Del.

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

Попробуем по другому. Вместо "вывести строчку "Введите число"" написать "выведите ресурс 34583". В коде вообще не встречается диагностика на разумном языке, а только обращения к подсистеме локализации. Маразм удобен тем, что если мы надрессировали программистов, они вообще не думают над сообщениями и не занимаются литературным трудом. Зато когда вы читаете код, вы вообще не понимаете что там происходит.

Разбиваем задачу на две.

I18n -- internationalization

  1. Globalization g11n
  2. Localization l10n

Что из этого списка можно более менее оптимизировать.

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

  1. Если у вас есть книжка, и автор выпустил новое издание, то если автор много переписал, то переводчику много переводить. А вот что касается текстовых идентификатров внутри программы -- ситуация может быть лучше. Вряд ли вы переназвали все кнопки внутри программы. Вы могли переставить их местами, или удалить две вставить три, или некоторые переназвать. В любом случае, если есть готовый перевод, то обновление может потребовать меньше работы, чем обновление, скажем, перевода документации. Правда возникают соображения -- все ли текстовые сообшения надо переводить. Мало ли для чего может понадобится const char *. В постфиксе вон в начале каждой функции стоит её описание в строке. Как в питоне докстринг. Типичный пример. "Найдено 18 файлов". Какие проблемы? %d файл, файла, файлов. Словоформ и правил их образования разные количества. Это достаточно легко автоматизируется, но это надо предусмотреть.
  2. Достаточно легко оптимизировать определение размера виджетов, если об этом задуматься на уровне упаковки виджетов. Если библиотека виджетов задумывается о том, что ширина текстовой метки может быть разной. Но библиотека должна ументь размещать виджеты так, чтобы они друг на друга не наезжали. Gtk и QT это умеют. Можно конечно так надизайнить интерфейс, чтобы было неудобно, но во многих случаях задача решаема.
  3. Локаль. Библиотека, которая умеет выводить данные с текущей локалью.
  4. Полуавтоматический вывод картинок.

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

Когда в 2009-2010 догромыхивало внедрение линукса в школах, деньги разворовали, ничего не внедрили -- вышел дистрибутив, который предполагался обновлением предыдущего пспо -- пспо5. Этот самый пспо5, там было проделано много работы, Inkskape был заменен на Редактор Векторной Графики. И кроме того был переведен учебник по geany. Причем перевод был написан на хтмле. Печальная история.

Непрограммные проблемы. Поведение переводчиков. Перевод это не древнейшая, но древняя профессия - толмач. С серьезными традициями, в том числе и технических. Например серьезный переводчик всегда работает с translation manner??. Сборник уже переведенных предложений. Особенно важно когда ижет промышленный перевод технической документации. Там много текста с малым количеством параметров. К сожалению, страшно далеки они от народа и никто не думае при заточке перевода продукта о реальных переводчиках. Сейчас эта тенденция потихоньку меняется, но и интерес к переводу ослабевает. Информационная связность провоцирует единое информационное пространство с единым языком -- современной латынью, то есть упрощенным английским. Мотивация ослабевает, это видно по тому, какая команда переводила кде3 и какая кде4.

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

Хорошо ещё, если множества слов не пересекаются. Паттерны-шаблоны-темплейты.

Проблема словаря, не похоже чтобы она с энтузиазмом разрешалась сообществом. enc.com сводный компьютерный словарь. Тенденция у ослабеванию в области перевода наличествует.

Чтобы хорошо переводить внутренности программных продуктов, человек должен хорошо знать и пп, и русский. А таких мало. Поэтому как правило есть координатор, который знает и то, и то. И набор людей, которые знают что-то одно.

Пора переходить к примеру инструментария по переводу.

gettext

Нету падежных форм. С ними вообще все плохо.

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

Бонусы:

  1. Геттекстизация состоит в расставлении оберток.
  2. Вы можете взять и одним двидением руки с помощью xgettext вынуть все строки для перевода.
  3. Если в вашей программе внезапно выяснилось, что строки в разных местах содержат одинаковые значения, то вы это быстро обнаружите и сможете решить хорошо это или нет, а также дать единообразный перевод. Например, пункт меню "отфигачить".

Поддерживаются числовые словоформы в виде правил.

Fuzzy translation

Идет обновление программного продукта. Обновились поля, которые надо переводить. Обновились, но значимо ли? Кнопочка могла переехать из одного файла в другой. Привязка изменилась, а значение осталось тем же. Перевод мог измениться, а мог и не измениться. Есть мозг, который это отслеживает -- ищет похожие строки и сигнализирует о них. Мозг геттекста очень странный. Способность хранить фаззи переводы может работать как translation M. Вдруг удалили перевод, а он потом снова появится. Упрошается также процесс доработки локализации в новых версиях.

Msmegre.

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

Другие системы перевода. Уже было сказано, как это устроено в джаве, мозилле, андроиде -- есть идентификатор, по нему находятся строки. Без инструмента не разберешься, но есть и полезные свойства. К сожалению, в свободном софте встречаются и самопальные системы локализации. Люди очень любят в этой области изобретать велосипеды, возможно не представляя всего объема. Чаще всего это приводит к системам, похожим на мозилльные.

Qt linguist

gtranslator

Морды, которые представляют собою текстовый редактор по сообщениям с привязкой к исходным текстам.

Есть несколько средней успешности проектов, в частоноси pootle, для редактирования индексв. Фишка путл в том, что он поддерживает в качестве бэкендов нескоько систем локализации.

omega t -- инструмент для переводчиков. Традициионнно пользуются виндовом trans. Омега т хранит в стандартном формате, которым, правда никто не пользуется.

LecturesCMC/LinuxApplicationDevelopment2012/Conspects/09 (последним исправлял пользователь eSyr 2012-12-21 05:35:56)