gettext: рецепт жаркое из антилопы в Javascript

[@mayhem]

так если они на одном сайте у них и должен быть один ПР. Разве нет?

[@polyakov_andrey]

Это только про Pr речь идет, тиц везде постоянен.

[@Wott]

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

[@kirik]

Пользовался gettext при разработке проекта на php. Старые добрые массивы оказались гораздо удобнее в плане хранения переводов. После каждого изменения .po файла генерирование .mo файла сродни компиляции — на одну операцию больше. Плюс к этому gettext кэширует перевод после первого обращения, и нету адекватного способа почистить кэш (кроме как назначить другое имя для .mo файла). Возможно это недостаток только php библиотеки gettext.

[@TravisBickle]

1. Напишите скрипт в несколько строк который будет проверять дату модификации файлов каждую секунду и перекомпилировать .po-файл. Если руки прямые, то inotify.

2. Куда кеширует? ;-)

[@kirik]

1. зачем?
2. в память, вероятно :)

[@mayhem]

редакторы сами перегенерируют .mo файлы. в чем проблема? а про кеш вообще не понятно

[@kirik]

Про кэш. Редакторы может и генерят, только не вижу смысла (и удобства как такового) использовать для редактирования перевода специальный редактор.

[@BreathLess]

Специальный редактор, вообще-то для специалистов по переводам, которым не в радость копаться в ваших исходниках.

[@mayhem]

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

[@kvf77]

не гоните — это только проблема Windows, в *NIX .mo файл подхватывается на лету

[@FractalizeR]

blog.mozilla.com/webdev/2007/02/06/teaching-cakephp-to-be-multilingual-part-2/

[@kvf77]

И? я вам говорю, что нормальный сервер под линукс не требует рестарта при замене .mo файла. Наймите нормального админа. Под виндой да, нет толкового решения. А переименовывать файлы, это бред, нафига забивать память кэшем строк гет текста? К тому же в нормальном проекте строки в .po меняются редко — чего вы там постоянно меняете?

[@FractalizeR]

Сервер не имеет к этому никакого отношения. gettext.so загружается в память один раз. После подгрузки *.mo файла в кэш, он не проверяет, изменяется ли этот файл на диске или нет и все запросы удовлетворяет из кэша. Кэш будет обнулен только при перезапуске процесса, подгрузившего gettext.so. Если PHP работает в любом из cgi режимов — проблем гораздо меньше. Но если он работает, например, как модуль Апача, а сам апач — в воркер режиме, будут проблемы. Потому что кэш никак не обнулить без перезапуска процесса воркера апача.

[@Alex_EXEcuter]

проблема есть, решается переименовыванием .mo файла или рестартом апача.

ИМХО лучший способ i18n на PHP — комбинированный. На тестовом сервере работаем с массивами, при выгрузке на продакшен кладем все в .po и .mo.

[@Wott]

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

Это такой хитрый способ убрать слова-паразиты?

[@vosi]

тоже занимаюсь велосипедом
и вот сейчас задумываюсь, как бы так реализовать тоже самое, но на ХСЛТ

[@TravisBickle]

;-) А я написал jquery.i18n. Скоро напишу статью.

[@jury]

Вскоре я понял что нет смысла излишне нагружать сервер переводами фраз, которые не индексируются поисковиками

Такое поведение обусловлено спецификой проекта? Просто интересно по какой причине вы отказались от серверного перевода в пользу JS.

[@aml]

За автора не отвечу. А мы пользуемся gettext для javascript в приложении, у которого интерфейс построен на ExtJS. Он один раз загружается вместе со всеми переводами, и дальше все надписи на кнопках и контролах переводятся в браузере. От серверного перевода при этом, конечно, не отказываемся — сообщения бизнес-логики приезжают в браузер уже переведёнными.

[@jury]

Да, в вашем случае это оправдано. Если переводы используются активно, то всё время перегружать ExtJS накладно. Но везде требования к сервисам разные. Например, не представляю как можно заставить поисковик нормально проиндексировать многоязычный сайт без уникальных урлов и приходящих с сервера переводов без Ajax. А в 90% случаев требования к проектам именно такие.

[@XBeg9]

