Folks, I''m struggling to work out the correct place for storing object validation error strings. Standard conventions would tell me to put all validation in the model, and if necessary override the error message using the :message symbol. But I''m struggling to see how this works with I18N. All error messages incorporate the (english) field name, and I can attach just one (english) error message to each validation. Even without I18N issues, the presentation might use different terminology than the model, or terminology might even change during development. I could create an exception class that deals with parameterized error messages (does this already exist?), and then format these exceptions in the controller before presentation. But this would seem to be something that has likely been done before. Does anyone have experience in this area? Should I just not worry about I18N yet, given the low probability of building something that reaches the point where this is a consideration? Thanks, Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 10/12/06, Chris Hughes <Chris.Hughes-kJrSCcAphiGWd6l5hS35sQ@public.gmane.org> wrote:> > I''m struggling to work out the correct place for storing object > validation error strings. Standard conventions would tell me to put all > validation in the model, and if necessary override the error message > using the :message symbol. > > But I''m struggling to see how this works with I18N. All error messages > incorporate the (english) field name, and I can attach just one > (english) error message to each validation. Even without I18N issues, > the presentation might use different terminology than the model, or > terminology might even change during development. > > I could create an exception class that deals with parameterized error > messages (does this already exist?), and then format these exceptions > in the controller before presentation. But this would seem to be > something that has likely been done before. > > Does anyone have experience in this area? Should I just not worry about > I18N yet, given the low probability of building something that reaches > the point where this is a consideration? >Take a look at heavy artillery - Globalize plugin ( http://www.globalize-rails.org/wiki/). Also, there is an alternative - gettext plugin (http://manuals.rubyonrails.com/read/chapter/105). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Chris, I ran into a problem related, but not quite like yours. My situation involved having a user-configurable central store of error messages, something that could be customized for each validation on each attribute on each model and might be changed often based on the whims of others. The final solution, after going through a few iterations of nastiness involving things like rewriting all the validation methods so they check the customized error messages, was this: Let the validation occur as normal. Then (as an after_validate callback) go over the error messages and change them from the default to the custom. At this point, the model is known, the attribute is known because of the structure of ActiveRecord::Errors, and the validation is known because of the distinctive default message. It''s nice and scalable, too. All you have to do is know the default message for any new validation introduced to your system (from a plugin, perhaps). -- -yossef --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---