BugTracker: локализация (часть девятая)

24 марта, 2009
bug_tracker_logo_part9

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

Но при этом не решенным остался вопрос локализации.

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

В этой части я расскажу, как перевести эти сообщения на русский язык.

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

Например, правила для проверки email выглядят следующим образом.

  1. $this->form_validation->set_rules('email', 'lang:email', 'required|valid_email');

Здесь мы вызываем метод set_rules из библиотеки form_validation. В первом параметре указываем имя поля в форме (атрибут name), во втором – его описание, в третьем – правила.

Сейчас нас интересует второй параметр. Нам нужно, чтобы CodeIgniter подставил вместо него правильное описание поля.

Для этого нужно выполнить 4 шага.

1) Открываем файл \application\config\config.php и устанавливаем язык по-умолчанию.

  1. $config['language'] = "russian";

Теперь CodeIgniter будет прежде всего искать файлы с описаниями в папке \application\language\russian.

2) Создаем папку \application\language\russian и в ней файл form_fields_lang.php. Обратите внимание: окончание _lang обязательно.

3) В этом файле создаем массив с описаниями полей:

  1. <?php
  2. $lang['title'] = '"Заголовок"';
  3. $lang['uname'] = '"Ваше имя"';
  4. $lang['category_id'] = '"Категория ошибки"';
  5. $lang['description'] = '"Описание ошибки"';
  6. $lang['email'] = '"eMail"';
  7. $lang['password'] = '"Пароль"';
  8. ?>

Ключи элементов этого массива должны совпадать с именами, которые указаны после lang: (во втором параметре метода set_rules).

4) Загружаем файл с описаниями полей. Для этого в конструктор контроллера добавляем строку.

  1. $this->load->language('form_fields');

Обратите внимание. Окончание _lang.php не указываем.

После этих манипуляций описания полей будут правильно отображаться. Но сами ошибки будут на английском.

Для их руссификации нужно скачать файлы с переводами.

Архив распаковываем в папку \application\language\russian.

Всё. На этом работа заканчивается. Названия этих файлов совпадают с названиями их английских версий, поэтому CodeIgniter загрузит их автоматически.

Заключение.

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

Для этого нужно найти и исправить весь русский текст в исходниках баг трекера. А их довольно много. Это и файлы шаблонов, и сообщения в контроллере, и текст в представлениях.

Я не ставил задачи сделать мультиязычное приложение, но если этот пункт для вас важен, в CodeIgniter входит Language Helper для этих целей. Использовать его не сложно, самый трудоёмкий этап – создание файлов с переводами. И нужно внимательно следить, чтобы в исходниках проекта напрямую не был жестко прописан текст.

До встречи!

P.S. Думаю, к следующему выпуску будет готова демонстрационная версия баг трекера. И безусловно выложу архив файлами проекта.

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

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

]]>

Добавьте эту страницу в google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

]]>

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

]]>
  • Big_Shark
    Легче всего и лучше всего использовать разные шаблоны для разных языков.
    Так как 1 предложения по русски может быть короче в несколько раз чем на английском и так далее.

    Жалко что стандартный wiev очень слабый в КИ
    хотелось бы поддержки шаблонов и layout.
  • Скорее на английском фраза будет короче :)

    В принципе к CI можно подключить сторонний шаблонизатор, тот же smarty.

    разные шаблоны для разных языков


    Может быть комбинировать оба подхода? В любом случае для сообщений встроенный библиотек нужны файлы с переводами.
  • Big_Shark
    Это верно.
    Смарти никогда не буду использовать в своих проектах.
    Я использую нативные шаблоны под типа встроеных в CI но им не хватает ряда изменений.
  • По идее, чем больше возможностей у шаблонизатора, тем он тяжелее. Поэтому приходится выбирать.
  • Полностью согласен. Возможность перевода нужно закладывать изначально.
    В этом баг трекере я такой цели не ставил (может зря?), поэтому и жизнь себе упростил.
    И все-таки в данном случае создание файлов перевода займет больше времени. Это же не CMS и кода не много ;)
  • SM
    Точно про проектирование подметил.
    У меня обычно на него до 30% всего времени работы над проектом уходит. Затом потом все просто, тупо кодирование и отлов ошибок
  • Недавно MaxSite после года разработки переводили на многоязычные рельсы. И повыковыривать из исходников жёстко прописанный вывод по русски и повставлять вместо этого вывод через функцию локализации — оказалось чертовски занудной работой. ГОРАЗДО более занудной, чем создание файлов с переводами.
    Аналогично LiveStreet между 0.2 и 0.3 версиями.
    Поэтому мой совет тем, кто хотя бы в отдалённой перспективе предполагает перевод своих приложений на другие языки — изначально закладывать многоязычность и сразу писать вывод сообщений из языковых файлов, а не напрямую.
    Проектирование рулит.
blog comments powered by Disqus ]]>