Inconsistent Locale used in the administrative UI

[Nadahar]

The problem

I'm working on a binding, and while testing that translations work like expected, I encountered something strange. When I change language under Settings -> Regional Settings (and reload), some of the UI changes to the new Locale while other parts don't.

I scratched my head for a while, thinking it was something wrong with my binding, until I started debugging what was actually happening and discovered that the "preferred language" from the browser is also used to determine which Locale is requested. It looks to me that some elements use the browser language, and some user the configured language.

Expected behavior

At the very least, it should be consistent.

Personally, I also think that it's much better to use the configured language than the browser "preferred language". You might think that a user would typically have the browser language set to his/her native language, but that is not the case for me at least. My native language is Norwegian, and if I configure my browser to use that, I get a more or less broken web. There are so many terrible solutions and automatic translations out there, that "smaller languages" like Norwegian are unusable. So, to configure your browser to show the language you want in MainUI, you'd have to break large parts of webpages in the same browser.

Steps to reproduce

Configure the browser language and the configured language to different languages (that have translations) and watch them intermingle.

[pacive]

I remember having dealt wit the same issue. IIRC, the problem is that the rest endpoints use the Accept-Language http header to determine what language to respond with. The SSE event stream, that sends all item state updates doesn't have access to the http headers however, so it uses the configured locale. Previously it used the system default locale, but a change was made to get it from the OH config, which was the best that could be achieved (without major refactoring).

[Nadahar]

But why doesn't the REST endpoints use the configured language instead? That would solve the issue, wouldn't it? As I see it, the browser language isn't really much to go by anyway, since you can't freely choose it as it applies to ALL web pages.

[lolodomo]

Here is an example how it is implemented in core framework:
https://github.com/openhab/openhab-core/blob/main/bundles/org.openhab.core.io.rest.core/src/main/java/org/openhab/core/io/rest/core/internal/thing/ThingTypeResource.java#L137
The language coming from the caller is used. If null was provided, the language setup on server side would be used.

Here is the getLocale method:
https://github.com/openhab/openhab-core/blob/12f2314a2d1cbd3157bead4b6de9159bea37275d/bundles/org.openhab.core.io.rest/src/main/java/org/openhab/core/io/rest/LocaleServiceImpl.java#L44

I tend to thing it should be changed on UI side, just by not providing any accept language header.

Alternative option is to update in core framework every method behind a REST call and just ignore the HTTP accept language parameter. This change is easy but it should be changed in a lot of methods.

[Nadahar]

I tend to thing it should be changed on UI side, just by not providing any accept language header.

That sounds like a simple and "elegant" option to me. If one really wanted to, one could make it an option in the UI, but it's hard to see when it would be beneficial to use the browser language given that everything won't use that language anyway.

[lolodomo]

That sounds like a simple and "elegant" option to me

What option ? Change in UI or change in server ?

[Nadahar]

I meant to change the UI not send a locale. The information is basically useless anyway, since it will never apply to all elements.