i18n - 创建语言文件时使用哪些命名约定？
我正在开发一个需要 i18n 支持的 CMS。翻译字符串作为数组存储在语言文件（即 en.php）中。是否有任何命名约定......
我如何改进下面的示例语言文件......
// General
'general.title' => 'CMS - USA / English',
'general.save' => 'Save',
'general.choose_category' => 'Choose category',
'general.add' => 'Add',
'general.continue' => 'Continue',
'general.finish' => 'Finish',
// Navigation
'nav.categories' => 'Categories',
'nav.products' => 'Products',
'nav.collections' => 'Collections',
'nav.styles' => 'Styles',
'nav.experts' => 'Experts',
'nav.shareyourstory' => 'Share Your Story',
// Products
'cms.products' => 'Products',
'cms.add_product' => 'Add Product',
// Categories
'cms.categories' => 'Categories',
'cms.add_category' => 'Add Category',
// Collections
'cms.collections'=> 'Collections',
'cms.add_collections' => 'Add Collection',
// Stylists
'cms.styles' => 'Stylists',
'cms.add_style' => 'Add Style',
'cms.add_a_style' => 'Add a style',
// Share your story
'cms.share_your_story' => 'Share Your Story',
// Styles
'cms.add_style' => 'Add Style',
I'm developing a CMS that required i18n support. The translation strings are stored as an array in a language file (ie, en.php). Are there any naming conventions for this..
How can I improve on the sample language file below...
// General
'general.title' => 'CMS - USA / English',
'general.save' => 'Save',
'general.choose_category' => 'Choose category',
'general.add' => 'Add',
'general.continue' => 'Continue',
'general.finish' => 'Finish',
// Navigation
'nav.categories' => 'Categories',
'nav.products' => 'Products',
'nav.collections' => 'Collections',
'nav.styles' => 'Styles',
'nav.experts' => 'Experts',
'nav.shareyourstory' => 'Share Your Story',
// Products
'cms.products' => 'Products',
'cms.add_product' => 'Add Product',
// Categories
'cms.categories' => 'Categories',
'cms.add_category' => 'Add Category',
// Collections
'cms.collections'=> 'Collections',
'cms.add_collections' => 'Add Collection',
// Stylists
'cms.styles' => 'Stylists',
'cms.add_style' => 'Add Style',
'cms.add_a_style' => 'Add a style',
// Share your story
'cms.share_your_story' => 'Share Your Story',
// Styles
'cms.add_style' => 'Add Style',
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我见过的一个有趣的选择是使用英文字符串本身作为键：
需要注意的一些要点：
cms.styles在应用中错误地显示为Stylists。但是'Styles' => “造型师”非常引人注目，尤其是对于单行审核脚本而言。Category等术语出现在不同的位置而重复它们。One interesting option I've seen is to use the English strings themselves as the keys:
Some points to note:
cms.stylesincorrectly appears asStylistsin the app. But'Styles' => 'Stylists'stands out like a sore thumb, particularly to a one-line auditing script.Categoryjust because they appear in different places.关于文件命名约定，您可能需要使用 ISO 639-2 Alpha 3 代码：
http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
With regards to file naming conventions you might want to use ISO 639-2 Alpha 3 codes :
http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
使用英语单词作为键可以很好地发挥作用，但是稍后您可能会遇到问题。随着应用程序的增长，您可能需要开始为键命名，以便更容易找到它们，例如通过控制器和操作/目的/上下文。
示例：如果您有一个带有关键“类别”的翻译，这将阻止诸如“categories.flashes.failure”之类的命名空间，这些命名空间对开发人员来说是有表达力的，但又不会与文本过于紧密地联系在一起。
这是我处理上面示例的方法，假设没有 WordsController ；-)
这也使得编写不涉及翻译的测试变得更容易。
Using English words as keys can work well, however you may run into issues later. As the app grows, you may want to start namespacing your keys so they're easier to find, eg by controller and action/purpose/context.
Example: If you have a translation with key "categories", that would would prevent namespacing things like "categories.flashes.failure", which are expressive to the developer without being too closely tied to the text.
Here's how I'd handle the above example, assuming there's no WordsController ;-)
This also makes writing tests which aren't concerned with translations easier.
您也可以使用 gettext 代替。
You could also use gettext instead.