BugTracker: локализация (часть девятая)
Сегодня мы продолжаем разработку собственной системы отслеживания ошибок. В предыдущих частях мы рассмотрели добавление записей о багах и комментариев к ним.
Но при этом не решенным остался вопрос локализации.
По-умолчанию CodeIgniter выводит сообщения об ошибках на английском языке. Прежде всего, это касается описаний ошибок, которые возникают при некорректном заполнении форм.
В этой части я расскажу, как перевести эти сообщения на русский язык.
Самое интересное, что часть работы мы уже сделали при создании правил для проверки полей форм.
Например, правила для проверки email выглядят следующим образом.
-
$this->form_validation->set_rules('email', 'lang:email', 'required|valid_email');
Здесь мы вызываем метод set_rules из библиотеки form_validation. В первом параметре указываем имя поля в форме (атрибут name), во втором – его описание, в третьем – правила.
Сейчас нас интересует второй параметр. Нам нужно, чтобы CodeIgniter подставил вместо него правильное описание поля.
Для этого нужно выполнить 4 шага.
1) Открываем файл \application\config\config.php и устанавливаем язык по-умолчанию.
-
$config['language'] = "russian";
Теперь CodeIgniter будет прежде всего искать файлы с описаниями в папке \application\language\russian.
2) Создаем папку \application\language\russian и в ней файл form_fields_lang.php. Обратите внимание: окончание _lang обязательно.
3) В этом файле создаем массив с описаниями полей:
-
<?php
-
$lang['title'] = '"Заголовок"';
-
$lang['uname'] = '"Ваше имя"';
-
$lang['category_id'] = '"Категория ошибки"';
-
$lang['description'] = '"Описание ошибки"';
-
$lang['email'] = '"eMail"';
-
$lang['password'] = '"Пароль"';
-
?>
Ключи элементов этого массива должны совпадать с именами, которые указаны после lang: (во втором параметре метода set_rules).
4) Загружаем файл с описаниями полей. Для этого в конструктор контроллера добавляем строку.
-
$this->load->language('form_fields');
Обратите внимание. Окончание _lang.php не указываем.
После этих манипуляций описания полей будут правильно отображаться. Но сами ошибки будут на английском.
Для их руссификации нужно скачать файлы с переводами.
Архив распаковываем в папку \application\language\russian.
Всё. На этом работа заканчивается. Названия этих файлов совпадают с названиями их английских версий, поэтому CodeIgniter загрузит их автоматически.
Заключение.
В данном случае мы просто русифицировали баг трекер. Ничего сложного, но проблема в том, что выполнить обратную операцию, т.е. перевести приложение на английский, намного сложнее.
Для этого нужно найти и исправить весь русский текст в исходниках баг трекера. А их довольно много. Это и файлы шаблонов, и сообщения в контроллере, и текст в представлениях.
Я не ставил задачи сделать мультиязычное приложение, но если этот пункт для вас важен, в CodeIgniter входит Language Helper для этих целей. Использовать его не сложно, самый трудоёмкий этап – создание файлов с переводами. И нужно внимательно следить, чтобы в исходниках проекта напрямую не был жестко прописан текст.
До встречи!
P.S. Думаю, к следующему выпуску будет готова демонстрационная версия баг трекера. И безусловно выложу архив файлами проекта.
Понравилась статья? Подписывайтесь на продолжение 
!
Или на мой твиттер 
Добавьте эту страницу в 
Опубликовано в CodeIgniter, PHP, Web разработка Комментарии (7) »
Комментарии (7)
Вы можете отслеживать обсуждение записи с помощью RSS 2.0
Вы также можете оставить комментарий, или трекбек с Вашего сайта.
Недавно MaxSite после года разработки переводили на многоязычные рельсы. И повыковыривать из исходников жёстко прописанный вывод по русски и повставлять вместо этого вывод через функцию локализации — оказалось чертовски занудной работой. ГОРАЗДО более занудной, чем создание файлов с переводами.
Аналогично LiveStreet между 0.2 и 0.3 версиями.
Поэтому мой совет тем, кто хотя бы в отдалённой перспективе предполагает перевод своих приложений на другие языки — изначально закладывать многоязычность и сразу писать вывод сообщений из языковых файлов, а не напрямую.
Проектирование рулит.
Точно про проектирование подметил.
У меня обычно на него до 30% всего времени работы над проектом уходит. Затом потом все просто, тупо кодирование и отлов ошибок
Полностью согласен. Возможность перевода нужно закладывать изначально.
В этом баг трекере я такой цели не ставил (может зря?), поэтому и жизнь себе упростил.
И все-таки в данном случае создание файлов перевода займет больше времени. Это же не CMS и кода не много
Легче всего и лучше всего использовать разные шаблоны для разных языков.
Так как 1 предложения по русски может быть короче в несколько раз чем на английском и так далее.
Жалко что стандартный wiev очень слабый в КИ
хотелось бы поддержки шаблонов и layout.
Скорее на английском фраза будет короче
В принципе к CI можно подключить сторонний шаблонизатор, тот же smarty.
Может быть комбинировать оба подхода? В любом случае для сообщений встроенный библиотек нужны файлы с переводами.
Это верно.
Смарти никогда не буду использовать в своих проектах.
Я использую нативные шаблоны под типа встроеных в CI но им не хватает ряда изменений.
По идее, чем больше возможностей у шаблонизатора, тем он тяжелее. Поэтому приходится выбирать.