Category Archives: Technology

Adobe Machine Translation Tooling For Moses Presented At MT Summit 13

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

Members of the Adobe MT team were on hand at MT Summit 13 in Xiamen China to present Adobe’s MT achievements and demonstrate next generation tooling for the Moses open source MT platform.  Adobe team members Ray Flournoy, Yu Gong, Christine Duran, and Jeff Rueppel made the journey to attend the 4 day biannual conference.  The conference moves from Europe to North America and this year was hosted in China for the first time.  (Adobe Summer 2011 Intern Yifan Hi took a break from his post doctoral duties and presented his research as well.)

Yu Gong and Jeff Rueppel gave a demonstration of 3 new Adobe tools for streamlining the development of Machine Translation engines using the Moses open source system.

(Adobe’s Scoring Harness Tool)

Adobe employees demonstrated Adobe’s Scoring Harness Tool. (seen above) The scoring harness is one several building blocks Adobe is putting in place to facilitate the automation of MT engine development and deployment.  The scoring Harness automates the quality testing of MT engines using industry recognized standards for engine quality, (Bleu, Nist, Meteor, and TER) and will permit the dynamic testing of new engines against engines already used for production.

Formatting with alternate calendars in Flex

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

Dates can be formatted in various calendars in the Flex SDK. Let’s explore how it works.

Flex SDK lets you format a given date in “alternate calendars” besides the Gregorian calendar. The industry convention refers all non-Gregorian calendars as alternate calendars. To use an alternate calendar, it requires a little bit of care in your Flex application.

Types of calendars

Before we dive into the alternate calendar usages in the Flex SDK, let’s take a brief look at a couple of calen­dars of the world so that you get familiar with what this calendar talk is about. Please be aware, I can only describe the basic usages of some common alternate calendars. There are complexities behind each of the calendars and I may not be explicitly state them. Investigate fur­ther before you actually use them.

Gregorian calendar

This is the calendar most systems provide as the standard. You probably know this calendar already but here are some of the characteristics: There are always twelve months in a year and each month has 28 to 31 days. The numbers of days in each of the months are fixed (30 or 31 days) except for the second month (February), which includes 28 (non-leap years) or 29 days (leap years). The number of days in a year is fixed (365 or 366 days).

Islamic calendar (Hijri calendar)

Islamic calendar is one of the lunar calendars.  There are always twelve months in a year. Each month has ei­ther 29 or 30 days. Beginning of a month is determined by observing the moon phase (Islamic religious calendar). Because of this nature, it is not very possible to predict the dates with the Islamic religious calendar. For the sake of convenience, there is the variant of the calendar, Islamic civil calendar, which determines the dates through some pure mathematical calculation. Islamic civil calendar may not be accurate for religious events. Number of days in a year is 354 or 355 days. Hence, the Islamic calendar year and the Gregorian calendar year are not synchronized.

Japanese calendar

Japanese calendar is very similar with the Gregorian calendar. The difference is the era part and the year. The Gregorian calendar has been using the same era name for the past 2,000 years (AD; Anno Domini). There is also BC (Before Christ) era but BC years are not by supported by pretty much all calendar apps. On the other hand, Japanese calendar era name changes when there is new emperor. Therefore, every ten to a couple of ten years, there are new eras. *1

*1 Before the 1868, the era name changes were more frequent, an era lasted only as low as two years. But just like the BC in Gregorian, there is not much demand to be able to deal with the older eras in today’s calendar applica­tions.

There are much more types of calendars in the world but I hope you got some ideas how calendars can vary.

How to use the alternate calendars in Flex SDK

Now let’s look at the usage of alternate calendars. How do you use calendar other than the Gregorian in the Flex SDK? The an­swer is to use the locale ID.

The locale ID can optionally contain calendar tag. For example:

Locale ID Meaning
ar-SA Arabic used in Saudi Arabia
ar-SA@calendar=islamic Arabic used in Saudi Arabia. Islamic calendar
en-US@calendar=islamic English used in the U.S. Islamic calendar.

When you need to format a date in an alternate calendar, the calendar tag can be appended to the locale ID. Here is an example:

