Русский язык ровный по написанию и слова с заглавными буквами в середине предложения воспринимаются как крик. В английском это норма, но не нужно делать с этого кальку. Также неуместны обращения типа Вы, Вам и т.п. в середине предложения. Это верноподданичество и лизозадство. Я могу составить целую инструкцию по этому поводу. Одно из основных направлений здесь — увеличение пунктов шрифта с обычных 12 до 14 и даже 16. Недальновидному начальнику нравится обращение к нему в крупном виде; в добавок с годами зрение ухудшается…

Далее, русский перевод, в основном, на треть длиннее английского оригинала. Это приводит к тому, что интерфейс «плывёт» и не производит того впечатления, как в оригинале. Всегда нужно искать синонимы чтобы по максимуму вписаться в рамки оригинала и не поломать исходный интерфейс.

Международная и русская бухгалтерская лексика отличаются. Идут долгие разговоры о МСФО с её терминологией. У нас чуть ли не ГОСТом стала лексика 1С. Система сильно лоббируется и её отчёты обязательны для налоговой… Эта система начиналась с огульной русификации электронных таблиц типа SuperCalc и Exel. По началу русские макросы были довольно уродливы. Лексика 1С внедрялась годами и шла от сокращений пространных терминов в заголовках столбцов электронных таблиц. Отсюда бухгалтерские термины с несколькими заглавными буквами в словах. От этого, наверное, следует отходить и придерживаться лексики оригинала. 1С не догма и всё со временем меняется.

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

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

Часто употребляются динамически формируемые списки заключаемые в одиночные или в двойные квадратные скобки — списки и списки списков (как, например, в шаблонах писем рассылки. Здесь же часто используются шаблоны подстановки адресов и проч.)

Не стоит переводить булевы and, or, xor (в любом регистре) и выражения сравнения типа equal, not equal и т.п. Они скорее всего будут использованы в фильтрах поиска построенных на так называемых доменах (областях) — списках заключённых в квадратные скобки.

Составные вещи из слов разделённых точками или знаками подчёркивания переводить однозначно не стоит. Это скорее всего внутренние названия переменных, путей доступа и проч.

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

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

На основе некоторого опыта предлагаю серию своих заметок по переводу продукта на русский язык. В начальные времена Wndows перевод был коряв и более толковая работа получалась на английском. Но OpenERP никак не подходит к личному использованию, а вколачивать текущие данные и пользоваться результатами аналитики будут люди имевшие в школе по английскому 3 с — или вообще учившие немецкий или французский. Так что вопрос перевода весьма значимый.

Разработчики OpenERP весьма вольно подошли к использованию системы gettext и внесли в файлы переводов непереводимые куски динамически формируемых кодов условий и подстановок (например для массовых рассылок). Эти штуки называются доменами (областями) и заключаются в динамически, опять же, формируемые квадратные скобки.

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

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

По умолчанию у полей с типом many2many нет параметра ondelete, как у полей с типом many2one, который отвечает за то, что делать с элементом, который ссылается на другой элемент, если этот другой элемент удаляют.

У опции ondelete есть в таком случае два варианта:
cascade — удалять элемент при удалении родителя (не знаю как правильно назвать тот элемент, НА который ссылаются)
restrict — запрет удаления родительского элемента

Бывают случаи, когда для полей many2many тоже было бы неплохо использовать аналог опции ondelete=restrict. У меня как раз такой случай. Есть две модели — product.attribute и product.attribute.group, между которыми связь many2many.

Читать дальше →

Добро пожаловать в сообщество OpenERP-Russia!

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

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

Успех сообщества зависит от каждого из нас.