Интернационализация в PHP-фреймворках

КОНСТАНТИН ЧУХЛОМИН, программист в компании-агрегаторе платежных систем, занимающейся разработкой бэк-офиса и личного кабинета клиентов

Интернационализация в PHP-фреймворках

В статье рассмотрены примеры популярных PHP-фреймворков, которые применяются для решения проблемы адаптации сайта к языковым и культурным особенностям региона пользователя

Один из основых способов расширения аудитории сайтов-сервисов – сделать их понятными для пользователей, говорящих на разных языках. Многие PHP-фреймворки предлагают свои приемы для решения этой задачи.

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

Небольшое введение

Когда создают продукт (под продуктом мы понимаем какой-либо сайт), которым будут пользоваться люди из разных стран, встает вопрос, как сделать так, чтобы продукт адаптировался под пользователя, его родной язык и национальные стандарты? В таких случаях применяется локализация ПО. Часто вместе с термином локализация встречается термин интернационализация.

• Локализация программного обеспечения – процесс его адаптации к культуре какой-либо страны. Как частность – перевод пользовательского интерфейса, документации и сопутствующих файлов программного обеспечения с одного языка надругой [1].
• Интернационализация – технологические приемы, упрощающие адаптацию продукта к языковым и культурным особенностям региона (регионов), отличного от того, в котором он разрабатывался [2].

Как видно из определений, интернационализация – это основа для последующей локализации. Мы можем предусмотреть интернационализацию приложения на несколько языков и локализовать приложение на русский и английский. Длякраткости написания термин «интернационализация» сокращают до i18n, а «локализация» – до L10n.

Что нужно локализовать на сайте? Первое, что приходит в голову, – это перевод строк: подписи полей формы, меню, содержимое. Кроме этого, необходимо также позаботиться о корректном отображении чисел, дат, словоформах, валюте.

Интернационализация приложений

Как проблему локализации решают в мире ПО? В худшем случае (и, к сожалению, самом распространенном), локализацию «вшивают» в код. Это сводит на нет любые попытки дополнить или исправить локализацию в приложении безвмешательства в код. Возможны случаи, когда такой подход оправдан, например, в редко обновляющихся продуктах с малым объемом текста, таких как навигаторы, многие iOS-приложения и т.д. При постоянно развивающемся проекте этоне лучшая практика.

Следующий шаг – выделение локализации из кода в базу данных или специальные файлы (например, .po либо его бинарную версию .mo). Использование баз данных не радует скоростью работы запросов, а файлов – удобством дляпереводчика.

Интернационализация в популярных PHP-фреймворках

Подходы. Во многих современных фреймворах есть встроенные механизмы, облегчающие локализацию. Заранее прошу прощения, если я не упомяну ваш любимый вариант. Из всех «каркасов» наиболее тесно я работал с Yii, поэтому прошу сниходительно отнестись к незнанию некоторых аспектов работы других фреймворков.

Определимся с терминами, которыми мы будем оперировать. Переводы строк из одного языка в другой часто хранят в файлах и называют их словарями. Обычно «оригинальный язык» – английский, чаще всего его и советуют взять заоснову. Плохим решением будет выбор русского языка в качестве основного (быстрее, проще и дешевле перевод с английского).

Иногда поступают другим образом: ключи словаря представляют собой некоторый набор английских слов, разделенных запятой, четко указывающий, в каком месте системы следует искать его использование. Например, ключ model.user.error.missingPassword указывает на сообщение о недостающем пароле в модели пользователя, a button.label.cancel – на надпись, которая будет на кнопке «Отмена» в обычном состоянии.

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

Локализуя приложение, следует аккуратно относиться к множественным формам у разных слов. Если для английского языка все более-менее просто (добавил s на конце для множественного числа и все), то, например, в русском придется помучиться. Я помню, в одном из проектов даже существовала функция, которая выбирала, какое из переданных слов подходит к переданному числу. Объявлялась она как-то так: plural($one, $two, $five, $n). Вызывалась так: plural('страница', 'страницы', 'страниц', 7). Если все это когда-нибудь придется переводить на другие языки, то голова пойдет кругом. Всевозможные варианты множественных форм можно посмотреть здесь [3].

Итак, начнем...

Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 57-61.

Комментарии могут оставлять только зарегистрированные пользователи