import spark.formatters.DateTimeFormatter;
private function calendarDemo():void
{
    var d:Date = new Date(2011, 9, 15);
    var dtf:DateTimeFormatter = new DateTimeFormatter();
    dtf.dateStyle = "long";
    dtf.timeStyle = "none";
 
    dtf.setStyle("locale", "en-US");
    trace("(1) " + dtf.format(d));
 
    dtf.setStyle("locale", "ar-SA");
    trace("(2) " + dtf.format(d));
 
    dtf.setStyle("locale", "ja-JP");
    trace("(3) " + dtf.format(d));
 
    dtf.setStyle("locale", "en-US@calendar=islamic");
    trace("(4) " + dtf.format(d));
 
    dtf.setStyle("locale", "ar-SA@calendar=islamic");
    trace("(5) " + dtf.format(d));
 
    dtf.setStyle("locale", "en-US@calendar=japanese");
    trace("(6) " + dtf.format(d));
 
    dtf.setStyle("locale", "ja-JP@calendar=japanese");
    trace("(7) " + dtf.format(d));
}

Here is the result you might get.

Please note that the result may vary depending on the run-time platforms.

Limitations you should be aware of

There are couples of limitations in the current Flash Player and Flex SDK for alternate calendar support.

  1. The Date class can handle only Gregorian dates.
  2. The Spark DateTimeFormatter class can format a Date object but parsing feature (translating a formatted Gregorian or non-Gregorian date string into a Date object) is not available. English Gregorian date string can be parsed through the Date class constructor in some degree.
  3. The availability of alternate calendar support and its behavior is platform dependent. Please check the plat­form if the alternate calendar support is important for your application.

If you would like to know more about alternate calendars, the calendar entries on Wikipedia is a good source.

Invoking ICU from Adobe AIR Applications

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

Adobe Flash and AIR are ubiquitous platforms to develop rich internet applications. Flash is used for browser based applications and AIR is used for developing native platform applications. Both platforms have considerable support for globalization. Globalization enablement features like locale aware formatting/parsing, collation, case transforms, localization and multi-lingual text rendering are supported by both these platforms. But some more globalization features like text normalization, transliteration, Unicode character properties, encoding conversions, charset detections, Unicode string utilities etc are still missing in the Adobe AIR and Flash platforms. One of the primary reasons for not adding all these features inside the Adobe runtime platforms is the size of the software.

To overcome the size limitation issue, Adobe AIR and Flash can invoke the services of external dynamic libraries through ActionScript. There are some well known external libraries which have rich globalization support like ICU, GNU glib, Verisign IDN library to name a few. Fortunately the upcoming Adobe AIR 3.0 (now available as Adobe pre-release) has a wonderful feature called ActionScript native extensions, which is about ActionScript programming interface for a native code library like MS Windows DLL, Os X FrameWork, Android JAR or shared library or iOS static library. Please see Adobe AIR3 beta site http://labs.adobe.com/technologies/flashplatformruntimes/air3/ on how to download and take part in the Adobe AIR pre-release. Please make a note that this native extensions feature is available _only_ in Adobe AIR platform, not in the Flash platform.

In this blog, I demonstrate a sample (Download air_icu ) application to invoke ICU from an Adobe AIR application on Windows platform. Readers are reminded that this is only illustration sample software and by no means production quality software. Hence readers must exhibit discretion in using this software as it is. The sample illustrates ICU word breaking, sentence breaking, utf-conversion and Unicode character property verification.

You will need the following software to build an ICU extension for AIR platform.

1         Building ICU extension for Adobe AIR

Adobe AIR t native extensions, also known as ‘ane’ or ‘ANE’ files are archived packages. These consist of

  • ActionScript wrapper classes calling into external DLLs
  • The external DLLs
  • XML file describing details of external DLLs

The archived ANE files are used just like SWC libraries in integrating into an AIR application. In other words, ANE file is a library and it has public ActionScript APIs.

Covering all details about the ActionScript extension is too much for this blog article, but I will explain the steps to build this sample and run. Below are the sequential steps and commands.

1.1       Building Windows AIR ICU Extension DLL

1)      The AirIcuExtensionWin folder has the Visual studio solution ‘AirIcuExtension.sln’. Open this in MS VS2010.

2)      The file AIRIcuExtension.cpp has the necessary code needed to interface with Adobe AIR 3 beta 2. It also has the wrapper routines calling ICU C functions.

3)      This is a DLL project and the build output is AirIcuExtension.dll

1.2       Building ActionScript Library

1)      Build the actionscript library using the below command.

C:Flex4.5.1bincompc.exe -source-path src -include-classes com.adobe.extensions.AirIcuExtension  -external-library-path C:air3_beta2frameworkslibsairairglobal.swc -output binAirIcuExtension.swc

The file AirIcuExtension.as in the folder srccomadobeextensions has the public class AirIcuExtension which calls the ICU routines. In this sample, calling ICU sentence breaker, word breaker, normalizer, utf-conversion and Unicode character property have been illustrated.

1.3       Packaging ActionScript native extension

Open the binAirIcuExtension.swc is a zipped archive. Open it using WinRAR or WinZip program and extract the library.swf file in the swc package into the AirIcuExtension/bin folder.

The folder srcresources contains file extension.xml, AirIcuExtension.dll and ICU dlls icudt48.dll, icuuc48.dll, icuio48.dll and icuin48.dll. The file external.xml defines the external library details to AIR runtime.

For simplicity, place the AirIcuExtension.dll, ICU dlls and extension.xml files in AirIcuExtensionbin folder. All these files are packaged into a zipped archive called AiricuExtension.ane using the following command.

C:air3_beta2binadt -package -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target ane AirIcuExtension.ane extension.xml -swc AirIcuExtension.swc -platform Windows-x86 library.swf AirIcuExtension.dll icudt48.dll icuin48.dll icuio48.dll icuuc48.dll

Using Adobe FlashBuilder4.x or  C:air3_beta2binadt program, one can make an AIR certificate.

The output is an archive file AirIcuExtension.ane in the AirIcuExtension/bin folder.

1.4       Building the Test program AirIcuExtensionTest.mxml

Now that we built and packaged the native extension package AiricuExtension.ane, we are readu to use this and call ICU services in a test program.

The folder AirIcuExtensionTestsrc contains the test file AirIcuExtensionTest.mxml. The descriptor file AirIcuExtensionTest-app.xml has  the details of native extension. Using the mxml compiler, AirIcuExtensionTest.swf is built as follows in AirIcuExtensionTest folder.

C:Flex4.5.1bincompc.exemxmlc +configname=air -external-library-path ..AirIcuExtensionbinAirIcuExtension.ane -output bin-debugAirIcuExtensionTest.swf — srcAirIcuExtensionTest.mxml

The output swf file AirIcuExtensionTest.swf is placed in the bin-debug folder.

1.5       Building AIR package for executing AirIcuExtensionTest

The final step is to package the above AirIcuExtensionTest .swf and AirIcuExtension.ane files into an AIR executable folder.  Execute the following command

C:air3_beta2binadt -package -XnoAneValidate -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target bundle AirIcuExtensionTest.air AirIcuExtensionTest-app.xml AirIcuExtensionTest.swf -extdir ….AirIcuExtensionbin

The output of the above command is a folder AirIcuExtensionTest.air. Inside the folder, there is AirIcuExtensionTest.exe. You can execute and see the output.

2         Conclusion

The sample illustrated how to invoke ICU from ActionScript. The AIR ICU extension is easy to build using the publicly available Adobe Flex SDK and AIR3 Beta 2 SDKs. It will be much easier to do all this in the future Adobe Flash Builder IDE using GUI. The advantages of this feature are

  • AIR developers looking to develop international applications for desktop or mobile have the full power of ICU at hand. Many Unicode features, encoding conversions, IDN conversion utilities, string processing, transforms and many more international features can be easily coded.
  • The native ICU extension once built can be used any any developer as it is a library.
  • The Actionscript APIs calling ICU can be coded using the same signatures as ICU C++ API. This eliminates the learning curve.
  • Since ICU is in native code, performance is not compromised.
  • Since it is ICU, developers can expect cross-platform behavior in AIR programs.
  • Since the extension is a AIR library, ICU updates can be easily re-packaged in to the ane file.

In the future once AIR3 is released, a full fledged ICU native extension with proper API definitions will be a great globalization project.

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.

Difference between Flex SDK’s Matching Collator and Sorting Collator

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

Flex SDK has two kinds of collators. Do you know the differences?

First of all, let me explain what a Collator is. The Flex SDK Collators are classes that are designed to compare two strings. Their compare functions return a numeric value to tell which of the two items is smaller or larger.

