Tag Archives: localization

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.

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

Des OatesLocalization 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!

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…

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.

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

Do you create multilingual content or apps using Flash Builder? Do you use a localized version of Builder? Why or why not? Do you prefer to develop in English while deploying in multiple languages?

We would like to hear your voice and understand your pain points. Please link to our short survey on Flex and localization so we can understand what is important to you.
Many thanks!
Janice Campbell, Flex Localization

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.