Salesforce

SDL WorldServer - Segmentation error when source language is set to Spanish (Latin America) es-419, English (Hong Kong), Somali and other languages

« Go Back

Information

 
Article TypeSolution Article
Scope/EnvironmentSDL WorldServer
Symptoms/Context
When creating a WorldServer project with source language Spanish (Latin America) es-419, English (Hong Kong) or Somali, I see an error at the Segment Asset step as follows:

Execution output: Error while executing automatic action: com.idiominc.ws.ArgumentException: No such culture: es-419
Execution output: Error while executing automatic action: com.idiominc.ws.ArgumentException: No such culture: so-SO


etc.

There is no issue when Spanish (Latin America) or English (Hong Kong) are set as target languages. The project can be saved and exported correctly, so the issue is only at segmentation when the source languages are Spanish (Latin America) or English (Hong Kong) . Following other languages are affected as well:

Pashto
Hausa
Bengali
Burmese
Igbo
Sindhi
Tajik
Yoruba

The SDL Custom Cultures are installed as explained in this article:

In WorldServer, some of the locales/cultures supported in SDL Trados Studio 2017 and WorldServer are not synchronized

 
Resolution
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.

User-added image

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.
Root Cause
This issue has been filed as defect CRQ-12805
Reference
Attachment 1 
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by