Here is an example:

<fx:Declarations>
    <s:SortingCollator id="c1"/>
    </fx:Declarations>
    <s:VGroup>
        <s:TextInput id="uiInput1" text="ABC"/>
        <s:TextInput id="uiInput2" text="ABC"/>
        <mx:Text id="uiOutput" text="{c1.compare(uiInput1.text, uiInput2.text)}"/>
    </s:VGroup>

This example shows 0 as the compare result by default. As you alter the inputs, the result becomes -1 if the first input is smaller or 1 if larger. See the screenshots below.

 width=

 width=

 width=

The difference in sorting

Now, let’s talk about the differences of Matching and Sorting Collators. Actually, they are essentially same but they have given some specific initial collation parameters good for general string matching (MatchingCollator) or parameters good for general string sorting (SortingCollator). Example below illustrates why two different collators are useful.

Assume you have following items in your Array. You want to sort the items and find a specific string from the items.

  • naïve
  • Naïve
  • NAÏVE
  • naive
  • Naive
  • NAIVE
  • adolescent
  • youthful

If you sort items using a SortingCollator class with “en_US” (English spoken in U.S.) locale, you get following sort result.

  • adolescent
  • naive
  • Naive
  • NAIVE
  • naïve
  • Naïve
  • NAÏVE
  • youthful

This ordering makes sense for most usages. (At least that is what we have hoped.) Lowercase letters come first over upper cases; letters without accent come first over ones with accent.

On the other hand, if you sort the items using a MatchingCollator, you get following result. (Result may vary as some attributes are ignored.)

  • adolescent
  • Naïve
  • NAÏVE
  • naive
  • naïve
  • NAIVE
  • Naive
  • youthful

You may notice that upper/lowercase ordering and accent character ordering are not consistent with a MatchingCollator class. In fact, the MachingCollator class is not designed for sorting.

The difference in matching

Now, assume you want to search a specific string, “naive“, from the list. With a SortingCollator class, you get following result:

  • naive

Yes, only one string with a SortingCollator class.

On the other hand, with a MatchingCollator class, you get following result.

  • Naïve
  • NAÏVE
  • naive
  • naïve
  • NAIVE
  • Naive

As you can see, the string comparison was done in more lenient manner with MatchingCollator class. Often such leniency is desired when searching strings.

Although SortingCollator and MatchingCollator behave differently as you have seen above, those classes are pretty much same underneath. In fact, they can mute to the other sibling by setting their properties. If you need to control more details of sorting/matching behavior, you also manipulate the properties. Please see the Flex SDK references for more details.

References

The example program used in this article

<?xml version="1.0" encoding="utf-8"?>
   <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
   >
   <fx:Declarations>
      <s:SortingCollator id="sortingCollator" locale="en_US"/>
      <s:MatchingCollator id="matchingCollator" locale="en_US"/>
      <s:Sort id="sort"/>
      <s:ArrayCollection id="arrayCollection" sort="{sort}" source="{wordList}"/>
   </fx:Declarations>
   <fx:Script>
      <![CDATA[
         private static const wordList:Array = [
            "naïve", "Naïve", "NAÏVE",
            "naive", "Naive", "NAIVE",
            "adolescent", "youthful" ];
         private function setCollator(useSortingCollator:Boolean):void
         {
            const collator:Object = useSortingCollator ?
            sortingCollator : matchingCollator;
            sort.compareFunction = function (a:Object, b:Object, fields:Array):int
               { return collator.compare(a as String, b as String); }
            arrayCollection.refresh();
            uiResult.text = "Sort Result:n" + arrayCollection.toString();
            uiResult.text += "nnStinrgs equal to 'naive' are:n";
            for (var i:uint = 0; i < arrayCollection.length; i++)
            {
               if (!collator.compare(arrayCollection[i], "naive"))
               uiResult.text += arrayCollection[i] + "n";
            }
         }
      ]]>
   </fx:Script>
   <s:VGroup paddingTop="20" paddingBottom="20"
         paddingLeft="20" paddingRight="20" height="100%">
      <s:Button label="Use SortingCollator" click="setCollator(true)"/>
      <s:Button label="Use MatchingCollator" click="setCollator(false)"/>
      <s:TextArea id="uiResult" height="100%"/>
   </s:VGroup>
    </s:Application>

