Posts in Category "English"

Join Us: 3rd Adobe Experience Manager Multilingual Content Special Interest Group Meeting

The Multilingual Content Intelligence team at Adobe is excited to host our third Adobe Experience Manager Multilingual Content Special Interest Group (SIG) meeting on Thursday, Nov. 7, at our headquarters in San Jose. Our program this time is on Digital Asset Management (DAM), and we plan to focus on how DAM can be used for multilingual purposes. During the meeting, we’ll also have a Multi Site Manager (MSM) review session to share feature enhancement plans for future releases.

This is a great opportunity to understand basic concepts of DAM and related best practices in a multilingual context. Attendees will also rub elbows with our Adobe experts, share their experiences and challenges, and network with peers from various industry leading companies that are putting Adobe Experience Manager to use.

The details:

Date: Thursday, Nov. 7, 2013

Time: 8:30 AM – 4:30 PM PST
Address:  Adobe San Jose headquarters
345 Park Avenue
San Jose, CA, 95110

The event is free, but you must register in advance to attend. For registration, please visit: https://adobesig.eventbrite.com

For more information or any questions, you’re welcome to ping me at: seunlee at adobe.com

We hope to see you next week!

Seungmin Lee

Sr. Program Manager

Sharing localized eLearning courses across social media via Adobe Captivate

Adobe Captivate is an electronic learning tool which can be used to author software demonstrations, software simulations, and randomized quizzes in swf and HTML format which can be converted and uploaded to video hosting websites. This content can be shared over Facebook and Twitter to make eLearning a very simple and interesting task. Adobe Captivate is shipped in 7 locales – English, French, German, Japanese, Spanish, Korean  and Portuguese but courses and demonstrations can be created in other languages as well and we can share these localized courses very easily. Getting an online content in native language sets learners free of their dependency on English locale.

Creating localized eLearning courses 

Below steps guide that how simple it is to share your high quality creations and demonstrations on YouTube and further over twitter/Facebook via Adobe Captivate 7 without even having much prior knowledge of the product. It will also highlight some of the trivial yet important issues which might prevent users to share content in English as well as non-English locales. This solution can be helpful to many native content creators.

1. Launch Captivate and select Video demo or Software Simulation from Start up page. Software simulation records events such as mouse click, keyboard entry, and system events and create slides accordingly. Video demo lets you create a single video which can be directly published to mp4 file.

111

2. Select the application or screen area which you want to demonstrate and select default presets for idevices(iphone, ipad), YouTube or customize it as per requirement. Select panning mode to focus screen areas manually/automatically with mouse movement.

2

 3. Select “settings” button and go to Global Preferences. And select the language in which you want to generate the captions. Captions are generated automatically in case of software simulations which help in guiding throughout the training. Captivate allows you to create captions in multiple locales present in the list. They can be edited manually if required.

3

11                   Captions can be generated in any of the languages selected by the user.

4. Add audio narration to your demo by selecting proper audio input device. System audio can be added as well to the projects along with narration.

4

5.  After all settings click record button. Add narration and keep demonstrating your project. After completion hit END or click system tray icon in task bar.

6. The video will play before you and there is option to edit it but if it is properly recorded just click “YouTube”. Click the Folder icon to publish it locally as mp4 file. (This can be shared as standalone file as well) . You can adjust the aspect ratio, quality, FPS in this workflow. Even after getting a copy store at your machine captivate asks about YouTube publish as well.

5

6

Edit Mode: If the video needs some correction click “Edit” and modify the video. Cutting of extra video, zooming on important areas, split of video into two parts, inserting objects, inserting another PIP (picture in picture) video is possible in edit mode.

Sharing courses on YouTube, Facebook & Twitter

1. Publish to YouTube:

If you already have a YouTube account, enter your credentials and accept the license agreement and Log in to YouTube.

For new users with no YouTube account, click over new user and you’ll be redirected to sign up page for Google. Create your account and after successful creation come right back to Adobe Video Publisher and enter your details. Many a times users face an issue that even if after successful creation of account they are not able to login and face an error that specified user name/password incorrect although on YouTube they can log in with same credentials.

7

  8

The issue is that every new account on YouTube needs verification. Without account being verified you cannot upload your video. To verify the account you can create your YouTube channel or verify via your phone.(This applies to Adobe Presenter Video creator as well)

Once you have logged in add description to your video and mark it under proper category public/private and UPLOAD! You can further view you video on YouTube or copy link to share with peers.

2. Publish to Facebook and Twitter

To share the course on Facebook/twitter check respective buttons and POST.

9

Sometimes user might face a blank dialog or a dialog saying internal error occurred when they post video on Twitter and issue is not easily isolated. Even restart/republish does not lead to any success. 

10

The reason behind this is oAuth issue. We have to ensure that system’s time stamp is in Sync with Twitter’s. Twitter returns the current time in the “Date” HTTP header with every request. If your request fails due to a time stamp mismatch, use this time to determine the delta between the system clock and its server clock and adjust your oAuth_time stamps for subsequent requests accordingly. So all you need to check is that system time is set same as per proper time zone and you have not modified it. For eg. If your time zone is (US and Canada) Eastern Time then your system time should be same as current time of that region only else twitter won’t return your request. And you’ll get internal error. This issue can occur with people following different locales who may set their zone to some other region and system time to their own region. Can refer https://dev.twitter.com/discussions/204  for more details.

(Also applicable to Adobe presenter video creator.)

By following the above simple steps, students can now use their own Facebook/Twitter accounts to learn more by enrolling in these courses. It will be a great experience to learn via social networking portals . So start recording and sharing your projects in ADOBE CAPTIVATE and share them worldwide to connect with more and more people and encourage eLearning – the most fast and efficient learning practice.

The Problem with Localizing Software for Multiple Platforms

Adobe has a long history of developing products for multiple platforms, be it desktop applications like our flagship Creative Suite applications or newer touch applications like Photoshop Touch. Most of our desktop apps have been built for both Windows and Mac and newer applications continue on this trend with support for iOS and Android including Tablet and Phone form factors for both.

Of course this would not have been possible without the careful efforts of the engineering team to largely maintain a single code base for all platforms.

While having a single code base has obvious benefits, in the UI layer it is often important to have platform specific variations for better usability. Each platform usually has a specific convention for referring to system menus, short cut keys and UI elements. For example on a windows platform a UI String could be – “Select a media file via the Browse button or enter a valid pathname.” and the same string for the Mac Platform could be – “Select a media file via the Choose button or enter a valid pathname.”

This means that translatable UI strings may have many variations in the source language depending upon which platform they are intended for. This is what our globalization group usually refers to as ‘Platform Variance’. Localizable strings are essentially multivalued entities. Each localizable string has an identifier and multiple associated values each of which can be selected based on certain criteria. The most obvious and commonly used criteria is the UI locale of the application but it need not be the only one. Platform too can decide the value of a string.

Platform variance support is not just useful for handling terminology differences for referring to system UI elements, it also helps adapt strings for different screen sizes. Modern application are designed for supporting multiple device form factors like tablet and phone with the UI being tweaked for each platform for best user experience. Platform variance in this case can be used to support longer strings for the Tablet view and shorter strings for the Phone view.

Yet another area where platform variance support could potentially be useful is in having different localizable values for a Pro version versus a Consumer version of the application.

However, localizing strings with platform variant data is a problem. The problem is two fold, one is in managing the processes and project schedule to allow for agile localization and simultaneous release for all target platforms. The second aspect is technically supporting the platform variance in both programming libraries and translation tools. Many tools and libraries assume a single value for a source and a target string, but in case of platform variance not only can there be multiple source and target values for a string there need not be a one-to-one correspondence between source and target values. There may be multiple platform variants for a source string that map to the same translated/target value or a single source string may need to be translated differently based on platform for the target locale. For example:

  • en_US: “Please close the dialog and start over.”
  • default fr_FR: “Fermez la zone de dialogue et recommencez.”
  • Windows fr_FR: “Fermez la boîte de dialogue et recommencez.”

Since I am part of the globalization tools team here at Adobe, the remainder of this post I describe the problem more from a technical tools and libraries perspective, drawing from my experience. The process problem is also pretty complex and would probably take a much longer blog post to discuss. In fact there’s a related one already on this blog, see – link.

Platform Variance Support in Libraries

Ideally the globalization libraries/APIs used in the code to manage externalized strings and the corresponding storage formats for the externalized data should have a notion of a platform variant value for each string. There should be a way to request a string value for a specific locale and platform along with a provision to fall back to a default value in case a platform specific value is not specified.

As an example, the Java ResourceBundle API supports selecting a bundle by ‘Locale’, there is no explicit mention of a ‘Platform’, but the ‘Locale’ itself is extensible to support variants. The variant mechanism in the ‘Locale’ can be used for supporting different platforms and there is also a fall back mechanism. At Adobe we have a custom developed cross platform library called ZString for managing externalized strings with explicit support for platform variance.

Platform Variance Support in Translation Tools

Most translation management systems (TMSs) have a one-to-one model of source strings with matching translated strings for each locale. This assumption is behind the architecture of the TM matching algorithms as well as the design of the translation workbench. A typical translation workbench usually offers a side by side view of source and target strings, but only supporting a single source string corresponding to a single translated value.

Typical Translation Workbench

A typical side by side view of Source and Target content in a translation tool

We are still searching for the ideal solution to this problem. For managing the TMs a possible workaround using existing systems is to have duplicate entries in the Translation Memory (TM) or a separate TM for each platform.

However, translators are still constrained by the view presented by their translation workbench. A possible solution to allow translation vendors to provide platform specific translations is to duplicate all the source strings for each possible target platform. The source value for the default platform can be used as the source value for all other platform unless the application UI already specifies a value for a specific platform in which case that is used. Now the translator can provide different translations for each platform if required. This workaround however seems to be a significant amount of additional work for the translators. Some optimization is possible by translating a single platform first and leveraging translations for all the other platforms.

In an ideal scenario the translation workbench would provide a side by side view of all platform variants for the source string and the target strings. With the ability for the translator to remove variants from the translated string where they are not required and propose variants for the translated string even if the source string does not have any. This would allow translators to work through the source content in a single pass, editing leveraged translations, providing new translations where required and proposing platform specific translated values as appropriate.

An approximation to this ideal view is an Excel sheet with each source string being represented in a row and having a separate column for each platform for both source and target strings. With blank values in a platform column signifying that the default translation is to be used for that platform and non-blank platform entries being used for the platform specific translations.

Ideal Translation Workbench

A proposed translation workbench view allowing simultaneous translations for multiple platforms

We are still experimenting to find the optimal solution for our needs, that offers flexibility to translators and yet leverages our investment in existing translation tools and processes. The goal is to be able to support faster agile release cycles with all platform releases happening simultaneously.

I think this is a good forum to ask our blog readers if they have faced similar problems and the solutions they have developed to deal with it.

Marketing Localization at Adobe – What works, what’s challenging

I have been asked lately to talk to a couple of peers in the industry about Marketing Localization at Adobe and thought this would make an interesting blog post as well.

At Adobe, Marketing Localization is centralized and consists of a team of International Program Managers, which I manage.

I believe this is still the right model for us. Adobe has offices all over the world and decentralizing marketing localization would actually introduce inefficiencies. That said, the challenge with a centralized model is to balance productivity with the ability to provide GEOs with the right process and tools so they can participate and provide valuable input around GEO-specific nuances, country specific content, etc. This is an on-going challenge and we work very closely with our Marketing Managers worldwide to conquer it.

The challenge here is the balance between giving more flexibility and freedom of expression to the regions and the use of productivity tools such as Translation Memory. If we want to leverage the savings that TMs and other tools offer to localization (and we do), we can offer some flexibility in the target content but not as much as sometimes the regions would like to have – for instance, complete re-writes of segments.

At Adobe we are aware to these issues and the key here is to work closely with the regional offices and offer them opportunities to provide feedback early on, directly into the source content, before localization starts. It also means providing opportunity for reviews on localized content that is presented in context in a process that allows for easy feedback. Our GEOs are Field Marketing Managers and we are sensitive to the amount of time spent in reviews.

Challenges

There are always challenges in localization and in particular in Marketing localization, where ‘good translation’ is just not good enough.

Take the Digital Marketing BU for example. Worldwide campaigns around the digital marketing solutions have to appeal to ‘marketers’, to professionals that create marketing content, and so the ‘localization quality bar’ for the content we provide to our GEOs has been raised significantly.

Here’s an example of a recent campaign that was particularly challenging for localization due to the use of the very US centric expression “ticks them off”.  For translators is not always a clear choice of words for the target language.  The ‘weight’ of the expression and what it conveys need to be taken into consideration.

12

Regional offices are free to create their own marketing materials – International Brand Guidelines are in place and Adobe’s Brand team works directly with the GEOs to ensure a consistent interpretation and use of our brand.

We are very protective when it comes to the Adobe brand and although the regional offices are given some flexibility in terms of creating some of their own marketing materials (in their original language), Adobe’s Brand team normally is involved to make sure the materials follow the established international brand guidelines.

What regions or international markets are most difficult or challenging for localization?

I think anyone that works in localization would start by saying that Japanese is a very challenging language to localize. The idea of ‘translation’ is already something that is not appreciated by the Japanese market. A very good ‘translation’ still means ‘it’s translated’ and so it has a different flow and feel than the content that is originated in Japanese.  This becomes an even greater challenge around marketing content.

At Adobe we do have a successful program for localizing marketing campaigns into Japanese and that involves working very closely with our in-country product marketing managers and employing in-country copy editors when necessary.

That said, every language and every country present challenges. We recently had to deal with orthography changes in Brazilian Portuguese, tonality changes in Spanish (formal to a more informal tone), imagery issues in the middle east, different ‘flavors’ of a single language, and so on. I guess I would say that there are no ‘easy’ regions. Our work is always interesting and we look at these challenges with a very positive attitude – these challenges are what differentiate translation from localization and it’s always exciting to be part of this process, where you see the source messaging deployed all over the world and having the intended appropriate impact in every region, around the globe.

What aspects of branding are most important to localize for regional audiences? What channels are most important?

The emphasis has greatly shifted to online content (web pages, multimedia content and social), the larger part of the content we now localize will end up on Adobe’s 57 international sites. The need for printed content has decreased but there are still certain regions that need to be supplied with printed content. We try to listen to our GEOs and provide relevant localized materials.

The Adobe ‘look and feel’ is very homogeneous in all our sites. Our regional offices have the flexibility to add country specific content but the site template is the same for all locales and all international sites are centrally managed.

Regional offices are also free to create some of their own marketing materials – International Brand Guidelines are in place and Adobe’s Brand team works directly with the GEOs to ensure a consistent interpretation and use of our brand.

I believe the big challenge now is the creation of a strong and successful Creative Cloud brand worldwide – and we are well underway :-)

Bottom line

The regional offices should be an extension of your team and taken into consideration in every step of your processes and tools.

 

Localized Prerelease Programs

The Localization team at Adobe is continually working at enabling more avenues and channels for our international user to provide us feedback on the internationalization and localization aspects of our products. One such channel is Localized Prerelease Programs. Through these programs, we encourage our international users to provide feedback on UI, translation, and overall world readiness of our unreleased products. These localized prerelease programs allow you to test products in your native language and provide feedback in a structured manner through the prerelease site. We welcome any feedback on the language used throughout the UI, ensuring that the product functions and appears natural in your language. Feel free to give us feedback on truncations, overlaps, clippings, flawed UI geometry or any cross-product inconsistency that you observe in the product in your language.

You can show your interest in participating in Adobe’s Localized Prerelease Programs by filling this form. Make sure you select ‘Yes’ to the question ‘Would you like to participate in a localized Prerelease Program ?’ and specify the language that you are interested in.

Internationalization as an Architecture

Creating global-ready, internationalized applications requires many people: engineers, project managers, translators, and often in-country experts. If everything goes as planned, the final product is internationalized and localized to meet the needs of a specific market. The required teamwork is amazing, and sometimes the expense can be surprisingly large. The mistaken conclusion is that internationalization must always be expensive, and that the effort simply costs too much in terms of schedules, resources, and of course money. The worst part about the conclusion is that the expense can be minimized considerably by rethinking when and how internationalization is performed.

Two causes of expensive internationalization are the delays in actively thinking about it and thinking of it as a simple feature. Often product managers and engineering teams simply do not plan for localization from the beginning of their project’s lifecycle. This is common in product teams that target English-only regions first. Unfortunately, engineers and product managers mistakenly think that they will be able to add the internationalization and localization “feature” at a later time when needed. This is an expensive mistake, and it comes from thinking of internationalization as a feature instead of an architectural and design style. The result is that the final product does not contain any framework for localization and has not been designed with internationalization and localization in mind. Ultimately, it is difficult and expensive to retrofit or “fix” an application that has a single language architecture and design. Internationalization simply touches too many areas of a product to be considered as a one-time feature that can be added to the product sometime in the future.

You can save yourself the expense and difficultly of retrofitting or fixing an English-only product by thinking of the internationalization step as an architectural element rather than a feature. A feature can be readily added to a product often because it has limited scope within the application or has few dependencies. A new feature is often “low-touch” or only lightly coupled with other features or areas of a product. Internationalization, however, often affects all aspects of an application. Areas of the product that involve number, date, time and currency formatting can cut across many areas. Internationalization is a “high-touch” activity that affects most areas of an application because user interfaces, strings, icons and colors, numbers, dates, and time values are used throughout an application. Finding and fixing those areas so that they are internationalized and localizable is an onerous task once the product already exists and is in production.

If you architect your product from the beginning so that localizable elements are isolated from core business logic, you make the localization task easier later. How can you think about internationalization as an architectural task rather than as a feature?

First, understand that internationalization will affect many aspects of your system. Think about all the areas that utilize strings and other localizable resources. The list may be bigger than you first imagined.

Secondly, after identifying those areas, extract those text strings and other resources so that they can be translated independently without touching your application’s source code. Every programming platform has a means of isolating resources from the core application. Learn about that mechanism and use it. Think of this step as creating the generic, language-neutral scaffolding upon which the rest of your application will be built. You want to create a core set of business logic and user interface layout that is independent from language and culture. Later, the language-specific elements can be translated and added onto this core architecture.

Lastly, architect your application to load needed language modules at runtime rather than having them hard-coded into the application. Placing the right internationalization architecture in the product from the beginning costs little in terms of time lines and resources, and it pays off significantly over time when product teams discover that their “English-only” application is now desired in new language markets.

Generating help in multiple locales using Adobe RoboHelp 10

Adobe RoboHelp software is an easy-to-use authoring and multichannel, multiscreen help publishing solution.

Using RoboHelp 10

  • You can deliver content to iPad and other tablets, smartphones, and desktops using output formats such as multiscreen HTML5.
  • Working in multi-author environments using next-generation collaboration and review features.
  • To personalize and optimize content for relevance and search.
  • Easy development of context-sensitive help with usability enhancements.

Adobe RoboHelp 10 supports output formats as shown in graphic below:

 1

The help author has to concentrate on the content and need not to worry about different output formats as it would be handled by RoboHelp itself. They have to simply select the output formats and generate with required options.

 

How to change default Language setting?

RoboHelp 10 is shipped in English, French, German and Japanese locales but the help can be generated in many more languages.

Help authors many a times face such scenarios when they have to generate the output in multiple locales.

When you create a new project the default Project language is same as that of installed RoboHelp.

This implies that the same language is used by RoboHelp to show any text/LNG Strings in the output apart from main authored content spelling checks, and dictionaries and in generating smart indexes. Besides help content there are a lot of default text elements in output runtime user interface of help systems like table of contents, index, glossary, search, no results found etc. This is a big list of such strings which can be there in any help system commonly called LNG strings.

But if you want a different language for these then use can select it from the Project settings dialogue.  For example if you are using French RoboHelp and want Spanish language settings then you can go to “File > Project Settings” and select Spanish from the Language dropdown. Refer to image below:
2

4

3 

RoboHelp provides fine control over language setting and besides project users can define language for a particular topic or even for a particular paragraph.

To change language setting of a topic open “Topic Properties” dialog and change the language from dropdown in “General” tab.

5

 

 

 

 

 

 

 

 

For changing the language for a particular paragraph open the “Paragraph” dialog and define new language from here.

Language defined at the paragraph level takes precedence over language defined at a topic level. Language set at the topic level takes precedence over language defined at a project level. Language defined at the project level can never take precedence over language defined at paragraph level. If multiple languages are defined at the project, topic, and paragraph level then the effective language as per the precedence is used for dictionary or thesaurus association and for spell checking.

Users can change this default language to following 36 languages:

Bulgarian(Bulgaria), Catalan(Spain),Croatian(Croatia), Czech (Czech Republic), Danish(Denmark), Dutch(Netherlands),English(UK), English(US), Estonian(Estonia), Finnish(Finland), French(Canada), French(France), German(Germany), German(Switzerland), Greek(Greece), Hungarian(Hungry), Italian(Italy), Japanese (Japan), Korean (Korea), Latvian(Latvia), Lithuanian (Lithuania), Norwegian Bokmal(Norway), Norwegian Nynorsk(Norway), Polish (Poland), Portuguese(Brazil), Portuguese(Portugal), Romanian(Romania), Russian(Russia), Simplified Chinese (China), Slovenian(Slovenia), Spanish(Spain), Swedish(Sweden), Thai (Thailand), Traditional Chinese (Taiwan), Turkish(Turkey), Vietnamese (Vietnam)   

So it is interesting to note that while we are localizing Adobe RoboHelp in 3 languages, we are enabling our users to create help with ample support in 32 more languages.

Going a step further -> Editing LNG strings for customized needs

While as part of RoboHelp localization we provide LNG strings in 36 languages, users can also modify these strings for any language to suit their needs.

The LNG strings can also be edited for any customization needs. This can be done from File > Project Settings > Advanced button > LNG file tab

6

All the strings are listed in the LNG File tab under different sections like WebHelp, AIRHelp etc. The desired string can be edited by selecting and clicking on Edit button. In this way help authors can also edit the LNG strings to customize existing strings.

 

How to create multilingual WebHelp from RoboHelp? 

  1. Create a project in RoboHelp.
  2. Create separate topics for each language.
  3. Create separate table of contents from above topics for each language.
  4. Also create separate index and glossary for each language
  5. From the Single Source layout (SSL) pod open the WebHelp and click on content categories.
  6. Create new categories by clicking on New button and rename it after any particular language.7
  7. Each content category is now shown as a separate language. Select it and set the language specific Table of Contents, Index, Glossary and language.
  8. 8Now generate WebHelp and open it in browser.
  9. Select any particular language from the category dropdown.

 9

 

Please note that the system you intend to open the localized help should have the locale specific code pages installed.

Authors :-
Sumer Singh – Lead Quality Engineer
Vinay Krishan Sharma – Program Manager

 Adobe RoboHelp homepage

Globalization Myth Series – Myth 4: It Takes 6 WEEKS to Localize a Product!

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

Adobe’s Globalization team is committed to driving continuous improvement in customer experience and improving efficiency.  These are two of Adobe’s areas of focus for 2013.

The top customer feedback we used to receive was that localization of our products needed to be more agile.  The digital video team, for instance, moved to releasing English and localized products in one installer; they needed to sim-GM in order to release quickly and meet the market expectations.  The creative products customers in Brazil and Russia, for instance, were getting tired of waiting six months to get their hands on a localized product.  Like many in the industry, Adobe’s Globalization team began to face pressure to localize with fewer resources, reduce localization turnaround time, and improve quality.

Our challenge is to meet the aggressive release schedules of Adobe’s Clouds—Digital Media and Digital Marketing, their companion products and tools in 20+ languages. Currently, our team uses, roughly, 65% of our resources on Digital Media localizations, and 15% on Digital Marketing localizations (20% is dedicated to Print, tools development, finance, and other initiatives).  The localization team is made up of approximately 150 people—international program managers, international engineers, international quality engineers, and interns located in the US, China, India, Japan, and Romania, supporting approximately 150 product and functional teams.

In this paper we will show how Adobe has been able to accelerate localization and we will, hopefully, debunk the belief that localization takes 6 weeks.  With limited budget, we are meeting expectations, sim-shipping English and 20+ languages for the Adobe Cloud-based products—Digital Media and Digital Marketing– Developer/Web tools, and Touch Apps.  We support any agile workflow and release schedules can be as short as every 2-4 weeks (Photoshop.com, Acrobat.com, Cloud Manager, adoberevel.com), 6 weeks (DPS, AdobeRevel), to continuous releases (CCM) varying from twice a week to monthly.  In these workflows, we can complete a localization cycle as quickly as within 24 hours.  Our ultimate goal?  We are preparing for the day when Adobe products get released multiple times a day!

Sample SCRUM Schedule – Localized product sim-releases in 20 languages every 6 weeks

Slow is History! – Product Team Concerns in the Past and Globalization Team Response

Adobe product development models come in many flavors.  In general, the ‘waterfall’ model was considered standard.   Products such as Photoshop, Acrobat, InDesign, and Illustrator were well-suited for standard localization.  That is, at UI Freeze milestone, the localization team would step in and begin the localization process.  This meant that, by English GM, the localized versions were lagging behind by 4-6 weeks.

This localization model—start localization after UI Freeze milestone—had several drawbacks.  Localization partners got overwhelmed at end game; localization issues were found too late and, when issues were classified as “show-stoppers,” they could jeopardize the product release schedule; many critical defects ended up getting deferred for the next product release.  The model was costly, time consuming, it increased stress and burnout.

With the event of multi-lingual installers, SaaS, Cloud-based products, and new development workflows used by Adobe product teams such as Scrum, Kanban, Scrumban, or Adobe’s own Aphid,  the Globalization team was faced with new requirements which called for a more accelerated localization workflow.  The new business model required that localization should be possible in any locale, be scalable to a large set of languages, and respect various budget constraints.  Product teams started to question whether the localization team was ready to keep up with the pace of the business. The answer was a big “YES, OF COURSE!”

For the sake of comparing two different models, see below a waterfall-model localization schedule and an agile localization schedule from the same period—2004.  The product following the waterfall model on the left, chose to ship single-language versions in a staggered schedule; the one on the right, based on Adobe’s Aphid model, released their product with a multi-lingual installer as a single binary.  At this point in time, Globalization was ready to accommodate both Product Teams.

