#1477 confirmed

Better localizability for dm-validations

Reported by gix | January 15th, 2011 @ 11:01 PM | in 1.1.1

I want to revise the issue of localization again because it has been one of the pain points for me in using datamapper; and the last (and only?) ticket I could find on this issue is several years old and closed.

dm-validations allows changing the error messages, but that's of little use without the ability to translate model and field names. It also doesn't integrate nicely e.g. into Rails.

There are different ways to achieve this, but I think it would be good if dm-validations would be language-agnostic. For example instead of generating an error message immediately when adding an error, add information about the violation: the resource, field name, failed validation and validation-specific context values (user object, :password, :too_short, :minimum => 6).

With such an approach it would be easy to put different ways of translation on top of it, e.g.

  • a default implementation when using dm-validations stand-alone,
  • dm-rails can tie it into the i18n part of Rails.

Custom messages can be added as additional context information (my fork of dm-validations does that), though with the suggested localizability these would maybe become a bit superfluous.

Comments and changes to this ticket

  • Piotr Solnica (solnic)

    Piotr Solnica (solnic) January 16th, 2011 @ 04:52 AM

    • State changed from “new” to “confirmed”
    • Assigned user set to “Piotr Solnica (solnic)”

    Yes! I'm suffering because of that too. Let's work on this man, I'll start by looking at your fork. It's already too late to push this into 1.1 release, but we can add that to 1.1.1!

  • Piotr Solnica (solnic)

    Piotr Solnica (solnic) January 16th, 2011 @ 04:55 AM

    • Milestone set to 1.1.1
    • Milestone order changed from “196330” to “0”
  • Piotr Solnica (solnic)

    Piotr Solnica (solnic) January 20th, 2011 @ 02:22 AM

    I've quickly looked at your forks, all looks great. I will try to use it in my app as a test drive. If it works fine then why not merging your work in now? Are there any public/semipublic API changes?

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) January 29th, 2011 @ 02:03 PM

    I don't know too much about localization, so I'll let people who know more speak up about specifics. One idea I had, playing off gix's original, is to instead of returning error messages like we do now, we setup objects for each type of error that have enough information in their type, attributes to reconstruct the error message, but when stringified default to the current error messages we have now.

    This would allow us to keep a lot of the same API we have now, but we'd have rich objects for each error message that could be built on top of.

    I'd probably want some sort of base class for the behavior, one subclass for each distinct error message, and one for custom validators. We can switch on the object type for different behavior for each object, rather than inspecting a Symbol attribute (which is just simulated polymorphism, a code smell).

  • gix

    gix February 1st, 2011 @ 01:38 AM

    That's essentially what my idea and branch do, except there is a single class instead of multiple ones, and context is provided via a hash. It would be easy to change that if it's preferred that way. Actually thinking about it I prefer that idea myself instead of having a symbol for each error.

    Regarding backwards compatibility, this mostly affects the ValidationErrors collection (methods like #on, #each or #[] returning error objects instead of strings). Giving error objects #to_str and #to_s methods returning the formatted error message works as long as no string methods are called on it. But since there is no real overlap in methods between the error class and strings method_missing could take care of it and delegate it to the message returned by #to_s (and give a deprecation warning).

  • Xavier Shay

    Xavier Shay February 7th, 2011 @ 08:30 PM

    This feature would help me out

  • gix

    gix February 8th, 2011 @ 10:21 AM

    I pushed a second version implementing a cleaner way of transforming errors (see https://github.com/gix/dm-validations/commit/7145db7c8d8c556a2c787a5282b4750c82818fa0#diff-0).

    Some unresolved things:

    • I kept a single class for errors (called Violation), because I see no value in abstracting that further (you would need around 27 different classes to cover all combinations), it certainly does not really help dealing with additional validator-specific values.
    • I'd like to have some input on whether the class property to set a transformer is the best way to go (I'd prefer clean DI but that's not really possible with DM).
    • Method and block validators aren't changed yet so that they return violation objects, too, instead of messages.
    • How should custom messages be handled with multiple validation contexts? The specs use a message hash with the context symbol as key, but the whole hash is passed in as "error message" which seems weird to me because I have to remember the context to retrieve the appropriate message.
  • Dan Kubb (dkubb)

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »