Заметка о переводе - первая (технические средства)
Общим местом является использование юникода и системы 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
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)
По большому счёту система 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
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)