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

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

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

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

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

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

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

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

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

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

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

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

Waterfall – InDesign                                                                             Agile – Audition

 

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

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

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

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

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

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

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

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

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

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

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

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

Airport Background

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

  • Source strings were final and reviewed (proofread)

Our Product Teams’ expectations were:

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

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

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

 

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

Airport Turn-around-time per language, per quarter

Conclusion

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

____

Credits:

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

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

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

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

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

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

The above mentioned issues are not encountered while:

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

These issues are encountered while:

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

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

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

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

                                                       Control panel settings

                                                   Change current system locale

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

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

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

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

 Step 1

 Step 2

Step 3

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

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

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

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

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

Learn more about the meeting here.

 

 

Ready For The Community: Adobe Translation Center (ATC)

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

A single gateway into Adobe’s Community Translation “universe”

November 2012 marks the month when Adobe’s Globalization group is launching the “Adobe Translation Center” (ATC) at translate.adobe.com. For Adobe’s customers and fans, ATC will be the single access point to provide feedback and improvement ideas for existing translations in “Adobe languages”, the shipping languages of an Adobe product. At the same time, the center will also be the place where our vibrant and growing translator community explores – in a collaborative fashion – opportunities for “community languages”: Languages that are in high demand by their speakers, but not delivered as part of our product offerings.

ATC Landing Page

ATC landing page

So far, our community translation “universe” consists of two planets, reflecting its current two main focus areas:
Adobe Translation Center
itself is now offering functionality allowing fans to collaborate on user interface (UI) translation (formerly this has been available through Adobe Translator). The activity around UI translation has been growing quickly, supported and used by several hundred contributors.
The Adobe TV Community Translation project is ATC’s very successful bigger twin: More than 2,500 translators have already translated subtitles for more than 14,000 minutes of video to make educational, entertaining, and helpful content available in a growing number of languages.

Not too long ago …

In November 2011, this blog presented the success case of how fans and users enabled Adobe Business Catalyst (BC) to ship with an additional language UI in Dutch, entirely translated by the BC partner community. The motivation driving this effort was the interest to better serve the partners’ customers in that language (BC with Dutch UI).

Since then, the ATC product team has been busy at work and put a significant effort into improving the Translation Center’s “look & feel” and its functionality. Entering feedback and translation suggestions is now possible intuitively and in a visually pleasing interface that follows the overall Adobe.com experience. As with all Adobe products, agile development methodologies are allowing the team to react to user feedback: Even though ATC is now launched, we still consider it to be “work in progress” (as opposed to “set in stone”) and are eager to hear what the community desires in order to be more productive or to have a more delightful collaborative translation experience.

Product Explorer

Product Explorer

“Community Translation” at Adobe

At Adobe, community translation refers to the process of enabling our users to translate content in a collaborative environment, assisted by professional translators or moderators. Types of content available for community translation today are videos (through Adobe TV) and software user interface (through the functionality within Adobe Translation Center). In the future, we expect community translation to expand into areas like documentation or user forums.
Ideally, collaboration and interaction between contributors should make community translation a rewarding and fun experience. We are confident that our tools will contribute to such an experience, so that lively and passionate communities will be developing and thriving around them.

Why does Adobe promote community translation?

Adobe has a long history related to localization and globalization. Our products are reaching people all over the world and allow them to express their creativity, regardless of their native language or the locations where they live and work. No matter what language we are using, when speaking to our users, we are always deeply impressed, how important our products are for them and with how much passion they speak of them.
At its core, Adobe is a company as international as our users. We have offices around the world, and in all our teams worldwide one finds colleagues from all over of the globe: The desire to serve all our international customers with excellence, is deeply engrained in ourselves and is reflected in our daily work.

Adobe’s community translation program is one means to get another step closer to the goal of shipping “world-ready” or “truly global” Adobe products, based on demand expressed and input provided by our customers and user communities around the world.

Lightroom Polish

Lightroom Polish project

