On Apr 26, 11:13 pm, Sven Fuchs <[email protected]> wrote: > Hi Hongli, > > cool, that's a great writeup! Thanks for turning this discussion > towards more practical points :) > > Perhaps it helps when I also add some disclaimer about myself. I'm not > biased towards or against Gettext in any way, too. I've used it a lot > a quite some years ago. In fact it was me who repeatedly tried to get > Gettext people on board while we worked on Rails I18n. I do think > though that the API in fact is the best bread of all solutions for > Rails we had previously, including ruby-gettext. That of course > doesn't mean it can not be improved, but to me it means we should not > go back to a less flexible API. > > In your list I'd suggest that 9.) is just an example of a more > abstract point: "Symbols as keys" makes it possible to compute keys. > You can not compute default translations. Rails itself leverages that > for validation messages, I've seen people using it for "resourceful > controllers" (e.g. flash messages) and there are tons of other > situations where this is useful. Computing keys allows you to define a > generic translation that works for most of the situations and > overwrite that for particular situations where you need something > special - thus effectively reducing the amout of repetition a lot. You > can also react to contexts (e.g. pick a particular translation > depending on the type of an object) flexibly where you'd otherwise > need to use generic translations/messages. Thus, I believe that > "Symbols as keys" allow for a more abstract way of coding. > > I'd also suggest to add another pair of pro/con arguments to the list. > Using "defaults as keys" usually means that you have the actual > translations cluttered throughout your code. Of course, Gettext allows > you to "announce" translated strings through gettext_noop when you > want to collect messages at a central place but that requirement > really feels much more like jumping through hoops than just using > Symbols in the first place. > > (Also, I'd like to remind of the motivations that lead to such > solutions as Gibberish, Globalite (not Globalize) and > SimpleLocalization. People wanted a simple and clean API, they > explicitely did not want to mess with Gettext which was designed, > let's face it, in 1994 for C. It feels old and awkward to many.) > > I really wonder though if both approaches actually are mutually > exclusive, or mutually exclusive in all areas (Rails core, plugin > land, user/dev/app land). > > Imagine a helper like this: > > def _(msg) > I18n.t(msg, :default => msg) > end > > For pluralization there could be a similar helper. This should work > for all messages that do not contain a dot. I wonder if we can get rid > of this limitation. Approaches that come to my mind: > > 1. Make the scope separator (dot) configurable. That might mean that > Rails core should not continue using dots as separators (but instead > just use Arrays for scopes). > 2. Escape/unescape dots in the helper. > 3. ? > > Btw. re "Gettext falls back to the default string which is usually > English" - you can do the same thing easily with Rails I18n. It just > wasn't part of our original requirements ("the simple backend works > for English") so we left locale fallbacks to the plugin land.
The remaining issues are *really* subjective. - Putting default translations in the code is clutter in your opinion. In my opinion it's the opposite: it makes the code easier to read. :) gettext_noop is a bit weird at first but I don't see it as any worse than what all the other localization frameworks provide. - You view the fact that SimpleLocalization, Globalite and co are not designed with the Gettext style as proof that people want something simple and clean. The way I see it is that they haven't seriously tried Gettext. I think their view of "simple" is like coding a web application without using MVC - it's simpler but it gives you more headache down the road. I find it "interesting" that pretty much all open source desktop applications use Gettext. Gettext has been used to translate hundreds, if not thousands, of desktop applications to dozens of languages. Yet the web applications world seems to completely ignore Gettext. For PHP I can understand, everybody's reinventing the wheel there. But Rails? Your idea regarding the computability of symbols is interesting. On an abstract level it does seem to fit within the Rails philosophy, but it remains to be seen how useful it is in practice and whether anyone can come up with a good implementation. In any case, what is clear that at the very least, Rails should have better I18n tools. There should be tools that alert translators which translations need to be updated, how many strings still need translations, for writing the translations, etc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
