Каковы хорошие стратегии организации файлов локализации для trans() в Laravel 5.x?

Это вопрос о методологии и предлагаемых практиках. Я знаю, что он не привязан строго к фреймворку и даже не к PHP, и ответ может быть «это зависит от вас». Но я беспокоюсь о лучших практиках и методологии, поскольку обычно существует лучший подход для определенного контекста.

Я хотел бы знать, как лучше всего использовать именование клавиш для функции trans() в Laravel 5.1?

Учитывая, что встроенные переводы Laravel хранятся в массиве, меня беспокоит то, какая иерархия позволяет мне достичь следующих целей:

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

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

читабельность. Таким образом, переводчики могут определить назначение ключа даже при отсутствии значения перевода.

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


В качестве примера предположим, что я хочу назвать успешное оповещение об обновлении модели пользователя для профиля управления. Возможные подходы:

trans('manager.user.update.alert.sucess')

trans('alerts.success.manager.user.update')

trans('manager.user.alert.update.success')

trans('alert.the_user_was_updated_successfully')

Обновить

К ноябрю 2016 года похоже, что Laravel 5.4 представляет механизм перевода на основе JSON. это может упростить файлы перевода. Тем не менее, забота об умной файловой структуре и хорошо организованных текстах является плюсом.


person alariva    schedule 03.08.2015    source источник


Ответы (1)


Мое предложение состояло бы в том, чтобы использовать вариант параметризованного перевода в Laravel.

Я бы предложил такую ​​структуру:

Для общего контента, который можно использовать повторно:

trans('messages.alerts.update.success', ['item' => 'User']);   // results in: 'User has successfully been updated'
trans('messages.alerts.update.success.default');               // results in: 'Updated was successfull.'

Для контента, который строго связан с определенной областью/проблемой... (в данном случае с менеджером):

trans('manager.alerts.update.user.success');   // results in: 'User has successfully been updated'

or

trans('manager.alerts.update.success', ['item' => 'User']);   // results in: 'User has successfully been updated'
trans('manager.alerts.update.success.default');               // results in: 'Updated was successfull.'

Мысль заключается в том, что для чего-то, что специфично для менеджера, например, сообщения об успешном обновлении, которое, вероятно, будет отличаться от других сообщений об успешном обновлении, вы должны начинать с чего-то определенного, например: manager.alerts.... В общих случаях (где одно и то же сообщение может использоваться в нескольких вариантах использования) вы должны начать с чего-то общего, например messages.alerts.update....

На мой взгляд, следует избегать имен вроде trans('alert.the_user_was_updated_successfully'), потому что у вас могут возникнуть БОЛЬШИЕ проблемы, когда вы захотите изменить сообщение. Ключ по-прежнему будет отражать старое значение, а значение будет новым.

Относительно Ваших целей:

согласованность и повторное использование: определенное количество контента будет дублироваться. Этого нельзя избежать. Однако эту проблему можно свести к минимуму путем структурирования контента и наличия файла(ов) с общими словами и фразами, например. commons.words commons.phrases или 2 файла (слова и фразы) с несколькими категориями. Пример: commons.time.day , commons.hello_world ...

читабельность: это будет проблемой, если вы не дадите переводчику файл, в котором уже есть все его значения (на языке по умолчанию или на исходном языке, с которого он/она может переводить). Я действительно не понимаю, почему у вас нет первоначального перевода/контента.

организация. Вы должны попытаться думать так, как если бы вы были в шкуре разработчика. Если вы пытаетесь найти что-то конкретное, вы будете думать и пытаться найти что-то по этой конкретной теме (manager.alerts.... в этом случае), но если вы ищете что-то более общее, вы, скорее всего, будете искать что-то общее (messages.alerts.... в этом случае). )

У меня похожая проблема, и я опубликовал вопрос об этом. К сожалению, особого интереса к этой теме также не было.

person Traveller    schedule 11.11.2015
comment
спасибо за Ваш ответ. Я действительно знал ваш вопрос со вчерашнего дня. Я согласен с вашим подходом, и ints сортирует то, как я справляюсь с этим до сих пор. - person alariva; 11.11.2015
comment
Не согласен, если у вас есть, например, сообщение ok как на manager.alert, так и на common.alert. вы должны перевести его для каждой части проекта. и все же это ничто по сравнению с кошмаром, с которым вы столкнетесь, пытаясь выяснить, к какой категории относится сообщение, каждый раз, когда вы хотите что-то записать. Категоризация сообщения по части проекта неверна. вы должны относиться к сообщениям независимо от того, в какой части они используются. - person Hossein Shahdoost; 24.11.2015
comment
@Hossein Shahdoost Но в том-то и дело, что вы в первую очередь должны иметь это сообщение в общем доступе (для общего контента), и только если возникнет необходимость в конкретном, вы поместите его в конкретное. Общее в общем, конкретное в конкретном - person Traveller; 24.11.2015
comment
@Traveller, тогда что делает сообщение конкретным и что делает его общим? и это не только первая часть, все остальные подкатегории, которые вы используете, могут вызвать дублирование. - person Hossein Shahdoost; 24.11.2015
comment
@Hossein Shahdoost Иногда содержимое (например, сообщения) должно немного отличаться в зависимости от контекста, но не быть одинаковым. Например: сообщение о том, что пароль недостаточно надежен, в большинстве случаев может быть простым ("пароль недостаточно надежен"), но также может иметь похожие варианты в зависимости от контекста (пароль должен содержать хотя бы одну цифру... , пароль должен состоять из x символов, пароль пользователя должен быть... или «пароль администратора должен быть более надежным) - person Traveller; 24.11.2015
comment
@Hossein Shahdoost У вас не будет дублированного контента, у вас будет сообщение «ОК» в административной части, только если оно должно отличаться от общего. Сначала вы должны заполнить общую часть общим контентом и только после этого добавить конкретный контент в конкретную часть, если в этом возникнет необходимость. - person Traveller; 24.11.2015