Language configs are being created with duplicate keys preventing imports

[ribsdigital]

Describe the bug Some languages have duplicate key values in the generated config files resulting in not being able to run a uSync import.

To Reproduce Steps to reproduce the behavior:

1. Create the following two languages in the backoffice, Arabic (world) (iso code ar-001) and Chinese (Simplified, China) (iso code zh-Hans-CN)
2. Do a full uSync export
3. Doing an uSync import results in the following error: Error: Duplicate: Item key 00001000-0000-0000-0000-000000000000 already exists for \zh-hans-cn.config - run uSync Health check for more info.
4. Running a uSync health check returns the following details:

   
   There are 1 clashe(s) where files share the same keys

There are multiple clashes where items of the same type share the same keys.

Clash [\Languages\zh-hans-cn.config] shares an id with [\Languages\ar-001.config]

To fix this perform a clean export from the uSync dashboard

5. Viewing the generated language files confirms the duplication of the key value:

<?xml version="1.0" encoding="utf-8"?>

Arabic (world) ar-001 false false en-US

<?xml version="1.0" encoding="utf-8"?>

Chinese (Simplified, China) zh-Hans-CN false false en-US

**Expected behavior**
Language config files should be generated with unique keys.

**About your Site (please complete the following information):**
 - Umbraco Version: 13.4.1
 - uSync Version: 13.2.4
 - Browser [e.g. chrome, safari]: n/a

**Additional context**
Looking through the source, we've found the [LanguageSerializer.cs](https://github.com/KevinJump/uSync/blob/v13/main/uSync.Core/Serialization/Serializers/LanguageSerializer.cs) has the following code:

protected override XElement InitializeBaseNode(ILanguage item, string alias, int level = 0) { // language guids change all the time ! we ignore them, but here we set them to the 'id' // this means the file stays the same!

// for backwards compatibility, use the LCID unless its
// the 'unknown' value then use the iso-code turn that into a guid
var key = item.CultureInfo.LCID != 4096 
    ? Int2Guid(item.CultureInfo.LCID) 
    : item.IsoCode.ToGuid();

return new XElement(ItemType, new XAttribute(uSyncConstants.Xml.Key, key.ToString().ToLower()),
    new XAttribute(uSyncConstants.Xml.Alias, alias),
    new XAttribute(uSyncConstants.Xml.Level, level));

}

To simulate the logic, we ran the following code against a number of languages:

var isoCodes = new List { "en-US", "ar-001", "es-ES", "fr-FR", "id-ID", "pt-PT", "zh-Hans-CN" };

var output = new Dictionary<string, Guid>();

foreach (var isoCode in isoCodes) { var cultureInfo = CultureInfo.GetCultureInfo(isoCode);

if (cultureInfo.LCID != 4096)
{
    output.Add($"{isoCode} used Int2Guid({cultureInfo.LCID})", Int2Guid(cultureInfo.LCID));
}
else
{
    output.Add($"{isoCode} used isoCode.ToGuid()", isoCode.ToGuid());
}

}

Both `ar-001` and `zh-Hans-CN` report having the `LCID`  of `4096` meaning that the output should result in a unique key for both:

![image](https://github.com/user-attachments/assets/9d15b6e6-9117-4000-a97a-32dc9b15b34a)

However, it would appear that the code in uSync is reporting the same LCID for these two languages meaning they both run through the `Int32Guid()` method which results in the same key of `00001000-0000-0000-0000-000000000000` being generated.

[KevinJump]

Hi,

yeah i think this is fixed, just not released 😞 - which is why the code looks OK, behaves ok in your test but doesn't when it comes to actually running it.

the fix was made late June, but there hasn't actually been a release since then - so its not public.

I will take a look see what (if anything) else is pending and push at least an overnight release out to fix this for you.

[KevinJump]

the fix has been released in v13.2.5 now.

[ribsdigital]

thank you for the swift turn around kevin! we've just updated to v13.2.5 and tested, works like a charm 😉