Re: #544: Localization & BeanValidation


Gunnar Morling
 

I see, thanks for clarifying the details, Christian!

To me it seems that'd be a very reasonable default behaviour for
JAX-RS; people still could plug in a custom LocaleResolver based on
their custom requirements and context, e.g. preferring a Locale for
which they provide a resource bundle with validation messages.

2017-05-29 15:36 GMT+02:00 Christian Kaltepoth <@chkal>:

Hi Gunnar,

sorry, the term "priority" was a bit misleading in this context. Actually it
uses the "quality value" from the "Accept-Language" header.

See:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language

Christian

2017-05-29 14:26 GMT+02:00 Gunnar Morling via Groups.Io
<gunnar.morling=googlemail.com@groups.io>:

Hi Christian,

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.
This seems very useful, pretty much like what could be useful within
JAX-RS itself. That selected Locale could then be used with a
specifically set up message interpolator, just as JSF defines this
integration with Bean Validation.

Out of curiosity, how is that priority be defined?

--Gunnar



2017-05-28 16:00 GMT+02:00 Christian Kaltepoth <@chkal>:
Hey Pavel,

The struggle here is with the SupportedLanguagesProvider - it feels
like
it should be used for something more than BV - I think it's fair to say
that
if localizaiton of BV error messages is the sole purpose of such
provider,
it shouldn't be introduced. And I can't think of any other sensible use
right now.

I would like to take the opportunity to describe what MVC did to support
internationalization which relates to the issue we are discussing here.
As
MVC builds on top of JAX-RS, this may (or may not) be interesting for
you.

For MVC we identified a few locale-dependent aspects which we had to
support:

Data type conversion as part of the data binding mechanism needs to be
locale aware. So something like @FormParam("price") BigDecimal price
needs
to be parsed according to the number formatting rules of the specific
locale.
Formatting data according to locale dependent rules when rending the
view
(date format / number format). This certainly isn't something relevant
for
JAX-RS.
Generating binding and validation errors message in the specific
language.
This is basically what we are talking about here.

To support these scenarios we defined the term "request locale" as the
locale which is used for any locale-dependent operation within the
lifecycle
of a request. The request locale is resolved for each request using the
following SPI:

public interface LocaleResolver {
Locale resolveLocale(LocaleResolverContext context);
}

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.

But developers can customize this by providing their own resolver. So if
the
developer wants to support only a specific subset of locales, he could
simply create a custom resolver and match the supported locales against
the
Accept-Locale header as described in Pavel's previous mail.

You can see the full SPI here:


https://github.com/mvc-spec/mvc-spec/tree/master/api/src/main/java/javax/mvc/locale

All the details are described in the MVC spec document (pages 37-38):

https://github.com/mvc-spec/mvc-spec/raw/master/spec/spec.pdf

I'm not sure if anything described here could be useful for JAX-RS. Of
cause
we (the MVC EG) would be happy to see any of our APIs to be integrated
into
JAX-RS.

Christian


--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal



--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal

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