Re: #544: Localization & BeanValidation

Santiago Pericas-Geertsen

Hi Gunnar,

 Other than message interpolation, is there any other scenario where locale information is important in BV? What comes to mind is a string that contains a representation of a locale-specific date format, for example. 

 Pavel and I were discussing locale support included but not limited to message interpolation. I think you’re right about the fallback for messages.

— Santiago

On May 24, 2017, at 11:54 AM, Gunnar Morling via Groups.Io <gunnar.morling@...> wrote:

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, and 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().


Join to automatically receive all group messages.