Globalization Myth Series – Myth 3: Language support should be limited to the official language(s) of a country

This article was originally written in English. Text in other languages is provided via machine translation.

Problem statement

In the globalization field, we often observe cases where companies mix up the usage of countries and languages when delivering products to their global customers. Assumptions are often made that people living in a country should receive services in that country’s most common language(s) – such as – Japanese in Japan, English in the United States or Russian in Russia. Good companies will even support multilingual situations like Belgium and Switzerland, which support multiple official languages – but is it really enough?

In this blog article, we argue that the concepts of “Country” and “Language” should be treated apart – even though they are related.

Languages have no borders

Historically, languages have spread around the world through immigration, invasions and colonization. This is why Spanish is spoken in South America, English in the United States, French in Senegal and Canada – just to name a few examples.

Languages haven’t been limited to their homelands in a long time. For example, Spanish and Portuguese have spread to the point where most of their native speakers are found outside the Iberian Peninsula. Only 8.95% of Spanish speakers are actually Spaniards [1]. We could argue that there are different flavors of Spanish, Portuguese or French, but, in essence, these languages are the same and they are not confined by country boundaries.

Twitter is a great tool to visualize languages spoken around the world. Eric Fisher created a cool language map using Twitter data [2], which clearly shows borders being redefined. Catalan appears on the map and multilingual countries like Belgium disappear under France and The Netherlands.

Map of languages as used with Twitter

Figure 1: European Language Map – Author: Eric Fischer

Official languages leave some major gaps

Many companies launch products/services in a country and limit localization and features to the official language(s) of that country. In software, a typical example is to create a new product for the American market and limit functionalities to English-speaking users’ needs. But this is usually not enough – even if the market is limited to the United States.

Recent U.S. Census data shows that 60 million (or 21%) of Americans aged 5+ years old speak another language than English at home. Spanish takes a big part of the pie with 25 million, but languages like Chinese, Tagalog, French, Vietnamese, German and Korean are each well above the 1 million speakers mark [5]. This is very understandable considering the immigration history of the country.

In addition, the U.S. welcomed 59.7 million international visitors in 2010 [6]. Of those, 33.4 million were from Canada and Mexico and 26.4 million from outside North America. Knowing that these foreigners spend on average $4,000 during their stay, this market segment shouldn’t be ignored.

Using the Greenberg’s index, which measures the probability that 2 persons in a country would speak the same language, The Economist shows that language diversity is happening in all countries around the world and, especially, in nations other than the United States, Russia and China [7]. Also, is an excellent source of data around language adoptions.

This diversity is also visible in Adobe’s analytics. Thanks to the Adobe Digital Marketing Suite and our Dynamic Language Delivery technology, we are able to capture the languages in which our worldwide customers would like to receive products and/or documentation. Figure 2 shows the language requests for Adobe Nav in the United States. Data collected with this small application basically confirms the diversity of the population in the U.S since languages such as Spanish, Arabic, British English, Korean, Simplified Chinese, Traditional Chinese, Dutch, Russian and Turkish are all requested by users located in the United States.

Languages expected by DLD users

Figure 2 – Unsatisified language requests for Adobe Nav in the United States

Language diversity in any country is the chief reason why software products should be developed with a global audience in mind. Even if the user interface or documentation is left in English, desktop, web and mobile applications should at least be able to input, display and print characters for most languages.

Similarly, we have been able to capture data about the preferred languages on This data confirms that countries and languages are two separated concepts – and while most customers from a country read the content in an official language, a big chunk of visitors still prefer to read the content in a different language. For example, with the Action Script Reference (ASR) guide, we noticed that, in Russia, only 68% of the Flash developers prefer reading the documentation in Russian versus 31% in English (a non-official language) and 1% in other languages. Similarly, numerous Flash developers outside of Russia choose to read the ASR documentation in Russian (See Figure 3).

Distribution of Russian Action Script Readers around the world

Figure 3 – Country distribution of Action Script Reference read in Russian language

This is another example why assumptions between countries and languages shouldn’t be made.

As people continue to become more mobile, it is critical to separate the concepts of country and language. This mobility is what spread languages beyond borders and creates the need to have languages supported everywhere.

A language is a customer preference, which can’t be constrained by country borders.

Consequently, if languages don’t have borders, flags shouldn’t be used to represent them as often seen on web-sites. Flags are meant to represent political entities [3]. A common example is to represent the English language with the British “Union Jack”. But it’s not culturally sensitive for English speakers from Australia, India or United States. Some have addressed the problem by mixing multiple countries’ flags into one although it’s making the situation even more confusing. The flag below (Figure 4) represents the German language (spoken in Germany, Austria and Switzerland) and we can imagine how convoluted the Spanish language flag would look like since Spanish is the official language in 14 countries [4] and spoken in many more!

Using flags to represent languages can become complex

Figure 4 – Flags and Languages (WikiMedia)


In summary, we offer 3 take-aways to consider when launching a product globally:

  1. Differentiate the concepts of “country” and “language”. As such, don’t use flags to represent languages.
  2. Don’t limit support to the official language(s) of a country/region. Some languages may need to be supported even though they don’t have official status.
  3. Languages don’t have borders and need to be supported globally. Capture users’ preferred language(s) so you can serve them in their language independently of their location.


Globalization Myth Series – Myth 1: Software Globalization = Internationalization = Localization = Translation

This article was originally written in English. Text in other languages is provided via machine translation.

