You are here: Foswiki>Gnumed Web>BackendI18NRu (12 Mar 2013, IvanLykov)EditAttach

Управление i18n/l10n в бэкэнде

Обоснование

Многие таблицы в GNUmed хранять перечисления, подобные типам документа. Для пользователей в Германии необычно видеть тип документа направительное письмо. Для них более узнаваемо Врачебное направление. Такой перевод может быть сделан на уровне приложения gettext. Тем не менее, полезнее способ сообщить базе данных и приложению, что направительное письмо и Врачебное направление в действительности одно и то же, чтобы пользователи, говорящие на разных языках, смогли бы работать с одной и той же базой данных и понимать типы документов друг друга. Поэтому, необходимо предоставить это право возможности перевода в бэкэнде. Однако, PostgreSQL пока не поддерживает напрямую локализацию содержимого базы данных.

Концепции

  • переводы не влияют на данные никаким образом
  • в переводах разрешена прозрачность для SELECT
  • по требованию допустимы переводы в SELECT
  • пользователю разрешено выбрать по умолчанию язык вывода
  • возможно переключение языка вывода по умолчанию для каждого пользователя по желанию
  • разрешены неполные переводы через откат к языку "по умолчанию", если для заданной строки они не доступны
  • переводы должны ссылаться на ту же строку в столбце перевода

Объекты базы данных

Для подробных сведений см. документацию схемы базы данных. Все значимые объекты собираются в схемы i18n.

Таблицы и обзоры данных

  • i18n.i18n_curr_lang
    • хранит на каждого пользователя язык вывода по умолчанию
  • i18n.i18n_keys
    • перечисляет все исходные строки, которые должны быть переведены
  • i18n.i18n_translations
    • содержит все переводы строк
  • i18n.v_missing_translations
    • перечисляет строки, не имеющие перевода для языка, найденного в i18n.i18n_curr_lang

Функции

  • i18n.i18n(text)
    • используется сценариями DDL базы данных для регистрации переводимых строк
  • i18n._(text) and i18n._(text, text)
    • используется в =SELECT=ах и определениях производных таблиц для перевода предоставленной строки
    • довольно похожи на gettext() в других языках программирования, как правило, под псевдонимом _()
    • удобные оболочки в схеме public
  • i18n.set_curr_lang(text)
    • устанавливает язык вывода по умолчанию для текущего пользователя
  • i18n.set_curr_lang(text, name)
    • устанавливает язык вывода по умолчанию для пользователя name
  • i18n.force_curr_lang(text)
    • принудительно устанавливает язык вывода по умолчанию для текущего пользователя, даже если переводы не доступны

Как все это совмещается

Как добавить возможность перевода в базу данных

Импортируйте gnumed/server/sql/gmI18N.sql в базу данных. Обычно это выполняется при работе начального загрузчика через файлы конфигурации.

Как предоставить переведенный столбец

Предположим, что у нас есть таблица, перечисляющая семейные связи. Обычным созданием таблицы будет
create table relationship (
    pk serial primary key,
    description text
);

Таблицы ClinicalOrganizingAndWorkflows будут ссылаться на таблицу relationship.pk. Выполнение запроса, подобно select description from relationship where pk=1;, возвратит все введенное в базу данных с первичным ключом 1, например "sister". Немецкий пользователь, однако, предпочел бы вместо этого вернуть строку "Schwester". Иными словами, мы желаем иметь возможность показать перевод для типа члена семьи, например, для relationship.description. Простейший способ может использовать SQL-функцию _() в инструкции SELECT, например: select description, _(description) as l10n_description from member where pk=1;. Это возвращает перевод для relationship.description, как дополнительный столбец l10n_description.

Во многих случаях это более удобно для определения производных таблиц, добавляющих столбец перевода, такой как:
create view v_relationships as
    select
        pk,
        description,
        _(description) as l10n_description
    from relationship
;
Можно затем просто выбрать из этой производной таблицы через select l10n_description from v_relationships where pk=1;.

Как добавить переведенные данные в базу данных

даже если установлен язык вывода для пользователя, и соответствующие столбцы создаются таким образом, чтобы они переводили их содержание, по-прежнему необходимо переводить данные в базе данных.

Как правило, данные добавляются путем предписания, подобно insert into relationship(description) values('sister');, что не помогает с переводами. Когда вставка данных, используемых в столбцах перевода, должна выполняться следующим образом: insert into relationship(description) values(i18n.i18n('sister')); Функция i18n.i18n() будет заботиться о дополнительной вставке строки 'сестра' в таблицу i18n.i18n_keys, где команды перевода найдут ее и обеспечат перевод, скажем, на немецкий следующим образом: insert into i18n_translations(lang, orig, trans) значения ('de_DE', 'sister', 'Schwester');. Теперь соответствующий SELECT должен вернуть переведенные данные.

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

Как добавить перевод (язык) в базу данных

Предположим, нужно добавить перевод с именем klg_PLUTO для вашего хоста farout.

  • используйте select i18n.force_curr_lang('klg_PLUTO'); для установки языка текущего пользователя на klg_PLUTO
  • используйте gnumed/server/locale/dump-missing-db_translations.py для получения пропущенных переводов
  • переведите строки в сценарии SQL, который был сгенерирован
  • выполните psql -h farout -d gnumed_vXX -U gm-dbo -f the-file.sql (заменив XX на версию в запросе)
  • обращайтесь к разработчикам, чтобы они могли добавить ваш перевод к процедуре начальной загрузки
Topic revision: 12 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark