Hi Vladimir, On 27.04.2009, at 18:02, geekQ wrote: > the most important question is, whether the core team would sacrifice > *some* parts of humanize, pluralize and other string concatenation > voodoo, especially in ActiveRecord to allow for 100% linguistically > correct translations and smooth, enterprise-ready localization > workflow.
Exactly which parts are you referring to? > Currently we have to put a lot of effort into monkey patching to work > around the opinionated decisions baked in into Rails. Again, it would be great if you could list the exact places that you found need monkeypatching. > Missing possibility of changing the default string has never been an > issue, > neither in my personal decade of writing international applications > (different open source platforms, Microsoft.net and pre-dot-net) nor > for big > open source projects with longer history. It has been an issue which is why people implemented key based solutions. >> It turned out >> that this implementation seems to work for (as you say) 95% of all >> usecases which is much more than we expected. > So this solution does not qualify for any serious enterprise or > governmental (European Union) application. 100% linguistically correct > translations are required. 95% is much less that is expected from us. Right. Which is why we have a pluggable backend so you can implement your needs in plugin land. If you need patching to core, please list the places that need patching. If you need changes to the API, please do so, too. > All the kinds of hierarchically organized scopes (computed keys) > and (optional) translation inheritance do not work in environment > with role separation. Inheritance and method overriding > work in OOP. But it does not work for translations. > A translation agency needs a comprehensive and flat list > of strings to be translated. To be able to make a > decision about to override or not to override or where to override > they would need to analyse the application source code. Only manually > created and obligatory translation scope makes sense. Maybe they don't make sense for the most part of translation agencies. That doesn't mean they don't make sense for the rest. >> 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.) > And since then adapted for 20 different programming languages. > Bindings > for dynamic language, e.g. Python are very nice. Same API can be used > for Ruby too. Yeah, still asuming a C'ish API and compilation stage though. > * pluralization rules are different for different languages, > gettext uses a formula in a programming language per language for > that > * some languages have 3 or 5 plural forms as opposite to 2 in English > and German > * only complete sentence can be pluralized, not a single word Yup. The API covers that. > The question remains, whether this really is the direction towards > Rails > is heading. If so, we would contribute a solid Gettext based I18n > implementation that addresses the aforementioned issues. This however > requires some breaking changes within the Rails core and a consensus > about the necessity of them being addressed. I believe this ship has sailed about 1 year ago. It's not the question anymore whether or not we want that API. The question is if everybody who has good ideas rolls up their sleeves and implements them *using* this common API. If you want to do that for Gettext I'm absolutely sure the community will welcome that with big applause. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
