JavaScript « JavaScript I18N/Интернационализация

Какие методы интернационализации javascript вы посоветуете? Я использую zend framework и там есть встроенный механизм для этого, а как быть со скриптами не знаю, еще не сталкивался.

Буду рад советам бывалых.
0
i18n javascript интернационализация

1 ответов

В закладки вопрос.

Вот недавно в ленте проскакивала парочка скриптов, претендующих на реализацию gettext'а в Яваскрипте. Вроде всё легко.

А можно еще проще — просто сделать отдельный файл, ru.js, а в нем обычный словарь (объект, {}). Потом его подключать на страничку.

Лично мне всегда удается обойти интернационализацию в Яваскрипте простым способом — какой-либо текст или сообщение (на нужном языке) уже существует в ХТМЛ-коде страницы и мы его показываем, когда нужно — при неправильном заполнении форм, в попапах (не в алертах) и т.п.

0

В своём проекте (серверная часть написана с использованием J2EE, но всё ниже применимо и к другим технологиям, в принципе) используем примерно такое дело:


alert(L(M.$_ACCOUNTS_REMOVED, removedAccountsCount))
 
где

* L - функция, которая преобразует сырое сообщение, грубый аналог MessageFormat в Java (кстати, парсер почему-то схавал двойной доллар, потому что у нас на проекте эта функция называется $$)

* M - глобальное пространство имен со списком алиасов и сырых сообщений; все такие сообщения хранятся у нас в файлах вида en-UK.js, ru-RU.js, uk-UA.js и т.д., которые компилируются во время сборки самого проекта до того, как крутится сам веб-апп-контейнер

* $_ACCOUNTS_REMOVED - "сырое" сообщение, в этом случае: "{0} accounts removed"; как становится ясно из примера, иногда вызова L можно избегать (например, alert(M.OK)), но это, конечно, не очень надёжно и зависит исключительно от внимания разработчика

Скажу, немного с оглядкой на сам проект, в котором участвую, что технически интернационализация сильно зависит от того, толстый ли сам клиент для самого сервиса. Если во внимание берётся только простенькая вюшка, то и обычных JSP достаточно, если немножко научить их работать с ресурсами сообщений, или прикрутить туда какую-то свою i18n-библиотеку тегов. Более гибко с этим справляется, например, JSF (который, к моему огромному огорчению, мы проигнорировали два года назад на этапе запуска проекта), где по большому счёту эти возможности поддерживаются "из коробки". Но, оба способа основываются на том факте, что языковые ресурсы целиком хранятся на стороне сервера, если идёт речь о статическом контенте, что иногда приводит к тому, что в толстых клиентах приходится дублировать сообщения -- т.е., что-то "слева", а что-то "справа". Это, в свою очередь, означает, что услуги переводчиков обходятся дороже. В принципе, в идеале, всё, что показывается в толстом клиенте, должно содержаться именно в клиентских JS-файлах (к примеру), и может обрабатываться, примерно так:

<input id="save-grid-changes" type="button" data-message="SAVE_CHANGES"/>
 
где SAVE_CHANGES -- алиас с пространства имён M, описанного выше. Рендеринг локализированного сообщения осуществляется кодом вида:
$(document).ready(function() {
    localizeDom(); // contains special formatting rules, so all messages are purely front-end only
    hideLoadingIndicatorOverlay();    
})
0