Importing language files that include a change of the default language into a clean install appears to fail.

[NikRimington]

Tested on Umbraco v8.5.3 and uSync 8.4.3

When importing languages into an empty Umbraco site, if this import includes changing the default language to a different language the change doesn't happen. Instead a replacement language appears to get created.

Scenario:

1. Create new Umbraco site and run the installer, Do not add a starter kit.
2. Change the default language from English US to English UK
3. Add a new language, e.g. Welsh
4. Delete the connection string & umbraco version from the web.config and delete the database.
5. Run through the installer again.
6. perform a usync import

Result:
This results in 3 languages instead of 2. This is an issue for multiple reasons.

1. The first is ID's of languages are different meaning fallback languages are wrong.
2. An extra language is present that the site might not need.

[NikRimington]

Workaround

After doing the install, before doing the uSync import manually change the default language to the new culture. This will allow the import to work correctly.

[KevinJump]

yeah looking into it now, I think its the code that detects the rename, isn't firing all the save updates it needs to, so you end up with two language files that claim to be the default (when one of them should really be blank).

[NikRimington]

I don't think it's an issue in "save" but more during import. Example files attached.
Languages.zip
If these are present and you do the import without doing the work around, you end up with 3 languages instead of 2.

[KevinJump]

yes, its because when you change the language (say from en-us to en) the existing language file isn't marked (en-us.config) as an empty-delete file, so that means you have three import files ready instead of two and a blank, which is how it should work.

[KevinJump]

the update fixes this by exporting the language again when you do the rename, (it already exports the content again, because that all changes).

[KevinJump]

At the moment the only issue is the delete of the old language fails on first import (but the new language is set as default, and everything should work) - a second import removes the rouge en-us you have.

We should, in theory, be able to deal with this with post-processing of the folder, but its a bit of a pain to keep nice, as post-processing by default only works on successful things, and the delete will fail the first time around :(

[NikRimington]

That doesn't sound like what's happening to me. It looks like it's seeing the new en-GB language and creating that which means it's got a new ID. This then causes problems in my scenario as cy-GB has ID 1 as the fallback language but en-GB is being created with an ID of 3.

It's as if the rename is being skipped over and not recognised properly.
Could you set the "rename" file to contain the old and new codes so it knows which "full" file to then look at for other properties?

Happy to have a chat on slack or something to explain further?

[KevinJump]

Yeah but I am not sure where are you using the ID value comes from. in Umbraco, all the language stuff is done via iso code (en-us) ID values can't be relied on because they just increment, so one site some adds English then welsh and it's 1 = en then they add welsh then English and its 2 = en.

the fix does also have a bit of import logic where it will do the default language thing again at the end because if we encounter the new default language before the old one, we can't set it (until we have unset the existing one) - but we can do that at the end, because we will have unset the default, on the first pass, so we can set the new one on the second.

[NikRimington]

The uSync file stores the ID for the fallback:

<Language Key="00000452-0000-0000-0000-000000000000" Alias="cy-GB" Level="0">
  <Id>2</Id>
  <IsoCode>cy-GB</IsoCode>
  <CultureName>Welsh (United Kingdom)</CultureName>
  <IsMandatory>true</IsMandatory>
  <IsDefault>false</IsDefault>
  <Fallback>1</Fallback>
</Language>

[KevinJump]

Yeah, but its never used :) the next release is actually taking it out because it just causes false positives on comparisons.

https://github.com/KevinJump/uSync8/blob/v8/8.2/uSync8.Core/Serialization/Serializers/LanguageSerializer.cs#L103

[NikRimington]

Except here: https://github.com/KevinJump/uSync8/blob/84868a4773ec8d20d1b8b7bb44dcb7d7951e3e2b/uSync8.Core/Serialization/Serializers/LanguageSerializer.cs#L109 It's the fallback value that uses the ID.
Is that going to be updated to store the ISO Code?

[KevinJump]

Indeed well spotted! (why are Umbraco still storing this shizzle as IDs!)

[KevinJump]

OK, with all the fallbacks, and stuff going to this works, will be in the 8.5 release.