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.


GALA Webinar on Localization Project Management

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

Manish Kanwal, International Program Manager at Adobe will be conducting a webinar at GALA (Globalization and Localization Associates), which is the largest non profit standards organization within the language industry. The webinar will present insights into the best practices for managing a complex localization project. Additionally, it will elucidate with a case study of a comprehensively large project with engineering teams spread across the globe including, linguistics, reviewers, legal, supply-chain, marketing, customer-support and many more.

Join this webinar to acclimatize what it takes to project manage and localize in demanding conditions, right from the point the product is envisaged until its public launch. Event details are available here, it will be broadcasted on 26 July 11:00 EDT

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

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

In April, we launched our Globalization Myth series by debunking the myth Globalization = Internationalization = Localization = Translation. This time, we will dismantle another urban legend: “This software product is only for the U.S.”

The problem statement(s)

When a new software product is being designed and implemented, we often hear things like:

  • “Our product is in English only, so we don’t need to worry about localization at all.”
  • “Let’s not worry about localization for now since the initial language requirement is just English.”
  • “Let’s get English out of the door first and we’ll worry about localization later.”
  • “We are now only focused on features, not localization.”

Also, in the statements above, the term “localization” is often interchanged with “globalization” and “internationalization”.

This is somewhat understandable, since the United States has historically been both the top producer and consumer of software products, and its main language, English, has been the world’s lingua franca for over a century.

A reality check

Unfortunately, the above assumptions reflect a mindset that produce a significant negative business impact in the long term. They are false from several perspectives:

  • Very often, software products end up being localized. Can you name a commercially successful software product that is not localized?
  • Even if a product is never localized because of its nature – let’s say it’s a developer tool – or because of little market demand (e.g. some developing markets), its internationalization is likely important for two reasons:
    • The content created with the product might need to be localized. Using  Adobe examples, every day many thousands of customers localize text layers of Photoshop documents, magazine articles created with InDesign, text in Flash animations, websites created with Dreamweaver, and rich internet or mobile application created with Flash Builder, into languages Adobe does not localize their products into.
    • Certain regional markets have specific requirements. Again using Adobe products as examples, specific requirements from our customers in India and the Middle East have motivated us to add Indic support and bidirectional features to InDesign CS6 MENA, even though it’s not localized into Arabic, Hebrew or any Indic language. Also, we have included support for Hanko in Acrobat, to reflect the way documents are signed in East Asia.
  • Internationalization becomes more expensive later on. Remember the car engine analogy we provided in our previous myth article? Thus, it’s critical that product development teams understand the various requirements of internationalization, and the technical, resource and time challenges for meeting them as early as possible, so as to prevent costly architecture changes and code re-writes later on.

The higher cost of delayed internationalization 

Various Total Quality Management studies have demonstrated the benefits of addressing issues at the beginning of a development cycle. The same principles apply to Internationalization. The earlier it gets considered in the product development cycle, the better the overall product quality and the cheaper the development costs will be.

As shown in the graphic below, the cost of addressing internationalization during the Design, Coding and Testing phases are respectively 2, 3 and 4 times more expensive than addressing internationalization during the Requirements phase.

These ratios get even worst after the localization cycle starts (factor of 15x if the product is localized into 15 languages) and the costs of addressing internationalization after a product ships can even become astronomical (30 x).

For example, failure to define and design product requirements in the Requirements and Design phases that meet global customers needs will increase the cost of internationalization in subsequent phases (Coding, Testing, etc.) because of additional time product development teams will spend with:

  • Reporting internationalization-related defects
  • Changing or re-writing areas impacted by internationalization, such as those handling:
    • Dates, times, calendars, numbers, currencies, addresses, measurement units
    • User interface strings, which may require the use of libraries providing string externalization, and changes to all string loading code (e.g. one of Adobe’s teams dedicated 1 developer to work 3 months exclusively on this task)
    • User interface elements such as dialogs and palettes, which may require the conversion from using static UI libraries to dynamic ones.
    • Text processing (input, display, output, sorting, searching), which requires the addition of Unicode support – a low level code which requires major re-testing – and may require the adoption of a new text engine, a major architectural change.
  • In cases where internationalization work is performed many product versions later:
    • Getting developers up-to-speed with impacted code which they might not have originally written, often sifting through legacy code that may not be in use anymore.
    • Re-testing impacted areas of the code that were released in previous versions of the product
    • Project management of focused, ‘one-time’ internationalization efforts
  • Responding to requests and questions from affected customers regarding the lack of support for their language (this has to be explained to every new customer)
  • Managing relationships with third-party solution providers who might have provided the missing internationalization support, and with whom the company might have entered a royalty-sharing agreement with

Also, there might be indirect costs that are associated with:

  • Loss of potential revenue from markets that require internationalization
  • Public exposure of the product’s lack of internationalization when third-party developers fill the gap by marketing their own solutions

Examples of international support in English / non-localized products

The best way to illustrate the importance of international support in English-only products is to show examples of products that have done it.

A calendaring application

In the first example below, an English-language calendaring application offers support for the Thai and Islamic calendars, allowing users from Thailand and 17 Arabic-speaking countries to use it.


A tag cloud application and a text editor

It’s very important that any application providing text input or display features support characters from writing systems other than Latin, the one English and most other European languages is based on.

In the next example, a web-based tag cloud application with an English-only user interface allows users to write characters from up to 6 different writing systems representing hundreds of languages, by selecting specific fonts.

The desktop-based text editor below supports close to 20 writing systems, meaning virtually anyone in the world can type with the English version of the product.

A travel website

The following, English-UI travel website offers a good example of how currency, date and time formats are correctly adapted for its German users.

The benefits of global design

In summary, product designers should rarely envision their software products as “U.S. only”. There are many benefits to thinking globally from the start:

  • You will be able to meet any new localization business requirements in much less time and with much less cost. When it comes to localization, in today’s globalized economy, it’s often not a matter of “if”, but a matter of “when”.
  • You will be able to sell your products to customers worldwide, as opposed to those living only in the U.S. or in English-speaking countries, even if your product is not localized (yet).
  • Global architecture design and coding is a one-time investment, and it’s a lot less costly than subsequent re-architecture and re-coding.

Our next globalization myth will be published next month. In the meantime, do you have any good examples of internationalized English-only applications you would like to share? Let us know!

See also

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

InDesign CS6…. Welcome to India!

This article talks about the overall objective of Localization in a new market or in business terms an “Emerging Market”. You might wonder, “why that specific word Emerging?” Because of the business opportunity it presents by taking a product to a new market where the demand exists, but somehow the product was not made available.

In the publishing domain, India is still one of the few countries where Print has seen a steady growth. Excerpts from one of the famous research site below:

