SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL Speech to Text
SDL Managed Translation - Enterprise
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Tridion Docs Developers
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL Contenta S1000D
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
Wishing you all a happy and healthy 2021!
A customer has asked whether we can add a target locale of Arabic (Israel) to ensure that the LSP chooses a translator with the correct dialect. We currently use the generic Arabic ar. I can create a new locale with the display name Arabic (Israel), but if the language code remains the same, would this not create issues in the memories?Thanks in advance for your help!Dave
we wish you a happy and healthy 2021 too! Thank you for the interesting question and the opportunity to clarify how this works.
The language displayed in the Translation Memory is always the…
Hi Dave, FYI: the issue you had with Spansih (Latin America) as source language has been fixed starting from WS version 11.5. Changes in the Database should be only done when no other acceptable workaround…
The language displayed in the Translation Memory is always the actual Language name and not the one referenced to in the "Name" field of the Locale configuration, which can be changed to any name while configuring any language/locale. Hence, if you have 2 language names based on the same language and language code, for example based on Arabic (U.A.E.) and (ar-AE), but with different names as
Arabic (U.A.E.) - original nameArabic (Israel) - changed name
if you translate a project with both these target languages and the TM is updated with the translation, when you look into the TM you will find the translation for Arabic (Israel) and Arabic (U.A.E.) both under Arabic (U.A.E.). Therefore, you will not - indeed - have separate TM entries, which is obviously a problem.
Therefore, the recommendation is to use a language that you do not use at all in your projects and change its name to the unsupported language, in this example "Arabic (Israel)". The TM will be created under the actual original language name and also the language code when exporting that TM and/or when exporting the project to a Studio pacage will be the one from the original language name.
On a side note: you mentioned that you are currently using Arabic (ar) which is a generic locale that is not supported by FTS. I assume that you have already mapped this language to a different one in exchange.properties in order to be able to save and export/import projects created with this language using File Type filters. See also article: gateway.sdl.com/.../communityknowledge so in your "real" project created under this language, you are probably already using a different language code than "ar".
I hope this helps you.
Hi Caterina,Thank you for your prompt and detailed answer! We actually don't have any project types defined where Arabic is a source language. We made a decision at the start of our WorldServer journey to limit source languages in projects with segmentation to the 8 most important corporate languages. Everything else uses a generic "Source" language and goes as manual translation (which we needed anyway to allow for the large number of PDF and other non-segmentable file types). In this particular case Arabic (Israel) would only be a target language. We had an issue with Spanish (Latin America) and used the UPDATE database command to change the sublanguage code from 419 to NI. Could we use this same approach here to create ar-IL?
Hi Dave, FYI: the issue you had with Spansih (Latin America) as source language has been fixed starting from WS version 11.5. Changes in the Database should be only done when no other acceptable workaround is present. You could try the same approach as for Spanish (Latin America) should work, but since we have not tested, so it would be at your own risk. If you need more assistance on this, please created a support case referring to this post and I will pick it up. Thanks, Caterina
Thanks, will do! We now have 11.6 on our QA system so I was looking into reverting that change, which is how I got the idea we could do that for Arabic (Israel), too.
Just wanted to confirm that after having our SQL team run the update restoring es-419 it does indeed work as it is supposed to under WS 11.6 :-)