This issue has been fixed starting from
SDL WorldServer 11.5.0.25.
If when using WorldSeerver 11.5 or a later version of WorldServer the error, most likely on saving the asset, occurs of the form:
Culture is not supported. Parameter name: name xx-xx is an invalid culture identifier.
then the language is not supported on the Windows version on which FTS is installed.
The details from Microsoft of language supported by different versions of Microsoft windows is found in: https://msdn.microsoft.com/en-us/library/cc233982.aspx
In previous versions, there are two possible workarounds:
1- Use a supported English or Spanish flavor by adding it to your Locales. For instance, for Spanish, use Spanish (Mexico), Spanish (Modern Sort) or Spanish (International) and refrain from using Spanish (Latin american)
2- If you want to keep
Spanish (Latin American), you can go to
Management > Business Rule Linkage > Locales > and change the locale configuration by opening the
Spanish (Latin American) Locale and select a different language to be associated with the locale name
Spanish (Latin American). For instance, associate it with
Spanish (Nicaragua) or
Spanish (Mexico), which are both supported.
3- You can leave the locale configuration as it is and if you are working on a environement hosted by SDL, we (SDL Support) can map the locale
Spanish (Latin American) to a different, supported locale in the Database, such as
Spanish (Nicaragua) or
Spanish (Mexico)To map
Spanish (Latin America) to
Spanish (Nicaragua) in the Database, run this
UPDATE statement in the WorldServer Database:
update languages set subLangCode='NI' where name='Spanish (Latin America)'
To map it to Spanish (Mexico):
update languages set subLangCode='MX' where name='Spanish (Latin America)'
As a result, the
Spanish (Latin America) Locale in your
Worldserver environment will now be mapped to language code
es-NI or
es-MX instead of
es-419 (which is the default code for this language). This change will resolve the segmentation error.
Note: when applying #2 or #3, while the locale will display as
Spanish (Latin American) in your
Locales list and/or when creating a project. However, the Translation Memory updated with your project translated into
Spanish (Latin American) will display it as the language it was mapped to, i.e.
Spanish (Nicaragua) or
Spanish (Mexico). The same will happen when exporting the project to a Studio package: the language appearing in Studio will be the one that has been mapped to. This will - however - have no impact to the project translation or the export/import process of Studio packages.
This mean that with workarounds #2 and #3. internally the languages codes of the supported language will be used, and when exporting to Studio they will display as such.
You can apply the same workaround for English (Hong Kong), mapping it to a working source language that you do not use.