Заметка о переводе - первая (технические средства)

Общим местом является использование юникода и системы gettext. В модулях OpenERP каждый модуль имеет подкаталог i18n (это сокращение для довольно длинного internationalization — по количеству букв — I18n). В этом каталоге располагается файл-шаблон эталона перевода с расширением .pot и национальные файлы с расширениями .po. Файл .pot создаётся отдельно после написания всех программ и подпрограмм модуля, вбирает в себя все строки программ подлежащие переводу и имеет не плоскую структуру. Это хорошо видно при его просмотре с помощью простого текстового редактора. Здесь и автор перевода и комментарии по каждой строке и возможные варианты перевода для числительных и…

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

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

Однако главное-то в том, что все строки перевода привязаны по месту в программах и подпрограммах модуля. В .po файле может быть несколько идентичных строк для перевода, но у них разные привязки. Из этого следует, что при обновлении в программах модуля строк кода Python (при добавлении или удалении), связи рвутся и образуются дыры в уже переведённом. Разработчики, как я понял, мало обращают внимание на это обстоятельство и обновления .pot файлов производятся только в момент новой версии.

Файлы .pot служат, как я уже сказал, шаблоном для национального файла перевода — например, ru.po

Инструмент для перевода удобнее всего, на мой взгляд, редактор poedit, он кроссплатформенный и имеется и в Linux и в Windows, хотя конечно есть и несколько других редакторов (тот же Emax). Сам .pot файл содержит только английский текст строк и пустые строки для перевода. Причём иногда строку правильнее называть позицией, потому как текст для перевода может быть весьма объёмным (например, лицензия GNU в файле для GTK клиента). Редактор poedit позволяет создать из .pot файла национальный .po файл, а также скорректировать .po файл по изменениям в .pot файле.

Из-за различной концовки текстовых строк в NIX и Windows приходится делать два варианта файлов перевода. Пакетное изменение не проходит в связи с содержанием в файлах служебной информации иногда совпадающей с символами конца строк. poedit в настройках позволяет задать вариант концовки строк.

По правилам Pythona на основе .po файлов должны автоматически создаваться транслированные (сжатые и более быстро работающие) файлы .mo, но я вижу это в единственном числе только в GTK клиенте.

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

Предлагаемая разработчиками система перевода от пользователей далеко не всегда работает по всему содержимому показываемого экрана и не может обеспечить полностью 100% перевод. Вдобавок безсистемные переводы от многих пользователей вносят сумятицу понятий в переводах.

Система Rosetta ориентирована на точечные исправления. И затрудняет действия при объёмном переводе.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

6 комментариев

avatar
я вообще первый раз о .pot файлах тут прочитал :) Я, чтобы переводить модули собственной разработки, просто захожу в Администрирование-Переводы-Импорт/Экспорт-Экспорт переводов. Там выбираю свой установленный модуль, и экспортирую файл ru.po, а в нем уже вручную в пустые строки переводов вписываю перевод
avatar
Файлы .pot рассчитаны на многоязычные системы.
Кстати, если вы в программах будете писать текстовку на русском, то продукт для русскоязычных будет работать быстрее, чем на других языках (а для английского придётся заводить файл перевода en.po).
avatar
Так это нормальная практика делать для своего модуля перевод на английский, а не на русский извращаясь и придумывая текст на английском в коде?
avatar
я думаю ответ здесь прост — делаешь модуль только для России — можно и на русском только. Если хочешь для всех расшаривать, то лучше оригинал на английском + русский файл перевода…
avatar
Коллеги не знаю как правильно, но где то в книге по OpenErp прочитал, что по умолчанию все модули имеют английскую основу, т.е. пишутся на английском и потом к ним идут фаилы перевода в папке i18n. К стати фаила en.po по этому и нет (я не нашел :)). И по своему опыту скажу что еслиделаете что то объемное то лучше писать на английском(потом сответствено добавить фаил перевода). Если что то еденичное и для себя то может и не надо заморачиваться :).
avatar
Не то чтобы мне было влом делать ru.po, иной раз я просто не могу придумать адекватное название на английском :(

Оставить комментарий