Localization does not propagate into the profile selection

[rus-kilian]

When running the App in localization and browsing the profiles of an org, the profiles aren't displayed using the localized profile title but the generic one.

Example: Universität Stuttgart -> STAFF (instead of "Mitarbeiter") when using de_DE

[restena-sw]

When querying the CAT API for the list of org names and/or profiles, the localized variant is delivered automatically if the API call contains &lang= such as &lang=de in this case.

[pauldekkers]

Good feedback @rus-kilian, thanks! We'll think of a way to provide language specific discovery (and possibly do this in a backward compatible way so we can offer it to existing installations, or do it from a new release on).

[pauldekkers]

On Android it looks like we don't get the Accept-Language for the discovery files, so no patching older versions. (It would have worked for iOS.) It makes sense to develop this for Android 11 and new iOS releases only.

I kind of expected we would get the default/other language from the API, maybe without a lang= parameter (or lang=C). Is there such a thing, @restena-sw? The default fallback seems to be English, also without parameter - which is why the default is hardly used I think.

(As an example, I've added default, de, en, fr to IdP 7018, and I only get the default when I ask for es.)

[restena-sw]

Can you check if this is consistent with normal UI? When I go to https://cat.eduroam.org/?idp=7018 I get the (Nederlands) "Universiteit" for all the CAT-supported languages which do not have an explicit localised variant registered - I would think "Universiteit" is the one you selected as "default/other"? Of course for the registered ones I get University, Universität, a.s.o.

So - does the returned name from API behave the same?

[pauldekkers]

I think that's the same behaviour - maybe just not what I expected. If I set my iPhone language to Dutch, I get the English version. If I set my iPhone language to Spanish, I get the Dutch version. Same as in the API. Only the registered languages match.

I guess I expected I would get the default language if there was no match, like, for Dutch, with "NL" not being in the translations. (Still makes sense to me, actually.)

[restena-sw]

So... after a deep look at the code... The function core\common\Language::setLang() first collects desired language info from external evidence, and in decreasing priority stuffs it into an array of candidate languages:

1. from HTTP GET
2. from HTTP POST
3. from SESSION
4. from HTTP_ACCEPT_LANGUAGE
5. from the configured fallback language in the product's master config file (which is EN on cat.eduroam.org)

For all the candidates it found in the list, it picks the first it finds which also exists in the product config. Note, in the case of omitting the language, or setting it to something "inexistent", this list will always contain only EN from 5). It does that because for installer generation and input handling, it needs to have a valid mapping between language code and a system locale (e.g. 'en' => 'en_GB.UTF8'), for gettext to work.

That is the language in which it will serve all strings in UI (not applicable in API of course), and will deliver institution names, profile names etc. in that language if those names are configured in that language. If not, it will fallback to the "default/other" entry (and fall back further to English if that is also not set).

In the case of an inexistent language, it will thus set itself to English, and deliver English if set. If an org would have no English name variant set, it would then fall back to "default/other".

[restena-sw]

I guess the core of the issue is that we need to call setlocale() with a locale, not just a two-letter ISO code. Since we don't typically have that, many moons ago I wrote this comment at the pertinent place:

        // madness! setlocale is completely unflexible. If $tryLang is "en"
        // it will fail, because it only knows en_US, en_GB a.s.o.
        // we need to map stuff manually
        $localeTmp = FALSE;

It also needs to be an /installed/ locale, otherwise the call fails.

The only thing I can imagine is to use the two-letter ISO code internally (for name variant precedence calculations) while setting the locale to en_GB.UTF8 for all the "inexistent" languages.

I can't say how many side effects this will have, as it also affects display of numericals (comma vs. dot), alphabetical sort order etc.