“Contrary to most other markets in the world that continue to witness an erosion of the print media industry, in India, the sector witnessed a growth of ten percent in 2010 and is expected to continue to grow at a similar pace over the next five years. Rising literacy levels and low print media penetration offer significant headroom for growth, says a FICCI-KPMG report, recently released at FICCI FRAMES 2011 event…………”[Source All About Newspaper, publish date March`2011]

Does this present an opportunity for Adobe to expand in the Print Media space leveraging its one of the most popular Desktop publishing software InDesign®. Yes, but at what cost? Let’s weigh in the cost and benefits.

  1. Over the course of last few years, Adobe India sales force has been meeting Indian customers to understand how InDesign can be made ‘India ready’.
  2. In India, English is quite close to as being the second most spoken language just behind Hindi, giving a leeway to probably still hit the market with an English user interface (UI).
  3. The most talked about area in the frequent customer meetings was the support of Indic scripts in Print and Desktop Publishing Adobe applications. The current World-Ready composers for middle-eastern text included partial support for several Indic scripts. However, a number of bug fixes and product support requirements were needed for Adobe to officially certify and launch the product in India.

The specifics listed above did carve a path for InDesign to see support for Indic scripts in CS6 release. Based on input from the Product Management, the following 10 Indic scripts ranked highest on the priority list to support:

Each of the locales above have a good percentage of Print Media in the Indian market ranging from Newspaper, Magazines, Journals, etc. To support these locales was a tough road ahead since most of these locales use complex character combination, glyphs, hyphenation rules, dictionary support.

Phase 1 of this project included adding dictionary support in InDesign for these locales. We integrated the locale-specific open source dictionaries, evaluated them against competing products (with similar support) spanning a series of script specific test data hand-picked by linguists. The test criteria being:

  • Test maturity and quality of the dictionaries embedded
  • Misspell words intentionally and compare the corrected words
  • Ensure the words in InDesign when copied maintain their sanctity
  • Validating a few language rules, as applicable, such as hyphenation, matras, spellings, etc

Dictionary evaluation did show quite impressive results, allowing us to move to second phase of this endeavor of analyzing InDesign for Indic scripts.  After a significant number of complex workflows, a few engineering tweaks along the way, we were able to achieve what we set our eyes at initially.

  • Added dictionaries and spell checkers for the 10 scripts
  • Added Hyphenation for the 10 scripts
  • Bundled 1 Indic font family: Adobe Devanagari
  • Included a script that users can run to set relevant defaults and correctly handle imports from Word docs etc.

Even though we started off this effort as a seed project, codenamed as InDesign Indic 1.0, we were able to achieve more than we shot for. InDesign proved not just compatible for the majority of the locales listed above but offered notable support for even the most complex glyphs.

Switch to the World-Ready Composer, an alternate composition engine, with a single click of indicPreferences.js in Window > Utilities > Scripts panel to explore the Indic world in InDesign. By virtue of basic Indic script support in InDesign CS6, you can now type in these languages and characters would shape and render correctly. And yes, there will be more refinements to the Indic Script support in future releases to come.

Let us know what you think and how you plan to use these features.  Please visit here for the complete list of Language support in InDesign CS6.

Contributed by Harpreet Singh (Adobe India)

Announcing PSE11 and PRE11 Programs for French and German Users

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

Adobe Prerelease Programs are your chance to experience, evaluate and influence upcoming products & technologies from Adobe within a smaller, more focused user environment. Prerelease Programs facilitate a symbiotic development process allowing Adobe to share products in the development stage to gather early feedback. In the process you get a chance to shape the upcoming products and adapt to the new products faster.

Multiple engagement channels are available to Prerelease participants at Adobe:

  • Access to download Prerelease software/technologies and technical documentation
  • Ability to report bugs & request features for the Prerelease software
  • Access to the Prerelease user forums for sharing ideas directly with Adobe product teams and other likeminded folks of the product’s community
  • Opportunity to participate in various product-related surveys

A Prerelease program is an endeavour to engage the real users of the product – YOU – early in the development cycle of the product, to listen and learn from you on how the product is working for you.

Current Prerelease Opportunities: How to Apply?

You may fill in the application forms for expressing your interest to join a products’ Prerelease program at Adobe. The participation will be entirely based on the requirements of the program and the credentials of the participant.

Following products have been opened up prerelease testing opportunities with French and German builds:

Photoshop Elements 11 for French Users– Sign-up now to participate in the Adobe Photoshop Elements Localized program and preview exciting new functionality! – Apply now

Photoshop Elements 11 for German Users – Sign up to participate in the Adobe Photoshop Elements Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for French Users – Sign up to participate in the Adobe Premiere Elements 11 Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for German Users – Sign up to participate in the Adobe Premiere Elements 11 Localized Program and preview exciting new functionality! – Apply now

We look forward to your participation in this pre-release program. In case of any issues of if you need more information, please feel free to contact Manish Kanwal at or Nimra Khan at


Adobe lança primeiro fórum em português

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

Muito obrigado a todos que participaram da enquete que publicamos semana passada, sobre a idéia de criar um fórum em português no Adobe Forums. Os resultados da enquete estão disponíveis aqui.

Em resposta à preferência da maioria das 25 pessoas que responderam, estabelecemos o primeiro fórum em português em um produto (Illustrator):

Se você é um usuário do Illustrator, visite-nos!

Dependendo da popularidade desse fórum, talvez consideremos a criação de novos fórums para outros produtos.

Leandro Reis
Senior Program Manager, Globalization
Adobe Systems

Adobe Moses Tools now available for Windows

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

We have an update on the [tp no_translate=”y”]Adobe Moses Tools[/tp] which we announced on this blog on May 11.  The tools are now available in pre-built packages for [tp no_translate=”y”]Windows[/tp]!  Check out the download section of the M4Loc site to get the [tp no_translate=”y”]Windows[/tp] packages and for documentation and other information about the tools.

Please download the tools and let us know what you think!

–Raymond Flournoy
[tp no_translate=”y”]Senior Program Manager[/tp]
[tp no_translate=”y”]Translation Technology Team[/tp]

Adobe Flash – Content Creation & Localization Guidelines

Global publishing with Adobe Digital Publishing Suite

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

Digital publishing is a global business

Digital publishing is catching on worldwide, as international catalog, magazine and book publishers are increasingly producing digital versions of their publications, in an growing number of languages.

[tp no_translate=”y”]Adobe Digital Publishing Suite[/tp] (DPS) offers digital publishers with the ability to create multilingual content for the enjoyment of their international readers. This article provides some basic information about the creation of multilingual publications with DPS.

Content localization: region-specific vs language-specific

Region-specific publications carry the main brand (of the magazine, retailer, etc), but are customized to an individual region or country. In the case of magazines, articles are written by local authors, often covering topics and people of local significance.

Language-specific publications translated versions of a single source of content. The articles and authors are the same, the only thing that changes is the language of the content.

Presenting the translated content

With language-specific publications, there are a few different ways to present the translated content, which can impact layout decisions.

The most common type of presentation is single-language, where each language version of the publication is downloadable as a separate application.

Multilingual applications can contain two or more sets of translations of the original content. The translations can be presented through toggling or side-by-side.
With the toggling approach, readers can navigate between content written in different languages by pressing a ‘language switch’.

The article toggling effect provides a smooth user experience, but it does require additional work (i.e. scripting) behind the scenes to make it happen.

The side-by-side approach puts the translations next to each other, typically with different font types, sizes and colors.

Authoring content in different languages

At the core of the DPS workflow is Adobe InDesign, which allows text authoring in many languages. The latest version of the product (CS6) is available in 3 flavors providing distinct levels of language support:

  • InDesign CS 6.0 – Provides core typographical support for a wide range of languages, including those written in certain non-western scripts. It’s localized into English and 16 other European languages.
  • InDesign CS 6.0 ‘CCJK’  – In addition to the core set of typographical features, provides typographical, layout grid and frame grid features for editing East Asian text. It’s localized into Chinese Simplified, Chinese Traditional, Japanese and Korean.
  • InDesign CS 6.0 ‘ME’ – In addition to the core set of typographical features, this version provides full support for bi-directional languages such as Arabic, Hebrew, Farsi, and Urdu. Find out more about the Middle Eastern features here. The ME version is available in English and French user interfaces.

The linguistic capabilities of InDesign are well documented in the product’s help pages, and in articles written by various InDesign experts. Below are some language-specific topics that can assist in the creation of multilingual content in InDesign:

Creating localizable content 

In multilingual digital publishing, a critical aspect of content authoring  – regardless of the language it’s originally written in – is to ensure that it’s localizable, i.e, that it can be easily adapted into (an)other language(s). Below are a few guidelines for creating localizable content in InDesign:

  • Allow for text expansion – Word length varies considerably from one language to another. For example, German and Finnish sentences are on average longer than English. Also, Asian fonts require more vertical space than Latin fonts in order to render certain complex symbols clearly. Thus, it’s important to keep some buffer space around text so that translations can fit it nicely.
  • Apply styles – It’s critical that all text formatting is based on styles, as it ensures consistent formatting across all languages, and it allows for easily changing fonts for languages whose characters are not supported by the font of the source document.
  • Link images – Linked images are much easier to manage during translation
  • Connect text frames – This will ensure text will continue to flow nicely after it’s translated.

More guidelines on content localizability with InDesign will be provided in a future post.

Localizing the content

Localization of InDesign files is typically performed by professional translation agencies, who handle exported IDML (InDesign Markup Language) files in commercial translation management systems (TMS). Ben Cornelius’ article provides a good overview of this process.

Also, some vendors are starting to offer new and innovative ways to localize InDesign content, such as 1i0’s one2edit WYSIWYG tool.

But regardless of the way the content is localized, it’s very important that the work comprehensive: everything, including not only the article text, but also titles, captions, headers, footers, footnotes, and art, should be translated or adapted.

For maximum coverage, even media features, such as audio or video clips, should be subtitled and translated, or dubbed.

Below are some examples of locale-sensitive conventions – dates and times – that need to be adapted for each region.

Publishing the content: DPS multilingual options

The bulk of the process for publishing localized or multilingual content with DPS is not any different than English or single-language content, which is described here.

But, there are a few multilingual options available.

For publications written in bi-directional languages such as Arabic, Farsi, Urdu and Hebrew, readers expect to be able to swipe pages by moving their finger from left to right (ie in the opposite direction than in an English publication), thus right edge binding is necessary. 

To do activate this feature, in the [tp no_translate=”y”]Digital Publishing Suite[/tp], select Right Edge Binding in the [tp no_translate=”y”]Folio Producer[/tp] page.

You can also set this in In InDesign, by selecting the Right Edge Binding  checkbox in the [tp no_translate=”y”]Folio Properties[/tp] dialog.

3eesho is a fine example of a bi-directional publication created with DPS.

Language tagging

Tagging your publication with language information will allow it to be searched by language from e-stores. This can be done during the building of your viewer application, in the [tp no_translate=”y”]Viewer Builder[/tp]:

Localized versions and availability

The [tp no_translate=”y”]Digital Publishing Suite[/tp] user interface is currently localized into English (UK, US), French, German, Italian, Spanish, and Japanese.

DPS Single Edition is available in the U.S., Canada, and Mexico. Availability is expected this year in Australia, Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Latvia, Lithuania, Luxembourg, Malta, New Zealand, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, South Africa Netherlands, Spain, Sweden, Switzerland, and the United Kingdom.

Examples of multilingual publications created with [tp no_translate=”y”]Adobe Digital Publishing Suite[/tp]

Check out many examples of multilingual digital publications created with [tp no_translate=”y”]Adobe Digital Publishing Suite[/tp] by visiting the Digital Publishing gallery.

AMT – Adobe Moses Tools Now Available

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

I’d like to announce that [tp no_translate=”y”]AMT (Adobe Moses Tools)[/tp] are at last open sourced and available for download.

All code and documentation has been submitted to [tp no_translate=”y”]M4LOC Moses[/tp] for Localization.

Prepackaged DMGs for OSX users can be found here:

Source code for those interested in building on the tools and improving them can be accessed here:

I would be psyched to hear from folks who download and use the tools and are looking to improve them.  It’s been a long road from jumping into the deep end with [tp no_translate=”y”]Moses[/tp] until where we are today.  There’s still plenty to get done.  Let’s work on building that together.