More content into more languages!

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

With all the internet chatter about Google’s decision to end their free machine translation (MT) API and transition to a paid service, some of you may be curious what role machine translation plays at Adobe.

Adobe does not currently integrate Google’s API into any products so we are not directly affected by this change. But we do license machine translation technology from commercial vendors and we are actively investigating ways to leverage MT throughout the company.

Adobe has a market presence in over 30 different languages, so any bit of documentation produced in English potentially multiplies out to a considerable cost if translated into all of those languages. Likewise, every day the company receives incoming communication in the form of emails, testing feedback, and customer service inquiries in even more languages!

To help manage this communication both directions, the Globalization Group at Adobe has turned to machine translation technology. The first step has been to insert MT into the document translation process. Instead of sending documentation out for translation from scratch, we first run the text through MT engines that have been customized for Adobe terminology, and then have our translators post-edit the output. Doing so, we see a speed-up of up to 50% with greater terminological consistency.

Right now, about 20 products are using MT for at least one language — including Photoshop, Acrobat, and Illustrator — and the list is expanding each month.

And the story doesn’t end there!  We are actively working on other ways to leverage MT to improve our ability to serve and communicate with a worldwide audience. Watch this blog as we gradually roll out new initiatives in the coming months!

— Raymond Flournoy
Senior Program Manager, MT Initiatives
Translation Technology Team

Localized Platform ActionScript Reference

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

The Adobe® Flex® ActionScript® 3.0 Language Reference in 6 languages is no more; the ActionScript® 3.0 Reference for Adobe® Flash® Professional in 16 languages bit the dust as well. Before you panic, the localized ActionScript References have gone the route of the English-language ActionScript® 3.0 Reference for the Adobe® Flash® Platform.

Announcing! The Platform ASR, as we affectionately call it, is now available in all 16 languages of the Flash Platform: English, French, German, Japanese, Korean, Simplified Chinese, Traditional Chinese, Spanish, Italian, Dutch, Brazilian Portuguese, Swedish, Russian, Turkish, Polish and Czech!

In addition to English, commenting has been enabled for French, German, Japanese, Spanish, Italian, Dutch, Brazilian Portuguese, and Simplified Chinese.

Now, if you develop in Flex, ColdFusion and Flash, in a language other than English, let’s say Japanese, you will be able to filter on those products and get the AS classes you need, all in one single document!

Not all products are supported in every language, but the beauty of this “all products under one roof” scenario is that you won’t have to go back and forth between the English-only version and a localized version if you are, for example, a Flex and ColdFusion developer. That’s because, for those products not supported in a particular language, you will find the English default in the same document. For example, French is supported by Flash Pro, AIR, Flash Player, Flex, but not LiveCycle or ColdFusion. So, in the French Platform ASR, you will find French and English together, depending on which products or runtimes you filter on.

The URLs to each language, for your convenience:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/fr_FR/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/de_DE/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/ja_JP/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/es_ES/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/it_IT/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/pt_BR/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/sv_SE/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/nl_NL/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/ko_KR/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/zh_CN/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/zh_TW/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/cs_CZ/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/pl_PL/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/ru_RU/FlashPlatform/reference/actionscript/3/
http://help.adobe.com/tr_TR/FlashPlatform/reference/actionscript/3/

I hope you are as excited about this as I am. Please blog and tweet about it, but most importantly, start using the new Platform ActionScript Reference in one of the above languages! Let me know what you think.

[Janice Campbell, Platform Localization]

Adobe AIR Launchpad Localized

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

Adobe AIR Launchpad v2.5.0, the desktop tool (created by Platform Evangelist Greg Wilson & team) that helps Adobe Flex® developers get started building desktop and mobile applications deployed on Adobe AIR, is now available in seven new languages in addition to English: French, Spanish, German, Portuguese, Russian, Chinese, and Japanese.

For details about the Launchpad v2.5.0 new features, including the localizations, visit Holly Schinsky’s (aka devgirlFL) blog. The language used at runtime is determined based on the default OS language. So far, feedback has been positive. If you wish to help us improve on it, please post to the AIR Launchpad Forum.

Thanks, the Flex Localization Team

The Localization Wall

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


Des Oates
Localization Solutions Architect

