Posts in Category "Myths"

Globalization Myth Series – Myth 4: It Takes 6 WEEKS to Localize a Product!

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

Adobe’s Globalization team is committed to driving continuous improvement in customer experience and improving efficiency.  These are two of Adobe’s areas of focus for 2013.

The top customer feedback we used to receive was that localization of our products needed to be more agile.  The digital video team, for instance, moved to releasing English and localized products in one installer; they needed to sim-GM in order to release quickly and meet the market expectations.  The creative products customers in Brazil and Russia, for instance, were getting tired of waiting six months to get their hands on a localized product.  Like many in the industry, Adobe’s Globalization team began to face pressure to localize with fewer resources, reduce localization turnaround time, and improve quality.

Our challenge is to meet the aggressive release schedules of Adobe’s Clouds—Digital Media and Digital Marketing, their companion products and tools in 20+ languages. Currently, our team uses, roughly, 65% of our resources on Digital Media localizations, and 15% on Digital Marketing localizations (20% is dedicated to Print, tools development, finance, and other initiatives).  The localization team is made up of approximately 150 people—international program managers, international engineers, international quality engineers, and interns located in the US, China, India, Japan, and Romania, supporting approximately 150 product and functional teams.

In this paper we will show how Adobe has been able to accelerate localization and we will, hopefully, debunk the belief that localization takes 6 weeks.  With limited budget, we are meeting expectations, sim-shipping English and 20+ languages for the Adobe Cloud-based products—Digital Media and Digital Marketing– Developer/Web tools, and Touch Apps.  We support any agile workflow and release schedules can be as short as every 2-4 weeks (Photoshop.com, Acrobat.com, Cloud Manager, adoberevel.com), 6 weeks (DPS, AdobeRevel), to continuous releases (CCM) varying from twice a week to monthly.  In these workflows, we can complete a localization cycle as quickly as within 24 hours.  Our ultimate goal?  We are preparing for the day when Adobe products get released multiple times a day!

Sample SCRUM Schedule – Localized product sim-releases in 20 languages every 6 weeks

Slow is History! – Product Team Concerns in the Past and Globalization Team Response

Adobe product development models come in many flavors.  In general, the ‘waterfall’ model was considered standard.   Products such as Photoshop, Acrobat, InDesign, and Illustrator were well-suited for standard localization.  That is, at UI Freeze milestone, the localization team would step in and begin the localization process.  This meant that, by English GM, the localized versions were lagging behind by 4-6 weeks.

This localization model—start localization after UI Freeze milestone—had several drawbacks.  Localization partners got overwhelmed at end game; localization issues were found too late and, when issues were classified as “show-stoppers,” they could jeopardize the product release schedule; many critical defects ended up getting deferred for the next product release.  The model was costly, time consuming, it increased stress and burnout.

With the event of multi-lingual installers, SaaS, Cloud-based products, and new development workflows used by Adobe product teams such as Scrum, Kanban, Scrumban, or Adobe’s own Aphid,  the Globalization team was faced with new requirements which called for a more accelerated localization workflow.  The new business model required that localization should be possible in any locale, be scalable to a large set of languages, and respect various budget constraints.  Product teams started to question whether the localization team was ready to keep up with the pace of the business. The answer was a big “YES, OF COURSE!”

For the sake of comparing two different models, see below a waterfall-model localization schedule and an agile localization schedule from the same period—2004.  The product following the waterfall model on the left, chose to ship single-language versions in a staggered schedule; the one on the right, based on Adobe’s Aphid model, released their product with a multi-lingual installer as a single binary.  At this point in time, Globalization was ready to accommodate both Product Teams.

Waterfall – InDesign                                                                             Agile – Audition

 

With the acquisition of Macromedia in 2005, Adobe Localization faced many new and exciting challenges. Dreamweaver, for instance, ran prerelease programs for all languages, which meant that localization had to be right behind English, at the same level of development, testing, and stability as English. Thanks to the many talents that we acquired and the level of cooperation between companies, we were able to leverage best practices and meet the expectations of the new Product Teams.

In 2007, Adobe acquired Scene7, a software company enabling websites to have real-time rich media; then Omniture, in 2009.  In 2010, Adobe acquired Day Software, a market leader in next-generation Web Content Management.  In 2011, web tool companies such as TypeKit and Nitobi, the maker of PhoneGap; Efficient Frontier, a digital marketing company; and Iridas, the maker of SpeedGrade, a professional color correction application; in 2012, Adobe acquired Behance, the leading online platform to showcase and discover creative work.

All these new cloud-based services demanded improved localization velocity, mostly through internationalization and automation.  Development cycles were short – 2-6 weeks – and updates were frequent and web based. Our team needed to shift focus in order to meet these cloud-based product requirements.

