Как стать автором
Обновить

Комментарии 12

А чем не устроил стандартный вариант?
Зачем плодить целую кучу одинаковых контроллеров, если можно использовать __() и менять язык через I18n::lang()?
Извините, но Вы видимо вообще не читали статью, так что даже не знаю, что ответить))
Извиняюсь, видимо устал и не сразу понял некоторые моменты…

Тогда еще вопрос
// если не совпадает перенаправляем
if ( $lang_uri != LANG ) {
     $this->request->redirect(LANG);
}

Не кажется ненужным?

Если я зашел через прокси Германии, то я теперь на русском не смогу посмотреть сайт?
Ведь даже если я попытаюсь перейти на ru-версию, меня перенаправит обратно на немецкую.
// если не совпадает перенаправляем
if ( $lang_uri != LANG ) {
     $this->request->redirect(LANG);
}

Это нужно, потому что мало ли пользователь должен всегда видеть «правильный» язык.

Конечно можно, это пользователь может сам уже может выбрать — обычно в шапке есть выпадающий список, где каждый язык написан по родному: Русский, English, Deutsch. При изменении записывается кука и тогда метод lang() выдает выбранный язык для пользователя.

Но при первом посещении сайта, пользователь из Германии, конечно, увидит сайт на немецком.
Неужели в кохане нельзя установить базовый префикс для всех роутов?
Конечно можно. Задается через base_url в Kohana::init.
Ну а там же нельзя, в таком случае, определить язык для модуля перевода и не писать его в каждом роуте, как ТС?
Язык можно определять до вызова Kohana::init.
Язык пользователя также можно определить через $_SERVER['HTTP_ACCEPT_LANGUAGE']. Метод не 100%, но при этом не нужна база ip.
Ну, да это уже дело каждого, как определять язык пользователя, я выделил это в метод lang(), где каждый может это делать по своему усмотрению.
Почему для action ставятся ограничения, а для lang нет? Например чтобы он был например не больше двух символов или 'lang' => 'ru|en|de'
Не совсем понял, почему I18n::lang() должен устанавливать язык в зависимости от контроллера. То есть перевод одной и той же кнопки в шапке будет разным для разных страниц (точнее, он будет продублирован в разных файлах)?

Если говорить о роутинге, вероятно лучше было бы создать отдельные классы (Route_I18n, HTML_I18n) для работы с такими адресами, и в них завернуть всю необходимую функциональность. Константа LANG тоже неправославна, хотя бы из-за возможного конфликта с подключенными вендорными библиотеками.

Ну и, конечно, вопрос перевода контента не раскрыт. По сути, все вышеописанное позволяет делать легкий перевод интерфейса. И то, иногда бывает удобнее создать отдельные шаблоны для разных языков, чем дергать постоянно __() для отдельных элементов), тут напрашивается класс View_I18n, который бы проверял наличие шаблона для текущего языка. И тд
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.