For companies who realize they need to translate or localize their website, they should ask themselves “Is our website ready for translation?” And when I say website, I mean the web content management system (WCMS) that serves as the platform for authoring, storing and publishing their website, as well as the content served via the website.
Let’s take a quick test. Look at the homepage for a Yachting Club website. Can you detect any items on the page that would need to be translated or localized in order to function appropriately for visitors from another country who speak another language? This Yachting Club wants to translate their website for Brazil and Brazilians traveling through one of the club’s marinas, and the United Arab Emirates, where Arabic is spoken and there is a potentially large yachting market.
How many items do you see that would need to be addressed before this company could successfully launch and use their website in these new markets for these native language speakers of Portuguese and Arabic? 1..4…10…more than 10?
If you guessed more than 10, then you are right. There are at least 14 items on this website detectable by just viewing the homepage that require localization!
1. Any Search tool/utility needs to be enabled to support different character sets (including European, Asian, and Arabic scripts). This means the search function will accurately perform a correct string comparison for any languages.
2. Input fields must be enabled to allow for data entry in different languages. So if the values of the input fields will be stored in a database, the database will need to be enabled to handle all different characters from all the languages. String concatenation and UI creation at run time typically presents problems. This practice of putting fragmented strings together to create sentences and messages at run time does not always take into consideration the linguistic requirements of the languages into which a product is localized. For example, where in English it is correct to say “Welcome John”, in Spanish this may be incorrect if the User is a woman: “Bienvenido John” versus “Bienvenida Mary”.
3. Some 800 numbers will work only in the United States and so locale-specific country numbers would need to be used and displayed based on the language/locale page.
4. Linguistic, cultural, legal design issues with ALL content:
a. Content should be correctly translated
b. Cultural issues: Content should be culturally correct, maybe even customized
c. Legal issues: Content may need a “scrubbing” for legal issues
d. Design: Expansion issues with languages that are longer than English like Portuguese or need to be displayed right-to-left like Arabic
5. Content may need a “scrubbing” for transactional legal issues. A well-developed, comprehensive IPR and cyber commerce compliance strategy should be a major part of the business plan of any company looking to do business globally.
6. Legal issues: Content may need a “scrubbing” for legal issues specific to adhering to Privacy laws in other countries. The European Data Protection Directive strictly regulates personal data collection, processing and transfer.
7. Graphics may require localization if they are not culturally appropriate for your target locale. This bikini clad lady would be fine for the USA and Brazil but would NOT be culturally appropriate for many Middle Eastern locales.
8. Text expands in many languages so graphics should be designed with expansion in mind. Graphics should be created using the “layers” feature in most graphic applications (Photoshop, Illustrator), keeping text and graphics separate so the text can easily be extracted and localized.
9. Visitors to a website from varying locales may be confused by date formats. The format MM/DD/YY is unique to the United States. Most of Europe uses DD/MM/YY. Japan uses YY/MM/DD. The separators may be slashes, dashes or periods. Some locales print leading zeroes, others suppress them.
United States 09/10/2013
10. Websites or applications that support only one currency need to be adapted to record the currency along with the amount. As with date formatting, currency is not constant throughout the world. A correct culture-sensitive representation of currency needs to take into consideration the currency symbol ($, €, ¥, £), the currency symbol placement (before or after the digits), the negative-amount display (negative sign, use of parentheses) and finally the decimal separator (“,”, “.”, etc).
United States ($127.54)
Netherlands 127,54 €-
11. The format for telephone numbers around the world varies significantly. So input fields and the routines that process information dealing with telephone numbers should be able to handle the variety of formats. Here are some examples:
United States (123) 456 7890
China 1234 5678
Poland (12) 345.67.89
12. Address input fields must be adjusted to allow for data entry that matches mail formats from different countries. So if the values of the input fields will be stored in a database, the database will need to be enabled to handle all different characters and formats from all the languages and countries. City, State, Zip might work in the USA but other countries may have Provinces and not States and no Zip codes.
13. Visitors to a web site from varying locales may be confused by date formats. Again date formats are different in different countries and you want to make sure you can accept and store these formats correctly and of course ship a product or reserve a slip on the right days and months.
14. Iconography should be reviewed for cultural appropriateness. The “Okay” hand gesture in Brazil is like “flipping someone the Bird” in the USA.
|Culturally correct in the USA, but not in Brazil and other countries!|
|Might look like this in another culture OR country 🙁|
Thankfully, many of the items above can be addressed out of the box with some straightforward configurations using the right web content management system. Website design and development teams still need to ensure ALL content is appropriately localized from a Linguistic, Cultural, Legal and Design perspective in order for a site to fully function and be effective for a specific country or user base.
To learn more about which content management systems do a good job supporting Multilanguage websites see:
- Adobe CQ5 and translation: Website Translation in Adobe Experience Manager – Adobe CQ5
- Sitecore and translation: Set up and Management of Multilingual Websites in Sitecore
- Ektron and translation: Managing your Multilingual Website with Ektron 8.5 CMS
- EPiServer and translation: Website Content Localization with EPiServer 7
To learn more about Linguistic, Cultural, Legal and Design issues with global websites see: