jasonmit / ember-i18n-cp-validations

ember-i18n support for ember-cp-validations
MIT License
21 stars 16 forks source link

ds-error translations #35

Open hanssen opened 7 years ago

hanssen commented 7 years ago

Hello,

when the server sends an i18n-key as response, it would be nice if the according translation would appear with a ds-error validation. Currently only the static text is shown. Maybe a flag or separate i18n key in the response would be a good choice, but a lookup of the response text in the translations and fallback to it might be good enough.

Is this already possible with the current implementation? Does my issue sound like a useful new feature?

Many thanks in advance, Sascha

jasonmit commented 7 years ago

@hanssen I don't typically use ember-data so I'm not aware of what you're referring to. Can you provide examples? I also don't want to couple ember-i18n-cp-validations to anything ember-data, so if this solution involves that it's best to treat it as a standalone addon.

hanssen commented 7 years ago

@jasonmit I am using following ember-cp-validations validator: validator('ds-error')

The server responds with following message:

errors: [{
  detail: 'forms.errors.already_in_use',
  source: { pointer: 'data/attributes/username' }
}]

The message from detail automatically appears as validation error message in my view.

So ember-data requires this error format and ember-cp-validations handles it very nicely with the according validator. I am only missing the translation.

My idea was to look up the detail message and translate it, if a translation could be found. On the other hand, the detail message might not be intended for i18n usage. So we might extend the errors object by an i18n attribute, which will be used to retrieve the translation.

errors: [{
  i18n: 'forms.errors.already_in_use',
  detail: 'error xyz',
  source: { pointer: 'data/attributes/username' }
}]
jasonmit commented 7 years ago

@hanssen sorry for the late response. I would like to land support to address this. Unsure if I'd want to couple it to an i18n prop, any solution should be flexible to handle different shaped error objects.

hanssen commented 7 years ago

@jasonmit I referred to the error object docs and the meta object seems to be a pretty solution:

errors: [{
  source: { pointer: 'data/attributes/username' },
  meta: { messageKey: 'forms.errors.already_in_use' }
}]
jasonmit commented 7 years ago

@hanssen I'm on board with that.