Passing in _locale to localize does not work?

[ComLock]

Enonic version: 6.4.0
OS: Linux

If you hardcode language by passing in _locale=“en” to the localize function, you will still get the site language.

I want to localize the error pages to use the Accept-Language header.
So that people who wants Nynorsk rather than Norsk Bokmål can be happy too.

I was thinking get the lang from here:
http://xp.readthedocs.org/en/stable/developer/ssjs/http-request.html?highlight=language

And pass it to thymeleaf:
http://xp.readthedocs.org/en/stable/reference/view-functions/localize.html?highlight=_locale

Or do I really have to write my own localization library as suggested here:

Internationalization in 6.0

Hi, You should in admin double click your Site and set the locale on it in the bottom of the form. This is then sent automatically to the localize function. I've made that example work in 6.0 by also adding the "_locale" param and sending that in. Haven't tried without yet, but if you say it doesn't work you might need to "fetch" this in your Controller first and pass on to Thymeleaf.

[aro]

Can you write the line where you are using the _locale parameter?

Make sure you don’t add the double quotes around the language code when using the Thymeleaf function. Like this:
<div data-th-text="${portal.localize({'_key=user.greeting', '_locale=nn-no'})}"></div>

The example of the HTTP Request in the docs might be a bit misleading. The "headers" object will include all the headers in the request. But there will not be such a “Language” header (unless you have some custom logic in the client).

What you normally get is an "Accept-Language" header containing the language preferences as configured in the browser. Depending on the languages and order you set in your browser you will get a header like this:

"Accept-Language": "en-US,en;q=0.8,ca;q=0.6,es;q=0.4"

We do not parse the Accept-Language string, so you have to implement your own in the controller to get the preferred language code string, and pass it to the localize function.

I think the resolving from the header to the localize language code might be a good function to add to the i18n module, in a future release.