Каковы хорошие стратегии организации файлов локализации для 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 это может упростить файлы перевода. Тем не менее, забота об умной файловой структуре и хорошо организованных текстах является плюсом.
Решение
Мое предложение было бы использовать параметр параметризованного перевода в 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'
или же
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.... в этом случае)
У меня похожая проблема и я разместил вопрос
об этом.
К сожалению, также не было большого интереса к этой теме.
Другие решения
Других решений пока нет …