The JW.org website supports more than 675 written languages. And it doesn’t stop at written languages; it also supports more than 90 different sign languages as well as downloadable PDFs in languages ranging from Adyghe to Zazaki, for a total of 941 languages.
Apple, by comparison, supports a mere 34 languages. And Amazon, the company now synonymous with world domination, supports just 15 languages. Based on my studies, the world’s leading brands support an average of 31 languages, adding roughly one new language per year.
Religious leaders understand well the power of language. And so do the tech leaders. Sadly, too many other business leaders have not yet come to this realization.
Notice how precipitously the language curve drops; it plateaus at roughly 40 languages for companies such as Audi, IKEA, 3M, Nikon and Cisco. And yet 40 languages is still a significant accomplishment for most organizations. The average number of languages, among the leading global brands, is just 32 languages.
The next great language boom will center around India, but this will take time as even companies such as Amazon and IKEA have been resistant to fully invest in the many official languages of this country.
In it, I define the “translation economy” and the opportunities (and challenges) it presents to all organizations.
From the information economy to the translation economy
The internet connected the world’s computers, and the digitization of content enabled the rapid flow of information around the world, which drove several decades of what came to be known as the information economy. But one of the great myths of the information economy – and the World Wide Web, for that matter – was the idea that a company could go global simply by launching a website. While the Internet connects computers, it is language that connects people, and the information economy has for too many years exhibited an English-language bias.
I recently wrote an op-ed for the Seattle Times about the importance and value of thinking globally. Here’s an excerpt:
Consider Starbucks. In 2003, this aspiring global company supported a mere three languages. Today, it supports 25, which may sound like a lot until you compare it to many other global brands. Among the leading global brands, the average number of languages supported is 31, a new high based on my years of research. And then there are those companies that left 30 languages behind years ago — like Facebook, which supports more than 90 languages, and Google, which supports more than a hundred.
This degree of language growth isn’t just a tech phenomenon. John Deere supports 31 languages, Ford supports 42, and even Jack Daniels is fluent in 22 languages.
So while the U.S. leaders are speaking the rhetoric of isolationism, American companies of all sizes are speaking a different language — in fact, a lot of languages.
Dates are often used as case studies to illustrate the risks of ignoring cultural differences. For example, the date 4/7/2011 could be taken to mean July 4th by some and April 7th by others.
The not-so-simple approach to dates
Using the toString, toDateString or toTimeString
The simplest way to write a Date value would be to use the toString method, such as today.toString(). It produces, by definition, a system-defined presentation of the date.
In practice, you get some English-language notation, such as “Sat Jul 04 2015 13:30:50 GMT+0300,” independently of the language of the page, or the browser, or anything. However, browsers may try to localize the time zone denotation in their own ways. The code document.write(new Date(2115,6,11)) gives different results based on different browsers. The following examples are from browsers on a Finnish version of Windows 7 Pro:
So three of the six browsers write the time zone using a name in the language of the underlying operating system. Only Safari gets it right; Firefox and Chrome mess up the letter “ä” in two different ways.
The best we can say about the toString method for Date is that it produces some human-readable presentation of the moment of time. The presentation is widely understood, but far from universally. It would not look good on a page otherwise in Greek, Chinese, or Thai.
Similar challenges apply to using the methods toDateString and toTimeString.
Beware of implicit Date toString conversions
The deceptive toLocaleDateString
It would be natural to expect that the toLocaleDateString method produces a localized presentation of the date, and it does. But, as a developer, the locale is beyond your control. Little does it help to have the date localized in Swahili when it should be in Arabic.
You may also get essentially different results on different browsers even with the same system. For example, writing a date on a Finnish Windows operating system, with user interface language set to French, I get:
Internet Explorer: dimanche 1 juillet 2012 Firefox: 11. heinäkuuta 2012 Opera: 11/07/2012
Globalize to the rescue
To localize the display of Date values, you could override the built-in toString method. For that, you would need code that converts a Date value to a localized string in a format that is suitable for the target locale.
This example uses a full-length (‘F’) format, which contains all of the date information. In many contexts, it would be better to display only subsets of this information, such a short date. To get more granular control, we need specific presentation formats, which we cover in more detail in Part II. But this code is an effective and lightweight way to protect against accidental non-localized writing of Date values.
Using the Globalize library, you could write the following:
In the example above, the first two script elements are needed to refer to external library files. The files are assumed to reside in the same folder as the page, so that you can use just filenames as URLs. The files referred to can be downloaded via the Globalize page at GitHub. The page address still reflects the old name “jQuery Global” of the library, but the Globalize library is now totally independent of jQuery, though it reflects same general idea “write less, do more.” Using Globalize by no means excludes using jQuery, but neither does it require it.
The code uses the “plain” way of accessing an element with getElementById() and setting its innerHTML property. If you are used to jQuery, you would probably want to replace the assignment with a shorter construct: