Потратил несколько часов на переделку своих контроллеров и i18n-файлов. Как оказалось, в метод errors() объекта Validation можно передать параметр $filename (имя i18n-файла), после чего ошибки будут переданы в виде строки ‘filename.fieldname.rule‘.
Напомню, что многие параметры в Kohana (lang-ресурсы, настройки конфигурации), хранящиеся в виде массивов, доступны в виде строки segment1.segment2.segment3….segmentN, например Kohana::config(‘database.default.connection’) — это элемент $config['default']['connection'] из файла config/database.php.
Чем это удобно? Мы можем группировать ресурсы логически:
// i18n/ru_RU/forum.php $lang = array ( 'username' => array ( 'label' => 'Логин', 'required' => 'Логин не введен', 'length' => 'Логин слишком короткий', 'username_available' => 'Логин занят', 'default' => 'Неизвестная ошибка в логине', ), 'registration' => array ( 'title' => 'Регистрация пользователя', 'result_ok' => 'Аккаунт создан успешно', 'result_sent' => 'Письмо с кодом активации отправлено на адрес %s', ), ); $lang['captcha'] = Kohana::lang('captcha'); // i18n/ru_RU/captcha.php $lang = array ( 'label' => 'Защита от ботов', 'valid' => 'Вы неправильно ввели код', 'required' => 'Вы не ввели код защиты от ботов', ); |
Как видите, мы сгруппировали ресурсы для поля username (тексты ошибок в случае непрохождения валидации, текст метки для html-тэга label и т.д.). В дальнейшем мы можем использовать их и в других процедурах, где используется данное поле. Обратите внимание, что правила валидации пишем как есть (‘required‘, ‘valid‘ и т.д.), в том числе и для собственных правил (username_available для модели Auth). Если какой-либо ресурс не найден, то будет использован ключ ‘default‘ (например ‘captcha.default‘). Таким образом, вместо доброго десятка ресурсов можно просто указать дефолтный с какой-либо общей ошибкой.
Также посмотрите на последнюю строчку файла forum.php. Дело в том, что если на форме присутствует каптча, то я обычно добавляю для нее правило в модели, соответственно в методе errors() имя lang-файла будет соответствовать остальным полям (‘forum‘, а не ‘captcha‘). Поскольку плодить одинаковые массивы ресурсов для каптчи я не хочу, просто делаю копию из другого файла. Теперь Kohana::lang(‘captcha.required’) и Kohana::lang(‘forum.captcha.required’) вернут одно и то же.
А что за группа ресурсов ‘registration‘? Это объединенные в массив ресурсы для процесса регистрации пользователей. Действительно, что нам мешает? Вместо отдельных громоздких ‘forum.registration_label‘, ‘forum.registration_result_ok‘ и т.д. мы логически собрали все в один компактный массив. Так и добавлять ресурсы удобно, и быстро найти отдельные строчки можно.
Loading ...
Оу, а вы как без этого раньше жили? В кохана такое элегантное решения, что я даже не думав в ту сторону велосипедить. В документации кажется оно есть.
Сам не знаю
Как увидел, чего я лишался почти полгода…
зачем присутствуют строки:
‘label’ => ‘Логин’,
то есть как или где используется ‘label’?
и почему нигде нет ‘default’?
Он используется во вьюшке (тэг LABEL). ‘default’ использовать необязательно, если перечислены все возможные переводы (а они по сути состоят из правил для validate() и используемых в шаблонах или контроллерах текстовых ресурсах).
например в файле auth/models/auth_user.php
вижу строку
78: $array->add_error(‘username’, ‘invalid’);
этого кода нет в примере выше
поэтому лучше добавить
‘default’ => ‘Не правильный логин’
ну или что-то такое
Ну, не перечислять же все возможные варианты в заметке, посвященной несколько другой теме
Я просто вслух выругался, что пропустил такую удобную возможность, как встроенный механизм взаимодействия validation и i18n.
Кстати, ‘default’ тогда уж должен содержать что-то типа ‘Неизвестная ошибка’, чтобы не запутывать лишний раз пользователя.
уже есть
‘unknown_error’ => ‘Неизвестная ошибка при валидации поля %s.’
так, что лучше все же конкретнее для данного поля
‘default’ => ‘Неправильный логин’
а про ‘default’ надо было упомянуть иначе картина не полная
Честно говоря, не знаю, в каком случае может быть возвращена ошибка ‘unknown_error’, т.к. по умолчанию будет использован как раз-таки ‘default’ … В общем, тут дело вкуса, я предпочитаю предусмотреть все возможные ошибки, хотя подстраховаться не помешает.
По поводу ‘default’ дополню статью, спасибо.