Каковы причины использовать или не использовать собственный gettext в PHP по сравнению с самостоятельной сборкой? - PullRequest
Новая
       31

Каковы причины использовать или не использовать собственный gettext в PHP по сравнению с самостоятельной сборкой?

6 голосов
/ 25 марта 2011

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

Ответы [ 2 ]

5 голосов
/ 25 марта 2011

Расширение gettext имеет некоторые причуды.

  • Оно сохраняет строки перевода в памяти и, следовательно, может потребовать перезапуска (в рамках времени выполнения mod_php), когда каталоги обновляются.
  • API gettext не был специально разработан для веб-приложений.(Он ищет переменные окружения и настройки системы. Вы должны подать заголовок Accept-Language ложкой.)
  • У многих людей возникают проблемы с его настройкой.
  • С другой стороны, есть и другие.инструментальная поддержка gettext.

У вас почти всегда будет меньше проблем с созданным вручную решением.Но, как говорится, API gettext непревзойден в краткости._("orig text") является более или менее оптимальным интерфейсом для перевода текста.

Если вы хотите что-то кодировать самостоятельно, я рекомендую вам сосредоточиться на этом.

  • Используйтепростое имя функции .Вместо _() несколько php-приложений используют двойное подчеркивание __().Не используйте какую-либо библиотеку, которая затрудняет использование переведенных строк.(Например, при использовании Zend Framework всегда пишите функцию-обертку.)
  • Принимайте необработанный текст на английском языке в качестве ввода.Избегайте мнемонических ключей перевода (например, BTN_SUBMT)
  • Ни при каких обстоятельствах не используйте базу данных для каталогов переводов.Эти тексты являются данными времени выполнения, а не данными приложения.(Плохой пример см. В osCommerce.)

Часто вы можете избавиться от сценариев PHP-массива lang/nl.php, не содержащих ничего, кроме $text["orig english"] = "dutch here";, которые легко использовать из любого используемого вами метода доступа.

Также старайтесь не вдавливать все в эту систему.Иногда неизбежно использовать второй механизм для более длинных текстов.Я, например, использовал template/mail.EN.txt для больших капель.

1 голос
/ 25 марта 2011

Gettext не поточно-ориентированный .

Прежде чем принять решение о реализации собственного, я предлагаю вам взглянуть на Zend_Translate .Он имеет встроенную поддержку адаптера gettext, а также TMX, CSV, INI, Array и других форматов.Также должно быть достаточно легко написать собственный адаптер, если предпочитаемый вами формат не поддерживается, например, хранилище базы данных.

...