As a first step, if you haven't done so already, make sure to install
SDLCustomCultures.msi for your version of WorldServer.
You can download the WorldServer distribution package from the RWS FTP site using your FTP customer account. If you have any problems, please raise a WorldServer support case.
These are the locales supported after installing the Custom Cultures:
-
-
|
Culture ID
| Culture Name |
| ca-ES-valencia | Valencian |
| chr | Cherokee |
| chr-Cher | Cherokee |
| chr-Cher-US | Cherokee |
| en-HK | English (Hong Kong) |
| es-419 | Spanish Latin America |
| ff | Fulah |
| ff-Latn | Fulah |
| ff-Latn-SN | Fulah |
| fr-CD | French (Congo) |
| fr-CI | French (Ivory Coast) |
| fr-CM | French (Cameroon) |
| fr-HT | French (Haiti) |
| fr-MA | French (Morocco) |
| fr-ML | French (Mali) |
| fr-RE | French (Reunion) |
| fr-SN | French (Senegal) |
| gn | Guarani |
| gn-PY | Guarani (Paraguay) |
| haw | Hawai |
| haw-US | Hawaiian (United States) |
| jv | Javanese |
| jv-Latn | Javanese (Latin) |
| jv-Latn-ID | Javanese (Indonesia) |
| ku-Arab | Central Kurdish |
| ku-Arab-IQ | Central Kurdish (Iraq) |
| mg | Malagasy |
| mg-MG | Malagasy (Madagascar) |
| mn-Mong-MN | Mongolian (Traditional Mongolian, Mongolia) |
| my | Burmese |
| my-MM | Burmese (Myanmar) |
| ne-IN | Nepali (India) |
| nqo | Nqo |
| nqo-GN | Nqo (Guinea) |
| om | Oromo |
| om-ET | Oromo (Ethiopia) |
| pa-Arab | |
| pa-Arab-PK | Punjabi (Pakistan) |
| pt-AO | Portuguese (Angola) |
| ro-MD | Romanian (Moldova) |
| sd | Sindhi |
| sd-Arab | Sindhi |
| sd-Arab-PK | Sindhi (Pakistan) |
| sn | Shona |
| sn-Latn | Shona (Latin) |
| sn-Latn-ZW | Shona (Latin, Zimbabwe) |
| so | Somali |
| so-SO | Somali (Somalia) |
| st | Sesotho |
| st-ZA | Sesotho (South Africa) |
| ta-LK | Tamil (Sri Lanka) |
| ti | Tigrinya |
| ti-ER | Tigrinya (Eritrea) |
| ti-ET | Tigrinya (Ethiopia) |
| tl-x-SDL | Tagalog |
| tn-BW | Setswana (Botswana) |
| ts | Tsonga |
| ts-ZA | Tsonga (South Africa) |
| tzm-Tfng | Central Atlas Tamazight |
| tzm-Tfng-MA | Central Atlas Tamazight (Tifinaght, Morocco) |
| ur-IN | Urdu (India) |
| x-es-XL | Spanish Latin America (Deprecated) |
| zgh | Standard Moroccan Tamazight |
| zgh-Tfng | Standard Moroccan Tamazight (Tifinagh) |
| zgh-Tfng-MA | Standard Moroccan Tamazight (Tifinagh, Morocco) |
| es-x-int-SDL | Spanish(International) |
| es-x-mo-SDL | Spanish(Modern) |
| haw-x-sm-SDL | Samoan |
| haw-x-na-SDL | Nauru |
| sw-x-ny-SDL | Chewa |
| zh-x-hmn-SDL | Hmong |
| quz-x-ay-SDL | Aymara |
| hi-x-bh-SDL | Bihari |
| en-x-bi-SDL | Bislama |
| en-x-fj-SDL | Fijian |
| ml-x-su-SDL | Sundanese(Roman) |
| iu-x-ik-SDL | Inupiaq |
After the installation, you might find that some of the languages are still not available in WorldServer. The reason for this is that when using the FTS Server in WorldServer, it is important to note that the default operating system cultures, default .NET cultures, and user-defined cultures determine which cultures are available. The version of Windows on which the FTS Server is installed also plays a role in which .NET culture codes are available. Not all versions of Windows have all .NET cultures available. For example, Windows Server does not support a number of cultures. The same is true for certain locales in WorldServer that have never been supported by .NET. You can map these WorldServer locales to .NET cultures in the exchange.properties file.
If a language is not available in WorldServer, you can map an existing locale to map it to a language code that is supported by the Studio File Types in exchange.properties on the server where WorldServer is installed. For example, map as below (make sure the studioLocaleMapping ID property is unique):
studioLocaleMappingHM = Hmong, de-DE
studioLocaleMappingRU-MD = Russian (Moldova), ru-RU
studioLocaleMappingTG = Tigrigna (Eritrea), ti-ER
studioLocaleMappingTG2 = Tigrigna (Ethiopic), ti-ET
studioLocaleMappingNO = Norwegian, nb-NO
studioLocaleMappingMK = Macedonian, mk-MK
studioLocaleMappingBurmese = Burmese, my-MM
studioLocaleMappingCentralKurdish_Irak = Afar, ku-Arab-IQ
After adding the property to exchange.properties file, save your changes and restart WorldServer and FTS. Test the change by creating a test project with that language. Once the project is created, open the Task in Browser Workbench and do a Save to confirm that there is no error, and export the Task to a WSXZ package. Open the WSXZ package in SDL Trados Studio and confirm that it opens in the language corresponding to the language code used in the mapping.
Note: The language code in the WorldServer UI does not change.
If you are not sure about the language code supported by Trados Studio:
1- Open any source file with the affected target language as a standalone file in Trados Studio.
2- Do a Save: this action will create a bilingual Studio file in SDLXLIFF format.
3- Open the SDLXLIFF file in Notepad and next to target-language= you will find the language code supported by Trados Studio. Use that language code for mapping.
However, keep the following points in mind:
- When the translation of a project with a source or target language that has been mapped in exchange.properties updates your TM, the language displayed in the TM will still be the one with the original name, even if you have changed/edited the name of that language. This is because the TM refers to the locale name and not the Language name, which can be edited to anything. So assuming you have added a mapping to language "Afar" like this
studioLocaleMappingValencia = Afar, ca-ES-valencia and then you renamed the language name in the UI from "Afar" to "Valencian". In the Translation Memory that has been updated after the mapping, the language/locale will still be "Afar".
- The Language Code in the list of your locales will also still remain the original one, in the example above with "Afar", it will be "aar-ET". The language code from the mapping in exchange.properties will not be displayed here.
- Still following the same example, the WSXZ package that you will export from the project will contain the Language code "aar-ET" s part of the name, although the language code in the SDLXLIFF file inside the package will be the one that you have mapped "ca-ES-valencia". For example the name could be similar to "tasks_Testproject_1305_aar_ET_xliff.wsxz". This might be confusing. Just ignore this naming convention in the WSXZ project name and focus on the "correct" language code that will display after opening the package in Trados Studio.
