Где почитать про разработку мультиязычных систем?

Question

[AJ]

Доброго хабралюди.

В рамках разработки международного проекта задумался над мультиязычностью и способе реализации. Безусловно, я видел решения со стороны. Немного с ними работал, но как редактор.

Принцип достаточно прост. Языковой файл, скрипт-интегратор, js скрипт геопривязки. Однако хотелось бы почитать подробно, чтобы избежать велосипедов и подводных камней.

Заранее спасибо за ответы.

Comments

[AJ]

UPD: GetText — хорошее решение, но не очень элегантное
UPD2: Нашел метод создания класса на основе содержимого языкового файла. Т.е. в файле ERROR_NUMBER=«Ошибка номер », а в скрипте это вставляется как LocText::ERROR_NUMBER — интересует древность и программная чистота метода. Может кто юзал…

Answer 1

[Mike Grigorieff]

На чем разработка идет? PHP, Rails? Для Rails к примеру используют встроенный класс i18n

Comments

[Сергей Протько]

ну раз вопрос запощен в хабе PHP То думаю вопрос не имеет смысла.

[Mike Grigorieff]

Извиняюсь, открыл вопрос из общей ленты, ну почитайте про Gettext

[AJ]

GetText оказался довольно интересным. Читаю. Спасибо

[AJ]

Но не совсем элегантным, снова в поиске

Answer 2

[Сергей Протько]

Ну как бы тут существует много подходов. i18n есть во всех нормальных фреймворках, перевод содержимого можно организовать связанными таблицами с локалью. JS обычно делают с применением шаблонов каких-то, которые так же можно подменять в зависимости от локали или подменять их часть, так же можно воспользоваться библиотеками для интернационализации под JS (благо есть несколько неплохих). В целом же я не видел какого-то общего случая, ибо все случаи разные и требуют своего подхода.

Comments

[AJ]

В целом понятно. JS будет применяться исключительно для геолокации с последующей записью в SESSION юзера.

[AJ]

Перевод будет по принципу тегирования. Общепринятая практика. Ну и максимально простая.

[Сергей Протько]

github.com/symfony/Translation — если вам gettext не понравился.

[AJ]

Это решение аналогично GetText. У них есть общая особенность: основной язык английский и нужно писать английскую версию. По мне намного проще использовать ключ=текст.

[Сергей Протько]

Несовсем верно, именно что Translation не ограничивает вас выбором языка, вы можете так же использовать просто ключь-значение. Во всяком случае на моим проектах именно так оно и работает, ключи вида admin.category.create и текст задается только для нужных локалей.

[Сергей Протько]

По сути это лучший компонент для локализации из всех что я пробовал. Он может и через Gettext работать если нужно.

Answer 3

[Назар Мокринский]

Я себе реализовал так:

$L->some_phrase;                           //Строка перевода, если перевод отсутствует - возвращается "Some phrase"
$L->mail_body($site_name, $username);      //Так работают переводы, которые требуют подстановки пользовательских данных, сама строка перевода в формате функции printf(), конкретно тут используется vsprintf()

$L — это объект, который при создании или вызове метода смены языка загружает переводы с JSON файла. Так же есть возможность вместо строковых подстановок использовать замыкания (например, когда выводится время и нужно менять окончание слова). Вызовы несуществующих свойств и методов ловятся с помощью __get() и __call().

Если интересно, как это работает на практике — пишите в личку, покажу.

Comments

[Сергей Протько]

А не лучше-ли использовать метод какой-нибудь класса с использованием фэлбэк локали в случае если перевода нету?

[Сергей Протько]

Я к тому что магия это плохо, и в этом случае она не к месту.

[AJ]

На мой взгляд это велосипед, причем многоскоростной двухподвес с электромотором… Ничего личного :)

Я указал, что ищу готовые решения, элегантные и простые.

[Назар Мокринский]

А не лучше-ли использовать метод какой-нибудь класса с использованием фэлбэк локали в случае если перевода нету?

Такая локаль есть, текущая накатывается поверх нее, оставляя недостающие переводы от базовой локали. Но если перевода вообще нет (например, на стадии разработки удобно) — тогда выводится как я писал выше.

Я к тому что магия это плохо, и в этом случае она не к месту.

Чем плохо? По-моему такой подход удобный (минимум лишнего кода), и очевидный при чтении исходников. Можно писать даже так:

$L->{'Привет, мир!'};

И это будет совершенно корректно работать. К стати, в JS используются те же переводы, глобальной переменной L присваивается JSON — и готово.

На мой взгляд это велосипед, причем многоскоростной двухподвес с электромотором… Ничего личного :)

 Я указал, что ищу готовые решения, элегантные и простые.

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

[AJ]

Там идет работа с классом. Процесс наполнения я не вижу. Если это имя свойства, то понятно. Наполнение класса происходит вручную? Если так, то я не понимаю, почему нельзя создать языковой файл по принципу КЛЮЧ=ЗНАЧЕНИЕ и наполнить класс на основе этого файла с помощью fopen и максимум 10-ти строчным циклом. Дальше просто подключить этот файл к скрипту вывода и использовать ключи в нужных местах. Вариант файла, естественно, подключается на основе локали юзера.

[Назар Мокринский]

$L — это объект, который при создании или вызове метода смены языка загружает переводы с JSON файла.

Конечно, переводы грузятся с JSON файла, а не зашиваются в класс. Свойств как таковых и нет, есть метод __get(), который вытаскивает переводы с protected массива, в котором они хранятся. Я дал пример использования, вот реализация, если интересно.

[AJ]

Был не прав. Невнимательность — страшная штука. Читаю. Спасибо.

Answer 4

[Андрей Ширяев]

Я думаю вам стоит взяться за gettext, т.к. у него помимо всех необходимых возможностей есть еще и готовый софт в том числе и для переводчиков. Я в свое время тоже искал разные решения, но так и не нашел нечего подходящего. Есть стандарты например: от microsoft что-то на xml (названия уже не помню), но gettext все-таки быстрей и есть инфраструктура.

Comments

[AJ]

На фоне прочитанного я, вероятно, лишен выбора. Самым эффективным везде признается GetText. Единственное, что меня раздражает, так это тегирование.
Smarty обязательно использовать для работы GetText? Или можно обойтись без шаблонизатора?

[Андрей Ширяев]

Конечно можно использовать без шаблонизатора, библиотеки для работы с gettext есть на всех популярных языках, а конечный файл со словарями бинарный и кешируется в памяти? по этому на шаред хостинге лучше не использовать gettext.

Вообще проблема, которую вы огласили выше (надо писать на английском в оригинале) актуальна только на тот случай если вам нужно работать с формами окончаний. Если же у вас статичные строки, то вполне можно использовать русский в оригинале.

[AJ]

Проблема работы с формами окончаний естественна при работе с русским языком. Она сама появится со временем.