I am also not a big proponent to switching languages (like reverting to English after Swahili (for instance) has failed). At least, not in development environment. When developing I want to spot missing translations easily. A translation missing message is easier to spot. I can understand why you'd want that in production though: at least show some text then none. In fact, I always raise translation missing errors during development, just to make sure I don't forget something.
So, I would do it with a config option: I18n.fallback :to => :generic_locale I18n.fallback :to => :sister_locale I18n.fallback :to => :default_language if Rails.env.production? Might even introduce a lowest level: just humanize the key. I18n.fallback :to => :humanize if Rails.env.production? And while I'm brainstorming, specify fallback order, to set prejudice of sister locales: I18n.fallback_order += [ 'es-MX', 'es', 'en-US', :en ] or use globalize2 syntax: I18n.fallbacks.map :sms => [:"se-FI", :"fi-FI"] Iain On Jan 14, 4:26 pm, Kip <[email protected]> wrote: > Chris, good ideas (I'm new to this conversation). I think there's a > new function to get the available locales in I18n which would allow > this to work without breaking interfaces (need that to find out the > sister locales that are available). Very easy to update to accomplish > that. > > The inclusion of a non-same-language fallback (ie. from fr to en) > sounds a little more problematic from a user experience perspective > doesn't it? So perhaps an option to allow that fallback would be > required - but that then would change the interface to > I18n#translate. Do you have some thoughts on this and what would be > appropriate? > > Cheers, --Kip > > On Jan 15, 1:53 am, Chris Cruft <[email protected]> wrote: > > > This fallback functionality was discussed substantially in Globalize > > last year -I was a big proponent. It is very much needed for real- > > word apps. However, I would suggest a three (or four) level hierarchy > > of preference: > > > In decreasing order of preference: > > > 1. The specified language (fr-CA in this example) > > 2. The related "generic" language (fr) > > 3. Any related "sister" language (fr-FR or fr-CH) > > 4. The overall default language (en-US) > > > I like looking at the "fallback" concept this way as it encompasses > > the existing default language of the app as well. And including > > "sister" languages means that an app that already has en-US > > translations can support en-GB (and such) with no difficulty. > > > -Chris > > > On Jan 13, 10:11 pm, Kip <[email protected]> wrote: > > > > I've uploaded a small rails plugin that changes the behaviour of > > > I18N#translate which attempt to lookup a translation in a broader > > > locale if the current translation fails. The idea is to be able to > > > maintain only small localization files for regional differences (where > > > appropriate). Example: the differences between en-US, en-UK, en-CA, > > > en-AU are miniscule. Duplicating then maintaining the content is not > > > much fun. > > > > With this plugin, I18N#translate will do the folllowing: > > > > 1. Lookup in the current locale (or the one supplied in options to > > > #translate) > > > 2. If not found, look in the broader locale if one exists. > > > > If our locale is "en-UK", look first in "en-UK", then in "en" (which, > > > for english speakers, is helpful since Rails supplies defaults for > > > this locale). > > > > Git repository is > > > at:http://github.com/kipcole9/rails-i18n-translation-inheritance-helper/... > > > > Cheers, --Kip > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
