# Rails 3 validation error messages

**URL:** <https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226>\
**Category:** Rails I18n\
**Created:** [January 25, 2010, 1:07pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226 "2010-01-25T13:07:14Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 25, 2010, 1:07pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/1 "2010-01-25T13:07:14Z")

</div>

[José, Mateo, I’ll move this to the list]

Ok, so we’ve had this short non-discussion on rails-core 🙂

It seems that Rails 3 validation error messages will be back to the  
state of pre 2.3.3 at least for a short period of time. Unfortunately  
nobody from rails core seems to back any of the decision options up so  
the decision to break AR full\_messages etc might “just happen” and we’ll  
get some extra fire over here.

On the other hand this gives us the opportunity to start over with a  
clean solution from scratch, implement it and get it hammered in  
plugin-land and only move it to Rails after we know what we’re doing.

I’ve thus started to draft my ideas about this in code:

[http://github.com/svenfuchs/messages\_proposal](http://github.com/svenfuchs/messages_proposal)

I’ve tried to separate all debatable “features” into optional modules.  
That doesn’t mean these absolutely must be optional in Rails in the end  
(even though I’d think it would be a good idea).

Enjoy and let me know what you think!

Here’s a copy of the readme:

# Proposal: validation error messages in ActiveModel

This stuff is a very rough draft of how I propose to deal with  
validation  
error messages (and potentially other usecases that need I18n support,  
such as  
form labels).

It might go into Rails or end up in some plugin or gem.

I’m not looking so much at the actual integration to ActiveModel, yet.  
So far  
I’m just trying to sketch out the underlying stuff so that it covers all  
requirements in a consistent way.

I want this stuff to be re-usable in other places where similar patterns  
occur  
when it comes to I18n, such as form labels and potentially other stuff.

Requirements:

- Strings in class method calls should be treated as plain text by  
default  
(might optionally want to treat them as translation keys for  
gettext-style  
class method calls if requested by the user).
- Symbols in class method calls should be treated as translation keys.
- Use values from class method calls consistently with translation keys  
that  
are implicitly built for a validation.
- Different translation variants (such as :full\_message) for the same  
message  
should be possible.
- Translation calls should optionally be able to cascade over scopes if  
requested by the user.
- Support format strings, e.g. “{{attribute}} {{message}}”

See the tests, especially active\_model\_test.rb

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 26, 2010, 4:02am UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/2 "2010-01-26T04:02:58Z")

</div>

> [José, Mateo, I’ll move this to the list]
> 
> Ok, so we’ve had this short non-discussion on rails-core 🙂

Yeah, I was a bit afraid that would happen

> It seems that Rails 3 validation error messages will be back to the  
> state of pre 2.3.3 at least for a short period of time.  
> Unfortunately nobody from rails core seems to back any of the  
> decision options up so the decision to break AR full\_messages etc  
> might “just happen” and we’ll get some extra fire over here.

Well, as I mentioned in my message to the rails core list, we can get  
the lazy translation functionality back by having errors[:attribute]  
return an array-like object rather than an array. The 2 consequences  
of this are:

a) Reproducing all the functionality of an array will take a lot of  
code, but then I don’t believe it’s actually necessary to implement  
full array functionality; as long as it’s easy to add errors and the  
object is enumerable, I think it will suffice for most peoples needs.  
(i.e. is it really useful to be able to pack or zip the error array?)

b) Not returning arrays will break lots of tests; not a big deal  
considering some of the other major changes being rolled out in 3.0,  
but I felt I bit uncomfortable submitting a patch like that so I  
wanted some feedback first.

> Rails in the end (even though I’d think it would be a good idea).  
> I like where you’re going with this, and it would work well with the  
> change I’m proposing above, which would take care of the active model  
> integration. How would you propose we collaborate on this? I can push  
> my work to my rails fork, but that might not be the easiest for others  
> to run it?

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 26, 2010, 1:22pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/3 "2010-01-26T13:22:30Z")

</div>

On Jan 26, 2010, at 4:02 AM, Mateo Murphy wrote:

> > Ok, so we’ve had this short non-discussion on rails-core 🙂  
> > Yeah, I was a bit afraid that would happen

I guess we have to raise more attention. In any case we’re breaking some  
behavior that people do expect.

> Well, as I mentioned in my message to the rails core list, we can get the lazy translation functionality back by having errors[:attribute] return an array-like object rather than an array. The 2 consequences of this are:
> 
> a) Reproducing all the functionality of an array will take a lot of code, but then I don’t believe it’s actually necessary to implement full array functionality; as long as it’s easy to add errors and the object is enumerable, I think it will suffice for most peoples needs. (i.e. is it really useful to be able to pack or zip the error array?)

I agree. We’d probably want to implement at least as much as is tested  
in the test suite.

> b) Not returning arrays will break lots of tests; not a big deal considering some of the other major changes being rolled out in 3.0, but I felt I bit uncomfortable submitting a patch like that so I wanted some feedback first.

I think in the long run this aspect of AM (returning a plain Array) must  
go away anyway. Arrays are too stupid for what we need.

> I like where you’re going with this, and it would work well with the change I’m proposing above, which would take care of the active model integration. How would you propose we collaborate on this? I can push my work to my rails fork, but that might not be the easiest for others to run it?

What about aiming for a plugin for now. I’d add you as a collaborator  
and we work a monkey-patch’ing plugin out over there.

I believe a plugin would be the best option right now. We haven’t heard  
back from Rails core, yet, so this is just me guessing wildly but I  
would bet that they don’t want to delay Rails 3 beta because of this  
stuff. Plus, we’d have to implement it (and meet the expectation to “do  
the right thing”, resolve all potential discussions etc.) really  
quickly. So instead we could try to get a plugin ready when Rails 3 beta  
comes out and ask people to use it and help us when they want “fancy”  
I18n error messages. Then we could aim for pushing it back to Rails for  
3.1 or something.

