Translations update from Hosted Weblate

[weblate]

Translations update from Hosted Weblate for Keycloak/Admin UI.

It also includes following components:

• Keycloak/Theme base/account

• Keycloak/Theme base/admin

• Keycloak/Theme base/login

• Keycloak/Theme base/email

• Keycloak/Account UI

Current translation status:

[ahus1]

@jonkoops @thomasdarimont @robson90 - I see that the tests fail, I need to look into this next week if some tests depend on translations.

I also see that the German language now has a translation of all other languages. AFAIK the English language has entries for each language in the language's own writing, which would indicate not to translate those entries. If we choose to not translate them, we should better move those strings to a different file. Still this is open for discussion: in an admin UI it would make sense to translate the languages if they are presented to an admin to select them. If they are presented to a user in the login page, it would be good not to translate them as a user might not recognize their language in the current UI's language. (I am currently unable to look at the UIs, so I might be wrong here, will do that next week).

Happy to hear your thoughts. While the build breaks and with the question I raised about the language names, I ask you to slow down the translation a bit and wait for this PR to be merged. I assume we will resolve this next week.

[jonkoops]

I also see that the German language now has a translation of all other languages. AFAIK the English language has entries for each language in the language's own writing, which would indicate not to translate those entries. If we choose to not translate them, we should better move those strings to a different file.

Agreed, those strings should not be translated. But perhaps they don't need to be in a property file either. Could we use Locale.getDisplayName(); to get the language name on the Java-side? For example:

Locale locale = new Locale("nl");
System.out.println(locale.getDisplayName()); // "Dutch"

@ahus1 WDYT?

[thomasdarimont]

Thanks for looking into this!

My 2 cents:
While working on the german translations I also noticed that the locale names could be pulled form the JDK, that's in fact what I used
to create the translations in the first place... but I hesitated to question the implementation as it were "just a few strings..." ;-)

However, I'm in favor of using JDK built-in functionality. It seems that the languages are currently translated via messagebundle in
the UI since the server only returns the list of supportedLocales in the realm response.

If we want to leverage the translations built-in the JDK we could add a new supportedLocales endpoint to the
RealmLocalizationResource to expose a LocaleRepresentation.

Additionally there is also LocaleBean which is used by the language selection in Freemarker based pages.

[jonkoops]

If we want to leverage the translations built-in the JDK we could add a new supportedLocales endpoint to the
RealmLocalizationResource to expose a LocaleRepresentation.

There should be no need to create a new REST API endpoint for this, there are equivalent APIs on the browser-side we can use to localize this. Taking my previous example translated to JS:

const regionNames = new Intl.DisplayNames(['en'], { type: 'language' });
console.log(regionNames.of('nl')); // "Dutch"

[ahus1]

Thank you for the feedback. I'll prepare a PR to automatically blend in the Java translations of locales at the backend. This would allow us to leverage the translation override if anyone would want that. And the results shown would be consistent, independent of the user's browser settings. Please follow #29124 for the progress.

[ahus1]

@thomasdarimont - Weblate is buffering changes, so they might show up deferred only. With the latest squash-commit changes (maybe even before?) it will rebase this PR once there is a change in the parent repo. Let's see how often this happens, and how annoying this is to get the PR merged.

[ahus1]

@jonkoops - please review for the UI team. Thanks!