We do not have a Hotfix or a resolution for this defect yet. There are two possible workarounds:
1- Use a supported English or Spanish flavor by adding it to your Locales. When doing so, rename the Locale Name
to EN-Hong-Kong or similar. Sale for Spanish.
This would mean that internally the languages codes of the supported language will be used, and when exporting to Studio they will display as such.
In WorldServer, the locale name would appear as EN-Hong-Kong on the Create Project
Note that with this workaround you would have to make sure you separate the TM content by using a dedicated TM if you want the EN-Hong-Kong content to be separated from the supported English flavor you had chosen to use as a workaround.
2- Another workarund is to map Spanish (Latin America) or English (Hong Kong) to a different language in the Database. For instance, you could map Spanish (Latin America) to Spanish (Nicaragua), which is a language that most customers do not use.
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)'
As a result, the Spanish (Latin America)
Locale in your Worldserver
environment will now be mapped to language code es-NI
instead of es-419
(which is the default code for this language). This change will resolve the segmentation error.
Note: when exporting a WSXZ package from a project with source language Spanish (Latin America)
, after opening the WorldServer package in SDL Trados Studio
, the source language will display as Spanish (Nicaragua)
. That will not affect the WorldServer
project or the TM
when importing the Return package
back to WorldServer
: The project language both in the TM and in the project will still be Spanish (Latin America)
You can apply the same workaround for English (Hong Kong), mapping it to a working source language that you do not use.