Локализация клиентской части web приложений

Владимир | | Ajax, JavaScript, PHP, Web разработка.

js_localization

Сегодня я хочу рассказать о поддержке нескольких языков в клиентской части web приложений.

Прежде всего, определимся с задачей.

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

И если наше приложение не использует JavaScript, то можно считать задачу решенной.

Но на сегодняшний день JS используется все чаще и в основном для создания интерфейса, содержащего множество надписей, сообщений и т.п.

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

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

Теперь рассмотрим решение.

1) Создаем файлы переводов для каждого языка. Например,

text-ru.js
text-en.js

Примерное содержимое файлов может быть таким.

window.tr = {
	mes1:"Сообщение 1"
	, mes2:"Сообщение 2"
	, mes3:"Сообщение 3"
};
window.tr = {
	mes1:"Message 1"
	, mes2:"Message 2"
	, mes3:"Message 3"
};

Тут мы создали глобальный хеш (window.tr) и сохранили в нем текст, который нужно перевести.

Примечание. Если вы используете библиотеку вроде jQuery, то можно использовать глобальную переменную $ (она же jQuery).

(function(s) {
s.tr = {
		mes1:"Сообщение 1"
		, mes2:"Сообщение 2"
		, mes3:"Сообщение 3"
};
})(jQuery);

2) Нам нужно определить какой скрипт с переводами подключать. Для этого мы можем использовать примерно следующий php скрипт

<?php
$curLang = 'russian';
if ($curLang == 'russian') {
	$langPrefix = 'ru';
}
else {
	$langPrefix = 'en';
}
?>
<script src="js/i18n/text_<?php echo $langPrefix; ?>.js" type="text/javascript"></script>

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

Примечание. Файлы с переводами должны быть загружены до скриптов, которые их используют.

3) Можно пользоваться

Например, так

alert(window.tr.mes2);

или для jQuery варианта

alert($.tr.mes2);

Успехов!

Интересно почитать

Определяем скорость интернета

  • Владимир

    еще можно попробовать использовать хедер бравзера Accept-Language и применять rewrite в .htaccess или настройках сервера — что доступнее.
    хотя этот заголовок не всегда соответствует тому что хочет видеть пользователь, но как быстрый вариант некритичного приложения, чтобы не городить огород с базами, сессиями и пр.

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

  • Владимир

    еще можно попробовать использовать хедер бравзера Accept-Language и применять rewrite в .htaccess или настройках сервера — что доступнее.
    хотя этот заголовок не всегда соответствует тому что хочет видеть пользователь, но как быстрый вариант некритичного приложения, чтобы не городить огород с базами, сессиями и пр.

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

  • Владимир

    читать так: «хотя этот заголовок не всегда соответствует … » слово лишнее застряло 🙂

  • Владимир

    читать так: «хотя этот заголовок не всегда соответствует … » слово лишнее застряло 🙂

  • Интересно. Спасибо.

  • Интересно. Спасибо.

  • Хм, не знаю, мне кажется этот метод очень неудобным для больших приложений.

    Дамую удобнее было бы так:
    function t(«This is a text!», THIS_IS_A_TEXT);

    THIS_IS_A_TEXT — это текстовая константа.

    Все такие константы хранятся в файлах lang_ru.js, lang_en.js — с тем же принципом префиксов.

    Если константа не объявлена, то выводится текст из первого аргумента функции t, если определена, выводится содержимое константы.

    Таким образом переводы могут быть неполными, а только наполовину и если не найдено перевода для языка, то выведется дефолтный текст.

    А если генерировать JavaScript на стороне сервера, то вообще можно использовать классический для никса и дефолтный для PHP — gettext.

    • Может я не правильно понял, но по-моему это тот же метод, только с добавлением функции t.
      Согласен, что она очень удобная.

  • Хм, не знаю, мне кажется этот метод очень неудобным для больших приложений.

    Дамую удобнее было бы так:
    function t(«This is a text!», THIS_IS_A_TEXT);

    THIS_IS_A_TEXT — это текстовая константа.

    Все такие константы хранятся в файлах lang_ru.js, lang_en.js — с тем же принципом префиксов.

    Если константа не объявлена, то выводится текст из первого аргумента функции t, если определена, выводится содержимое константы.

    Таким образом переводы могут быть неполными, а только наполовину и если не найдено перевода для языка, то выведется дефолтный текст.

    А если генерировать JavaScript на стороне сервера, то вообще можно использовать классический для никса и дефолтный для PHP — gettext.

    • Может я не правильно понял, но по-моему это тот же метод, только с добавлением функции t.
      Согласен, что она очень удобная.

  • Метод отличается тем, что можно добавить дефолтный текст и отсутствие превода.

    • Я имел в виду хранение сток перевода.
      Насчет функции все понятно, повторюсь, она действительно очень удобная и расширяет возможности.

  • Метод отличается тем, что можно добавить дефолтный текст и отсутствие превода.

    • Я имел в виду хранение сток перевода.
      Насчет функции все понятно, повторюсь, она действительно очень удобная и расширяет возможности.

  • гм, имхо слишком замудрено… а если строк для перевода тысячи…

  • гм, имхо слишком замудрено… а если строк для перевода тысячи…

  • Хотел бы поделиться своим механизмом локализации и спросить Вас о том, насколько приемлемым он является.

    Все строки, подлежащие локализации хранятся в базе со следующей схемой:


    {
    идентификатор строки, //что-то вроде some_text_str
    язык перевода, //en, ru, etc
    перевод строки
    }

    В теле страницы прописаны константы вида #some_text_str#, которые заменяются на перевод, взятый из базы (локализация выполняется перед выдачей страницы пользователю).

    Далее конструкция немного усложняется:

    <div class="localization" rel='locale[some_text_str]'>#some_text_str#</div>

    Что происходит в таком случае?
    После генерации страницы на стороне сервера происходит замена текстовых строк вида #some_text_str# на некие текст в соответствии с локалью.
    Потом на стороне пользователя возможна автоматическая смена языка. Если пользователь выберет другой язык, то
    — с сервера будет подгружен файл локализации, содержащий все необходимые для данной страницы
    — содержимое div'ов на странице будет заменено на новое, полученное от сервера.

    • Я думаю, что любое решение приемлемо, если оно нормально работает 🙂

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

  • Хотел бы поделиться своим механизмом локализации и спросить Вас о том, насколько приемлемым он является.

    Все строки, подлежащие локализации хранятся в базе со следующей схемой:


    {
    идентификатор строки, //что-то вроде some_text_str
    язык перевода, //en, ru, etc
    перевод строки
    }

    В теле страницы прописаны константы вида #some_text_str#, которые заменяются на перевод, взятый из базы (локализация выполняется перед выдачей страницы пользователю).

    Далее конструкция немного усложняется:

    <div class="localization" rel='locale[some_text_str]'>#some_text_str#</div>

    Что происходит в таком случае?
    После генерации страницы на стороне сервера происходит замена текстовых строк вида #some_text_str# на некие текст в соответствии с локалью.
    Потом на стороне пользователя возможна автоматическая смена языка. Если пользователь выберет другой язык, то
    — с сервера будет подгружен файл локализации, содержащий все необходимые для данной страницы
    — содержимое div'ов на странице будет заменено на новое, полученное от сервера.

    • Я думаю, что любое решение приемлемо, если оно нормально работает 🙂

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