I’ve found that the best overall strategy is to somewhat reproduce the file structure so that given any translation, I can immediately find where it was called from. This gives me some kind of context for making the translation.
The majority of application translations are found in views, so my biggest top level namespace is usually views.
I create sub namespaces for the controller name and the action name or partial being used ex :
views.users.index.titleviews.articles._sidebar.header
Both of these examples should make it obvious what part of my app we’re translating and which file to look in to find it.
You mention navigation and buttons, if they are to be generic, then they belong in the views.application namespace just as do their view counterparts :
views.application._main_nav.links.about_us– a link in our app’s main navigation partialviews.application.buttons.saveviews.application.buttons.create– I have a bunch of these buttons ready to be used when needed
Flash messages are generated from the controller, so their top level namespace is… controllers! 🙂
We apply the same logic as we do to views :
controllers.users.create.flash.success|alert|notice
Again if you wanted to provide generic flash messages like “Operation successful”, you would write something like this :
controllers.application.create.flash.notice
Finally, keys can be anything that is valid YAML, but please stick to using periods . as separators and underscores _ between words as a matter of convention.
The only thing left to sort out now, is getting rails’ translations into its own namespace to clean up our top level 🙂