Why is Adobe building the Adobe Translation Center?

In the past, Adobe pioneered a few community translation programs, resulting in great responses from our users. After a series of pilots, we are now beginning to unify all of Adobe’s community translation efforts in a single place: Adobe Translation Center (ATC).
With engineers, user experience designers, and product managers, ATC has a dedicated product team whose goal it is to provide the best experience for translators from different communities. Building and maintaining such a platform represents a sizable investment for Adobe. However, we believe that the long term gain resulting from a better understanding of our international users, will be worth the effort, time, and investment.

Benefits of community translation

The cooperation between Adobe and its trusted professional translators has been working very well for many years now. This joint effort will continue to be a cornerstone of Adobe’s international success. However, there are some aspects of product translation where the involvement of the user community might have advantages over traditional workflows or may lead to something new altogether.

Feedback and translations through people using our products every day

It is impossible for professional translators to be experts for all products or areas they are translating for. While the professionals’ work for sure will always be correct, the everyday product user might – from time to time – have an edge to provide up-to-date translations.
In the past, we have experienced that a few translations in our products do not reflect the prevailing use of terms by our customers. In this area, we want to use the opportunity to make our translations match our users’ needs and expectations. With similar intent, we are leveraging mechanisms like community voting or commenting, so that translations match the expectations of the community at large and we are not representing isolated feedback.

It is important to note that there will be no “automatic way” for a community translation to enter the final product with review: In order to maintain the quality our products are known for, there will always be trusted moderators and reviewers close to the community who make the decision which string is ready for inclusion in the final product. By the way, only with the help of our partners on the professional translation side, will we be able to achieve scalability and support for the numerous community languages.

Evaluation of more Adobe product languages

ATC Lightroom

ATC Lightroom Page

Historically, Adobe has shipped in languages that have been representing our core markets: North America, Europe, Japan, Asia. That is a good number of languages already. With now the entire planet as the potential market-place for our products, however, we are constantly facing the question which languages to ship our products in. Currently, it is not possible to translate into all languages of the world due to logistics, cost, and incomplete information about addressable market size.
It is exactly the question which language to take on next, where community translation will help finding an answer by reversing a common mechanism: Instead of having to make assumptions about market sizes and demand for translated products before we ship them, ATC is empowering our users to indicate which languages are important to them and, hence, to us: Community membership size and translation speed for a product language, will be crucial indicators.

Shipping product languages vs. candidates for new languages

There are two different groups of languages which we are making available for community translation:

“Adobe languages” are all languages that are current shipping within a product. For “Adobe languages”, users can provide alternative translations if they discover typographic errors, if a string is too long or clipped, or simply, if they would prefer a different translation over the one that is currently appearing in the product. In our tools, shipping languages will usually appear as 100% translated and reviewed in our tools. Nevertheless, Adobe is looking forward to the community providing us feedback for those languages.

“Community languages” are not shipping with a particular product and we we make them available for community translation. For those languages, there can be different reasons why we are adding them to ATC: A passionate user community that we are aware of in a particular country, or repeated user requests to have a product available in their language, or business reasons on the Adobe side.

Full disclosure: To be perfectly clear, a “community language” which is 100 percent translated by a passionate community will not automatically be shipping with a future version of the product. The business decision which languages to ship, will remain the sole responsibility of the products’ stakeholders. Both the community and Adobe Translation Center team will always have to defer the final decision to the product team.

Why would users engage in community translation?

Lightroom Translation

Lightroom Translation

Users who participate in Adobe’s community translation program have a chance to get involved in the development of their favorite tools. They can directly affect the translation of a product through submitting suggestions.
And even if the translation into a specific language has already been completed, users will continue to have a channel to express their opinion (about translation quality). Or they can help us improving the product through reporting localization bugs in a convenient interface, without the need to go through complex bug reporting systems.

By joining the Adobe community translation program, users will strengthen their local community’s role and impact. In return, they will receive more attention. and, moreover, they have a good chance of influencing the future of an Adobe product, maybe even beyond localization support.

Community translation is already a common way for many companies (Adobe’s peers in the software industry among them) to explore new ways to interact and engage with fans, users, and customers. For Adobe, that type of interaction is one way to better hear the voice of our customers.

We strongly believe that our products will continue to improve because we intend to listen to that voice …

Please visit (and “like”) our Facebook page or start following us on Twitter.

 

Acrobat XI Ships with Improved Middle East Language Support

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

I am pleased to announce that Acrobat XI shipped earlier this month. The Acrobat development team worked hard to provide an improved level of support added for Middle East languages.  Below are details of the additional ME support provided in this release and how you can test drive and use it. We welcome your input, please post any feedback in the comments.

Rob Jaworski, International Program Manager, Acrobat

 

There are four main areas of improvement to Acrobat’s support provided to Acrobat XI: 1) minor editing, 2) Web Capture, 3) improved search functionality, and 4) Hindi/Farsi digits in Annotations.

In order to use these improvements, make sure Arabic and Hebrew language support has been installed.  On Windows 7 and Mac OS 10.x, all language support has been installed by default. You can simply install Arabic and Hebrew keyboard and set the OS format and regional setting as desire.  On Windows XP, if not using the localized Arabic and Hebrew OS version, you may need to install the right-to-left language support from the regional setting control panel in order to have Arabic and Hebrew font and keyboard available.

If you purchase and install the MENA version of Acrobat XI (I.e. English with Arabic support, English with Hebrew support or North African French) on the system, then Acrobat should launch with all the necessary MENA support options already enabled. However, if you purchase Acrobat XI in other application UI languages, the ME support can also be seen or tested by having the necessary options turned on manually.

Here are more details about the improved support for ME languages.

  • Minor Editing– Middle East support has been added to the minor editing feature in Acrobat XI, formerly called the TouchUp Tool. You can newly add or make simple edits to Hebrew and Arabic text on a PDF.  The feature is designed to handle digits, ligature and right-to-left text direction.
    • Before you start adding new ME text or editing existing ME text, make sure the ME support options are enabled.  Go to Edit menu (on Windows) or Acrobat menu (on Mac), select Preferences.  Click ‘Language’ category and verify the section “Editing Text in Middle Eastern Languages” as follows:
      • Main paragraph direction should be Right To Left
      • Ligatures is checked, if needed
      • Hindi Digits is checked, if needed
      • Enable Writing Direction Switching is checked
    • Open a PDF document and open the Tools pane.  Select ‘Add Text’ under Content Editing.  Switch keyboard to Arabic or Hebrew, mouse click on a PDF and start typing text.
    • Open a simple Hebrew or Arabic PDF document.  Open Tools pane.  Select ‘Edit Text & Images’.  Bounding boxes will be on drawn on the editable text. Switch keyboard to Arabic or Hebrew, mouse click at the text to perform a minor edit.
  • Web Capture– Users can use Acrobat XI to convert web pages, HTML files, or plain text files with either Hebrew or Arabic content into PDF documents.  The conversion can be performed via the plug-in buttons available within the supported browsers, i.e. Internet Explorer (Windows Only), Firefox (Windows/Mac) and Chrome (Windows Only).  The text will appear in the correct script and layout, and the output PDF can then be shared for review with other users using the existing Collaboration features.
    • Open an Arabic or Hebrew web page in a supported web browser.  If the Adobe PDF plugin is installed properly, the ‘Convert’ button on the menu bar should be available.   Click Convert to create a PDF from the web page.
    • Alternatively, within Acrobat, select File > Create > PDF from Web Page.  On the Create PDF from Web Page dialog, enter the URL and customize the settings via ‘Settings…’ button.   Specify the file type, language encoding, font setting and page layout.  Click OK to dismiss the setting dialog and click ‘Create’ to convert the web page to PDF documents.
  • Improvement in Search– In the ME version of Acrobat X, the “Ignore Page structure” option under Search preference has to be checked in order to search for ME text on a tagged PDF.  When the option is selected, it not only takes effect to bi-directional scripts but it could produce the irregular drawing for other scripts and could also produce inconsistent search index files, which results in various compatibility problems.  In Acrobat XI, the issue has been addressed by having the necessary implementation that is limited to ME scripts only and having search for ME on a tagged PDF enabled all the time without having to enable any option.
    • Open an ME tagged PDF.  Perform search for ME text using the regular search options available.
  • Hindi/Farsi digits in Annotations– In earlier releases of Acrobat, users are not able to enter Hindi or Farsi digits inside a pop-up note annotation before.  In Acrobat XI, the issue has been addressed to allow an Arabic user to determine the digits used in a pop-up note by using both OS format and current keyboard setting.
    • The digits used in a popup note are determined by both OS format setting and current keyboard.