Waterfall – InDesign                                                                             Agile – Audition

 

With the acquisition of Macromedia in 2005, Adobe Localization faced many new and exciting challenges. Dreamweaver, for instance, ran prerelease programs for all languages, which meant that localization had to be right behind English, at the same level of development, testing, and stability as English. Thanks to the many talents that we acquired and the level of cooperation between companies, we were able to leverage best practices and meet the expectations of the new Product Teams.

In 2007, Adobe acquired Scene7, a software company enabling websites to have real-time rich media; then Omniture, in 2009.  In 2010, Adobe acquired Day Software, a market leader in next-generation Web Content Management.  In 2011, web tool companies such as TypeKit and Nitobi, the maker of PhoneGap; Efficient Frontier, a digital marketing company; and Iridas, the maker of SpeedGrade, a professional color correction application; in 2012, Adobe acquired Behance, the leading online platform to showcase and discover creative work.

All these new cloud-based services demanded improved localization velocity, mostly through internationalization and automation.  Development cycles were short – 2-6 weeks – and updates were frequent and web based. Our team needed to shift focus in order to meet these cloud-based product requirements.

The Globalization team, in partnership with the Product Teams, worked towards an agile localization model.  Here were the first steps we took towards acceleration:

  • Ensured Adobe products were World Ready — created an assessment tool called the Globalization Report Card (GRC) to determine world readiness compliance.
  • Engaged international QE early in the development cycle to test and report internationalization bugs.  With that, international bugs were addressed in a timely manner which helped speed up the development cycle and improve products’ quality.  See “Globalization Myth Series – Myth 2: This software product is only for the U.S.” for evidence on the benefits of addressing internationalization issues at the beginning of the development cycle.
  • Worked cooperatively with the new Development Teams to set common goals and share best practices. This cooperation has resulted in better success rates than if localization were considered as an after-thought and as a different team.
  • Changed the mindset – if we got content EARLY and ITERATIVELY, we would localize software and documentation continuously.  Waterfall-based products started working with the globalization team prior to UI Freeze milestone.  We started localizing glossary kits early and testing localized builds sooner than in the past.  Documentation team started handing off non-final files prior to the usual “screen-shot ready build” milestone.  Localized documentation is now uploaded to the web at the same time as the English product and localization versions ship.
  • Developed more tools – invested in ALF (the Adobe Localization Framework is a multi-tiered system whose primary intent is to automate the localization process and facilitate the creation of localized products), machine translation (takes strings in one human language and automatically translates them into other human languages), World Server (an enterprise translation and globalization management system that enables Adobe to simplify and accelerate our translation and localization processes for any content, from our websites to instructional content to software applications and beyond), tools that helped achieve localization of fast releases nearly in sync with English.
  • Engaged our external localization partners earlier and began growing expertise in those teams. Some of our vendors now are capable of offering turnkey localization services for Adobe products. They have learned our products through prerelease, product demos, and training by our Globalization team.
  • Found new ways to engage with our customers through the Adobe Translation Center, international prerelease, and forums. These customers know our products best, so they can provide early feedback and we can save time in the long run.

With these measures in place, we were able to get closer to the English product schedule and were behind by just a couple of weeks.

Currently, the Globalization team has reorganized internally to manage the localization process for the end-to-end customer experience which includes software, marketing/web content, documentation, internationalization/localization testing, and educational materials.  We are better aligned and more agile, able to support localization for product cycles of 2-4 weeks (Photoshop.com, Acrobat.com, Cloud Manager, adoberevel.com), 6 weeks (DPS, Adobe Revel), to continuous releases (CCM) varying from twice a week to monthly. In order to achieve such challenging schedules, we are turning localizations around in 24 hours at times.

For instance, Adobe Creative Cloud is released with 16 localized components and its schedule today looks like this:

Standard, large projects schedules like Flash CS6, look like this:

Looking Forward — Introducing A.L.A., the Adobe Airport

One of Globalization’s biggest challenges is to meet the aggressive release schedule of Adobe’s Clouds, its companion products, web tools, and touch apps in 20+ languages.

In the same way that planes have to leave on scheduled time, crew and passengers in place, in a continuous flow, so do our localized products, where the crew is formed by International Program Managers, International Quality Engineers, International Engineers and ‘passengers’ are the assets (strings) for translation, from any number of products. The plane may only be going to France (say) or it may be doing stops in numerous countries. The frequency of flights will also vary, depending on demand.

Airport Background

