问题描述
我想知道 Laravel 5.1的trans()功能的键命名的最佳做法是什么?
I would like to know which are the best practices for key naming for the trans() function of Laravel 5.1 ?
考虑到内置的Laravel翻译存储在一个数组中，我担心的是哪种层次结构允许我实现以下目标:
Considering that built-in Laravel translations are stored into an array, my concern is which hirearchy allows me to achieve the following goals:
一致性:因此，我将使用具有相同含义的不同单词或创建许多最终具有相同翻译(例如常见单词)的不同键的可能性降到最低.
consistency: So I minimize the possibility of using different words for the same meaning, or creating many different keys that end up having the same translation (like common words).
可重用性:因此，我将翻译文件的总大小最小化，并尽可能减少翻译，并保持灵活性.
reusability: So I minimize the overall translation files size and translate as less as possible, and preserve flexibility.
可读性:因此，即使在缺乏翻译价值的情况下，翻译人员也可以确定密钥的用途.
readability: So translators can identify the purpose of the key even under lack of the translation value.
组织:开发人员可以轻松记住完整的密钥路径，并最小化每次检查翻译文件的次数.
organization: So developer can easily remember the full key path and minimize checking the transalation files each time.
举个例子，假设我要为管理配置文件命名用户模型更新成功的警报.可能的方法是:
To give an example, lets say I want to name a successful alert for User model update, for a management profile. Possible approaches are:
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年11月，看起来 Laravel 5.4正在引入JSON的翻译机制，可以简化翻译文件.不过，更需要精巧的文件结构和井井有条的文字.
By Nov-2016, it looks like Laravel 5.4 is introducing a JSON based translation mechanism that might simplify translation files. Still, caring for smart file structure and well organized texts are a plus.
推荐答案
我的建议是在Laravel中使用参数化翻译选项.
My suggestion would be to use the parametrized translation option in Laravel.
我建议采用这样的结构:
I would suggest having a structure like this:
对于通用且可重复使用的内容:
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...之类的一般内容开始.
The thinking is that for something that is specific for the manager like having a update-successfull message that is likely to be different than other update-successfull messages that you should start with something specific like: manager.alerts....In generic cases (where the same message could be used in multiple use-cases) You should start with something generic like messages.alerts.update....
在我看来，应避免使用trans('alert.the_user_was_updated_successfully')之类的名称，因为当您想更改消息时，您可能会遇到大问题.然后，该键仍将反映旧值，而该值将是新值.
Naming like trans('alert.the_user_was_updated_successfully') should be avoided in my opinion because You could have a BIG problem when you want to change a message. The key would than still reflect the old value while the value would be new.
关于您的目标:
一致性和可重用性:将重复复制一定数量的内容.那是无法避免的.但是，可以通过结构化内容并通过使用带有常见单词和短语的文件来使此问题最小化. commons.words commons.phrases或2个文件(单词和短语)，带有几个类别.示例:commons.time.day , commons.hello_world ...
consistency and reusability: A certain amount of content will be duplicated. That cannot be avoided. However this problem can be minimized by structuring content and by having a file(s) with common words and phrases eg. commons.words commons.phrases or 2 files (words, and phrases) with a few categories. Example: commons.time.day , commons.hello_world ...
可读性:这将是一个问题，除非您为翻译器提供一个已经具有其所有值的文件(使用他/她可以从其翻译的默认或起始语言).我真的不明白为什么您没有最初的翻译/内容.
readability: This will be a problem unless you give the translator a file that already has all of its values (in the default or starting language from which he/she can translate from). I really don't see why you wouldn't have an initial translation/content.
组织:您必须像开发人员一样尝试并思考.如果您要查找特定的内容，您将尝试并尝试在该特定主题下查找某些内容(在这种情况下为manager.alerts....)但是如果您要搜索更通用的内容，则您更有可能搜索通用的内容(在这种情况下为messages.alerts....)
organization: You have to try and think like you would in the skin of a developer. If you are trying to find something specific you will thing and try to find something something under that specific subject (manager.alerts.... in this case)but if You are searching for something more generic you are more likely to search for something generic (messages.alerts.... in this case)
我有一个类似的问题，并发布了问题关于它.不幸的是，对该主题也没有太多兴趣.
I have a similar issue and have posted a questionabout it.Unfortunately there has also not been much interest in the subject.
这篇关于在Laravel 5.x中组织trans()的本地化文件的哪些好策略是?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！