I first got involved in the localization industry when I joined Aldus Corporation in Scotland in early 1994 shortly before it became part of Adobe. Kurt Cobain was still rockin ‘n rollin. Bill Clinton had just completed his 1st year of his 1st term and D:Ream were top of the UK music charts with ‘Things Can Only Get Better’. A prophetic anthem for todays article.

Back then Aldus’ European localization team comprised of a group of  around 40-50 in-house staff comprising of  Localization Engineers, QE,  Linguists, Graphics/DTP Professionals, Planners and Researchers. A grand assembly for sure. But as I recall our delivery capabilities were not quite so grand: For a typical software release, a localization project would:

  • Target no more than 10 target languages in total
  • Have no more than 2 or 3 languages actively worked on at any time
  • Be the only major software release worked on at that time
  • Employ little or no external partners
  • Take up to 9 months to complete large projects.

Nine months to localize one product in 10 languages. Seriously?  NASA can get a robots to Mars faster!

Contrast this to today. In Spring 2010 we released Adobe Creative Suite 5.0 :

  • 5 Suite Versions.
  • 15 individual products
  • 24 languages

Over 600 localized applications simshipped* with English, with 50% bug reduction over the previous release. I think you’ll agree it’s an incredible step up from the old days.

Nowadays Adobe Globalization group is slightly larger than it was back then. We focus mostly on Program Management, Globalization/Engineering Leadership and International QE. Almost everything else is handled by trusted partners. We are always looking to improve our productivity, quality, and global reach. As such we’ve made a lot of changes over the years to our processes our staff and our technology. It’s hard to capture all the changes we’ve made succinctly in a article like this, but based on this experience, I thought I’d share some lessons we’ve learned along the way.

The biggest changes we have made are in these interdependent areas: Architectural, technical, and cultural. Here’s some key points:

  • Internationalization. If done well initially, the localization benefits (financial and time-to-market) will outweigh up front the costs by an order of magnitude. Evangelizing best I18n practices for your technology is also a worthwhile endeavour. Internationalization support should be a key criterion when deciding on your development platform for your project.

 

  • Automation. We are always striving to improve localization automation in our business. Don’t think of localization as a human process. It doesn’t have to be. It could be a series of automated steps, one or more of which may require some human translation input. As a rule of thumb, the more manual steps you have in your localization process, the costlier it will be.  Whether you use a GMS, a bespoke system, or just a bunch of scripts- it doesn’t matter.  You will reap productivity rewards and reduce costs if you employ reliable, maintainable and repeatable automation.

 

  • Release/Build Integration. In the old days, our Localization Engineers built every component of the localized software that went on the CD manually on their own workstation. It was error-prone, and labor-intensive and required a lot of QE. Now all application language versions are built as part of a unified process. Localization has become simply a release engineering sub-process, allowing us to scale up our efforts dramatically. If you first optimize your automation, it makes sense to integrate the process into a single multilingual release configuration.

 

  • Trusted/Trusting Partners: The final area of change was the way we interacted with other groups.  We identified cultural and communication barriers between us and the groups we work with. Ultimately you need to establish trusted effective partnerships with the stakeholders in your localization processes. It may be internal teams such as development teams or business units that you need to reach out to, or external partners such as LSPs or translation providers.

 

Here at Adobe we started the ‘World Readiness’ programme: An initiative lead by my colleague Leandro Reis which provides an assessment framework to evaluate the global-readiness of our products. Along with highlighting the problems it offers advice and expertise on how to fix them. Our internal ‘customers’ were compelled by this approach, and our internal localization walls began to fall.

Similarly if you use external partners, they should be willing and capable of integrating with your business – not vice versa. That may require some initial training and ongoing mentoring. It’s easy decide not to do this, to keep the localization wall high between you and your partners, throw localization work back and forth over it but that model is ultimately more costly. The lack of transparency can lead to project overruns, increased defect rates, and occasionally chaos. However if you streamline your own localization processes, lower your localization walls and select competent partners willing to embrace your business processes, then you will gain a trusted capable partner, and your partners will gain a high-value, repeat-business client.  A win-win situation.

Just for fun I looked up  the number 1 song  in the UK charts when Adobe customers across the globe started receiving their localized copies of Creative Suite 5 in May 2010…

…”Good Times” by Roll Deep.

 

* simship: No more than 5 days after English