Language code vs Locale confusion?

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 de_DE.

I didn’t know de_DE was a formal language code … :thinking:

Reading a few threads about this:

and

If I have something that is language context sensitive, I’d then have to code for de and de_DE as two different languages as I’m sure that someone who actually wants formal German isn’t happy with getting informal German … :sunglasses:

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.

1 Like

Thanks. I was sort of thinking that was the reasoning behind it :+1:

I’ll adjust my code to split at underscore, for the needs of the app in this specific case.

1 Like

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.

1 Like

Is it not the other way around? Just curious.

1 Like

You are right. Fixed my posting seconds ago.

1 Like

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.