Re: #544: Localization & BeanValidation


Pavel Bucek
 

We are still not exactly sure how / whether it should be put into place.

JAX-RS implementation has to have list of supported locales, because there is a defined algorithm, which chooses effective locale for the response. Note that Accept-Language is a list of languages, not a single one. Thus we'd need to somehow get a list of supported languages and invoke algorithm which computes effective language/Locale for the response entity.

If there would be BV API which could do that, it would be great (I mean - if there would be a way how to pass a list of possible locales and let BV runtime to do the rest).

Introducing new interface like SupportedLocaleProvider is viable option, but when I try to get into a "user role", I would expect something more from that - maybe adding Language header to the response. That is certainly possible, but again problematic, since there is no guarantee that the response entity will respect that (and JAX-RS would need to provide a way how to obtain computed Language).

Also, seems like one of the main motivations for doing this is to provide support for MVC - and if there is Provider priority, this could be handled on MVC side (including BV, if MVC chooses to use it)..

Regards,
Pavel


On 25/05/2017 08:56, Markus KARG wrote:

If we want to support I18N on the JAX-RS server, it only would be straightforward to not only translation BV messages, but we also have to provide similar services to ALL providers, too. For example, why should it be correct that BV is supported, but custom exception providers are not, also custom MBWs (like for PDF) are not? I mean, content is content, and a service should be available to ALL sources of content, not just to BV.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Gunnar Morling via Groups.Io
Sent: Mittwoch, 24. Mai 2017 17:54
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] #544: Localization & BeanValidation

 

Bean Validation spec lead here, thanks a lot for considering this feature!

> Since there is no way how to get a list of supported locales

Why is it that you need to get the list of locales? The Locale mechanism has fallback implemented which is used by Bean Validation. So e.g. say you have ValidationMessages.properties, ValidationMessages_en.properties and ValidationMessages_de.properties. If you request with "en" or "en_US", it'd take the second. If you request with "de", it'd take the last one. If you request with any other Locale, it'd take the first one. This all happens automatically.

> hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already

I think there are good reasons for doing I18N on the server and on the client, it's not that one is always better than the other. E.g. doing it on the backend (i.e. JAX-RS) allows different clients to benefit from translations (say a JavaFX client as well as a web client using the same REST API). JSF btw. is integrating with Bean Validation already in the suggested way: it takes its current Locale and passes it to BV. I personally think JAX-RS could do it exactly in the same way: set up a Bean Validation message interpolator which takes the Locale from requests and passes this to calls of interpolate().

--Gunnar


Join jaxrs-spec@javaee.groups.io to automatically receive all group messages.