An Open Letter to Adobe Translation contributors and subscribers
A few years ago, we envisioned that the Adobe International Community would like to be involved in improving the quality of the products they use. We built the infrastructure that enabled our community to freely contribute feedback, vote on translations, propose new translations, and create new language offerings for some products.
While quality work is never “done”, we feel that we have achieved many of our objectives. Now is the right time to reimagine how we should engage with our Adobe community to support international releases in an agile world, where innovation rules.
On January 31, 2016, we will be closing down the Adobe Translation Center (ref. https://translate.adobe.com/adobe). We would love to receive feedback about your experiences; hear your suggestions for the future; and ideate with you about how to involve the Adobe international community in improving our products.
We give heartfelt thanks to you, our generous international community, for supporting this translation initiative over the years. You have lent your time and talents and shown sincere dedication. For that we are indebted and grateful.
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
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.
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 …
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
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.
This article was originally written in English. Text in other languages was provided by machine translation.
Today we’re rolling out some really cool multilingual functionality in our blog.
Thanks to a WordPress plug-in from Transposh, we are now able to provide translations in various languages for each of our blog posts, which can be easily selected through a simple language-switching mechanism, which you can find on the right sidebar of this page:
Up until now, we tried to reach many of our international customers by maintaining separate blog sites for each language. With the new functionality, we can now serve content in multiple languages in the same location.
For the moment, these are machine translations, which we all know are rarely perfect. But fortunately it’s also possible for readers to contribute better translations (you need to register with us first):
What I find really appealing with this new functionality is that original posts can be in any language, not just English. For example, we have some posts in Brazilian Portuguese, Spanish, Korean and Chinese. These can now be translated into any other available language, including English.
I have seen very few blogs that are multilingual. Our team is certainly the first one at Adobe to do so. Also, I believe we are one of the first multilingual corporate blogs.
I’m curious to see how this will be received by our community of readers. We’re starting with just a handful of languages. If you want to see it in other languages, let us know.
This article was originally written in English. Text in other languages was provided by machine translation.
Do you create multilingual content or apps using Flash Builder? Do you use a localized version of Builder? Why or why not? Do you prefer to develop in English while deploying in multiple languages?
We would like to hear your voice and understand your pain points. Please link to our short survey on Flex and localization so we can understand what is important to you.
Janice Campbell, Flex Localization