Probably the biggest misconception we encounter when talking with some colleagues from outside the Adobe Globalization team is that software “Globalization”, “Internationalization” and ”Localization” all mean the same thing, and that thing is somehow related to something almost anyone can understand: Translation.

We can’t blame our colleagues for holding such misguided beliefs, as these terms have been used and abused for generations.

It probably doesn’t help that there are also terms in use such as “Culturalization”, “World-Readiness”, ”Glocalization”, “Transliteration”, “Transcription”, “Localizability”, and “Japanization”.

The fact that each of these have corresponding abbreviations (e.g. G11n, I18n, L10n, T9n, C13n, L12y) and also different spellings (“Globalisation”, “Internationalisation”, “Localisation”, etc.) just helps make the whole thing more scary and confusing to civilians.

This article hopes to clarify these differences, and provide a better understanding of the various steps that make up software globalization.

Clarifying the terminology

We’ll focus our explanations around a few key basic terms that generate the most confusion. One thing to be aware of is that although the meaning of some tasks such as ‘translation’ and ‘localization’ are standard across the industry, some other terms such as ‘globalization’ and ‘internationalization’ are not. The definitions provided here are the predominant ones (which we use at Adobe).

Internationalization (commonly abbreviated as I18n) is an engineering exercise focused on generalizing a product so that it can handle multiple languages, scripts and cultural conventions (currency, sorting rules, number and dates formats…) without the need for redesign. Internationalization, sometimes referred to as world-readiness, can be divided into two sets of activities: enablement and localizability.

Localization (L10N) is the process of adapting a product or service to a particular language, culture, and desired local “look-and-feel”. Translating the product’s user interface is just one step of the localization process. Resizing dialogs, buttons and palette tabs to accommodate longer translated strings is also part of localization.

Translation (T9N) is simply converting the meaning of text in one language into another. In a software product, the content that are translated are user interface, documentation, packaging and marketing collaterals. Most translation work is done by professionals, although in recent years, some companies started exploring the use of ‘community’-translation, and machine-translation.

Globalization (G11N) refers to a broad range of engineering and business development processes necessary to prepare and launch products and company activities globally. The globalization engineering activities are composed of internationalization and localization while the business development activities focus on product management, financial, marketing and legal aspects.

World-Readiness is an equivalent term to Globalization, but it’s more often used in the context of internationalization.

How do they relate to each other

The simplified diagram below illustrates the relationship between the main globalization-related activities.

In summary, in the context of software:

  • Translation is one part of Localization
  • Internationalization is a pre-requisite of Localization
  • Internationalization and Localization are parts of Globalization
  • Globalization includes many business-related activities outside of the product itself.

A real-life analogy

Still having trouble understanding? Let’s make an analogy to a product everyone is familiar with: an automobile.

The Toyota Corolla is one of the most successful cars of all time. Over 30 million of them have been sold worldwide. But, had its makers not adopted the basic principles of globalization back in the 60s, the Corolla would hardly be known outside Japan today.

So, to achieve such success, Toyota had to:

  • Embrace early on the idea that they wanted to reach markets outside Japan. They set up a world-wide network of in-country marketing, sales and customer support organization. (Globalization)
  • Design and develop a car that could be easily adapted to other geographical markets with minimum cost and effort (Internationalization)
  • Adapt cars to specific geographical markets. For example, for the U.S., Canada and most of Europe, the steering wheel and pedals were easily moved to the left side of the car without structural changes. (Localization)
  • Provide instruction manuals in the language of the market. (Translation)

Example of localization of an automobile user interface

Where the problem lies

So what is the impact of this ‘generalization’ of terminology to the software globalization process?

The main problem is that most product teams look at globalization as a single monolithic process that occurs sometime after design and implementation of the English product, and owned by a single team (the ‘Globalization’ team). This mindset encourages a “throw-over-the-wall” approach which often results in:

  • Additional core engineering and testing effort to resolve critical internationalization issues found late in the schedule
  • Additional localization engineering and testing effort to manually handle localizability issues
  • Higher number of product defects
  • Schedule delays
  • Poorer customer experience

Using the automobile analogy in the previous section, a “throw-over-the-wall” approach would mean that, to adapt a Toyota Corolla designed for Japanese customers to the American market, engineers would need to move the engine or the suspension system in order to move the steering wheel and pedals from the right side to the left side of the car – an expensive and time-consuming operation.

Internationalization helps prevent this

The short story (key takeaways)

  • Globalization, internationalization and localization are related but different activities, performed by different teams at different stages of product development
  • Incorporate Globalization into your thinking as early as possible. Start during design. Ask yourself: which worldwide markets am I targeting in the short term and long term? What do these customers need? If you just think about today’s markets you will ignore globalization.
  • Implement an internationalized product even if you don’t think you will sell outside the U.S. or to non-English-speaking customers, because this decision can easily change and then alterations will be very expensive. If your product is successul in one market, you will most likely have great business opportunities abroad. So, plan for it.
  • Internationalization should be primarily performed by the product’s core engineering team. Do it once, do it right, then hand it over to localization.
  • The localization process will be a lot easier and cheaper if the product is well-internationalized.

The most successful global corporations have instilled Globalization as part of all its employees’ “DNA”. In order for a company or product team to be successful internationally, there must first be a conscious decision from executives and the buy-in from everyone involved in the design and development of a software product to go international. This means that, unless the product and the entire infrastructure surrounding it are not ready to capitalize on the opportunities present in an international market, the global revenue potential of the product will never be fully achieved, or at a prohibitive cost only.

See also

Globalization Myth Series – Myth 2: This product is only for the U.S.