Checkit and languages

[MajorBreakfast]

As you know from https://github.com/tgriesser/bookshelf/issues/224 I'm currently using bookshelf and checkit together. And I'm using it with express to build my API. First: I really like that you make an effort to support errors in multiple languages. But here's my problem: I'm using Checkit in the model and there I don't really know which language the user speaks because that depends solely on the request. The ideal solution would be if I could use Checkit client side to localize the validation errors I get from my API. I'm just thinking aloud here. Maybe all this is out of scope for this project. However it would be cool if all this would work out in an elegant way.

[bendrucker]

Localization on the client side is usually a bad idea. It would probably be easier to just pass in the language from the request to be honest.

[johanneslumpe]

And fall back to your default language if the language in the accept-language header isn't available.

[bendrucker]

I get that you're trying to keep the request information out of the model, but it's going to be way more of a headache trying to localize on the client. It poses performance issues and is a nightmare for maintainability.

[MajorBreakfast]

@bendrucker In my case the server provides an API and talks to the database. Most things that can be done on the client are done on the client. (-> Instant feedback, ember.js) I'm already running some validations (like is it an email address, required fields) on the client. Using the same validation framework in both places is sensible. However it would also make sense to move the translation of the server validation errors to the client side. A multilingual API is a tad useless. Doing that should be straightforward if checkits internationalization code became more decoupled. What do you think? @johanneslumpe For sending E-Mails I'll use accept-language. There I need to know the client's language.

[bendrucker]

In theory client side translation would seem like the right choice. But as the application grows it becomes a big issue. The translations object has to be fully populated before you can render a view. That means either serving one monolithic file or creating a set of API endpoints for internationalization and serving from there.

It's a tough issue. An API really shouldn't be serving up keys for a translation object. That means the response is basically unintelligible without the language dictionary. It becomes a big problem the second you go from a single purpose API w/ Ember to an API w/ 3rd party consumers. In that case a multilingual API is not only not useless, but a requirement.

{
  "error": {
    "message": "errors.myError"
  }
}

On the other hand, internationalization feels like a client side concern. You could use a header to specify that you just want the keys and that you will do your own internationalization.

Alex Sexton did a talk about client side internationalization last year at JSConf that might be worth a watch: http://www.youtube.com/watch?v=uXS_-JRsB8M

All I'm suggesting is that you spend some time diagramming this and think about whether you really want to do this client side. It could easily be a decision that takes days to reverse if you get it wrong.

[MajorBreakfast]

I had more like:

{
  "error": {
    "type": "ValidationError",
    "affectedFields": {
      "email": ["required"],
      "givenName": ["name"]
    }
  }
}

in mind. If the Error Object could be serialized like this then the translation isn't a problem on the other side if another instance of Checkit could take over.

About your file size concerns: I don't think it's a problem because I have at a maximum 30-50 different validation rules in my app ever. Most of them would be present anyway because I need them for client side validation.

Also: The example above is quite readable.

[MajorBreakfast]

@bendrucker Alex Sexton's messageformat.js seems preety legit. Thanks for mentioning his talk!

[bendrucker]

You got it! Most of the stuff Alex shares is awesome.

[MajorBreakfast]

@bendrucker I created a gist with a few thoughs on validation errors. Do me a favor and have a look at it. I'm open to improvements. I'm thinking about building an express middleware that transforms checkit erros into this form.

[MajorBreakfast]

I'm closing this issue now because it doesn't describe a concrete problem, just some ideas. :)