3 сентября, 2009

Сегодня я хочу рассказать о поддержке нескольких языков в клиентской части 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);

Успехов!

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

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

Понравилась статья? Подписывайтесь на продолжение !

Или на мой твиттер

Добавьте эту страницу в

Опубликовано в Ajax, JavaScript, PHP, Web разработка View Comments

S7a1k3r

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

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

{ идентификатор строки, //что-то вроде 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. Насколько часто посетители будут менять язык страницы я не знаю, зависит от сайта.
сайт nsk

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

То придется переводить их все ;)
Count Raven

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

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

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

Дамую удобнее было бы так:
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.
Согласен, что она очень удобная.
Дмитрий

Интересно. Спасибо.
Владимир

читать так: "хотя этот заголовок не всегда соответствует ... " слово лишнее застряло :)
Владимир

Поправил ;)
Владимир

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

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