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. I think my key objective is to find a way to have one level of fallback execute as close as possible to a non-fallback translation.
Sven: you expose me as a newbie on this for sure. More than happy to keep experimenting in plugins. Like many people, I'm working on my first i18n rails app, learning as I go. And this will probably provoke a lot of experimentation to balance function, peformance and maintainability. I want the skinniest implementation with the least overhead and best function :-) I have a few ideas around scoping translating keys to different locales which would then mean only a single translation lookup at the expense of having to calculate which locale to use. I'll report back hear after I try some more experiments. Now back to reading RFC 4647...... Cheers, --Kip On Jan 15, 8:33 am, Sven Fuchs <[email protected]> wrote: > Honestly I'd abstain from baking any such mechanism into core ... > until we really have solid experience with trying our ideas out in > plugins. There are lots of issues to dig up. So, let's have people > actually try out and use what we think are good idea - especially in > an area like this. > > Also, let me point you to Globalize2 :) It has Locale fallbacks baked > in. > > There are standards for these things, e.g. look up RFC 4647 ... we're > not the first to think about these things ;) > > Maybe we could think about a hook in I18n that let's you hook up > fallback logic, but I wouldn't ship any default behaviour, yet. Then > again, we already have the execption_handler for simple cases and you > can easily extend the backend class and use it for more complex cases. > > (I'm aware that we need to fix the backend for that because of the bug > discussed in the other thread.) > > On 14.01.2009, at 21:53, José Valim wrote: > > > > >> 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 think this is too complex. > > > IMHO, this should work exactly as class inheritance: if two classes > > are children of the same class, when a method is missing in one of > > them, they search only in the parent, never in the "sisters". > > > And I also agree with Kip that is strange falling from fr to en. > > > So I think that Kip implementation, at least in terms of features, is > > great. :) > > > I'm just worried with performance. In Kip example, almost all > > translations are kept in the parent and in theory it's twice slower. > > But we could fix that easily by merging language files when Rails is > > started in production. On the other hand, it would consume more > > memory. :) > > > And Sven, can we bake into I18n core a method that would return the > > "broader locale"? > > > I18n.locale = 'en-US' > > I18n.broader_locale #=> 'en' > > > I'm using this in Localized Templates and Kip is using also. This is > > probably needed. :) > > > -- > > José Valim > >http://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 -~----------~----~----~----~------~----~------~--~---