We started out with pilot projects, mostly projects which needed quick localizations at end game.  Our requirements were:

  • Source strings were final and reviewed (proofread)

Our Product Teams’ expectations were:

  • Human translations compliant with Adobe terminology
  • Fast translation
  • No functional/linguistic testing

Note that even though our tool collects strings from multiple products and sends them to the translators, we can guarantee terminology consistency and quality because the strings are first leveraged through World Server; and our translators make use of our glossaries for reference.

The Adobe Localization Airport (A.L.A.)  aims to provide one-hour localization turnaround. Our tool collects strings from multiple products and sends them to the translators. Once translated, the strings are distributed back to their respective products, presto!

 

Turn-Around-Time (TAT)from Q2 2012 to Q1 2013, TAT has decreased from an average of 12.7 hours to 7.8 hours.  Our goal, by end of Q2 2013, is to reach 1 hour TAT or less, should the project require that much acceleration.            

Airport Turn-around-time per language, per quarter

Conclusion

Localization does not take 6 weeks—it takes an average of 7.8 hours.  Our goal, by the end of Q2 2013, is to reach 1 hour TAT or less! This is a myth that we have debunked.  The Globalization tools and initiatives aim to make localization at Adobe even more agile, without compromising our products’ quality as well as customer satisfaction.

____

Credits:

The A.L.A. team—Ajay Kumar, Guta Ribeiro, Joel Sahleen, John Nguyen, and Warren Peet
Jean-Francois Vanreusel
Leandro Reis
Quynn Megan Le

RoboHelp: Recommendation for creating localized Microsoft HTML help which is not fully Unicode compliant

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

Technical help authors can use RoboHelp 10 to create help in multiple formats (like Webhelp, FlashHelp, AIR Help, MultiScreen HTML5 and Microsoft HTML etc.) and locales.

While generating localized Microsoft HTML help (CHM help) with English locale settings using RoboHelp, Help authors might face following issues:

  • CHM Help output is not getting generated
  • The Table of contents (TOC) entries get seen as question mark(as shown in below screenshot)
  • The Topics authored in the Help are not visible when viewed and an error is shown: “This program cannot display the webpage” (as shown in below screenshot)
  • Index for double byte languages may appear garbled

The above mentioned issues are not encountered while:

  • Creating other help formats using RoboHelp10.
  • Generating Microsoft HTML Help in the languages with code page 1252.
  • The languages are English, French, German, Italian, Spanish, and Swedish.

These issues are encountered while:

  • Generating Microsoft HTML help for rest other locales. (e.g. Russian, Japanese, Chinese Simplified and Korean)
  • Even for locales which seems to be similar to English and fall in code page 1250 like Polish, Hungarian, Croatian, Czech Albanian and Romanian

The reason for these issues is that HTML Help is not fully Unicode compliant.

For the help authors who want to generate localized (take Chinese Simplified as example) Microsoft HTML help we would recommend using the following settings –

  1. (Recommended) Change the language for *non-Unicode programs to Chinese (Simplified,PRC). There is no need to change the display language to Chinese as only changing system locale should work. Also keep the project language as Simplified Chinese.

                                                       Control panel settings

                                                   Change current system locale

*language for the non-Unicode programs can be changed from

  • Windows 7 -“Control Panel” >”Region and Language” >”Administrative” >”Change System Locale”
  • WinXPP-SP3-  “Control Panel” >”Regional and Language options” >”Advanced” >”Select a language”
  • WinXPP-Sp3 users’ also needs to install the Simplified Chinese language pack.

2.  If its required to keep English locale settings for some reason (generating help in multiple locales on same machine) then follow the below steps (also refer below screenshots) –

  • Create a new project with FilenameLocation in English and keep project language as Simplified Chinese
  • Create topics with name(Title and Filename) in English and topic content in Chinese Simplified
  • Create TOC and rename the TOC entries to Chinese
  • Index and “See also” also needs to be kept in English

 Step 1

 Step 2

Step 3

We hope that this blog helps our customers facing issues generating Microsoft HTML help in multiple locales. We also endorse other help formats like WebHelp , Flashhelp and AIR help which are fully Unicode compliant.

Mark your calendars: Quarterly Adobe CQ Multilingual Content Intelligence SIG meetup

Attention CQ customers, potential customers, system integrators or Adobe partners:

The Adobe CQ Multilingual Content Intelligence Special Interest Group (SIG) is growing, and they’d love for you to join them!

The next meeting is Monday, Jan 28, 2013, at the Adobe San Jose Headquarters.

Learn more about the meeting here.