Comments 43
UFO just landed and posted this here
Пользовался gettext при разработке проекта на php. Старые добрые массивы оказались гораздо удобнее в плане хранения переводов. После каждого изменения .po файла генерирование .mo файла сродни компиляции — на одну операцию больше. Плюс к этому gettext кэширует перевод после первого обращения, и нету адекватного способа почистить кэш (кроме как назначить другое имя для .mo файла). Возможно это недостаток только php библиотеки gettext.
1. Напишите скрипт в несколько строк который будет проверять дату модификации файлов каждую секунду и перекомпилировать .po-файл. Если руки прямые, то inotify.
2. Куда кеширует? ;-)
2. Куда кеширует? ;-)
редакторы сами перегенерируют .mo файлы. в чем проблема? а про кеш вообще не понятно
Про кэш. Редакторы может и генерят, только не вижу смысла (и удобства как такового) использовать для редактирования перевода специальный редактор.
Специальный редактор, вообще-то для специалистов по переводам, которым не в радость копаться в ваших исходниках.
и к тому же можно красиво поднастроить этот самый редактор и выглебать переводимые строки из кода автоматом и соответственно зачищать ненужные. в ручную это наверное аццкий труд поддерживать все в нормальном состоянии
UFO just landed and posted this here
не гоните — это только проблема Windows, в *NIX .mo файл подхватывается на лету
И? я вам говорю, что нормальный сервер под линукс не требует рестарта при замене .mo файла. Наймите нормального админа. Под виндой да, нет толкового решения. А переименовывать файлы, это бред, нафига забивать память кэшем строк гет текста? К тому же в нормальном проекте строки в .po меняются редко — чего вы там постоянно меняете?
Сервер не имеет к этому никакого отношения. gettext.so загружается в память один раз. После подгрузки *.mo файла в кэш, он не проверяет, изменяется ли этот файл на диске или нет и все запросы удовлетворяет из кэша. Кэш будет обнулен только при перезапуске процесса, подгрузившего gettext.so. Если PHP работает в любом из cgi режимов — проблем гораздо меньше. Но если он работает, например, как модуль Апача, а сам апач — в воркер режиме, будут проблемы. Потому что кэш никак не обнулить без перезапуска процесса воркера апача.
проблема есть, решается переименовыванием .mo файла или рестартом апача.
ИМХО лучший способ i18n на PHP — комбинированный. На тестовом сервере работаем с массивами, при выгрузке на продакшен кладем все в .po и .mo.
ИМХО лучший способ i18n на PHP — комбинированный. На тестовом сервере работаем с массивами, при выгрузке на продакшен кладем все в .po и .mo.
Вскоре я понял что нет смысла излишне нагружать сервер переводами фраз, которые не индексируются поисковиками, и что в ряде случаев лучше переводить на клиенте.
Это такой хитрый способ убрать слова-паразиты?
тоже занимаюсь велосипедом
и вот сейчас задумываюсь, как бы так реализовать тоже самое, но на ХСЛТ
и вот сейчас задумываюсь, как бы так реализовать тоже самое, но на ХСЛТ
Вскоре я понял что нет смысла излишне нагружать сервер переводами фраз, которые не индексируются поисковиками
Такое поведение обусловлено спецификой проекта? Просто интересно по какой причине вы отказались от серверного перевода в пользу JS.
За автора не отвечу. А мы пользуемся gettext для javascript в приложении, у которого интерфейс построен на ExtJS. Он один раз загружается вместе со всеми переводами, и дальше все надписи на кнопках и контролах переводятся в браузере. От серверного перевода при этом, конечно, не отказываемся — сообщения бизнес-логики приезжают в браузер уже переведёнными.
Да, в вашем случае это оправдано. Если переводы используются активно, то всё время перегружать ExtJS накладно. Но везде требования к сервисам разные. Например, не представляю как можно заставить поисковик нормально проиндексировать многоязычный сайт без уникальных урлов и приходящих с сервера переводов без Ajax. А в 90% случаев требования к проектам именно такие.
Не очень хороший подход… а если у вас json-массив (gettext) будет весить больше 1мб? Браузер то закеширует у клиента его, но первоначально будет загружать полностью… Разбивать на страницы каждый json файл? зачем новый велосипед?
Предположим что суммарный объем языкового файла равен 1 мегабайту, значит размер JS-скрипта, который использует этот языковой файл будет заведомо намного больше 1 мегабайта, т.к. вызовы аля _(«text») составляют незначительную часть всего кода.
Пойдем в рассуждениям дальше. Если сравнивать эту ситуацию с той при которой для каждого языка генерируется отдельный JS-код, объем докачки при смене языка сильно возрастёт.
> Разбивать на страницы каждый json файл?
JSON файл не надо разбивать. Надо для каждой логически обособленной сущности (компонента) делать свой файл.
Пойдем в рассуждениям дальше. Если сравнивать эту ситуацию с той при которой для каждого языка генерируется отдельный JS-код, объем докачки при смене языка сильно возрастёт.
> Разбивать на страницы каждый json файл?
JSON файл не надо разбивать. Надо для каждой логически обособленной сущности (компонента) делать свой файл.
КО, где же ты?
Объясни, пожалуйста, смысл таких извращений!
Объясни, пожалуйста, смысл таких извращений!
В django все уже изпадкаробки.
крутую вы «нормальную unix программу» родили
gettext — жуткий англоцентрический формат. Там же английский вариант является ключём в итоге куча проблем:
1. Некоторые разработчики сначала делают программу на своём языке, а потом уже переводят.
2. Одна строка на английском не всегда соответствует одной строке на других языках (например, глагол и существительное в англ. — одно и то же слово, а русском — два).
3. Если меняется английский текст, то надо менять его во всех переводах.
Да и что с плюрализацией (1 робот, 2 робота, 5 роботов)? В gettext её синтаксис и так ужасен, а в исходнике я вообще не нашёл, что можно менять плюрализацию для разных языков (а англ. плюрализация сильно отличается от русской).
1. Некоторые разработчики сначала делают программу на своём языке, а потом уже переводят.
2. Одна строка на английском не всегда соответствует одной строке на других языках (например, глагол и существительное в англ. — одно и то же слово, а русском — два).
3. Если меняется английский текст, то надо менять его во всех переводах.
Да и что с плюрализацией (1 робот, 2 робота, 5 роботов)? В gettext её синтаксис и так ужасен, а в исходнике я вообще не нашёл, что можно менять плюрализацию для разных языков (а англ. плюрализация сильно отличается от русской).
LOL. Всегда поражала воинствующая невежественность.
1. Ключем может являться любой вариант, просто принято написать программы на английском, но это не требование.
2. Ну и сделайте два варианта, с комментами о контексте.
3. А вы хотели чтоб изменения в переводы вносила фея?
4. С плюрализацией всё замечательно. Ну, то что вы не нашли, говорит только о том что плохо искали.
1. Ключем может являться любой вариант, просто принято написать программы на английском, но это не требование.
2. Ну и сделайте два варианта, с комментами о контексте.
3. А вы хотели чтоб изменения в переводы вносила фея?
4. С плюрализацией всё замечательно. Ну, то что вы не нашли, говорит только о том что плохо искали.
Так может для перевод лучше использовать иерархический формат типа JSON или YAML с кодом в ключе?
Да, не спорю, я мог пропустить код плюрализции. Но меня больше всего смущает формат плюрализации в gettext. В YAML интереснее:
robots: !!pl
0: нет роботов
1: %1 робот
2: %1 робота
n: %1 роботов
В gettext почти точно так же:
* www.gnu.org/software/gettext/manual/gettext.html#Plural-forms
* www.gnu.org/software/gettext/manual/gettext.html#Translating-plural-forms
* 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"
Но всё же, может укажите мне, где в этом проекте задаются правила плюрализации для каждого языка?
Что посоветуете в качестве альтернативы? Mozilla например все устраивает :)
Мне нравится YAML формат, как, например, в Rails. Главное, чтобы ключем был какой-то код.
YAML все равно надо в PHP компилировать ведь. Кроме того, YAML формат — это не средство локализации. Как у него с плюрализацией, падежными формами?
Ну я говорю о формате хранения, а не библиотеке. Собственно, в Ruby on Rails его не надо переконвертировать (компилировать), так как перевод загружается только один раз.
Плюрализация для всех языков есть (сразу из коробки). Формат:
Падежные формы — это обычно отдельная библиотека (в основном используется сервис от Яндекс), но я не встречал необходимости в нём (максимум, имена менять).
Плюрализация для всех языков есть (сразу из коробки). Формат:
robots: !!pl
0: нет роботов
1: %1 робот
2: %1 робота
n: %1 роботов
Падежные формы — это обычно отдельная библиотека (в основном используется сервис от Яндекс), но я не встречал необходимости в нём (максимум, имена менять).
Sign up to leave a comment.
gettext: рецепт жаркое из антилопы в Javascript