Arabic Digits: 1, 2, 3, 4, 5, 6, 7, 8, 9

Hindi Digits: ۹ ، ۸ ، ۷، ٦ ، ٥ ، ٤ ، ۳ ، ۲ ، ۱

Farsi Digits:  ۹ ، ۸ ، ۷، ۶ ، ۵ ، ۴ ، ۳ ، ۲ ، ۱

1. Under Arabic format setting (e.g. Arabic (Egypt) or Arabic (Saudi Arabia)):

(On Windows 7, Control Panel > Region and Language > Format = Arabic (<region>), select Additional Settings… and choose a standard digits = either Arabic, Hindi or Farsi)

Scenario (1)

When using English keyboard, then apply Arabic digits (1, 2, 3, 4, 5, 6, 7, 8, 9) in a popup note

Scenario (2)

When using Arabic keyboard, then digits display in a popup note…

A – Follow Standard Digits settings (Arabic, Hindi, Farsi)

B – If Standard Digits NOT set to either Arabic/Hindi/Farsi, then Hindi digits apply

2. Under English format setting (e.g. English (United States)):Arabic digits (1, 2, 3, 4, 5, 6, 7, 8, 9) will always be used no matter what current keyboard or standard digits settings are. Under this environment, a user can have digits displayed in Hindi by, under Region and Language > Additional setting, select ing Standard digits = Hindi and Use native digits = National.

“New York Times” estuda lançar página na internet em português

O Jornal Folha de São Paulo deste domingo (16.09) noticiou  que o New York Times está estudando fazer uma página do jornal em português. Os principais argumentos são porque o nosso idioma é o quinto mais usado na internet e a elevação do poder de compra dos consumidores brasileiros. Leia mais em

http://www1.folha.uol.com.br/mercado/1154124-new-york-times-estuda-lancar-pagina-na-internet-em-portugues.shtml

Adobe Type Community Translation

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

Earlier today the Adobe Type team launched a new pilot program for Community Translation. This program is aimed at getting translations for Adobe’s typeface notes and will reward contributors with free fonts. The team will be using the Adobe Translator application to get translations for approximately 400 typeface notes (also referred to as typeface histories). These typeface notes provide users additional information about the typeface and often include information about the history of the typeface. On average, these typeface notes are about 100 words in length.

Continue reading…

Using system fonts in Flex based applications

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

When working with Flash based applications, there are issues with fonts since the specified fonts might not exist on the user machine. The problem is compounded when you have international users each of whom might be working on multiple operating systems (Windows, Mac), multiple versions (Win XP, Win7, Win8, Mac 10.6, and Mac 10.7), multiple locales (French, Italian, Spanish, Russian etc) and thus having different available system fonts. One option to streamline the experience would be to embed fonts – entire fonts or specific subset of characters from a font. The other option would be to use the operating system’s default fonts.

Adobe’ installer and licensing components (which goes out with Master Collection and almost all point products like Photoshop, InDesign, and Illustrator) uses the later approach. The component identifies user’s locale from OS locale and then picks up a font from a prioritized list of pre-defined list of fonts for that locale. The font specification file has been externalized so that any future changes around font names could be easily verified and accommodated without making a code change. Further the list has been segregated based on font fall-back for text appearing in software UI and for text fields in the application.

