When a customer requests pricing or support for a translation we must confirm the locale. Let’s use Arabic as the example. We currently support Arabic (Saudi Arabia) ar-SA. When a customer asks about Arabic they may have a different locale (or culture) in mind but they don’t know that they should specify it. There are additional Arabic locales that our system could support:
CultureName |
DisplayName |
ar-IQ |
Arabic (Iraq) |
ar-EG |
Arabic (Egypt) |
ar-LY |
Arabic (Libya) |
ar-DZ |
Arabic (Algeria) |
ar-MA |
Arabic (Morocco) |
ar-TN |
Arabic (Tunisia) |
ar-OM |
Arabic (Oman) |
ar-YE |
Arabic (Yemen) |
ar-SY |
Arabic (Syria) |
ar-JO |
Arabic (Jordan) |
ar-LB |
Arabic (Lebanon) |
ar-KW |
Arabic (Kuwait) |
ar-AE |
Arabic (U.A.E.) |
ar-BH |
Arabic (Bahrain) |
ar-QA |
Arabic (Qatar) |
There are 2 INTERNAL documents on Box in this folder titled, Language Support Reference Documents https://convercent.box.com/s/9fhi87wh2w7vdswqruv2boz9lnlfkz8u
- LangPlanDraft INTERNAL - This is the list of locales that we already support, to some degree, and ballpark timing for locales that are planned
- system supported languages - This is the list of locales that the system can support based on what the Microsoft framework supports out of the box
Moving forward, please confirm the locale up front for all language translation requests. This is important for 2 reasons:
- Alignment on expectations – if there is a disconnect on the locale there will be a support or implementation gap that will lead to us or the customer missing a target date
- Cost and timing – there is overhead associated with each additional locale so it is a larger business decision to add a language that is not already planned
Comments
0 comments
Article is closed for comments.
Didn't find what you were looking for?
Post your question to the CommunityRelated articles