Hi Vladimir, On 30.04.2009, at 10:27, geekQ wrote: > 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)
Great, thanks for pointing that out. This is a known issue and I agree that we should get that fixed. There are few options to do that and discussion about that has already started over at http://groups.google.com/group/rails-i18n Please join in! We're keen on hearing your opinions. > 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. Integrating lamda support to the I18n API has been a request for a long time. It's also useful for localizing dates to rather funky rules and such. I've worked with Clemens yesterday on integrating and polishing his contributions and pushed it to a branch: http://github.com/svenfuchs/i18n/commits/lambda So this should then be possible: validates_format_of :account, :messages => lambda { _("foo") } Another option to solve this situation might be: validates_format_of :account, :messages => gettext_noop("foo").to_sym This is also being discussed on the rails-i18n list. Please let us know about your opinion. > = 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 Great list, this is helpful. Thanks! >>> * 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 Sure. Please distinguish the API from their implementations (backends). This is on purpose. There are a few more backend implementations in Globalize2: http://github.com/joshmh/globalize2/tree/a46ab1e885c37aff435823d992cc8c919b0e3c50/lib/globalize/backend Please think about the I18n API in Rails as similar to the Rack API support. Rack allows for previously unseen extensibility and exchangeability of concurrent implementations of rather focussed features. Now, even though Rails 2.x now supports that API it doesn't leverage all of the features it provides. E.g. Rack routing/url_generation is not supported, yet (will be there in Rails 3, afaik). Nobody's arguing Rails should stop supporting Rack for this reason though. And similar the fact that Rails does not perfectly support all features required for proper I18n/L10n does not mean it should stop supporting the I18n API. >> 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? If by "extensive monkey patching" you mean the bug/shortcoming in AR#full_messages then, no. > 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 Yeah, I know these are different approaches from what you have in mind. I've listed them because I have received some angry private messages that were based on the perception I wouldn't know about or conceal or downplay these efforts. Just wanted to make sure people know that I don't, these are great contributions. Thanks again! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