Не очень хороший подход… а если у вас json-массив (gettext) будет весить больше 1мб? Браузер то закеширует у клиента его, но первоначально будет загружать полностью… Разбивать на страницы каждый json файл? зачем новый велосипед?

[@TravisBickle]

Предположим что суммарный объем языкового файла равен 1 мегабайту, значит размер JS-скрипта, который использует этот языковой файл будет заведомо намного больше 1 мегабайта, т.к. вызовы аля _(«text») составляют незначительную часть всего кода.
Пойдем в рассуждениям дальше. Если сравнивать эту ситуацию с той при которой для каждого языка генерируется отдельный JS-код, объем докачки при смене языка сильно возрастёт.

> Разбивать на страницы каждый json файл?
JSON файл не надо разбивать. Надо для каждой логически обособленной сущности (компонента) делать свой файл.

[@twenty]

КО, где же ты?
Объясни, пожалуйста, смысл таких извращений!

[@roboter]

Жди картинки троллейбуса из хлеба. Ваш К.О.

[@aspel]

В django все уже изпадкаробки.

[@mchl]

крутую вы «нормальную unix программу» родили

[@Iskin]

gettext — жуткий англоцентрический формат. Там же английский вариант является ключём в итоге куча проблем:
1. Некоторые разработчики сначала делают программу на своём языке, а потом уже переводят.
2. Одна строка на английском не всегда соответствует одной строке на других языках (например, глагол и существительное в англ. — одно и то же слово, а русском — два).
3. Если меняется английский текст, то надо менять его во всех переводах.

Да и что с плюрализацией (1 робот, 2 робота, 5 роботов)? В gettext её синтаксис и так ужасен, а в исходнике я вообще не нашёл, что можно менять плюрализацию для разных языков (а англ. плюрализация сильно отличается от русской).

[@TravisBickle]

LOL. Всегда поражала воинствующая невежественность.

1. Ключем может являться любой вариант, просто принято написать программы на английском, но это не требование.

2. Ну и сделайте два варианта, с комментами о контексте.

3. А вы хотели чтоб изменения в переводы вносила фея?

4. С плюрализацией всё замечательно. Ну, то что вы не нашли, говорит только о том что плохо искали.

[@Iskin]

Так может для перевод лучше использовать иерархический формат типа JSON или YAML с кодом в ключе?

[@Iskin]

Да, не спорю, я мог пропустить код плюрализции. Но меня больше всего смущает формат плюрализации в gettext. В YAML интереснее:

robots: !!pl
  0: нет роботов
  1: %1 робот
  2: %1 робота
  n: %1 роботов

[@LastDragon]

В gettext почти точно так же:
* www.gnu.org/software/gettext/manual/gettext.html#Plural-forms
* www.gnu.org/software/gettext/manual/gettext.html#Translating-plural-forms

msgid ""
msgstr «Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11? 0: n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20)? 1: 2;\n»

msgid «One file removed»
msgid_plural "%d files removed"
msgstr[0] "%d slika je uklonjena"
msgstr[1] "%d datoteke uklonjenih"
msgstr[2] "%d slika uklonjenih"

[@Iskin]

Но всё же, может укажите мне, где в этом проекте задаются правила плюрализации для каждого языка?

[@FractalizeR]

Что посоветуете в качестве альтернативы? Mozilla например все устраивает :)

[@Iskin]

Мне нравится YAML формат, как, например, в Rails. Главное, чтобы ключем был какой-то код.

[@FractalizeR]

YAML все равно надо в PHP компилировать ведь. Кроме того, YAML формат — это не средство локализации. Как у него с плюрализацией, падежными формами?

[@Iskin]

Ну я говорю о формате хранения, а не библиотеке. Собственно, в Ruby on Rails его не надо переконвертировать (компилировать), так как перевод загружается только один раз.
Плюрализация для всех языков есть (сразу из коробки). Формат:

robots: !!pl
  0: нет роботов
  1: %1 робот
  2: %1 робота
  n: %1 роботов

Падежные формы — это обычно отдельная библиотека (в основном используется сервис от Яндекс), но я не встречал необходимости в нём (максимум, имена менять).

[@FractalizeR]

Ruby становится стандартом :) Разлюбить PHP, что ли? :))

[@Iskin]

Поиграться всегда можно :).