Ah, something I did! ;)
My first run through what is exactly happening here:
The problem is that users do thing exactly opposite to the default
validations.
When you're writing a custom validation:
validate :my_validation
def my_validation
errors.add(:title, :can_t_be_blank_or_is_not_valid) if
some_condition
end
But the built in validations do:
errors.add(:title, :blank, :default
=> :can_t_be_blank_or_is_not_valid)
Since I handled a errors.add the same way as I18n.translate, with the
default as last resort, this fails horribly.
I could do two things:
1. Make the user enter custom validations only using a default way,
making the second argument to errors.add practically useless. # =>
errors.add(:title, 'only show me when no translations are
present', :default => :can_t_be_blank_or_is_not_valid)
2. Make all the built-in validations behave different under water :S
3. Find out a way where both keys have meaning, but it would mean more
complexity in an already complex method.
Okay, not really 2.
I am not really sure on how to continue with this.
I think errors.add(:title, :can_t_be_blank_or_is_not_valid, :default
=> "show me only when no translations are present") is the right way
to do things. But it means redoing a lot of the rails validations.
What are your opinions??
On the topic of scoping: my bad, if it isn't in attributes or models,
it should go to messages.
Iain
PS. What a lame key 'can_t_be_blank_or_is_not_valid' ;)
> sven fuchs
svenfu...@artweb-design.de