Is there a language code vs locale confusion in Nextcloud (and possibly elsewhere)?
If I select
German (informal) as the language setting in my user’s profile, the language code in the
oc_preferences table is set to
de. If I select
German (formal), the language code in the table is set to
I didn’t know
de_DE was a formal language code …
Reading a few threads about this:
If I have something that is language context sensitive, I’d then have to code for
de_DE as two different languages as I’m sure that someone who actually wants formal German isn’t happy with getting informal German …
The de_DE is a locale, not just language. It consists of first he language code and then the region code. It reads “german in Germany”.
Other examples would be nn_no which reads “nynorsk in Norway” or sv_SE as “swedish in Sweden” or even sv_US which would be “swedish in the USA”.
This is all based on the Unicode CLDR.
EDIT: I realize this isn’t really what you asked. But I would reply that an informal language is one which isn’t specific to a certain region, whereas a formal one can be considered to be one that is specific to a certain region.
Thanks. I was sort of thinking that was the reasoning behind it
I’ll adjust my code to split at underscore, for the needs of the app in this specific case.
I urgently need to make a comment here regarding the German language. The German language is currently the only language at Nextcloud that has the luxury of maintaining two variants. On the one hand, there is the formal variant (de_DE) and the informal variant (de). The history of this implementation goes back to the time when Nextcloud was still called ownCloud. I would like to question whether this was a good approach. The whole thing is not carefree either, because on mobile platforms like Android and iOS this causes problems. If you take a look at the Nextcloud project at Transifex, you will see a colourful mix of language abbreviations. This is an addition.
Is it not the other way around? Just curious.
You are right. Fixed my posting seconds ago.
Yeah, this should really be changed. And it does not belong in the ‘lang’ preference unless specifically documented.
It also makes it somewhat “complicated” (not really, but …) to manage the return value of a fetch call to get ‘lang’ preference since you really need to make an exception (or split on underscore). And we all need what happens to hardcoded exceptions in code as it ages.
Well, yes and no. I’m well aware of the fact that
de_DE is a locale, but
de is the language code in this particular situation. IMHO,
de_DE has no place in a
lang preference (in particular since there’s a completely separate locale setting).
It’d be a much better solution (again, IMHO) to give developers an advice on how to properly handle this (and for Nextcloud to be changed).
Regardless of how this is “solved” at some point, there should be added documentation to explain this.