The list of fonts for each locale is listed towards the end of this blog post. Getting to this list has not been an easy task and there has been a huge effort from multiple teams for this. Some of the hurdles that the team had to clear were –

  1. Getting an exhaustive set of fonts used in each locale and OS
  2. Segregating the fonts according to UI and Text fall-back
  3. Putting those fonts and fall-back logic together in an xml file
  4. Identifying the font’s priority so that same logic works across all OS platforms and versions
  5. Working with linguists to test each screen with applied fonts for readability and aesthetics
  6. Iterating #3 and #4 based on linguist’ response and ultimately arriving at final font fall-back xml file
Locale UI Font Fall-back Text Field Font Fall-back
Japanese Hiragino Kaku Gothic ProN W3, Hiragino Kaku Gothic Pro W3, Meiryo UI, Meiryo, MS UI Gothic, MS Gothic, _sans Hiragino Kaku Gothic ProN W3, Hiragino Kaku Gothic Pro W3, Meiryo, MS Gothic, _sans
Korean AppleGothic Regular, Malgun Gothic, New Gulim, Gulim, _sans AppleGothic Regular, Malgun Gothic, New Gulim, Gulim, _sans
Chinese Traditional Heiti TC Light, Lihei Pro, Microsoft JhengHei, MingLiU, MingLiU_HKSCS, _sans Heiti TC Light, Lihei Pro, Microsoft JhengHei, MingLiU, MingLiU_HKSCS, _sans
Chinese Simplified Heiti SC Light, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Song, _sans Heiti SC Light, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Song, _sans
Russian, Ukrainian Lucida Grande, MS Sans Serif, _sans Lucida Grande, MS Sans Serif, _sans
All others * Lucida Grande, Segoe UI, Tahoma, _sans Lucida Grande, Segoe UI, Tahoma, _sans

All others include French, German, Spanish, Italian, Brazilian Portuguese, Netherlands, Swedish, Danish, Finnish, Norwegian, Czech, Polish, Turkish, Hungarian, Romanian, Slovenian, Slovak, and Croatian.
P.S: These font fall-backs were defined and tested for Flex 4.5.1 SDK with Spark components (using TLF, Text Layout Framework)

One caveat to note here is that system fonts keep changing from time to time, which usually amounts to new fonts, or new versions of existing fonts, but sometimes results in existing fonts becoming deprecated. In general, though, linguistic support in OSes, in terms of glyph coverage in bundled fonts, gets better, not worse.

Globalization Myth Series – Myth 3: Language support should be limited to the official language(s) of a country

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

Problem statement

In the globalization field, we often observe cases where companies mix up the usage of countries and languages when delivering products to their global customers. Assumptions are often made that people living in a country should receive services in that country’s most common language(s) – such as – Japanese in Japan, English in the United States or Russian in Russia. Good companies will even support multilingual situations like Belgium and Switzerland, which support multiple official languages – but is it really enough?

In this blog article, we argue that the concepts of “Country” and “Language” should be treated apart – even though they are related.

Languages have no borders

Historically, languages have spread around the world through immigration, invasions and colonization. This is why Spanish is spoken in South America, English in the United States, French in Senegal and Canada – just to name a few examples.

Languages haven’t been limited to their homelands in a long time. For example, Spanish and Portuguese have spread to the point where most of their native speakers are found outside the Iberian Peninsula. Only 8.95% of Spanish speakers are actually Spaniards [1]. We could argue that there are different flavors of Spanish, Portuguese or French, but, in essence, these languages are the same and they are not confined by country boundaries.

Twitter is a great tool to visualize languages spoken around the world. Eric Fisher created a cool language map using Twitter data [2], which clearly shows borders being redefined. Catalan appears on the map and multilingual countries like Belgium disappear under France and The Netherlands.

Map of languages as used with Twitter

