Комментарии 12
А чем не устроил стандартный вариант?
Зачем плодить целую кучу одинаковых контроллеров, если можно использовать __() и менять язык через I18n::lang()?
Зачем плодить целую кучу одинаковых контроллеров, если можно использовать __() и менять язык через I18n::lang()?
Извините, но Вы видимо вообще не читали статью, так что даже не знаю, что ответить))
Извиняюсь, видимо устал и не сразу понял некоторые моменты…
Тогда еще вопрос
Не кажется ненужным?
Если я зашел через прокси Германии, то я теперь на русском не смогу посмотреть сайт?
Ведь даже если я попытаюсь перейти на ru-версию, меня перенаправит обратно на немецкую.
Тогда еще вопрос
// если не совпадает перенаправляем
if ( $lang_uri != LANG ) {
$this->request->redirect(LANG);
}
Не кажется ненужным?
Если я зашел через прокси Германии, то я теперь на русском не смогу посмотреть сайт?
Ведь даже если я попытаюсь перейти на ru-версию, меня перенаправит обратно на немецкую.
// если не совпадает перенаправляем
if ( $lang_uri != LANG ) {
$this->request->redirect(LANG);
}
Это нужно, потому что мало ли пользователь должен всегда видеть «правильный» язык.
Конечно можно, это пользователь может сам уже может выбрать — обычно в шапке есть выпадающий список, где каждый язык написан по родному: Русский, English, Deutsch. При изменении записывается кука и тогда метод lang() выдает выбранный язык для пользователя.
Но при первом посещении сайта, пользователь из Германии, конечно, увидит сайт на немецком.
Неужели в кохане нельзя установить базовый префикс для всех роутов?
Язык пользователя также можно определить через $_SERVER['HTTP_ACCEPT_LANGUAGE']. Метод не 100%, но при этом не нужна база ip.
Почему для action ставятся ограничения, а для lang нет? Например чтобы он был например не больше двух символов или 'lang' => 'ru|en|de'
Не совсем понял, почему I18n::lang() должен устанавливать язык в зависимости от контроллера. То есть перевод одной и той же кнопки в шапке будет разным для разных страниц (точнее, он будет продублирован в разных файлах)?
Если говорить о роутинге, вероятно лучше было бы создать отдельные классы (Route_I18n, HTML_I18n) для работы с такими адресами, и в них завернуть всю необходимую функциональность. Константа LANG тоже неправославна, хотя бы из-за возможного конфликта с подключенными вендорными библиотеками.
Ну и, конечно, вопрос перевода контента не раскрыт. По сути, все вышеописанное позволяет делать легкий перевод интерфейса. И то, иногда бывает удобнее создать отдельные шаблоны для разных языков, чем дергать постоянно __() для отдельных элементов), тут напрашивается класс View_I18n, который бы проверял наличие шаблона для текущего языка. И тд
Если говорить о роутинге, вероятно лучше было бы создать отдельные классы (Route_I18n, HTML_I18n) для работы с такими адресами, и в них завернуть всю необходимую функциональность. Константа LANG тоже неправославна, хотя бы из-за возможного конфликта с подключенными вендорными библиотеками.
Ну и, конечно, вопрос перевода контента не раскрыт. По сути, все вышеописанное позволяет делать легкий перевод интерфейса. И то, иногда бывает удобнее создать отдельные шаблоны для разных языков, чем дергать постоянно __() для отдельных элементов), тут напрашивается класс View_I18n, который бы проверял наличие шаблона для текущего языка. И тд
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kohana 3.2: организация мультиязычности