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. Best Regards and good-bye, Vladimir --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
