Заметка о переводе - пятая (горячие клавиши)

Возможно вы обратили внимание на то, что в файлах .po в английских названиях пунктов меню присутствует символ подчёркивания. Причём в различных позициях английского слова (и в начале, и в середине слова, но не в конце). Это признак того, что следующий за ним символ будет выделен цветом или размером и будет использоваться в качестве «горячей» клавиши.
Я пока (до стабилизации перевода) эту возможность не использовал, поскольку очень легко получить пересечение и неоднозначность.
Но такая возможность есть и в будущем её нужно обязательно прикрутить.

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

Бизнес процессы и подход к OpenERP

Дорогие коллеги! С вашего разрешения немного добавлю свое мнение. Для пользователей действительно, какие либо разработки это просто темный лес. Я для примера сам пользователь в системе. По деятельности предприниматель. Т.е. скажу, что я не IT-ник, не программист. И что мне собственно нужно от OpenErp – результат. Результат моей предпринимательской работы.

Со старта – обозначу приоритеты моего спича :)

Сам столкнулся с подобными системами 4 года назад – надо было срочно выводить одну не большую компанию (фирму) по рекламным услугам из долгосрочного коллапса. Проблемы классические для любой деятельности. Плохая организация работ, отсутствие понятных бизнес процессов, смутные ориентиры и приоритеты в действиях сотрудников. Дезорганизация начиная от соучредителя – соответственно неадекватного давление на администрацию и что уж там говорить о штатных сотрудниках, все понимают что нужно зарабатывать деньги – бегают или топчутся на месте связывая себя все больше и больше. И так вывод – нужна система, которая сможет: Организовать, Систематизировать, Расставить приоритеты, Обозначить основные бизнес процессы(для начала) – и направить весь рабочий коллектив на видимый и доступный результат.


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

Заметка о переводе - четвёртая (локализация)

В OpenERP отдельным блоком идут модули локализации (l10n -сокращение от localization по количеству букв). В этих модулях представлены конкретные национальные планы счетов, планы налогов и шаблоны узаконенной отчётности. В продвинутых случаях для страны имеется несколько таких модулей.

Планы счетов забить с их подсчетами на основе узаконенных документов довольно просто и не надо делать из этого проблему. Это вопрос физического времени и квалификации. Вопрос с формами отчётности сложнее… Наше законодательство в процессе совершенствования и формы отчётности в постоянном изменении — нужна централизованная поддержка этих изысков законодательства.

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

Заметка о переводе - третья (стиль перевода)

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

Предлагаю заметки по русификации OpenERP

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

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

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

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