Localization fallback issue

[enkelmedia]

Which Umbraco version are you using?

15.4.0

Bug summary

Hi!

I just got this issue reported for my package "The Dashboard".

Basically, the user has "en-UK" configured as his language, and the package only ships "en-US". Historically the localization would fall back to "en-US" but it seems like this is not working in 15.4.0, actually it stopped working in 15.3.0.

I'm not sure what to expect here. Should this be considered a regression bug or am I doing something wrong in the package? The fallback worked in v15.0.0 and up until v15.2.3.

The code is open source and the localization configuration happens here: https://github.com/enkelmedia/TheDashboard/blob/v15/dev/src/Our.Umbraco.TheDashboard/Client/src/manifest.ts

I'm registering the localization manifest like this:

{
	type: "localization",
	alias: "TheDasboard.Localize.En_US",
	name: "The Dashboard Localization English (United States)",
	meta: {
		"culture": "en-us"
	},
	js : ()=> import('./localization/en-us.js')
},

Update:
I did try to change the casing when registering the localization to

meta: {
   "culture": "en-US"
},

But this did not have any effect.

Could it be that something made the culture case sensitive in the v15.3.0 release?

Specifics

No response

Steps to reproduce

See above

Expected result / actual result

Language should fall back to en-US, and probably not be case-sensitive (if this is the problem).

---

This item has been added to our backlog AB#52696

[github-actions]

Hi there @enkelmedia!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[iOvergaard]

Hi @enkelmedia
The default language in Umbraco is "en_us", but the fallback language is "en". So if your keys exist in "en", it should work. You could probably fix that by changing your "en_us" manifest directly to "en".

[iOvergaard]

I cannot say with certainty why it worked before 15.3.0. I know we had a case sensitivity problem in 15.3, which got fixed, but it shouldn't have anything to do with the fallback language, which has been just "en" since 14.0.0.

You can see the list of languages, their codes, and what the fallback is here: https://docs.umbraco.com/umbraco-cms/extending/language-files#supported-languages

[enkelmedia]

Thanks a lot for clarifying @iOvergaard! I can verify that this works on v15.3+

meta: {
   "culture": "en"
},

I'll submit a PR for this documentation article as well since it would make sense to use en in the sample when this is the default fallback.

// Markus

[enkelmedia]

Hmm... @iOvergaard

There is still something strange going on with the localization extension. After adding a localization like this, a new option is shown in the dropdown e.g. for "Swedish"

The same culture shows up twice, once from the core and once from the package.

[iOvergaard]

Probably more of that case-sensitivity issue again. Could you try and follow the cultures exactly as they are written in the Docs? The country code should be capitalized, for example "sv-SE".

[enkelmedia]

Hi @iOvergaard!

Just tested this by changing the language according to what you recommended, following the languages listed here: https://docs.umbraco.com/umbraco-cms/extending/language-files#supported-languages

{
	type: "localization",
	alias: "TheDashboard.Localize.Da_DK",
	name: "Danish (Denmark)",
	meta: {
		"culture": "da-dk"
	},
	js : ()=> import('./localization/da-dk.js')
},

Notice that the core CMS does not use the names listed in the link, I tried to use the same name Dansk (Danmark)

{
	type: "localization",
	alias: "TheDashboard.Localize.Da_DK",
	name: "Dansk (Danmark)",
	meta: {
		"culture": "da-dk"
	},
	js : ()=> import('./localization/da-dk.js')
},

And the result looks like this (duplicates):

I did try both da-dk and da-DK so it's not a casing issue for the culture ISO. There is something shady going on and the docs are not clear.

1. A breaking change was introduced in 15.3 that made en-us stop working as a fallback language. Even if the docs says otherwise it's still a breaking change in a minor release that requires me as a package dev to release a new version and communicate this to users.

2. Adding any new localication-extention adds new language options to the users language selection. This behavior exists in v15 as well, and I can replicate this up to 15.4.

3. The documentation and guides are not clear. The naming in the link you provided does not match the naming in the core and I cannot see anywhere that states that the name-property of the localization extension must match the name used in the core. If this is the case, I think that also need to be addressed, what if someone decided to change the naming in the core to match the ISO-standard that you linked to - in that case all package devs would need to update. I would vote for comparing cultures using the culture ISO (en-US, en-GB, da-DK) in a case insensitive way to avoid confusion.

Feel free to download the dashboard package source and try it out: https://github.com/enkelmedia/TheDashboard to see how this behaves.

[iOvergaard]

Thanks for testing it out, @enkelmedia.

Re 1:
"en-us" has never been intended to be the fallback language, so this surprises me. There was an adjacent issue in 15.2, where you could not switch between different versions of English; so if you were already on 'en-us', you could not switch to 'en'. You couldn't switch back to the default language if you chose something else. We tried to fix that in 15.3.

What may have happened in all of this confusion is that if you had a language out-of-band (for example, "en-uk" has never been a supported locale), we may have forced you into using "en-us" under the hood, thus making it act like a fallback language. The actual fallback language in the localization service is and has always been "en", but if the client thought you were on "en-us", it would have used that language.

You have stumbled into an unintended "feature" where "en-us" may have worked. The intention is for "en" to be the fallback, and the documentation has not indicated otherwise.

I believe we can find a good middle ground here and analyse if the user tries to set a non-existent language, and if that is the case, then we force you into "en-us" for compatibility reasons.

Re 2:
The languages should not be duplicated, which is an issue, and we will look into a solution.

Re 3:
The "name" field in your extensions should not matter; only the culture field. I believe this problem arises due to your point. 2.