i18n - What are some naming-convention to use in creating language files?

Question

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',

Answer 1

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

Answer 2

You could also use gettext instead.

Answer 3

One interesting option I've seen is to use the English strings themselves as the keys:

// General
'CMS - USA / English' => 'CMS - USA / English',
'Save' => 'Save',
'Choose category' => 'Choose category',
...

Some points to note:

1. This makes the application code more readable, and more transparent to the developer. The developer might not notice that cms.styles incorrectly appears as Stylists in the app. But 'Styles' => 'Stylists' stands out like a sore thumb, particularly to a one-line auditing script.
2. It is more fragile, since changes to the English text affect all the other language files. It should fail quite noisily, however, so it's easy to spot.
3. It is more robust, since the production system can trivially fall back to the English text if testing failed to spot an omission.
4. You don't have to repeat terms like Category just because they appear in different places.

Answer 4

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 ;-)

t(:'words.categories', :default => 'Categories')

This also makes writing tests which aren't concerned with translations easier.