Posts tagged "localization"

Announcing PSE11 and PRE11 Programs for French and German Users

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

Adobe Prerelease Programs are your chance to experience, evaluate and influence upcoming products & technologies from Adobe within a smaller, more focused user environment. Prerelease Programs facilitate a symbiotic development process allowing Adobe to share products in the development stage to gather early feedback. In the process you get a chance to shape the upcoming products and adapt to the new products faster.

Multiple engagement channels are available to Prerelease participants at Adobe:

  • Access to download Prerelease software/technologies and technical documentation
  • Ability to report bugs & request features for the Prerelease software
  • Access to the Prerelease user forums for sharing ideas directly with Adobe product teams and other likeminded folks of the product’s community
  • Opportunity to participate in various product-related surveys

A Prerelease program is an endeavour to engage the real users of the product – YOU – early in the development cycle of the product, to listen and learn from you on how the product is working for you.

Current Prerelease Opportunities: How to Apply?

You may fill in the application forms for expressing your interest to join a products’ Prerelease program at Adobe. The participation will be entirely based on the requirements of the program and the credentials of the participant.

Following products have been opened up prerelease testing opportunities with French and German builds:

Photoshop Elements 11 for French Users– Sign-up now to participate in the Adobe Photoshop Elements Localized program and preview exciting new functionality! – Apply now

Photoshop Elements 11 for German Users – Sign up to participate in the Adobe Photoshop Elements Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for French Users – Sign up to participate in the Adobe Premiere Elements 11 Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for German Users – Sign up to participate in the Adobe Premiere Elements 11 Localized Program and preview exciting new functionality! – Apply now

We look forward to your participation in this pre-release program. In case of any issues of if you need more information, please feel free to contact Manish Kanwal at mkanwal@adobe.com or Nimra Khan at nikhan@adobe.com.

 

Adobe Flash – Content Creation & Localization Guidelines

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.

 

Dynamic Language Delivery for Adobe’s Mobile Applications

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

Recently, at Adobe’s developer conference Adobe MAX 2011 in Los Angeles, representatives of Adobe Globalization group had the opportunity to present – for the first time publicly – how we are envisioning the deployment of localized resources (texts, user interface strings) to mobile applications in the field.

In their presentation “Dynamic Language Delivery for mobile applications” (here as an Adobe MAX video), Daniel Nay, engineering manager, and Dirk Meyer, product manager, demonstrated how language updates or entirely new languages, can be delivered to applications on mobile devices in a matter of seconds. (In the presentation video, you can find demo sequences at 7:00 and 35:50 on the timeline.)

Localization Of Mobile Applications

Like in all other areas of software creation, the development of mobile applications, too, is increasingly applying “agile development” principles: Short “sprints” are helping to implement specific features in a targeted fashion and to deliver them into the hands of users and customers faster, compared to desktop software products. At the same time, and as a consequence of the new development paradigm, the time between the frequent “pushes” of new product versions become shorter and is often measured only in weeks. As a consequence, an end-user is receiving updated product versions more frequently. Fortunately, their installation only takes a minute or less, and (most important for some!) they can be skipped, if they don’t seem attractive or if there is no time for the update.

Dynamic Language Delivery (DLD): Localization’s answer to agile development

In the world of short development cycles and frequent updates, the differences between versions of a mobile application often consist only of a single feature, or some fixes for software bugs. Accordingly, from a localization perspective, the delta between the localized strings from one version to the next, is often only a small one. There might even be cases, where it is merely a fix for a localized string that constitutes an update. In situations like that, it may look a bit out of proportion to initiate a complete localization cycle for such a small change. Because no matter whether changes are big or small, translators, build engineers and testers, all have to follow a complex workflow with many mutual dependencies before the product finally can reach the app(lication) “stores” or the “markets”. Starting such a powerful machinery, designed to flawlessly localize the most complex desktop applications, for only small changes, and doing so even more frequently than in the “non-agile” past? Again, a bit out of proportion, it seems …

Here now, DLD provides a new way to deploy language resources, like user interface strings or other texts used in an application. And it does so without hindering the fast and agile engineering workflows and without slowing down the subsequent application delivery. Instead, DLD workflows are designed to match agile development cycles, including rapid and frequent deliveries to end-users. DLD enables the testing of improvements and modifications instantly, and allows for approved deliveries to be performed in real-time, be it in staging or production environments.

