Automation Journey in the world of L10n!!

Automation Journey in the world of L10n!!

Feb’14, Reetika Ghai

Automate

The blog talks about the importance of automation in the world of localization and its increased need in the world of Agile

Paradigm Shift from Waterfall to Agile in the World of Localization

Do you know which is the fastest land animal in the world reaching speeds up to 113km/h?

Over the last two years, there’s been a gradual shift in the Software Development Life Cycle (SDLC) methodology for most of the Adobe flagship products. Product management has moved from yearlong waterfall product development life cycle to sprint-based Agile methodology (based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams).

As a result of changing market trends, we need to reinvent our approach to localization testing to meet the changing requirements of Agile methodology. In Agile, development and test cycles are shorter with quick turnaround time. In localization, test volumes have spikes considering the duration of the sprint cycle of 2-3 weeks. Features require frequent validation across multiple locales and platforms before certifying for a release in a simultaneous release model (sim-GM). In the Agile framework, it’s important to be cognizant of the business goals from localization perspective. I would categorize these in three broad areas:

  1. Time boxed frequent releases to market: With agile most of the Adobe products have at least one release every quarter to a frequency as high as weekly/monthly releases
  2. Increased test scope leading to increased localization efforts: With each sprint the legacy scope to certify LOC build increases
  3. Higher focus on rapid new feature development with simultaneous release to market: Certifying features on N Locale and M platforms in a sprint of 3-4 weeks

These goals create the following challenges for an International Quality Engineering (IQE) team while deciding the scope on the localized builds for localization testing:

    • Ensuring increased test coverage on the new features while balancing the coverage for legacy feature areas
    • Ensuring re-usability of tests across various platform variants
    • Ensuring test accuracy across repetitive scenarios on multiple languages
    • Ensuring faster execution to uncover defects early on
    • Ensure all the features work as expected on all supported platforms and locales
    • Ensure co-existence with different versions of the released product/patches
    • Ensure shipping the product simultaneously in all supported locales across geographies (sim-GM)
    • Ensure optimized test coverage on all the supported locales and platform variants

 

Automation in Agile & Localization

Why automation testing in Localization?

- Multiple Releases in an year

- High volume of testing

- Complexity of Platform: Locale combination

- Improved test coverage leading to better quality

- Scalability

- Faster time to market

- Cost Effectiveness

With these initial thoughts, we proposed to expand the automation coverage of Dreamweaver product features from English language to localized languages in September 2012. Our initial Goal was to attain 45% feature automation coverage on localized builds with respect to coverage on English build on Mac platform.

Gradually we built the feature automation capabilities in the next six months, starting from enabling the automation framework for localization (i.e., added support to the automation framework to run scripts on the localized operating system) to running daily smoke tests on all the 15 supported languages, and eventually having good feature level automation coverage.

Automation is a great way to overcome the above challenges and effectively achieve optimized test coverage on localization builds. With automation, it would be possible to certify incremental creative cloud releases for all the supported operating systems and language combinations supporting the time-bound releases.

With multiple releases to market in a year, manual execution of the repeatable test scope by the localization vendors leads to increased test efforts. The major part of the increased test effort can be attributed to incrementally increasing legacy test scope, i.e., legacy scope is cumulative the sum of all the deliverables in the past of a product and would increase with each sprint. On the other hand, automated tests can be run over and over again ensuring defined coverage across platforms and language combinations, thereby contributing to the overall product quality for the time boxed release. This not only eliminates the test redundancy but also helps in producing faster test results.

Having the legacy area automated would help the localization tester focus manually on the current sprint deliverable, hence uncover defects early in the test cycle.The IQE needs to be cautious in deciding the scope of automation on localized builds. Prioritizing the automation coverage is very important.

With each quarterly release to market, the certification scope of the legacy features set for a product is increasing, leading to amplified repeatable test effort across multiple sprints compared to one time validation in the yearly releases model

Legacy Automation Coverage

Journey into Dreamweaver Automation

DW Localization team has 88% Functional Coverage & 86.5% of conditional coverage w.r.t core coverage of 50% conditional and functional coverage in CC release for MAC!

For adopting product automation in localized languages, our journey stared by answering a few of our initial questions:

  • What features do we need to automate?
  • What will be the sequence of feature automation?
  • What locales should we consider to start with, based on data from prerelease and bug history?
  • What would be the best approach for optimized test coverage in the different locales?
  • In the automation framework, where should the locale specific strings (used in Test scripts) be placed? Or should we pull the strings directly for comparison from the Adobe Localization Framework (ALF) at runtime?
  • How much effort is required for adopting automation on locales?
  • What would be the initial setup required to start automation in the different locales?
  • How much additional effort is required for running automation scripts in localized builds regularly?
  • What will be the hardware needs and the challenge to meet them?
  • What should be the frequency of automation runs (daily smoke, basic feature plan, and new feature plan)?
  • How to have the best execution turnaround time on all locales? What should be the optimization matrix considering fast turnaround time in agile?

Initial 6 months journey into adoption of automation framework for Dreamweaver localization

Time chart

Dreamweaver Automation Framework

Dreamweaver automation is based on the Adobe homegrown automation framework called ‘Jerry’. The framework was developed by the Dreamweaver English QE team. It was written in Core Java, supported by apple scripts and java scripts in the backend, making use of the Dreamweaver’s API exposed by the developers.

DW framework


The diagram depicts the automation workflow:

Step 1: A job ticket (contains configuration details like TC #, Platform, Machine details, language information etc.) is fed into the Pulpo server.

Step 2: Pulpo server primary purpose is machine management and result logging. Pulpo server invokes the test machine based and executes the test automation based on the plan mentioned in the job ticket.

Step3: Once the execution is completed the log/results are copied to the Pulpo server for further analysis.

Step 4: Results are logged to the automation dashboard “AutoDash”

The Jerry framework contains automated test cases grouped under various test plans:

Daily Smokes – Basic test for validation of daily build

Basic Features Plan – Contains test cases of the legacy and new areas covering feature smoke in Test Studio

Acceptance Plan – Contains acceptance and full test pass coverage for features developed in legacy and present release cycle in Test Studio

We started with one iMAC machine dedicated to Dw automation. However, soon after proof of concept was successful, we added one more dedicated machine for automation on localized builds. The above test plans got executed on a pre-scheduled basis across all 15 locales on the predefined execution plan. Job tickets distributed across 15 locales were fed to the Pulpo server either manually or automatically and were triggered on the arrival of new build in Codex. Typically, by the time we arrived at the office, build sanity was completed on all the locales and we were good to share the builds with our vendor partners.

For monitoring and optimization of test coverage across 15 languages, a dedicated execution calendar was followed. Based on the calendar, different automation test plans were executed on various locales/platform combinations on a daily basis. Daily smoke test for build validation were executed, followed by dedicated full feature test pass on the weekends. The execution was pre-scheduled and the test coverage was distributed across locales for optimal results given the time and machine constraints.

Accomplishments & Learnings

Accomplishments

In the Creative Cloud (CC) release, we benefitted from having automated test passes on localized builds across 15 languages:

  • Overall test coverage efficiency improved four folds compared to manual test execution
  • Quick sanity test for acceptance of localization build before passing the build to vendor partners increased efficiency
  • Achieved quick turnaround time for basic feature testing by automation scripts
  • Parallel certification on multiple builds (Patch and Main line builds)
  • More focus on new features development part of the current sprint by the localization functional testers
  • Prerelease build certification completely through automation
  • Built blueprint and Code Sign verification through automation on all locales in 2 hours compared to 32 hours of manual verification

Learnings

  • Support from the core team: It is essential to have the automation blessed from the English team for optimal support. In case of Dreamweaver, we got immense support from the team, especially from Kiran Patil (Quality Manager) and Arun Kaza (Sr. Quality Lead) for driving the automation efforts on localized builds
  • Pilot on automation framework for one Tier 1/double-byte/Cyrillic locales to ensure the framework was robust and would support automation on most of the locales
  • Always document the issues /challenges you face during setting up automation, they always act as a reference point later
  • Ensure core scripts are independent of English strings. In Dreamweaver, updating the legacy automation scripts to make these scripts run on localization was a big challenge, as automation scripts were failing at string comparisons. Aishvarya Suhane (Localization Automation QE) was a great help for writing functions in automation framework and creating a few new scripts for resolving localization-specific issues.

Cheetahs in the world of localization …

Special thanks to Guta Ribeiro for inspiring & mentoring me to write my first Blog & Rakesh Lal for his support.

GALA Webinar on Localization Project Management

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

Manish Kanwal, International Program Manager at Adobe will be conducting a webinar at GALA (Globalization and Localization Associates), which is the largest non profit standards organization within the language industry. The webinar will present insights into the best practices for managing a complex localization project. Additionally, it will elucidate with a case study of a comprehensively large project with engineering teams spread across the globe including, linguistics, reviewers, legal, supply-chain, marketing, customer-support and many more.

Join this webinar to acclimatize what it takes to project manage and localize in demanding conditions, right from the point the product is envisaged until its public launch. Event details are available here, it will be broadcasted on 26 July 11:00 EDT

InDesign CS6…. Welcome to India!

This article talks about the overall objective of Localization in a new market or in business terms an “Emerging Market”. You might wonder, “why that specific word Emerging?” Because of the business opportunity it presents by taking a product to a new market where the demand exists, but somehow the product was not made available.

In the publishing domain, India is still one of the few countries where Print has seen a steady growth. Excerpts from one of the famous research site below:

“Contrary to most other markets in the world that continue to witness an erosion of the print media industry, in India, the sector witnessed a growth of ten percent in 2010 and is expected to continue to grow at a similar pace over the next five years. Rising literacy levels and low print media penetration offer significant headroom for growth, says a FICCI-KPMG report, recently released at FICCI FRAMES 2011 event…………”[Source All About Newspaper, publish date March`2011]

Does this present an opportunity for Adobe to expand in the Print Media space leveraging its one of the most popular Desktop publishing software InDesign®. Yes, but at what cost? Let’s weigh in the cost and benefits.

  1. Over the course of last few years, Adobe India sales force has been meeting Indian customers to understand how InDesign can be made ‘India ready’.
  2. In India, English is quite close to as being the second most spoken language just behind Hindi, giving a leeway to probably still hit the market with an English user interface (UI).
  3. The most talked about area in the frequent customer meetings was the support of Indic scripts in Print and Desktop Publishing Adobe applications. The current World-Ready composers for middle-eastern text included partial support for several Indic scripts. However, a number of bug fixes and product support requirements were needed for Adobe to officially certify and launch the product in India.

The specifics listed above did carve a path for InDesign to see support for Indic scripts in CS6 release. Based on input from the Product Management, the following 10 Indic scripts ranked highest on the priority list to support:

Each of the locales above have a good percentage of Print Media in the Indian market ranging from Newspaper, Magazines, Journals, etc. To support these locales was a tough road ahead since most of these locales use complex character combination, glyphs, hyphenation rules, dictionary support.

Phase 1 of this project included adding dictionary support in InDesign for these locales. We integrated the locale-specific open source dictionaries, evaluated them against competing products (with similar support) spanning a series of script specific test data hand-picked by linguists. The test criteria being:

  • Test maturity and quality of the dictionaries embedded
  • Misspell words intentionally and compare the corrected words
  • Ensure the words in InDesign when copied maintain their sanctity
  • Validating a few language rules, as applicable, such as hyphenation, matras, spellings, etc

Dictionary evaluation did show quite impressive results, allowing us to move to second phase of this endeavor of analyzing InDesign for Indic scripts. After a significant number of complex workflows, a few engineering tweaks along the way, we were able to achieve what we set our eyes at initially.

  • Added dictionaries and spell checkers for the 10 scripts
  • Added Hyphenation for the 10 scripts
  • Bundled 1 Indic font family: Adobe Devanagari
  • Included a script that users can run to set relevant defaults and correctly handle imports from Word docs etc.

Even though we started off this effort as a seed project, codenamed as InDesign Indic 1.0, we were able to achieve more than we shot for. InDesign proved not just compatible for the majority of the locales listed above but offered notable support for even the most complex glyphs.

Switch to the World-Ready Composer, an alternate composition engine, with a single click of indicPreferences.js in Window > Utilities > Scripts panel to explore the Indic world in InDesign. By virtue of basic Indic script support in InDesign CS6, you can now type in these languages and characters would shape and render correctly. And yes, there will be more refinements to the Indic Script support in future releases to come.

Let us know what you think and how you plan to use these features. Please visit here for the complete list of Language support in InDesign CS6.

Contributed by Harpreet Singh (Adobe India)

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

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

1. Purpose of this document
This blog is an outcome of an extensive study undertaken to identify best practices in localization of Flash based content.

Localizing structured content through translation management tools (like SDL WorldServer) can be a simple process. However unstructured content like text appearing in Flash videos is not easy. To add to it, tracking the efficiency of the linguistics becomes all the more difficult for unstructured content.

The blog covers all aspect of Flash localization including creating the English content the right way; so that it becomes localization “friendly”. This should result in cost and time savings; which is multiplied by the number of target languages should yield sufficient dividends.

2. Extraction of Text from a Flash animation

The difficulty of Flash animation localization depends on the globalization level of source – usually English Flash animations. During the localization process, all localizable text is extracted from the source animation, replaced by localized versions and localized strings are modified according to the style guides- including choice of font size, family etc. Occasionally localizable text is not included in the text layers but presented as graphics. Therefore the source animation has to be fixed in the first place to have it ready for localization. As a first step of Flash animation localization is to extract all localizable text from the animation. This is possible by using commercial tools such as “Flash Localization Tool” or renaming source .fla file to the .zip archive (just change extension from .fla to .zip) and extracting all .xml files from “LIBRARY” subfolder of the .zip. See Figure 1 and Figure 2 for more details.


Figure 1 – list of Flash archive with LIBRARY subfolder

Figure 2 – list of text layers in .xml format stored in the LIBRARY subfolder of a Flash archive

Flash native format is a zip archive with defined structure. Having a baisc knowledge of it enables one to easily extract all text layers from the animation. Once done, the only task remains to locate the text within the extracted .xml files and provide the translators with .ini file (if the translation is to be completed by using Trados CAT). Text layers in .xml files can be found surrounded by <characters>Your text</characters> XML tags.
The XML stores the information about font size, family and style (besides storing the localizable text). Most of this information like font family can be easily modified for all text if source font does not support the target language alphabet. For more details about Flash XML file please see Figure 8.

Best Practice # 1:
Never modify texts within text layers with help of action script. It will be difficult to understand script.

3. Pseudo localization
“Pseudo localization” is a process to ensure the animation is ready for localization and all localizable texts is in the text layers only. During this process all strings currently contained in text layers (.xml files) are replaced by pre-defined string, e.g. by “X”. Original .xml files in the LIBRARY subfolder are replaced by modified ones and when this action is completed, render.swf should be played back in Flash player. By playing these renders it is possible to locate any remaining text which was not pseudo localized for various reasons.
Text originally present in the text layers is displayed as “X” in this render. In case there is still any readable text it usually comes from embedded video, graphics or an action script. One can find example of pseudo localization in Figure 3, Figure 4 and Figure 5.

Figure 3 – Example of pseudo localization. All strings except “What’s new” were changed to “X”. “What’s new” is a graphics in Flash animation and thus can’t be easily edited.

Figure 4 – Same screenshot as in Figure “3″ but now localized into Russian. As you can see also “What’s new” is correctly localized. In this case source was fixed and localizable graphical texts were updated to text layers.

Figure 5 – Another example of pseudo localization. Displayed asset is a screenshot from an application and the only editable text is in the upper right corner. In this specific case, it was decided NOT to fake it and leave it in English as the font size was too small

Best Practice # 2:
Apply Pseudo localization to find out any localizable text whichis not in text layers within Flash project. If your project has been globalized ever since the ideal way, pseudo localization can be skiped.

 

4. Text layers in Flash animation
There are many ways to insert text into Flash animation. For example, avoid inserting graphical text (letters as graphical objects) and work with text layers only. If this is the case, DO NOT break text into multiple strings, and keep it in one string only, unless specifically required. Any separation in multiple substrings will result intext segmentation inside .xml file and can lead to loss of context during translation and thus incorrect localization of it’s substring.
In Figure 6 and Figure 7, one can find text “Loyal customers like you save with special upgrade pricing. Adobe Photoshop Elements & Adobe Premiere Elements is now a perfect 10!”
This sentence is separated into two different text layers. Such separation will result into segmentation of strings in the .xml file as well and translator will see them as two separated strings without any relationship between them, see Figure 8.

Figure 6 – “Loyal customers like you save with special upgrade pricing. Adobe Photoshop Elements & Adobe Premiere Elements is now a perfect 10!” text separation into two substrings. On this figure, the first part is visible.

Figure 7 – Second part of text “Loyal customers like you save with special upgrade pricing. Adobe Photoshop Elements & Adobe Premiere Elements is now a perfect 10!”

Figure 8 – Representation of substrings in the .xml file. Every substring is enclosed in the <DOMStaticText> tag inside .xml file.

It is not recommended to split a string into shorter substrings but rather keep them in one text layer whenever possible. Advantages of this approach are:
1. Localized string is well ordered so that localized substrings do not need to be reviewed by native speaker after localization and postprocess.
2. String is not divided into shorter substrings inside .xml file.
Today’s version of Flash allows authors to keep strings with different font family, color, style, size etc. in one text layer. Additionally, there is no need to separate them into several text layers. Keeping source strings in one text layer helps translators and localization engineers to spend less time on translation and post-processing of localized strings in the animation. It also decreases the chance of issues related to word order. In Figure 9 you can find example of complex string (part of the text is in yellow with bigger font) in one text layer.

Figure 9 – Complex string in one text layer only. There is no need to put text in yellow into a separate text layer. With today’s Flash you can create such complex strings.

Best Pratice #3:
Keep the number of text layers within Flash project as low as possible. If any text formatting is required, do it only one text layer (as much as possible).

 

5. Embedded Videos
Many a times, Flash animations may contain embedded videos. These embedded videos can be easily found in Flash object library under “Embedded Video” type, please see Figure 10.
If there are any segments to be localized within embedded videos and only the render has been provided, it will be very difficult and time consuming to localize such strings. In special cases, when the video is carefully analyzed, some text can be “faked“ with small effort.
However, animated text (Figure 11) or static one with moving background is almost impossible to edit and in order to localize this type of source it is necessary to spend many hours to fake just one or two seconds of the final render. The source simply needs to be re-created which increases the effort manifold.
With editable video project file one can modify all text layers inside embedded video and prepare localized versions of those videos.

Figure 10 – Embedded video “soccer.flv” with animated localizable string

Figure 11 – Example of localizable text within the embedded video impossible to fake, text is animated

Best Practice #4:
Embedded videos with localizable texts within Flash project increase the time and effort for localization manifold.
The best way to do is extract all text from Video, localize it, replace all localizable texts and create localized render first. Without editable video file, the only (harrowing) option is to try to fake text within embedded video, which is usually impossible. So DO NOT embed text/assets in videos if you want to localize it. Provide assets and video separetely instead.

6. Screenshot Animations
One can also create an animation inside the Flash project from a series of screenshots. See example of screenshots series in Figure 12 and Figure 13. Text in the screenshots are localizable ones and a source .psd with editable text layer needs to be created initially. Once completed and the text is replaced with a localized version, screenshooting of the localized series can be carried out.
If you have source editable .psd available, please provide it to your localization engineer. Moreover, text effects used in the localized Flash will be identical with those in the source Flash.

Figure 12 – Screenshot series. You can see both preview of the screenshot and also sequence of screenshots in the Flash timeline

Figure 13 – End of the screenshot series in the Flash animation. Text “The Big …” is animated within the series and every screenshot adds one letter of the text into the animation.

Best Practice#5: For any localizable text within a graphics (graphical text), it is important to provide source English assets. If source editable asset is not provided, it has to be re-created by localization vendor first to be able to replace text by a localized version and create render for Flash project. During re-creation of editable source asset some effects can be overseen and hence missed in localized version.

 

7. Buttons & Active Layers
It is vital to keep all buttons with localizable texts as “Movie Clip” type in the Flash project and not to use mixture of different Flash types to simulate button functionality. If button functionality consists of more Flash types, it is very likely that during post processing, the engineers may unintentionally use incorrect alignment of these objects in relation to each other inside certain frame. As a result, this will lead to a functional impact on the flash file, and in some cases, rending it corrupt
An example of corrupted button is described in Figure 14. Here the button consists of graphical text in the yellow box and active layer (shown as a blue frame) which plays role of “clickable” area. You may observe that the box is not aligned with active layer and the left side of this button will not be clickable. Additionally, right side contains an overlapped area which is active which is not correct.

Figure 14 – Corrupted button “What’s new”. Active layer (blue frame) is not aligned with yellow box.

Creating buttons as “Movie clip” will avoid similar issues in Flash animations. Sometimes, modification of assigned action script is required as well.

Best Practice #5:
Active layers outside of button in Flash can lead into misalignment within localized version of Flash. It requires once to resize button and active layer objects with every change in the no. of text characters in the button. Buttons created correctly eliminate potential misalignment risks and decrease the number of button re-sizings by a significant number.

 

8. Flickering
In some Flash players, localized text can exhibit “Flickering“ effect i.e., text is moved by one or a few pixel to left, right, up or down when the cursor is hovered over it. See Figure 15 for more details.

Figure 15 – Flickering in detail – the image is composed from two screenshots of the same part re-captured after few seconds later to see one pixel position changes

The only way how to fix the „Flickering“ issue is to convert text layers within localized Flash project into curves and render into final format. Graphical text (curves) doesn’t show the “Flickering“ effect any more

Best Practice #6:
Flickering effect is visible in some players only. It is recommended to use Flash players without Flickering effect. Otherwise, localized text layers have to be converted into curves before rendering into final format. When multiplied by number of target languages, effort will turn out to be huge.

 

9. Acknowledgements/Credits

This document was prepared from an independent study done in Photoshop Elements 11 by Jakub Škrabal & Petr Knápek from Moravia, and Akulaa Agarwal & Manish Kanwal from Adobe.

Please note that it can be applied to any Adobe/Non Adobe projects requiring localization of text and other assets in Flash files. For any questions, please feel free to reach out to Akulaa Agarwal(akulaa@adobe.com) and Manish Kanwal (mkanwal@adobe.com).

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.

 

A lightweight auto-complete ActionScript example with a trie

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


Auto-complete functionality is used widely over the internet and mobile apps. A lot of websites and apps try to complete your input as soon as you start typing. In this post, I would like to introduce a simple ActionScript auto-complete solution by using trie data structure.

A trie is an ordered tree data structure that is used to store an associative array. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Starting from the root node, you can check if a word exists in the trie easily by following pointers corresponding to the letters in the target word. Trie is a well-known data structure in computer science; you can find the detailed information about trie through Wikipedia.

Here is a simple trie implementation in ActionScript:

/**
* An simple data structure to store and look up words.
* @see http://en.wikipedia.org/wiki/Trie for additional details.
*/

public class Trie {
private var _rootKeys:Array;
public function Trie():void {
_rootKeys=[];
}

/**
* Return a list of words which have the given prefix.
*/

public function get(prefix:String):Array {
var results:Array=[];
var letter:String=prefix.substr(0,1);
var root:TrieNode=_rootKeys[letter];
if (root) {
getWordList(prefix, 1, root, results);
}
return results;
}

/**
* Add a word to the object which can be matched as a prefix.
*/

public function add(word:String):void {
var letter:String=word.substr(0,1);
var root:TrieNode=_rootKeys[letter];


if (!root) {
root=createNode(letter);
_rootKeys[letter]=root;
}
insertWord(word, 1, root);
}


private function traverse(root:TrieNode, results:Array, prefix:String):void {
if(root.children) {
for each( var c:TrieNode in root.children ) {
var node:TrieNode = c as TrieNode;
if( node.word ) {
results.push( prefix + node.value);
}
traverse(node, results, prefix+node.value );
}
}
}


private function getWordList(prefix:String,
position:uint,
root:TrieNode,
results:Array):void {
var letter:String=prefix.substr(position,1);
var child:TrieNode=root.children[letter];
if (!letter || !child) {
return;
}


if ( position<(prefix.length-1) ) {
getWordList(prefix, ++position, child, results);
}else {
if (!child.word) {
traverse( child, results, prefix);
}
}

}


private function insertWord(word:String,
position:uint,
root:TrieNode):void {
var letter:String=word.substr(position,1);
if (position==word.length || !letter) {
return;
}


var child:TrieNode=root.children[letter];
if (! child) {
child=createNode(letter);
root.children[letter]=child;
}


if (position==word.length-1) {
child.word=true;
} else {
insertWord(word, ++position, child);
}
}


private function createNode(letter:String):TrieNode {
return new TrieNode(letter,false);
}
}

Format date and time in non-Gregorian calendars

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

Although the Gregorian calendar is the most used civil calendar, there are other calendars used in different countries and regions.

Islamic calendar is used in many Islamic countries and it has quite a few variances. Japan uses the imperial calendar which identify the year with an era name(年号, nengō) and a number. Thailand uses a calendar that counts in the Buddhist era.

With flash.globalization package, you can easier format a date in non-Gregorian calendars. See the code below.

Difference between Flex SDK’s Matching Collator and Sorting Collator

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

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

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

Here is an example:

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

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

 width=

 width=

 width=

The difference in sorting

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

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

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

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

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

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

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

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

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

The difference in matching

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

  • naive

Yes, only one string with a SortingCollator class.

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

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

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

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

References

The example program used in this article

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

The Adobe Globalization Blog

This article was originally written in English.

 

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.

Enjoy
The Adobe Globalization Team