This way we could both back up Rails core re releasing Rails 3 soon and  
have the freedom to experiment with a good solution.

Wdyt?

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 26, 2010, 2:38pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/4 "2010-01-26T14:38:02Z")

</div>

sounds good 🙂  
IMHO it’s good idea.

2010/1/26 Sven F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> > 
> 
> considering some of the other major changes being rolled out in 3.0, but I  
> it?  
> it and help us when they want “fancy” I18n error messages. Then we could aim  
> To post to this group, send email to removed\_email\_address@domain.invalid.  
> To unsubscribe from this group, send email to  
> removed\_email\_address@domain.invalid[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> .  
> For more options, visit this group at  
> [http://groups.google.com/group/rails-i18n?hl=en](http://groups.google.com/group/rails-i18n?hl=en).

–  
Experiencia es lo que obtienes, cuando no obtienes lo que quieres.

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 27, 2010, 3:35pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/5 "2010-01-27T15:35:02Z")

</div>

On Jan 27, 2010, at 5:02 AM, Mateo Murphy wrote:

> > I agree. We’d probably want to implement at least as much as is tested in the test suite.  
> > A quick scan reveals:
> 
> \<\<  
> any?  
> empty?  
> include?  
> first
> 
> most of which is provided by enumerable anyway.

Ah, interesting.

> The \<\< method brings up a question I had regarding what you’ve started working on: in your Message class there’s both a type and a message attribute; how do you propose we populate these when the user passes a short message like errors[:name] \<\< “not valid”?

I think I might be able to factor type out.

It’s currently populated with the default validation key (e.g. :blank  
for validates\_presence\_of) and will only be used if message is nil (in  
Translated,  
[http://github.com/svenfuchs/messages\_proposal/blob/master/lib/message/translated.rb#L16](http://github.com/svenfuchs/messages_proposal/blob/master/lib/message/translated.rb#L16))

I see errors[:name] \<\< “not valid” as equivalent to specifying a String  
as a message on class-level as in

validates\_presence\_of :foo, :message =\> ‘not valid’

So, errors[:name] \<\< “not valid” would generate Message.new(nil, “not  
valid”) and always evaluate to “not valid”

If users want this to be translated the would need to do errors[:name]  
\<\< :not\_valid

Does that make sense?

> That sounds good to me. It’s a bit unfortunate that people will have to deal with an api change with 3.0, and potentially another in 3.1, but getting the word out about the plugin quickly should help mitigate that

Ok, I’ve added you to the repo at:  
[http://github.com/svenfuchs/messages\_proposal](http://github.com/svenfuchs/messages_proposal)

I’ve been working on the library code a bit more and I believe it should  
be usable as a base line for the plugin.

How do you think we could best collaborate? Maybe meet in  
[irc.freenode.net#rails-i18n](http://irc.freenode.net#rails-i18n)?

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 28, 2010, 5:25pm UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/6 "2010-01-28T17:25:34Z")

</div>

On 27-Jan-10, at 8:45 AM, Sven F. wrote:

> Does that make sense?

Yes it does, but just to throw this out there, what about using a  
subclass of error rather than a type? Treat it something like an  
Exception?

> How do you think we could best collaborate? Maybe meet in  
> [irc.freenode.net#rails-i18n](http://irc.freenode.net#rails-i18n)?

Sure, given the timezone difference though, unless you’re willing to  
meet late at night, it’ll have to be during the weekend…

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 29, 2010, 8:59am UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/7 "2010-01-29T08:59:48Z")

</div>

On Jan 28, 2010, at 5:24 PM, Mateo Murphy wrote:

> > If users want this to be translated the would need to do errors[:name] \<\< :not\_valid
> > 
> > Does that make sense?
> 
> Yes it does, but just to throw this out there, what about using a subclass of error rather than a type? Treat it something like an Exception?

I’ve now entirely removed this argument. Clients (i.e. #generate\_message  
in this case) can just default message || type themselves.

> Sure, given the timezone difference though, unless you’re willing to meet late at night, it’ll have to be during the weekend…

Ok, fine. Just give me a ping 🙂

---

<div class="post-metadata">

**Author:** ![Sven\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b5e925/32.png) [@Sven\_F](https://www.ruby-forum.com/u/Sven_F)\
**Post date:** [January 27, 2010, 5:03am UTC](https://www.ruby-forum.com/t/rails-3-validation-error-messages/182226/8 "2010-01-27T05:03:28Z")

</div>

On 26-Jan-10, at 7:21 AM, Sven F. wrote:

> > error array?)
> 
> I agree. We’d probably want to implement at least as much as is  
> tested in the test suite.

A quick scan reveals:

\<\<  
any?  
empty?  
include?  
first

most of which is provided by enumerable anyway.

The \<\< method brings up a question I had regarding what you’ve started  
working on: in your Message class there’s both a type and a message  
attribute; how do you propose we populate these when the user passes a  
short message like errors[:name] \<\< “not valid”?

> and help us when they want “fancy” I18n error messages. Then we  
> could aim for pushing it back to Rails for 3.1 or something.
> 
> This way we could both back up Rails core re releasing Rails 3 soon  
> and have the freedom to experiment with a good solution.
> 
> Wdyt?

That sounds good to me. It’s a bit unfortunate that people will have  
to deal with an api change with 3.0, and potentially another in 3.1,  
but getting the word out about the plugin quickly should help mitigate  
that