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!