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

24 марта, 2009
bug_tracker_logo_part9

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

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

По-умолчанию 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. Думаю, к следующему выпуску будет готова демонстрационная версия баг трекера. И безусловно выложу архив файлами проекта.

Понравилась статья? Подписывайтесь на продолжение 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 разработка Комментарии (14) »

]]>

Вы можете оставить комментарий. Трекбеки закрыты.

  • http://wave.fantregata.com/ Wave

    Недавно MaxSite после года разработки переводили на многоязычные рельсы. И повыковыривать из исходников жёстко прописанный вывод по русски и повставлять вместо этого вывод через функцию локализации — оказалось чертовски занудной работой. ГОРАЗДО более занудной, чем создание файлов с переводами.
    Аналогично LiveStreet между 0.2 и 0.3 версиями.
    Поэтому мой совет тем, кто хотя бы в отдалённой перспективе предполагает перевод своих приложений на другие языки — изначально закладывать многоязычность и сразу писать вывод сообщений из языковых файлов, а не напрямую.
    Проектирование рулит.

  • http://wave.fantregata.com Wave

    Недавно MaxSite после года разработки переводили на многоязычные рельсы. И повыковыривать из исходников жёстко прописанный вывод по русски и повставлять вместо этого вывод через функцию локализации — оказалось чертовски занудной работой. ГОРАЗДО более занудной, чем создание файлов с переводами.
    Аналогично LiveStreet между 0.2 и 0.3 версиями.
    Поэтому мой совет тем, кто хотя бы в отдалённой перспективе предполагает перевод своих приложений на другие языки — изначально закладывать многоязычность и сразу писать вывод сообщений из языковых файлов, а не напрямую.
    Проектирование рулит.

  • http://epavel.ru/ SM

    Точно про проектирование подметил.
    У меня обычно на него до 30% всего времени работы над проектом уходит. Затом потом все просто, тупо кодирование и отлов ошибок

  • http://epavel.ru SM

    Точно про проектирование подметил.
    У меня обычно на него до 30% всего времени работы над проектом уходит. Затом потом все просто, тупо кодирование и отлов ошибок

  • http://www.simplecoding.org/ Владимир

    Полностью согласен. Возможность перевода нужно закладывать изначально.
    В этом баг трекере я такой цели не ставил (может зря?), поэтому и жизнь себе упростил.
    И все-таки в данном случае создание файлов перевода займет больше времени. Это же не CMS и кода не много ;)

  • http://www.simplecoding.org/ Владимир

    Полностью согласен. Возможность перевода нужно закладывать изначально.
    В этом баг трекере я такой цели не ставил (может зря?), поэтому и жизнь себе упростил.
    И все-таки в данном случае создание файлов перевода займет больше времени. Это же не CMS и кода не много ;)

  • Big_Shark

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

    Жалко что стандартный wiev очень слабый в КИ
    хотелось бы поддержки шаблонов и layout.

    • http://www.simplecoding.org/ Владимир

      Скорее на английском фраза будет короче :)

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

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

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

      • Big_Shark

        Это верно.
        Смарти никогда не буду использовать в своих проектах.
        Я использую нативные шаблоны под типа встроеных в CI но им не хватает ряда изменений.

        • http://www.simplecoding.org/ Владимир

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

  • Big_Shark

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

    Жалко что стандартный wiev очень слабый в КИ
    хотелось бы поддержки шаблонов и layout.

    • http://www.simplecoding.org/ Владимир

      Скорее на английском фраза будет короче :)

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

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

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

      • Big_Shark

        Это верно.
        Смарти никогда не буду использовать в своих проектах.
        Я использую нативные шаблоны под типа встроеных в CI но им не хватает ряда изменений.

        • http://www.simplecoding.org/ Владимир

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

]]>
Tweet