The Globalization team, in partnership with the Product Teams, worked towards an agile localization model.  Here were the first steps we took towards acceleration:

  • Ensured Adobe products were World Ready — created an assessment tool called the Globalization Report Card (GRC) to determine world readiness compliance.
  • Engaged international QE early in the development cycle to test and report internationalization bugs.  With that, international bugs were addressed in a timely manner which helped speed up the development cycle and improve products’ quality.  See “Globalization Myth Series – Myth 2: This software product is only for the U.S.” for evidence on the benefits of addressing internationalization issues at the beginning of the development cycle.
  • Worked cooperatively with the new Development Teams to set common goals and share best practices. This cooperation has resulted in better success rates than if localization were considered as an after-thought and as a different team.
  • Changed the mindset – if we got content EARLY and ITERATIVELY, we would localize software and documentation continuously.  Waterfall-based products started working with the globalization team prior to UI Freeze milestone.  We started localizing glossary kits early and testing localized builds sooner than in the past.  Documentation team started handing off non-final files prior to the usual “screen-shot ready build” milestone.  Localized documentation is now uploaded to the web at the same time as the English product and localization versions ship.
  • Developed more tools – invested in ALF (the Adobe Localization Framework is a multi-tiered system whose primary intent is to automate the localization process and facilitate the creation of localized products), machine translation (takes strings in one human language and automatically translates them into other human languages), World Server (an enterprise translation and globalization management system that enables Adobe to simplify and accelerate our translation and localization processes for any content, from our websites to instructional content to software applications and beyond), tools that helped achieve localization of fast releases nearly in sync with English.
  • Engaged our external localization partners earlier and began growing expertise in those teams. Some of our vendors now are capable of offering turnkey localization services for Adobe products. They have learned our products through prerelease, product demos, and training by our Globalization team.
  • Found new ways to engage with our customers through the Adobe Translation Center, international prerelease, and forums. These customers know our products best, so they can provide early feedback and we can save time in the long run.

With these measures in place, we were able to get closer to the English product schedule and were behind by just a couple of weeks.

Currently, the Globalization team has reorganized internally to manage the localization process for the end-to-end customer experience which includes software, marketing/web content, documentation, internationalization/localization testing, and educational materials.  We are better aligned and more agile, able to support localization for product cycles of 2-4 weeks (Photoshop.com, Acrobat.com, Cloud Manager, adoberevel.com), 6 weeks (DPS, Adobe Revel), to continuous releases (CCM) varying from twice a week to monthly. In order to achieve such challenging schedules, we are turning localizations around in 24 hours at times.

For instance, Adobe Creative Cloud is released with 16 localized components and its schedule today looks like this:

Standard, large projects schedules like Flash CS6, look like this:

Looking Forward — Introducing A.L.A., the Adobe Airport

One of Globalization’s biggest challenges is to meet the aggressive release schedule of Adobe’s Clouds, its companion products, web tools, and touch apps in 20+ languages.

In the same way that planes have to leave on scheduled time, crew and passengers in place, in a continuous flow, so do our localized products, where the crew is formed by International Program Managers, International Quality Engineers, International Engineers and ‘passengers’ are the assets (strings) for translation, from any number of products. The plane may only be going to France (say) or it may be doing stops in numerous countries. The frequency of flights will also vary, depending on demand.

Airport Background

We started out with pilot projects, mostly projects which needed quick localizations at end game.  Our requirements were:

  • Source strings were final and reviewed (proofread)

Our Product Teams’ expectations were:

  • Human translations compliant with Adobe terminology
  • Fast translation
  • No functional/linguistic testing

Note that even though our tool collects strings from multiple products and sends them to the translators, we can guarantee terminology consistency and quality because the strings are first leveraged through World Server; and our translators make use of our glossaries for reference.

The Adobe Localization Airport (A.L.A.)  aims to provide one-hour localization turnaround. Our tool collects strings from multiple products and sends them to the translators. Once translated, the strings are distributed back to their respective products, presto!

 

Turn-Around-Time (TAT)from Q2 2012 to Q1 2013, TAT has decreased from an average of 12.7 hours to 7.8 hours.  Our goal, by end of Q2 2013, is to reach 1 hour TAT or less, should the project require that much acceleration.            

Airport Turn-around-time per language, per quarter

Conclusion

Localization does not take 6 weeks—it takes an average of 7.8 hours.  Our goal, by the end of Q2 2013, is to reach 1 hour TAT or less! This is a myth that we have debunked.  The Globalization tools and initiatives aim to make localization at Adobe even more agile, without compromising our products’ quality as well as customer satisfaction.

____

Credits:

The A.L.A. team—Ajay Kumar, Guta Ribeiro, Joel Sahleen, John Nguyen, and Warren Peet
Jean-Francois Vanreusel
Leandro Reis
Quynn Megan Le

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, Ethnologue.com 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 Adobe.com. 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)

Take-Aways

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.

References:

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

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.