Principles Of DLD

DLD technology effectively decouples the delivery of the the mobile core application (plus one or more core languages) from the deployment of subsequent language deliveries (like UI string fixes or new languages). It does so by using two completely independent avenues to get those resources to a customer. Here is how …

DLD enablement & deployment

First of all, a DLD-enabled core application takes the usual route and reaches the customer as a fully tested and functional product through being downloaded from a website, “store”, or “market”. DLD-enabled means that an application should integrate a DLD library to perform DLD-related tasks (this integration is very lean and can often be achieved with a single line of code). The other requirement for an application to be prepared for DLD is that it should be architected in a “world-ready” fashion: Strings should be replaceable, variable interface string lengths should be possible through dynamic UI layout capabilities, and more. The good news here: It is already an accepted best practice to write any software – no matter whether it supports DLD or not – in a “world-ready” way so that it supports internationalization features and easy localizability.

If, at a later point in time, new or updated text strings or a new language altogether need to be delivered, a second deployment path through the “localization cloud” will be used, completely independent from the application deployment avenue. The localization deliveries will be held available on servers, queried by the application from time to time for language updates. The frequency of these queries can be set with the help of preferences in the application and, of course, a user should always be able to opt-out of this functionality completely.

Customizing multilingual applications in user-friendly ways

In addition to non-intrusive, instant language updates and the option to add new languages when an application is already in the hands of users, there are more ways how we can see DLD supporting new features of multilingual mobile software.
For example, if an application does not come in the language preferred by the user, DLD functionality can be used to check whether this language might be available from the “localization cloud”. More intelligent applications might actually notice that among its current languages there is none matching the (user-preferred) system language … and trigger an alert to download a “language pack” in the system language, if it is available. Thus, DLD can be used to improve a multilingual user experience, where languages and language updates are available at any time: For those, the need to locate, download or install a complete application bundle does not exist anymore.

Finally, it is important to note (the presentation video shows this), that the language updates are available in the running application right away, without having to restart or perform another type of user action: new resources are loaded in the background and appear seamlessly, once they have been downloaded and integrated.

DLD’s Benefits

In summary, DLD comes with a number of benefits for consumers of mobile applications:

  1. “Instant, real-time” delivery and integration of localization updates and fixes for mobile applications in the field.
  2. Language updates can be configured per user preferences, ranging from completely “transparent” to “fully informed”.
  3. Additional languages desired by a user after an application install, can be added on demand, without having to download and install another complete application package.
  4. Missing languages complementing a local device environment, for example, after switching the system language, can be discovered and installed if the user so desires.

Moreover, software development teams are also among those that save time and effort through DLD technology:

  1. DLD library integration is “minimally invasive” (often, only a single line of code is required).
  2. Leveraging the localization cloud, “world-ready” applications will be able to receive language updates whenever they become available during the development process.
  3. DLD separates application development from localization workflows. By doing so, it removes many process and scheduling dependencies between the two.
  4. Development work can continue until late in the cycle and for as long as the application maintains a state ready to receive strings of multiple languages with different properties.
  5. Development work can continue until overarching milestones are requiring it to get ready for the push live. A user interface does not have to be “frozen” with the arrival of localization resources.
  6. Testing work becomes more efficient and will not be accompanied anymore by repetitive tasks of building and installing the application, before testing it for every language or localization fix. Instead, as long as language fixes are involved, they can be delivered to the application instantly and the testers can verify their integration into the application without delay.

In Short …

DLD is the first workflow allowing for immediate, dynamic, and on-demand localization of an application during post-development states. This is possible through making localized resources available as updates, without the need to re-deploy combined application-language packages as a whole.

Among the advantages of the DLD approach, an almost instant “time-to-market/user” and a much simplified development/localization interplay, are probably the two most valuable ones. From many angles and perspectives, DLD is a fast and resource-saving  way to perform localization deployment for mobile applications running on a variety of devices.

Expect to see it in your favorite Adobe mobile application at some point in the (near?) future.

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!

 

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