Server: Login bundle doesn't handle translation

[rullzer]

When setting the locale to dutch I would assume the login page to be in dutch...

The language is send correctly it seems as the bottom line is translated properly

But If I run in the console: t('core', 'Username or email')
I do get: Gebruikersnaam of email

So also JS is doing it right. But just the vue part doesn't do it right.

[rullzer]

Ah so it seems to happen because we do not load the actual language. Or we do. But not for this file.

Because the L10N is isolated here the default registering of the locales thus happens on the main one and not on the one in the app here.

[ChristophWurst]

Correct. Our l10n scripts do a OC.L10N.register(...) which means only the one main bundle with the global OC variable will get it.

The question is: can we change this registration mechanism? @MorrisJobke couldn't we also store the translations in a global variable that is accessible by any bundle/script?

Proposed solution

Instead of

OC.L10N.register(
    "accessibility",
    {
    "High contrast theme" : "Hoëkontrastema",
    "A high contrast theme to ease your navigation. Visual quality will be reduced but clarity will be increased." : "’n Hoëkontrastema om u navigasie te vergemaklik. Visuele kwaliteit sal verminder word, maar die duidelikheid sal verbeter.",
    "Dark theme (beta)" : "Donkertema (beta)",
    "A dark theme to ease your eyes by reducing the overall luminosity and brightness. It is still under development, so please report any issues you may find." : "’n Donkertema om u oë ’n ruskans te geen deur die algehele ligsterkte en helderheid te verminder. Dit word nog ontwikkel; rapporteer asb. enige probleme wat u ervaar.",
    "Dyslexia font" : "Disleksie-font",
    "OpenDyslexic is a free typeface/font designed to mitigate some of the common reading errors caused by dyslexia." : "OpenDyslexic is ’n gratis lettertipe/font wat ontwerp is om sommige van die algemene leesfoute wat deur disleksie veroorsaak word, te versag.",
    "Accessibility" : "Toeganklikheid",
    "Accessibility options for nextcloud" : "Toeganklikheidsopsies vir nextcloud",
    "Provides multiple accessibilities options to ease your use of Nextcloud" : "Bied veelvuldige toeganklikheidsopsies om u gebruik van Nextcloud te vergemaklik",
    "Web Content Accessibility Guidelines" : "Webinhoudtoeganklikheidsriglyne",
    "our issue tracker" : "ons probleemnaspoorder",
    "our design team" : "ons ontwerpspan",
    "Enable" : "Aktiveer"
},
"nplurals=2; plural=(n != 1);");

we do

_oc_l10n["accessibility"] = {
    "translations": {
    "High contrast theme" : "Hoëkontrastema",
    "A high contrast theme to ease your navigation. Visual quality will be reduced but clarity will be increased." : "’n Hoëkontrastema om u navigasie te vergemaklik. Visuele kwaliteit sal verminder word, maar die duidelikheid sal verbeter.",
    "Dark theme (beta)" : "Donkertema (beta)",
    "A dark theme to ease your eyes by reducing the overall luminosity and brightness. It is still under development, so please report any issues you may find." : "’n Donkertema om u oë ’n ruskans te geen deur die algehele ligsterkte en helderheid te verminder. Dit word nog ontwikkel; rapporteer asb. enige probleme wat u ervaar.",
    "Dyslexia font" : "Disleksie-font",
    "OpenDyslexic is a free typeface/font designed to mitigate some of the common reading errors caused by dyslexia." : "OpenDyslexic is ’n gratis lettertipe/font wat ontwerp is om sommige van die algemene leesfoute wat deur disleksie veroorsaak word, te versag.",
    "Accessibility" : "Toeganklikheid",
    "Accessibility options for nextcloud" : "Toeganklikheidsopsies vir nextcloud",
    "Provides multiple accessibilities options to ease your use of Nextcloud" : "Bied veelvuldige toeganklikheidsopsies om u gebruik van Nextcloud te vergemaklik",
    "Web Content Accessibility Guidelines" : "Webinhoudtoeganklikheidsriglyne",
    "our issue tracker" : "ons probleemnaspoorder",
    "our design team" : "ons ontwerpspan",
    "Enable" : "Aktiveer"
}
}

There has to be a script that makes sure the _oc_l10n exists (as we did with OC.L10N.register) and then any script can make use of the translation data, not just the global one.

Note that I omitted the plural function. We don't use this anymore as it would require eval and we forbid that as per CSP.

[MorrisJobke]

@ChristophWurst I guess I can't properly follow you. What is the problem? And the plurals are still loaded but we have a fixed set of functions now and it doesn't need to be done fully dynamic: https://github.com/nextcloud/server/blob/a5ec4a9af4582691038ec241dfcafaa5144e5f5a/core/src/OC/l10n.js#L175-L328

[ChristophWurst]

@ChristophWurst I guess I can't properly follow you. What is the problem?

OC.L10n.register is called by the l10n files. That API exists per bundle that ships OC: the main one and the login bundle. However, only the mail bundle also exports OC globally, thus its l10n registration is used, while the one from the login bundle isn't.

I think changing the l10n files will likely break as we also have to change all the apps and then you can't be compatible with older versions of Nextcloud and 17+. So I'll try to find a solution that works with the existing API but also store the translations to a global var where other bundles can access it.

And the plurals are still loaded but we have a fixed set of functions now and it doesn't need to be done fully dynamic:

Loaded and passed to OC.L10N.register, but that function ignores the parameter. Whatever is passed there won't be used.

[MorrisJobke]

OC.L10n.register is called by the l10n files. That API exists per bundle that ships OC: the main one and the login bundle. However, only the mail bundle also exports OC globally, thus its l10n registration is used, while the one from the login bundle isn't.

Ah ... makes sense :)

Loaded and passed to OC.L10N.register, but that function ignores the parameter. Whatever is passed there won't be used.

Yes - because as of now it uses the language code instead.