Posts tagged "globalization"

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.

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

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

Globalization Myth Series – Myth 2: This software product is only for the U.S.

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

In April, we launched our Globalization Myth series by debunking the myth Globalization = Internationalization = Localization = Translation. This time, we will dismantle another urban legend: “This software product is only for the U.S.”

The problem statement(s)

When a new software product is being designed and implemented, we often hear things like:

  • “Our product is in English only, so we don’t need to worry about localization at all.”
  • “Let’s not worry about localization for now since the initial language requirement is just English.”
  • “Let’s get English out of the door first and we’ll worry about localization later.”
  • “We are now only focused on features, not localization.”

Also, in the statements above, the term “localization” is often interchanged with “globalization” and “internationalization”.

This is somewhat understandable, since the United States has historically been both the top producer and consumer of software products, and its main language, English, has been the world’s lingua franca for over a century.

A reality check

Unfortunately, the above assumptions reflect a mindset that produce a significant negative business impact in the long term. They are false from several perspectives:

  • Very often, software products end up being localized. Can you name a commercially successful software product that is not localized?
  • Even if a product is never localized because of its nature – let’s say it’s a developer tool – or because of little market demand (e.g. some developing markets), its internationalization is likely important for two reasons:
    • The content created with the product might need to be localized. Using  Adobe examples, every day many thousands of customers localize text layers of Photoshop documents, magazine articles created with InDesign, text in Flash animations, websites created with Dreamweaver, and rich internet or mobile application created with Flash Builder, into languages Adobe does not localize their products into.
    • Certain regional markets have specific requirements. Again using Adobe products as examples, specific requirements from our customers in India and the Middle East have motivated us to add Indic support and bidirectional features to InDesign CS6 MENA, even though it’s not localized into Arabic, Hebrew or any Indic language. Also, we have included support for Hanko in Acrobat, to reflect the way documents are signed in East Asia.
  • Internationalization becomes more expensive later on. Remember the car engine analogy we provided in our previous myth article? Thus, it’s critical that product development teams understand the various requirements of internationalization, and the technical, resource and time challenges for meeting them as early as possible, so as to prevent costly architecture changes and code re-writes later on.

The higher cost of delayed internationalization 

Various Total Quality Management studies have demonstrated the benefits of addressing issues at the beginning of a development cycle. The same principles apply to Internationalization. The earlier it gets considered in the product development cycle, the better the overall product quality and the cheaper the development costs will be.

As shown in the graphic below, the cost of addressing internationalization during the Design, Coding and Testing phases are respectively 2, 3 and 4 times more expensive than addressing internationalization during the Requirements phase.

These ratios get even worst after the localization cycle starts (factor of 15x if the product is localized into 15 languages) and the costs of addressing internationalization after a product ships can even become astronomical (30 x).

For example, failure to define and design product requirements in the Requirements and Design phases that meet global customers needs will increase the cost of internationalization in subsequent phases (Coding, Testing, etc.) because of additional time product development teams will spend with:

  • Reporting internationalization-related defects
  • Changing or re-writing areas impacted by internationalization, such as those handling:
    • Dates, times, calendars, numbers, currencies, addresses, measurement units
    • User interface strings, which may require the use of libraries providing string externalization, and changes to all string loading code (e.g. one of Adobe’s teams dedicated 1 developer to work 3 months exclusively on this task)
    • User interface elements such as dialogs and palettes, which may require the conversion from using static UI libraries to dynamic ones.
    • Text processing (input, display, output, sorting, searching), which requires the addition of Unicode support – a low level code which requires major re-testing – and may require the adoption of a new text engine, a major architectural change.
  • In cases where internationalization work is performed many product versions later:
    • Getting developers up-to-speed with impacted code which they might not have originally written, often sifting through legacy code that may not be in use anymore.
    • Re-testing impacted areas of the code that were released in previous versions of the product
    • Project management of focused, ‘one-time’ internationalization efforts
  • Responding to requests and questions from affected customers regarding the lack of support for their language (this has to be explained to every new customer)
  • Managing relationships with third-party solution providers who might have provided the missing internationalization support, and with whom the company might have entered a royalty-sharing agreement with

Also, there might be indirect costs that are associated with:

  • Loss of potential revenue from markets that require internationalization
  • Public exposure of the product’s lack of internationalization when third-party developers fill the gap by marketing their own solutions

Examples of international support in English / non-localized products

The best way to illustrate the importance of international support in English-only products is to show examples of products that have done it.

A calendaring application

In the first example below, an English-language calendaring application offers support for the Thai and Islamic calendars, allowing users from Thailand and 17 Arabic-speaking countries to use it.

 

A tag cloud application and a text editor

It’s very important that any application providing text input or display features support characters from writing systems other than Latin, the one English and most other European languages is based on.

In the next example, a web-based tag cloud application with an English-only user interface allows users to write characters from up to 6 different writing systems representing hundreds of languages, by selecting specific fonts.

The desktop-based text editor below supports close to 20 writing systems, meaning virtually anyone in the world can type with the English version of the product.

A travel website

The following, English-UI travel website offers a good example of how currency, date and time formats are correctly adapted for its German users.

The benefits of global design

In summary, product designers should rarely envision their software products as “U.S. only”. There are many benefits to thinking globally from the start:

  • You will be able to meet any new localization business requirements in much less time and with much less cost. When it comes to localization, in today’s globalized economy, it’s often not a matter of “if”, but a matter of “when”.
  • You will be able to sell your products to customers worldwide, as opposed to those living only in the U.S. or in English-speaking countries, even if your product is not localized (yet).
  • Global architecture design and coding is a one-time investment, and it’s a lot less costly than subsequent re-architecture and re-coding.

Our next globalization myth will be published next month. In the meantime, do you have any good examples of internationalized English-only applications you would like to share? Let us know!

See also

Globalization Myth – Myth 1: Globalization = Internationalization = Localization = Translation

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

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.

 

Coming up: Globalization myth series

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

Starting this month, we’ll publish a series of articles on  globalization myths.

If you’ve worked in the Globalization industry long enough, you’ve probably heard many of the myths we are going to describe.

If you’re new or from outside the industry, then we hope this series will help set the record straight.

The first article will be published soon. Stay tuned.