Together we’ve successfully created a support network where we can share best practices and challenges using AEM and push each other further in our practice. As a keeper of this space of AEM community, I was very impressed by the commitment and enthusiasm that all of you have shown at the event. There were total 43 attendees from Singapore, Hong Kong, Malaysia, Australia, and United States in the room and 5 members joined us on Connect from the US.
On behalf of the group, I would like to thank you to all of our speakers, David, Angie, Alan and Eli for their leadership to be in service to the AEM community – so much thought, effort and time went in to the presentation that we have received and we are very grateful for that. Special thanks to David for flying in from California just to champion the first event in APAC, and Eli for generously putting together a special SEO session with such a short notice. Lastly many thanks to Therese Harris at Clay Tablet for funding some of the activities. All of you have embodied the true community spirit!
Until we see each other next time, let’s continue the conversations at our Linkedin group.
It’s a known fact that Apple’s two-third of the business comes out of outside United States regions and no company would undermine the value of the business which it is getting from international markets. Keeping that in mind and addressing this aspect even further, Apple has made some latest advancements in the Internationalization support of its mobile operating system iOS 9.
Here are the top 7 features which made the cut to the latest iteration of the mobile operating system iOS9:
Support for RTL – Right to Left Languages
One of the most notable feature of iOS 9 in regard to internationalization was the addition of support for right to left (RTL) languages like Arabic & Hebrew. Using the UIKit framework provided by Apple in its Xcode IDE, you can mirror your icons, text, animations in a jiffy. Furthermore, all those native interactions related to Apple’s OS would also get mirrored like while operating your iPhones & iPads you will swipe the screen from right to left to unlock your screen, swiping of home screens from right to left, navigate back in safari from the right and forward from the left et al.
Apple has gauged the growing demand for its mobile & tablet devices in India and therefore, it extended its keyboard support for some more Indian languages like Punjabi, Gujarati and Telugu. Evidently, the intent here is to capitalize the Indian growing smartphone market by offering some user-friendly features.
Now, Autocorrect in ‘QuickType Keyboard’ (For Japanese and Chinese users)
Apple has made the life easy of all those folks whose native language is Japanese and Chinese by offering them AutoCorrect feature in the QuickType keyboard. They can now simply select the text using the multi-touch feature of the new redesigned keyboard and then can apply the Auto correct feature to straight things up.
This feature will ease up the task of the users who find it challenging to type commonly used sentences a number of times using iPhone keyboard.
Transliteration for Hindi Keyboard
And that’s not all, Apple has also given a treat to its Indian customers by adding transliteration support for Hindi keyboard in which all those users who was not comfortable enough to type in Hindi directly, can now type in English characters and the powerful transliteration system will offer you suggestions by converting them to Hindi. For more detailed information about the last two features, have a sneak peek at the ‘Quick Type’ section at http://www.apple.com/in/ios/whats-new/.
More Keyboards (for French, German, Spanish etc.)
Apart from the Indian languages, the tech giant has also added new keyboards for some other regions like French (Belgium), German (Austria) and Spanish (Mexico).
Switch between number systems for cosmopolitan Dubai
Another important update to users living in UAE is giving them the freedom to switch between number systems. They can choose which number system (Arabic, Hindi) they want to use – so you can use your device in the way that feels most natural to you.
Predictive Input for Fr, De and some more languages
One more addition to the plate is the addition of predictive input for French (Belgium), German (Austria), Korean, Russian, Spanish (Mexico), and Turkish.
After all these updates to the keyboard, dictation and predictive typing system of the iOS, the current support provided by Apple for the world of languages in its mobile devices is demonstrated in the below snippets:
English (Australia, Canada, UK, U.S.), Chinese (Simplified, Traditional, Traditional Hong Kong), French (Canada, France), German, Italian, Japanese, Korean, Spanish (Mexico, Spain), Arabic, Catalan, Croatian, Cz_ech, Danish, Dutch, Finnish, Greek, Hebrew, Hindi, Hungarian, Indonesian, Malay, Norwegian, Polish, Portuguese (Brazil, Portugal), Romanian, Russian, Slovak, Swedish, Thai, Turkish, Ukrainian, Vietnamese
Quick Type keyboard support:
English (Australia, Canada, India, Singapore, UK, U.S.), Chinese -Simplified (Handwriting, Pinyin, Stroke), Chinese – Traditional (Cangjie, Handwriting, Pinyin, Stroke, Sucheng, Zhuyin), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian, Japanese (Kana, Romaji), Korean, Spanish (Mexico, Spain), Arabic, Bengali, Bulgarian, Catalan, Cherokee, Croatian, Czech, Danish, Dutch, Emoji, Estonian, Filipino, Finnish, Flemish, Greek, Gujarati, Hawaiian, Hebrew, Hindi (Devanagari, Transliteration), Hinglish, Hungarian, Icelandic, Indonesian, Latvian, Lithuanian, Macedonian, Malay, Marathi, Norwegian, Polish, Portuguese (Brazil, Portugal), Punjabi, Romanian, Russian, Serbian (Cyrillic, Latin), Slovak, Slovenian, Swedish, Tamil, Telugu, Thai, Turkish, Ukrainian, Urdu, Vietnamese
English (Australia, Canada, India, Ireland, New Zealand, Philippines, Singapore, South Africa, UK, U.S.), Spanish (Chile, Colombia, Mexico, Spain, U.S.), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian (Italy, Switzerland), Japanese, Korean, Mandarin (Mainland China, Taiwan), Cantonese (Hong Kong), Arabic, Catalan, Croatian, Czech, Danish, Dutch (Belgium, Netherlands), Finnish, Greek, Hebrew, Hungarian, Indonesian, Malaysian, Norwegian, Polish, Portuguese (Brazil, Portugal), Romanian, Russian, Slovakian, Swedish, Turkish, Thai, Ukrainian, Vietnamese
English (Australia, Canada, Denmark, India, New Zealand, Singapore, UK, U.S.), Spanish (Mexico, Spain, U.S.), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian (Italy, Switzerland), Japanese, Korean, Mandarin (Mainland China, Taiwan), Cantonese (Hong Kong), Swedish (Sweden), Dutch (Belgium, Netherlands), Norwegian (Norway), Russian (Russia), Turkish (Turkey), Thai (Thailand), Portuguese (Brazil)
Now with the news coming in that Siri would be localized into many more languages and would operate without an Internet connection when iPad Air 3 comes to the market, it certainly acknowledges the fact that Apple has a vision for its virtual assistant to break down all the language barriers. Hoping that Siri would be available in Hindi too, it would be a remarkable experience to hear some Santa Banta jokes from the smart voice-powered Apple’s assistant.
To conclude I would say, Apple has gone to the right way to push out features which may not be so relevant to announce during the unveiling of the OS at WWDC but are undoubtedly needed to support the international markets.
If you made this far, thanks for reading. Please let us know your feedback, comments about this article and if you know something which I have missed here, kindly drop in your comments and I will try my best to respond and take this conversation forward.
If you want me to write on a particular topic then do let me know.
The Multilingual Content Intelligence team at Adobe is excited to host our third Adobe Experience Manager Multilingual Content Special Interest Group (SIG) meeting on Thursday, Nov. 7, at our headquarters in San Jose. Our program this time is on Digital Asset Management (DAM), and we plan to focus on how DAM can be used for multilingual purposes. During the meeting, we’ll also have a Multi Site Manager (MSM) review session to share feature enhancement plans for future releases.
This is a great opportunity to understand basic concepts of DAM and related best practices in a multilingual context. Attendees will also rub elbows with our Adobe experts, share their experiences and challenges, and network with peers from various industry leading companies that are putting Adobe Experience Manager to use.
Date: Thursday, Nov. 7, 2013
Time: 8:30 AM – 4:30 PM PST Address: Adobe San Jose headquarters
345 Park Avenue
San Jose, CA, 95110
Any kind of digital creative content – whether it is a simple newspaper advert, or a large hoarding, or laying out a complicated magazine or a newspaper – comprises of handling text. Creating such a content for regional audience with software not supporting Indian scripts is like driving a left-hand-drive car in India – not comfortable at all.
How does a customer-oriented company like Adobe approach these users in the Indian subcontinent? Internal research shows that users in India are comfortable using English interface for software – what’s really needed is the ability to compose and handle text in Indic scripts, more so in text publication workflows.
While the publishing workflow is largely based on Adobe InDesign and we started supporting 10 of the most popular languages in Adobe InDesign CS6, there was a need to bridge the gap with other publication workflows utilizing Adobe Illustrator and Adobe Photoshop. Adobe did so with the latest release of Creative Cloud products by introducing Indic script support in Photoshop CC and Illustrator CC. Users can now compose their text in 10 regional languages, generate world class print output, and still be within their beloved Adobe environment.
The Creative Workflow
Common workflows in creation of digital content involve extensive flow of content cross InDesign, Photoshop, and Illustrator. Photographs are clicked with the digital cameras and are beautified in Photoshop. These are brought into Illustrator and converted to vector images and are further used as a part of an art work. Small sections of these images (even raster forms) could as well be converted to form a brush stroke in Illustrator CC. A complex artwork including raster images and vector art is finally rendered to print through an InDesign document, which blends this graphic with text stories to give a phenomenal impact to readers.
Such meshed workflows often use text at various places, and the users ought to be able to work with that text whenever needed in the workflow. They don’t want to wait until the artwork is placed into InDesign for them to be able to insert text in regional languages.
Covering the entire flow
As a creative professional, one always wonders if they could do some raster handling in Illustrator, or some type handling in Photoshop, or some vector handling in InDesign. All of these are possible with Adobe software today, and that makes using these three in our publication workflows so very seamless. Not only that, we also want to create that beautiful type effect in Illustrator using Indic characters in our regional language. We want to give titles to our Photoshop banners in our own language. And much more…
With the latest CC release, joining the excitement of the amazing features, Photoshop and Illustrator also provide support for Indic scripts as in InDesign.
What’s more? The overall experience with Indic scripts has been made far richer with a number of bug fixes.
In addition to extending Indic script support to Photoshop and Illustrator, we appreciate the need for Adobe fonts in languages other than Hindi. Well-designed Unicode fonts that support Indian scripts can enhance productivity and cross-compatibility of content created by creative users, including the content creators, the designers, and the editors. We thus took this initiative of providing this beautiful set of fonts, starting with Adobe Devanagri.
Adobe Devanagri was introduced in CS6 timeframe, and has now been extended to include the Marathi script as well.
A completely new font, Adobe Gurmukhi has also been introduced. This will come pre-installed for users to start creating content in Punjabi. Also, fonts for more Indian languages are on their way!
To read about the Indic support in InDesign CS6, please read this article.
Adobe has a long history of developing products for multiple platforms, be it desktop applications like our flagship Creative Suite applications or newer touch applications like Photoshop Touch. Most of our desktop apps have been built for both Windows and Mac and newer applications continue on this trend with support for iOS and Android including Tablet and Phone form factors for both.
Of course this would not have been possible without the careful efforts of the engineering team to largely maintain a single code base for all platforms.
While having a single code base has obvious benefits, in the UI layer it is often important to have platform specific variations for better usability. Each platform usually has a specific convention for referring to system menus, short cut keys and UI elements. For example on a windows platform a UI String could be – “Select a media file via the Browse button or enter a valid pathname.” and the same string for the Mac Platform could be – “Select a media file via the Choose button or enter a valid pathname.”
This means that translatable UI strings may have many variations in the source language depending upon which platform they are intended for. This is what our globalization group usually refers to as ‘Platform Variance’. Localizable strings are essentially multivalued entities. Each localizable string has an identifier and multiple associated values each of which can be selected based on certain criteria. The most obvious and commonly used criteria is the UI locale of the application but it need not be the only one. Platform too can decide the value of a string.
Platform variance support is not just useful for handling terminology differences for referring to system UI elements, it also helps adapt strings for different screen sizes. Modern application are designed for supporting multiple device form factors like tablet and phone with the UI being tweaked for each platform for best user experience. Platform variance in this case can be used to support longer strings for the Tablet view and shorter strings for the Phone view.
Yet another area where platform variance support could potentially be useful is in having different localizable values for a Pro version versus a Consumer version of the application.
However, localizing strings with platform variant data is a problem. The problem is two fold, one is in managing the processes and project schedule to allow for agile localization and simultaneous release for all target platforms. The second aspect is technically supporting the platform variance in both programming libraries and translation tools. Many tools and libraries assume a single value for a source and a target string, but in case of platform variance not only can there be multiple source and target values for a string there need not be a one-to-one correspondence between source and target values. There may be multiple platform variants for a source string that map to the same translated/target value or a single source string may need to be translated differently based on platform for the target locale. For example:
en_US: “Please close the dialog and start over.”
default fr_FR: “Fermez la zone de dialogue et recommencez.”
Windows fr_FR: “Fermez la boîte de dialogue et recommencez.”
Since I am part of the globalization tools team here at Adobe, the remainder of this post I describe the problem more from a technical tools and libraries perspective, drawing from my experience. The process problem is also pretty complex and would probably take a much longer blog post to discuss. In fact there’s a related one already on this blog, see – link.
Platform Variance Support in Libraries
Ideally the globalization libraries/APIs used in the code to manage externalized strings and the corresponding storage formats for the externalized data should have a notion of a platform variant value for each string. There should be a way to request a string value for a specific locale and platform along with a provision to fall back to a default value in case a platform specific value is not specified.
As an example, the Java ResourceBundle API supports selecting a bundle by ‘Locale’, there is no explicit mention of a ‘Platform’, but the ‘Locale’ itself is extensible to support variants. The variant mechanism in the ‘Locale’ can be used for supporting different platforms and there is also a fall back mechanism. At Adobe we have a custom developed cross platform library called ZString for managing externalized strings with explicit support for platform variance.
Platform Variance Support in Translation Tools
Most translation management systems (TMSs) have a one-to-one model of source strings with matching translated strings for each locale. This assumption is behind the architecture of the TM matching algorithms as well as the design of the translation workbench. A typical translation workbench usually offers a side by side view of source and target strings, but only supporting a single source string corresponding to a single translated value.
We are still searching for the ideal solution to this problem. For managing the TMs a possible workaround using existing systems is to have duplicate entries in the Translation Memory (TM) or a separate TM for each platform.
However, translators are still constrained by the view presented by their translation workbench. A possible solution to allow translation vendors to provide platform specific translations is to duplicate all the source strings for each possible target platform. The source value for the default platform can be used as the source value for all other platform unless the application UI already specifies a value for a specific platform in which case that is used. Now the translator can provide different translations for each platform if required. This workaround however seems to be a significant amount of additional work for the translators. Some optimization is possible by translating a single platform first and leveraging translations for all the other platforms.
In an ideal scenario the translation workbench would provide a side by side view of all platform variants for the source string and the target strings. With the ability for the translator to remove variants from the translated string where they are not required and propose variants for the translated string even if the source string does not have any. This would allow translators to work through the source content in a single pass, editing leveraged translations, providing new translations where required and proposing platform specific translated values as appropriate.
An approximation to this ideal view is an Excel sheet with each source string being represented in a row and having a separate column for each platform for both source and target strings. With blank values in a platform column signifying that the default translation is to be used for that platform and non-blank platform entries being used for the platform specific translations.
We are still experimenting to find the optimal solution for our needs, that offers flexibility to translators and yet leverages our investment in existing translation tools and processes. The goal is to be able to support faster agile release cycles with all platform releases happening simultaneously.
I think this is a good forum to ask our blog readers if they have faced similar problems and the solutions they have developed to deal with it.
Front In Bahia – an event focused in web front end tools and programming languages, including the Adobe Edge family of products, Dreamweaver, Typekit. The event will take place in Salvador, Bahia, one of the most beautiful cities in Brazil.
The help author has to concentrate on the content and need not to worry about different output formats as it would be handled by RoboHelp itself. They have to simply select the output formats and generate with required options.
How to change default Language setting?
RoboHelp 10 is shipped in English, French, German and Japanese locales but the help can be generated in many more languages.
Help authors many a times face such scenarios when they have to generate the output in multiple locales.
When you create a new project the defaultProject language is same as that of installed RoboHelp.
This implies that the same language is used by RoboHelp to show any text/LNG Strings in the output apart from main authored content spelling checks, and dictionaries and in generating smart indexes. Besides help content there are a lot of default text elements in output runtime user interface of help systems like table of contents, index, glossary, search, no results found etc. This is a big list of such strings which can be there in any help system commonly called LNG strings.
But if you want a different language for these then use can select it from the Project settings dialogue. For example if you are using French RoboHelp and want Spanish language settings then you can go to “File > Project Settings” and select Spanish from the Language dropdown. Refer to image below:
RoboHelp provides fine control over language setting and besides project users can define language for a particular topic or even for a particular paragraph.
To change language setting of a topic open “Topic Properties” dialog and change the language from dropdown in “General” tab.
For changing the language for a particular paragraph open the “Paragraph” dialog and define new language from here.
Language defined at the paragraph level takes precedence over language defined at a topic level. Language set at the topic level takes precedence over language defined at a project level. Language defined at the project level can never take precedence over language defined at paragraph level. If multiple languages are defined at the project, topic, and paragraph level then the effective language as per the precedence is used for dictionary or thesaurus association and for spell checking.
Users can change this default language to following 36 languages:
Bulgarian(Bulgaria), Catalan(Spain),Croatian(Croatia), Czech (Czech Republic), Danish(Denmark), Dutch(Netherlands),English(UK), English(US), Estonian(Estonia), Finnish(Finland), French(Canada), French(France), German(Germany), German(Switzerland), Greek(Greece), Hungarian(Hungry), Italian(Italy), Japanese (Japan), Korean (Korea), Latvian(Latvia), Lithuanian (Lithuania), Norwegian Bokmal(Norway), Norwegian Nynorsk(Norway), Polish (Poland), Portuguese(Brazil), Portuguese(Portugal), Romanian(Romania), Russian(Russia), Simplified Chinese (China), Slovenian(Slovenia), Spanish(Spain), Swedish(Sweden), Thai (Thailand), Traditional Chinese (Taiwan), Turkish(Turkey), Vietnamese (Vietnam)
So it is interesting to note that while we are localizing Adobe RoboHelp in 3 languages, we are enabling our users to create help with ample support in 32 more languages.
Going a step further -> Editing LNG strings for customized needs
While as part of RoboHelp localization we provide LNG strings in 36 languages, users can also modify these strings for any language to suit their needs.
The LNG strings can also be edited for any customization needs. This can be done from File > Project Settings > Advanced button > LNG file tab
All the strings are listed in the LNG File tab under different sections like WebHelp, AIRHelp etc. The desired string can be edited by selecting and clicking on Edit button. In this way help authors can also edit the LNG strings to customize existing strings.
How to create multilingual WebHelp from RoboHelp?
Create a project in RoboHelp.
Create separate topics for each language.
Create separate table of contents from above topics for each language.
Also create separate index and glossary for each language
From the Single Source layout (SSL) pod open the WebHelp and click on content categories.
Create new categories by clicking on New button and rename it after any particular language.
Each content category is now shown as a separate language. Select it and set the language specific Table of Contents, Index, Glossary and language.
Now generate WebHelp and open it in browser.
Select any particular language from the category dropdown.
Please note that the system you intend to open the localized help should have the locale specific code pages installed.
Sumer Singh – Lead Quality Engineer
Vinay Krishan Sharma – Program Manager
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 –
(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
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.
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.
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 Translationproject 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.
“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.
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
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?
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 …