Amazon’s uneven (and not unusual) language strategy

Amazon Crossing is the Amazon publishing imprint dedicated to translating non-English books into English. In just a few years it has grown to be a leading translator of literary novels.

I noted earlier that Amazon.in doesn’t significantly support Indian languages. But on the Amazon Crossing submission page, you will find support for Hindi, Bengali and Punjabi. The global gateway is shown below on the right:

The gateway is (sadly) missing a globe icon — though I suspect the Amazon Crossing logo is partly to blame (one globe too many perhaps).

Other languages supported include Arabic, Portuguese and Russian. What’s interesting here is that the language mix is noticeably different on the Amazon.com site.

Both Amazon.com and Amazon Crossing support 13 languages in addition to English as noted in the 2017 Report Card, which means Amazon still has a long ways to go before it competes with the leaders in languages. Here is the average number of languages supported by the leading global brands over the past seven years.

But what I wanted to call attention to is Amazon’s uneven support for languages across its different products and services — a phenomenon that is not unique to Amazon. Many multinationals I work with support different language mixes for different properties. The rationale is sound: Different products and services have different audiences, marketing strategies, global and regional partners, and local opportunities.

But how do you balance an uneven language strategy with a consistent global content architecture? For example, let’s say you have one product page localized into Russian and a visitor to that product page goes to the global nav menu and selects another product, naturally assuming this other product also is also localized into Russian, only to discover it is not.

This problem is only going to grow more acute as more companies decentralize their global product content and marketing strategies.

Of course, every challenge is also an opportunity. Where companies can differentiate themselves is in how effectively they manage user expectations, manage language expectations, and how they leverage machine translation to fill language gaps.

To learn more about which companies are doing the best job at managing language expectations, check out the Web Globalization Report Card.

Q&A with Jukka Korpela, author of Going Global with JavaScript and Globalize.js

What’s the most important thing you want JavaScript developers to learn from this book?
By making use of free tools such as Globalize.js, developers can easily adapt their applications for new markets with a minimal amount of work. For example, adapting the format of a date or number for a different country requires a single library function call.

This book also goes into more complex operations and functions, but it’s important that developers first get a feel for simple data format localization.

What is Globalize.js and why is it so valuable for developing global software?
Globalize is a standalone, open source JavaScript library that help you to globalize your JavaScript code. Globalize lets you adapt your code to work with a multitude of human languages. You need not know the languages or their conventions and you do not need to manually code the notations.

Globalize includes locale data for more than 300 locales, including presentation of numbers, date notations, calendars, time zones. It is easily modifiable and extensible to cover new locales.

You devote a chapter to the finer points of Unicode. Why is it so important for developers to understand Unicode?
Unicode has become widely used on web pages, in applications, and in databases, but most IT professionals still have a rather limited understanding of it. The generality of Unicode—covering more than 100,000 characters from all kinds of writing systems—has its price: complexities and practical issues. These issues are often encountered in common operations such as string comparison and case conversions.

You’re based in Finland. What common mistakes do you see made by developers who have localized software for your locale?
The most common mistake is partial localization: a page or application appears to be in Finnish or Swedish, but on a closer examination, you’ll see English notations for data items. Even the most current software may use a date notation like 11/6/2012, which is not only incorrect by our language rules, but also ambiguous.

Often, menus contain a mix of Finnish and English items. You might also see a dropdown list of countries of the world, with names in Finnish but in an odd order, usually based on English-language alphabetization rules.

Mistranslations are not rare and may cause real harm, particularly in menus, buttons, and labels for form fields. An expert may understand the cause of the problem—someone has translated a short fragment of text with no idea of the context−but average users are simply confused and may revert to use the English-language site as a lesser of two evils.

HTML5 proposes new input attributes, such as date and number. But these elements pose challenges that many developers might not be aware of. Can you explain why?
Browser support is still limited, inconstant, and partly experimental. But in addition to that, these elements have not yet been defined and implemented with globalization in mind. They may be implemented using browser-driven localization, using the browser’s locale. Adequate localization would reflect the locale of the content, the web page.

These issues can be partly addressed using code that avoids improper localization. But although the new elements are promising in the long run, they should be regarded rather as interesting features to be tested and used in controlled situations, rather than used in normal production.

Going Global by JavaScript and Globalize.js

NOTE: We also offer an enterprise price for a PDF copy of the book to be shared across your company.