Tag Archives: globalization

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.

 

Coming up: Globalization myth series

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

Starting this month, we’ll publish a series of articles on  globalization myths.

If you’ve worked in the Globalization industry long enough, you’ve probably heard many of the myths we are going to describe.

If you’re new or from outside the industry, then we hope this series will help set the record straight.

The first article will be published soon. Stay tuned.

CS5.5 trials now available in additional languages

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

You may now download Win/Mac trials of CS5.5 in your language:

Enjoy!

 

A lightweight auto-complete ActionScript example with a trie

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


Auto-complete functionality is used widely over the internet and mobile apps. A lot of websites and apps try to complete your input as soon as you start typing.  In this post, I would like to introduce a simple ActionScript auto-complete solution by using trie data structure.

A trie is an ordered tree data structure that is used to store an associative array. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Starting from the root node, you can check if a word exists in the trie easily by following pointers corresponding to the letters in the target word. Trie is a well-known data structure in computer science; you can find the detailed information about trie through Wikipedia.

Here is a simple trie implementation in ActionScript:

/**
* An simple data structure to store and look up words.
* @see http://en.wikipedia.org/wiki/Trie for additional details.
*/

public class Trie {
private var _rootKeys:Array;
public function Trie():void {
_rootKeys=[];
}

/**
* Return a list of words which have the given prefix.
*/

public function get(prefix:String):Array {
var results:Array=[];
var letter:String=prefix.substr(0,1);
var root:TrieNode=_rootKeys[letter];
if (root) {
getWordList(prefix, 1, root, results);
}
return results;
}

/**
* Add a word to the object which can be matched as a prefix.
*/

public function add(word:String):void {
var letter:String=word.substr(0,1);
var root:TrieNode=_rootKeys[letter];


if (!root) {
root=createNode(letter);
_rootKeys[letter]=root;
}
insertWord(word, 1, root);
}


private function traverse(root:TrieNode, results:Array, prefix:String):void {
if(root.children) {
for each( var c:TrieNode in root.children ) {
var node:TrieNode = c as TrieNode;
if( node.word ) {
results.push( prefix + node.value);
}
traverse(node, results, prefix+node.value );
}
}
}


private function getWordList(prefix:String,
position:uint,
root:TrieNode,
results:Array):void {
var letter:String=prefix.substr(position,1);
var child:TrieNode=root.children[letter];
if (!letter || !child) {
return;
}


if ( position<(prefix.length-1) ) {
getWordList(prefix, ++position, child, results);
}else {
if (!child.word) {
traverse( child, results, prefix);
}
}

}


private function insertWord(word:String,
position:uint,
root:TrieNode):void {
var letter:String=word.substr(position,1);
if (position==word.length || !letter) {
return;
}


var child:TrieNode=root.children[letter];
if (! child) {
child=createNode(letter);
root.children[letter]=child;
}


if (position==word.length-1) {
child.word=true;
} else {
insertWord(word, ++position, child);
}
}


private function createNode(letter:String):TrieNode {
return new TrieNode(letter,false);
}
}

Format date and time in non-Gregorian calendars

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

Although the Gregorian calendar is the most used civil calendar, there are other calendars used in different countries and regions.

Islamic calendar is used in many Islamic countries and it has quite a few variances. Japan uses the imperial calendar which identify the year with an era name(年号, nengō) and a number. Thailand uses a calendar that counts in the Buddhist era.

With flash.globalization package, you can easier format a date in non-Gregorian calendars. See the code below.

How to create a localized DateChooser in your Flex app

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

 

Xie Fang

By default the DateChooser in Flex shows the English UI. You need to set the dayNames and monthNames properties to localized strings so that it shows the language you want. But do you know that all these localized names are available in the flash.globalization package? Here’s how to get the localized names.

First, create a DateTimeFormatter object with the locale you are interested in the <fx:Script> section

Alternatively, if you feel more comfortable with MXML than ActionScript, you can use a MXML DateTimeFormatter in the <fx:Declarations> section.

Second, create a vectorToArray function for type conversion in the <fx:Script> section, we will explain a little more in the next step.

Third, in your <mx:DateChooser> component, set the dayNames and monthNames properties.


And since you are using the DateTimeNameStyle enums, you want to import them in <fx:Script>

Here, the getWeekdayNames and getMonthNames methods give the localized names as a vector of string. And vectorToArray function is used to convert them to array before assigning them to the DateChooser. The getFirstWeekday method gives the first day of the week for the locale. For example, many european locales use Monday as the first day instead of Sunday.

That’s it. Now run your app and you will see the DateChooser UI is showing in Chinese.

Change the locale to British English (en-GB) and Arabic, Saudi Arabia (ar-SA) to see how the locale changes the first day of week.

Think that this doesn’t save time than hardcoding? Such as:

It is true if you just need to localized to your language. But imagine you need to localize in multiple languages, or languages you don’t know, or you want language switchable by users at run time. Using flash.globalization is more scalable.

To learn more features provided by flash.globalization package, check out the ActionScript API documentation.

The Adobe Globalization Blog

This article was originally written in English.

 

Today we are launching Adobe’s first ever globalization blog. Adobe believes that everyone in the world should be able to express and exchange ideas in the language they prefer, and thus we have a strong interest in ensuring that our global customers are able to create applications, content and systems that satisfy the requirements of every geographical market.

Through this blog, we intend to provide our users with information that will enable them to achieve that. In addition, we will inform readers about new globalization-relevant product features, tools and libraries.

Also, we hope to hear from you! Have you found a globalization or localization bug? Do you have a globalization-related request for one of our products? Wrote some globalization guidelines that you want to share with the world? Here’s the place to share your feedback.

Enjoy
The Adobe Globalization Team