Forum: Rails I18n rails 3 validation error messages

[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

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

> [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?

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?

sounds good :)
IMHO it's good idea.

2010/1/26 Sven Fuchs <svenfuchs@artweb-design.de>

> >
> 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 rails-i18n@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-i18n+unsubscribe@googlegroups.com<rails-i18n%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rails-i18n?hl=en.
>
>


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

On 26-Jan-10, at 7:21 AM, Sven Fuchs 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

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...)

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

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?

On 27-Jan-10, at 8:45 AM, Sven Fuchs 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?

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

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 :)