Hi Kip, On 14.01.2009, at 23:46, Kip wrote: > 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.
Sorry. I really didn't want to come along blunt. If I did, please accept my apologies. Maybe I shouldn't write such emails while being feverish. > 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 believe this is exactly what we need to bring rails-i18n support forward: people feeling passionate about a certain feature, implementing their ideas as a plugin (or whatever library) and publishing them so that everybody can discuss and try them out. So maybe I should have stressed that not including something into core at this point doesn't mean to me that it's not useful or could never go into core or any such thing. For me it just means that I feel we need more experience, maybe concurrent implementations etc. to find out what we really want in core. > 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...... Awesome. I'm looking forward to read about your findings. I've linked your plugin on the rails-i18n wiki: http://rails-i18n.org/wiki Thanks for the great contribution! > > > 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 -~----------~----~----~----~------~----~------~--~---
