Adobe Localized Prerelease Program

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

Does breaking applications excite you…do you consider yourself a doom for faulty applications or are linguistically good enough to lecture everyone around….  We would love to hear from you !!

The Globalization team at Adobe with an eye to enhance the end user experience; has decided to launch the localized pre-release versions of several products and is looking for pre-release testers around the globe.

Excited…that’s not it…there are tons of goodies and cool adobe products be won*.

What are you waiting for…fill up the pre-release interest form available here and be considered.

Spread the word and be the first to grab hold of the most awesome technologies yet to hit the market.

(* subjected to individual contribution and discretion of Adobe Systems)

[Gaurav Bathla, Adobe India]

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:

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


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.

A Editora Globo Vai Usar a Adobe Digital Publishing Suite

Este artigo foi originalmente escrito em Português. Qualquer texto em outro idioma foi fornecido via tradução automática.

Editora Globo, o departamento de publicação da Organização Globo — um dos maiores conglomerados de mídia maiores na América Latina — escolheu a Digital Publishing Suite para publicar suas revistas. Localizada no Brasil, a Editora Globo já publicou a revista AutoEsporte usando a solução da Adobe. Agora, a editora planeja usar a Digital Publishing Suite para suas outras revistas, inclusive a revista semanal Época, bem como outras revistas de língua portuguesa como Época Negócios (negócio) e Galileu (ciência e tecnologia).

Para entender porque a Globo decidiu utilizar a Digital Publishing Suite como padrão, contatei Alexandre Maron, Diretor de Inovação Digital na Editora Globo. “A Digital Publishing Suite foi uma escolha natural com a estratégia de publicação da Globo,” escreveu Maron. “O Brasil é um dos países emergentes mais rápidos quanto a mídia digital. Queremos estar na vanguarda em termos de publicação e distribuir revistas digitais, e a integração avançada da Digital Publishing Suite com os nossos sistemas de publicação ajuda-nos a a alcançar estes objetivos — ao mesmo tempo, mantendo uma relação próxima com os nossos leitores.”

Folheei rapidamente páginas de algumas edições da AutoEsporte e uma determinada parte do conteúdo chamou a minha atenção. Normalmente, seria uma parte de interatividade ou um layout meticulosamente trabalhado que notaria, contudo, desta vez foi uma carta ao editor. Ilustrando a capacidade de revistas digitais em cativar o público, um leitor escreveu o seguinte: “Confesso que nunca fui leitor da AutoEsporte, mas a tentação de ver a revista no meu novo iPad foi grande.” “Vocês ganharam um cliente leal que, antes mesmo de terminar esta edição, já está esperando ansiosamente pela próxima.”

Baixe a revista AutoEsporte na App Store

Tradução do artigo: Adobe Digital PublishingBrazilian Publisher Editora Globo to Use Digital Publishing Suite


The differences of three globalization packages in Flash platform

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

Developers who are looking at the Flex SDK Hero releases noticed that we have three NumberFormatters (and other globalization-related classes) in the Flash Platform. If you’re wondering why, here’s the explanation.

The Flash platform has the following sets of globalization-related classes for different use cases.

  1. flash.globalization: Flash Player built-in
  2. mx.formatters: Flex SDK MX namespace
  3. spark.formatters/validators/globalization: Flex SDK Spark namespace

The flash.globalization package is implemented as native code in the Flash Player. As with other player classes such as Sprite, you link against playerglobal.swc or airglobal.swc to use it. This package is a recent addition to Flash Player. You need Flash Player 10.1 or AIR 2.0 (or newer versions of these) and a corresponding version of playerglobal.swc or airglobal.swc. They utilize the globalization features provided by the underlying operating system rather than using Flex’s ResourceManager. Therefore you can use any locale supported by the OS, not just the locales for which you built your application. However, these player APIs can produce different results on different platforms. For example, a Greek date might get formatted differently on Macintosh, Windows, Android, etc.

The second set of the globalization classes is provided by the Flex SDK and in the MX namespace. Actually, this MX set is the first globalization classes we provided in the Flash platform. The MX globalization classes provide some formatters for such as number, currency, date and so on. These classes use very limited locale information in the ResourceManager. If you want to do Greek formatting, you have to have Greek resource bundles (which Adobe doesn’t currently provide, although it does provide 16 other locales). Also, locale-aware collation and case conversion were not offered by these classes.

The third set of the globalization classes is also provided by the Flex SDK (beginning with version 4.5) and in the Spark namespace. This is our latest addition in terms of globalization classes. This set acts as glue between the flash.globalization features and the Flex SDK. This Flex Spark version has some advantage compared to the built-in Flash Player globalization features. In particular, they are about the compliance with the MXML syntax and the style inheritance. Those are indeed necessary to make the globalization feature as a part of the Flex SDK UI infrastructure.

Here is a summary comparing the three APIs:

Item Flash Player built-in globalization feature Flex  SDK MX globalization feature Flex SDK Spark globalization feature
Namespace flash.globalization mx.formatters and mx.validators spark.globalization, spark.formatters, spark.validators and others
Required minimum Flex SDK version N/A Flex 3 Flex 4.5
Required minimum Flash Player version Flash Player 10.1
Flash Player 9
AIR 1.1
Flash Player 10.1
Number formatter Yes Yes Yes
Currency formatter Yes Yes Yes
Date time formatter Yes Yes Yes
Number validator No Yes Yes
Currency validator No Yes Yes
Collator Yes No Yes
UI support N/A No


(DataGrid, Sort, SortField)

Supported locales Depends on underlying OS 16 Depends on underlying OS
Use in MXML No Yes Yes
Use in Script Yes Yes Yes
Locale style inheri­tance N/A No Yes


  • flash.globalization package document

  • Flex SDK mx.formatters package document

  • Flex SDK mx.validators package document

  • Flex SDK Hero (Beta) spark.globalization package document

  • Flex SDK Hero (Beta) spark.formatters package document

  • Flex SDK Hero (Beta) spark.validators package document (Not yet available as of the writing)

The Adobe Moses Corpus Tool – And Crossing That Bridge When You Come To It.

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

Here is the scenario:

It’s the 1950’s.  You are at the head of an expedition in Nepal, and the brave leader of a dozen mountaineers plus a couple hundred porters all walking deep into the Himalayas in search of an unclimbed summit.  The risks of the journey are high but you will be showered in glory by your nation, ticker tape parade and everything, when you return home successful. Entering a deep valley you come upon a long and narrow rope bridge which the whole expedition will have to cross.  The bridge is too weak to hold more then one person at a time and it takes 5 minutes for each person to cross.

You can get the the first 12 climbers across in an hour.

(12 Climbers x 5 minutes each = 60 minutes) so 1 hour to cross.

But the very last porter won’t make it across until almost 2 days after the first climber starts out.

(200 Porters x 5 minutes each = 1000 minutes) or an additional 41.6 hours to cross!

You may not be getting that ticker tape parade after all.


The success of the entire expedition is a stake.   Valuable resources, food, tents, climbing gear, etc. are going to end up spread all up and down the trail with their respective porters.  This means they won’t be arriving at base camp when and where you need them.  This is not a good way to get started.

The bridge crossing metaphor used here is a textbook example of encountering the limiting factor in your process chain.  No matter how many resources you can bring to bare on the project there is a choke point.  It can take many forms but identifying and solving this problem will be critical to reaching your goals.  It doesn’t matter how fast you proceed through all the other steps of your plan, you are going to lose those 2 days here unless something changes.

Does the narrow rope bridge which will only let one person across at a time sound like an unlikely obstacle to face in your machine translation project?  It’s not.  When we launched the Adobe Moses MT project last spring getting across this bridge was the first problem was faced.  Why?  Quite simply we had years of translation memory stored up from Adobe localization projects. All those years of TM were the raw materials to be used in building Adobe specific engines.  We knew with them that we could build better engines for translating Adobe products then we would ever find on the open market.  However, the sheer volume of TM that needed to be processed into a Moses ready corpus represented a blockage of serious proportions.


A quick back of the napkin metric to put this inperspective:

We found, given the existing tooling for corpus work, that it required 1-2 weeks of an engineer’s time to process 5-10 million words of translation from .tmx format into a pair of aligned flat corpus files. (i.e. Moses ready)

Moses does come with a set of support scripts for working these problems. (, clean-corpus-n.perl, etc.)  and they are functional.  That said, the effort is time consuming.   The scripts are all run from the command line.  A great deal of organization and discipline is required of the user or all the required steps can quickly get confusing.

If you have millions of words across multiple languages, as Adobe did,  you can see it’s going to take a long time for that one engineer to process those .tmx files.  If you add a couple more engineers then you can speed up the process but the overall time required per unit of .tmx cleaned hasn’t gone down.  This would be the equivalent of building a couple of more bridges across that chasm in the Himalayas.  It speeds things up but it’s expensive now and doesn’t lower costs in the future.


So if we’ve only got one bridge to cross then the solution is to reduce the time it takes us to cross that bridge.

The Adobe Moses Corpus tool was our solution to this problem.  While none of the individual steps in taking a .tmx file to a Moses ready state are too time consuming, those small steps all add up.  We decided to solve the problem once and for all and to develop a light weight, modular, GUI based, AIR app which any user could install and use to process TM files for Moses.  What does it do? Quite simply it lets you automate your corpus cleaning to improve efficiency.  It takes the multiple command line options available and allows the user to orchestrate using them on any .tmx without the worry of calling scripts and passing parameters.  How much does it help? While these numbers are loose, we’ve been able to increase the productivity of a single engineer working on corpus cleaning by up to 10x.


We can now do it in 2 days what used to take 2 weeks.

When you have millions of words of translation memory this is a big deal.  If you want to do MT for yourself you will need to solve this problem.  For us, the Adobe Moses Corpus tool continues to evolve as we learn more about the cleaning steps we want access to and how to order these steps.  It is our vision that it will fit into a greater more comprehensive package of MT related tools which may include the automatic testing and tuning of engines.  We continue to consider all the possibilities this tool would open up for the greater MT interested public and are open to ideas and collaborations with others around it’s improvement and extension.


There are plenty of bridges to cross on the way to building MT systems. Corpus handling is just one of them. Hopefully this knowledge makes your journey a bit more clear. Now get out there and build an engine!


A quick (but by no means complete) list of things of things that could be done to improve MT engine quality:

This is a short list of the steps the Adobe Moses Corpus tool can currently perform.  We are open to suggestions about adding other steps or refining the nature of these steps.

Clean Placeholder Tags

Clean URLS



Clean Numbers

Clean Duplicate Lines

Clean Long Segments

Clean Misaligned Pairs

The efficacy of each of these steps could be debated around the MT round table but in general most people will need to process their TM files through these steps before the can be used with Moses for engine building as well as to improve quality.