Figure 1: European Language Map – Author: Eric Fischer

Official languages leave some major gaps

Many companies launch products/services in a country and limit localization and features to the official language(s) of that country. In software, a typical example is to create a new product for the American market and limit functionalities to English-speaking users’ needs. But this is usually not enough – even if the market is limited to the United States.

Recent U.S. Census data shows that 60 million (or 21%) of Americans aged 5+ years old speak another language than English at home. Spanish takes a big part of the pie with 25 million, but languages like Chinese, Tagalog, French, Vietnamese, German and Korean are each well above the 1 million speakers mark [5]. This is very understandable considering the immigration history of the country.

In addition, the U.S. welcomed 59.7 million international visitors in 2010 [6]. Of those, 33.4 million were from Canada and Mexico and 26.4 million from outside North America. Knowing that these foreigners spend on average $4,000 during their stay, this market segment shouldn’t be ignored.

Using the Greenberg’s index, which measures the probability that 2 persons in a country would speak the same language, The Economist shows that language diversity is happening in all countries around the world and, especially, in nations other than the United States, Russia and China [7]. Also, Ethnologue.com is an excellent source of data around language adoptions.

This diversity is also visible in Adobe’s analytics. Thanks to the Adobe Digital Marketing Suite and our Dynamic Language Delivery technology, we are able to capture the languages in which our worldwide customers would like to receive products and/or documentation. Figure 2 shows the language requests for Adobe Nav in the United States. Data collected with this small application basically confirms the diversity of the population in the U.S since languages such as Spanish, Arabic, British English, Korean, Simplified Chinese, Traditional Chinese, Dutch, Russian and Turkish are all requested by users located in the United States.

Languages expected by DLD users

Figure 2 – Unsatisified language requests for Adobe Nav in the United States

Language diversity in any country is the chief reason why software products should be developed with a global audience in mind. Even if the user interface or documentation is left in English, desktop, web and mobile applications should at least be able to input, display and print characters for most languages.

Similarly, we have been able to capture data about the preferred languages on Adobe.com. This data confirms that countries and languages are two separated concepts – and while most customers from a country read the content in an official language, a big chunk of visitors still prefer to read the content in a different language. For example, with the Action Script Reference (ASR) guide, we noticed that, in Russia, only 68% of the Flash developers prefer reading the documentation in Russian versus 31% in English (a non-official language) and 1% in other languages. Similarly, numerous Flash developers outside of Russia choose to read the ASR documentation in Russian (See Figure 3).

Distribution of Russian Action Script Readers around the world

Figure 3 – Country distribution of Action Script Reference read in Russian language

This is another example why assumptions between countries and languages shouldn’t be made.

As people continue to become more mobile, it is critical to separate the concepts of country and language. This mobility is what spread languages beyond borders and creates the need to have languages supported everywhere.

A language is a customer preference, which can’t be constrained by country borders.

Consequently, if languages don’t have borders, flags shouldn’t be used to represent them as often seen on web-sites. Flags are meant to represent political entities [3]. A common example is to represent the English language with the British “Union Jack”. But it’s not culturally sensitive for English speakers from Australia, India or United States. Some have addressed the problem by mixing multiple countries’ flags into one although it’s making the situation even more confusing. The flag below (Figure 4) represents the German language (spoken in Germany, Austria and Switzerland) and we can imagine how convoluted the Spanish language flag would look like since Spanish is the official language in 14 countries [4] and spoken in many more!

Using flags to represent languages can become complex

Figure 4 – Flags and Languages (WikiMedia)

Take-Aways

In summary, we offer 3 take-aways to consider when launching a product globally:

  1. Differentiate the concepts of “country” and “language”. As such, don’t use flags to represent languages.
  2. Don’t limit support to the official language(s) of a country/region. Some languages may need to be supported even though they don’t have official status.
  3. Languages don’t have borders and need to be supported globally. Capture users’ preferred language(s) so you can serve them in their language independently of their location.

References:

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