Kiwix serve UI language is not detected (from Browser language) and always in English

[kelson42]

I don't know how the language detection is supposed to work, but if I visit https://library.kiwix.org/ with a browser with Accept-Language: it I get redirected to https://library.kiwix.org/#lang=ita and the interface stays in English, while the content is mostly about Italian language wikis with Italian descriptions.

Reorted first by @nemobis at https://github.com/kiwix/libkiwix/issues/1038#issuecomment-1873260728

[kelson42]

@veloman-yunkan Can you please fix that one? This is pretty serious problem.

[rgaudin]

AFAIK the UI language is applied client-side, based on the userlang key on the Local Storage. The #lang=ita in the URL changes the filter for the content. it's unrelated to the UI.

UI lang can be changed with ?userlang=it though. That's what the UI lang switcher does.

If I understand it right, until there's this key in LocalStorage, it uses a defaultUserLanguage that is sent by the backend (with the value computed from Accept-Language).

Problem being that on library.kiwix.org we cache viewer_settings.js so that default value is not correct.

Two me there are two issues:

• an infra one that I'll handle ; being not caching viewer_settings.js.
• Mixing server-side and client side for this is wrong IMO. We've decided to take the UI language management client side so we should parse the browser's data there and not rely on a server-side call.

@kelson42 @veloman-yunkan WDYT ?

[rgaudin]

I've fixed it on Varnish and can confirm that a fresh browser with a supported Accept Language gets the proper UI directly now. https://github.com/kiwix/k8s/commit/d40cc56f16c0a529b12239126b9ee2a660d26c89

Please respond to the other question.

[veloman-yunkan]

• Mixing server-side and client side for this is wrong IMO. We've decided to take the UI language management client side so we should parse the browser's data there and not rely on a server-side call.

There is a slight difference between client-side and server-side detection of browser language preferences:

The Accept-Language HTTP header in every HTTP request from the user's browser uses the same value for the navigator.languages property except for the extra qvalues (quality values) field (e.g. en-US;q=0.8).

If this can be ignored, then nothing prevents us from running the browser language detection fully on the client side.

[mgautierfr]

If this can be ignored, then nothing prevents us from running the browser language detection fully on the client side.

This can be ignore I think. At least, we must be able to "sort" the languages to use the one preferred by the user. The real qvalues are not so useful I think.

[veloman-yunkan]

Then the next question is why it is justified to spend any effort on this. The current implementation assumes that viewer_settings.js is not cached (so that a couple of kiwix-serve options are properly set in the viewer). If we are not going to change that too, I don't see any compelling reason to move the selection of the default user language from backend to frontend (which will inevitably perform worse for those users, if any, who deliberately set meaningful qvalues).

[rgaudin]

viewer_settings.js contains instance-related data. Those can even be considered default/fallback values as one can imagine that we will allow users to select those in the future.

As such (instance defaults), it should be cached.

The problem is that defaultUserLanguage is not an instance default, it's entirely based on the user's browser info.

If it comes from the browser and every other piece of language management is done entirely in the browser (client side), then it makes no sense to me to keep that in the backend.

Sure it works but this design is unsound. I'm not a maintainer here so I'll leave you with the decision to “spend any effort on this” or not.

[veloman-yunkan]

@rgaudin Your argument is convincing to an extent that my previous comment looks silly. I will provide a fix.