José, I've been thinking along the same lines as well. In addition, it seems to me that locale files are quite static for many applications and hence this deep merge could actually be done as a rake task. Something similar is done in the asset_packager plugin for javascript and css files.
You would have a source directory structure of locales that are as skinny as you can make then. In a config file specify the fallback chain for any locale. Then a rake task to merge and output the production locale files. This way, as you say, only one lookup, still maintain fallback but not have a performance hit. I'll experiment with this over the next few days and see where I get to. Cheers, --Kip On Jan 16, 12:14 am, José Valim <[email protected]> wrote: > > José, I worry about the performance for the same reasons you do. Best > > I could do is to cache the fallback_chain so it's only calculated once > > (per instance). But I agree, performance will be twice as bad on > > average since most keys will be in the broader locale. > > Kip, my point about performance is that you can merge locales when the > enviroment is loaded. > For example, if you have both "en-UK" and "en" locales, when your > Rails application starts you could do: > > en_uk_locale = en_locale.deep_merge(en_uk_locale) > > Then you will have all keys in "en-UK" locale and won't have to search > in "en" locale. > > I18n backend already have a method called merge_translations that does > a deep_merge. > So it probably won't need a lot of changes. > > -- > José Valimhttp://josevalim.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rails-i18n" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rails-i18n?hl=en -~----------~----~----~----~------~----~------~--~---
