On Thu, Apr 30, 2009 at 8:27 PM, geekQ <[email protected]> wrote: > > Hi, > > Sven Fuchs wrote: >> 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? > > The problem is best visible in the following line: > > http://github.com/rails/rails/blob/09a976ac58d2d7637003b92d51637f59f647b53a/activerecord/lib/active_record/validations.rb#L207 > > full_messages << attr_name + > I18n.t('activerecord.errors.format.separator', :default => ' ') + > message > > The counterpart in Rails3 is > http://github.com/rails/rails/blob/bab2bfa69220ca1b6c7b56dccc79cf8e41245306/activemodel/lib/active_model/errors.rb#L65 > > errors_with_attributes << (attribute.to_s.humanize + " " + error) > > This makes the whole ActiveRecord validation subsystem impossible to > use for linguistically correct validation messages. > > There are probably more places, where string concatenation is used, > but *validation* makes trouble whole the time. > > The second issue with ActiveRecord validations is using custom > messages. Gettext can not be used at this place without monkey- > patching, > that adds lambda support. > > > = Known Monkeys > > * in our project we monkey patched as follows > http://blog.geekq.net/2009/04/09/i18n-remove-validation-message-prefix/ > > * Masao Mutoh pointed out, that we do not need any monkey patching, > if we use N_ from his gettext library because he has already > monkey patched everything. > > * more monkey patching from masao > http://github.com/mutoh/* > > * following library also overrides the full_messages() > http://github.com/yaroslav/russian/blob/7960596ede5159462c41d5dcd07b137953bf1b3d/lib/russian/active_record_ext/custom_error_message.rb > > >>> * 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. > > Did not find documentation for that in activesupport-2.3 / I18n. > Now I've found some hints in the current Rails guide. > > But people are still forced to do a lot of programming per language, > like in > http://github.com/yaroslav/russian/blob/7960596ede5159462c41d5dcd07b137953bf1b3d/lib/russian/backend/advanced.rb > > >> 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. > > Could you point to at least one complete backend implementation, > that is entirely based on the Rails.I18n public API, without the > need for extensive monkey patching? > >> Lemme also point out that there are efforts from other people to >> improve Gettext integration for or use alongside with Rails I18n. >> Maybe most notably: >> >> - Masao Mutoh's gettext_rails >> - Sam Lown's i18n_gettext >> - Michael Grosser's fast_gettext > > No, it is not possible to implement serious Gettext or serious > internationalization on the basis of Rails I18n API, that is why > > - gettext_rails is a pure monkey patch solution, without any usage > of the mentioned API > - Michael Grosser's fast_gettext does not use the mentioned API > in any way > - Sam Lown's i18n_gettext is a Rails plugin, that simply wraps > the Masao's library and uses it as a fallback in addition to > the Rails simple backend. i18n_gettext is not a stand alone > internationalization solution > > >> Also, maybe this is a good time to take this discussion over to the >> rails-i18n mailinglist [2] to work out implementation details? I'll >> just post a follow-up over there. > > No, I was discussing the ActiveRecord and Rails core issues > here, not rails-i18n issues. If there is no interest here, > I'll not bother with further mails. > > > = Conclusion > > I've noticed, that > > 1. Internationalization is out of scope of the Rails core team > 2. Rails.I18n responsible do not grasp the important concepts > of internationalization > 3. All cool hacker, that need real internationalization, do > this currently by monkey patching Rails, especially ActiveRecord > > So I'll concentrate on doing the third until something changes on > the first.
Vladimir, Sven has tried repeatedly to get specifics out of you throughout this thread. Until this message there's been nothing but vague statements and rehashing of discussions which came to conclusion months ago. Sven and the rails-i18n team *do* grasp the issues that you've mentioned and have their i18n patches applied straight to rails. The guys on that list are responsible for directing the rails i18n effort and we listen to them and take their patches. You've cleaerly identified a few key points where the existing i18n api is lacking, and the ActiveRecord code is inflexible. Let's address those issues, and the right place to do those is the rails-i18n list and sven and co are the ones to talk with. Rather than throwing your toys out of the cot and feeling self-satisfied in the superior enterprisiness of your approach, you should try to work with Sven and the team to iron out all the issues with the existing api and let everyone benefit from the amount of work you've clearly put into this. If you're genuinely interested in enabling 'true gettext' support and removing the string concatenations in the validations API, then it will be surely be a few small, targeted patches. If on the other hand you're looking to dump wiki markup into mailing list threads and talk dismissively about the work of other programmers, then perhaps you should do that elsewhere. We're all working towards the same goal here, just because you've found some shortcomings doesn't mean that the people who did the existing work are evil or clueless. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
