v16: Changing the language of your content is now extremely hard and no longer UI driven

[jemayn]

Which Umbraco version are you using?

16.3.3

Bug summary

I've been working on a v16 site due to launch soon. Early on there was some confusion with the needed languages on the site, and ended up having the default language set to Danish (da-DK).

After a while it was decided it should be English (en-GB) instead. In v13, you could just go to the language and choose another in the dropdown:

However, now in v16 it is no longer a dropdown, and there are no apparent ways to swap:

Initially I thought it would be enough to simply swap the languages in the database, as it seemed like everything was based on the language ids.

However, after doing that I found that with the introduction of variant blocklists they now contain a reference to the culture string instead of the language id - here is a shortened example:

{
    "contentData": [
        {
            "contentTypeKey": "49168f20-c6e4-4aee-a02a-068575e4fff8",
            "udi": null,
            "key": "e45a72ee-0f43-4e85-b827-612c4a5ec5fd",
            "values": [
                {
                    "editorAlias": "Umbraco.RichText",
                    "culture": null,
                    "segment": null,
                    "alias": "headline",
                    "value": "{\u0022markup\u0022:\u0022\\u003Cp\\u003ESales \\u0026amp; Technology Offices\\u003Cstrong\\u003E Europe\\u003C/strong\\u003E\\u003C/p\\u003E\u0022,\u0022blocks\u0022:null}"
                }
            ]
        }
    ],
    "settingsData": [],
    "expose": [
        {
            "contentKey": "e45a72ee-0f43-4e85-b827-612c4a5ec5fd",
            "culture": "da-DK",
            "segment": null
        }
    ],
    "Layout": {
        "Umbraco.BlockList": [
            {
                "contentUdi": null,
                "settingsUdi": null,
                "contentKey": "e45a72ee-0f43-4e85-b827-612c4a5ec5fd",
                "settingsKey": "d1e914ab-9a86-4fcf-bb53-ae43a68627ec"
            }
        ]
    }
}

The expose object contains the culture strings on which it should be shown.

I've gotten it to work by running these queries against my db:

UPDATE pd 
SET pd.textValue = REPLACE(pd.textValue, '"culture":"da-DK"', '"culture":"en-GB"') 
FROM [umbracoPropertyData] pd 
INNER JOIN umbracoContentVersion cv 
ON pd.versionId = cv.id 
WHERE cv.[current] = 1 
AND pd.textValue LIKE '%"expose":%' 
AND pd.textValue LIKE '%"culture":"da-DK"%';

UPDATE [umbracoLanguage]
SET 
    languageISOCode = 'TEMP-SWAP',
    languageCultureName = 'Temporary Swap Value',
    isDefaultVariantLang = 0,
    mandatory = 0,
    fallbackLanguageId = NULL
WHERE id = 2;

UPDATE [umbracoLanguage]
SET 
    languageISOCode = 'da-DK',
    languageCultureName = 'Danish (Denmark)',
    isDefaultVariantLang = 0,
    mandatory = 0,
    fallbackLanguageId = NULL
WHERE id = 4;

UPDATE [umbracoLanguage]
SET 
    languageISOCode = 'en-GB',
    languageCultureName = 'English (United Kingdom)',
    isDefaultVariantLang = 1,
    mandatory = 0,
    fallbackLanguageId = 3
WHERE id = 2;

But even after that I had to go and manually publish several nodes with descendants, rebuild all caches and restart a couple of times to get it to work.
Oh also it apparently generated a bunch of new redirects in the umbracoRedirectUrl which I could luckily just truncate as the site is not live yet.

I hope this could return as a feature within the backoffice! Or atleast that the block data follows everything else that uses the language ids so it becomes less involved to move languages around.

Specifics

No response

Steps to reproduce

Set up a new site with multiple languages and blockslists, then try to change the language as descibed above.

Expected result / actual result

No response

[AndyButland]

Just to address the first part of this issue:

However, now in v16 it is no longer a dropdown, and there are no apparent ways to swap:

Although you don't have a drop-down here, functionally you can still change the default language via the UI. If you go to the language you want to make default, and change the toggle to set it to be the default language, it'll take over being the default and the original default language won't be any more.

I can see it's greyed out in your screenshot though. It should only be disabled if it's already the default language. This is the case for what I see in testing.

If you'd gone that route and hence kept the language IDs and ISO codes aligned, would that have avoided the later problems you found with the stored data (due to your language IDs and ISO codes no longer matching?

[jemayn]

I assumed that changing the default language would not retroactively swap all existing content of the old default to the new default. But I can try it out and get back to you here 🙂

[nielslyngsoe]

Because of this potential UX confusion and Jespers reply regarding some further investigation, I put the tag needs-more-info to indicate that we are awaiting that before moving ahewad with this issue.

[jemayn]

@AndyButland I tried with a backup of my db from before fixing it initially to change the default language to the desired new language.

It seems to have no retroactive effect on my content, all the content that was created in the wrong culture is still that culture, and all blocklists that are "exposed" with a culture string still have the old culture string.

My assumption here is the default language will only matter for new changes made after the swap.

So just to summarize, we have 2 issues here:

1. I cannot change a language in Umbraco to become a different culture, which means all content and versions tied to a language id cannot easily be swapped to a different culture.
2. With the new blocklist variation introduced recently they do not follow language ids but rather culture strings which is different from all other content and means that changing the culture of a language in Umbraco doesn't carry over to the block lists.

[jemayn]

Just wanted to check in and hear if you need any additional info from me as this is still flagged with needs-more-info 🙂

[AndyButland]

No, I think we can remove that label - which I'll do - but it's not obvious to me what change we could feasibly make is, hence issue is open but no further update as yet from my side. As you say, it's the culture string that's stored with the block content, and I can't see it's feasible to modify that - i.e. across potentially hundreds of content records - on the update of a language.

[jemayn]

I see your point. I'm not sure I understand why it is a culture string and not an Umbraco language ID like it is for content versions, etc. But I can see how it is hard to change it back now that it is out there.

If you decide not to change anything then that is fine by me, and this issue can be closed. Part of the reason for opening this is also to help others know what it takes if they are in a similar situation.