Author Archive: Dirk Meyer

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.

 

Collaborative Translation Helps Adobe Business Catalyst Add New Languages

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

Adobe’s Business Catalyst product is a hosted, “all-in-one” solution for building and managing business websites (see also Wikipedia.org). Out of the box, Business Catalyst (BC) provides support for five languages: In addition to English, it is being shipped in French, German, Spanish, Swedish, following the demand of its major and most important markets. A crucial role in the BC business model is played by the “partners” or “resellers”, who use the product to customize websites according to the needs of their customer groups.

In the past, BC continued to receive feedback from both their customers and their own sales organization that there was a high demand for more languages. The addition of such languages would enable the partners to start selling their business websites into more countries than are covered through the out-of-the-box languages.

Despite the partner feedback, the demand and the business case for new languages was difficult to measure or quantify for the BC team. In that situation, BC decided to use a new and  evolving infrastructure available at Adobe to leverage “community translation” in order to validate demand before committing to changes. Before we go into details, first some information about the initiative’s success and the surprising response that it received in some cases.

Initial Successes

It was just in June, that the five original Business Catalyst languages were posted publicly on a community translation site for user review and translation suggestions. For participants in the pilot, the tool to use was “Adobe Translator” (AT), an application giving them access to the BC interface strings and their translations. In addition to reviewing the “legacy” languages already included in the product, the community was given the opportunity to provide translations for additional languages. Initially, those included Danish, Italian, Dutch, Brazilian Portuguese, Romanian, and Slovenian, based on requests coming in from the BC partners. We expect that more languages will be added to this project over time.

Contributions as of Oct. 31

What happened over the next months was a textbook example of surprising and solid contributions coming from a community. Once empowered to work on the their favorite language, driven by the expectation to potentially improve their business, the partners accessed the translation tool and got to work. The table “Contributions as of Oct. 31″ shows a constantly increasing number of contributions for each month from June through October (the numbers represent words contributed per month and are not cumulative). Going into more detail and looking at the weekly contributions on the right, we can also identify two clear spikes of activity.

If we look at the table below, we can identify Dutch and French as languages that have reached 100% completion, meaning their translation has been completed. And indeed, the two spikes in the table above coincide with the points in time when Dutch (the first spike)  and French (the second one), reached translation completeness.

Words submitted on Oct. 31

In addition, it can be seen that there is also a significant activity, although not quite as “explosive”, taking place for Danish and Italian, two more languages not part of BC’s original set. German and Swedish are also receiving some attention, but on a reduced level.

Thus, within a very short period of time and with the help of their partners, BC is now in a position to add a language to their product that has not been shipped before, i.e., Dutch. The fact that BC was able to bring in their partners in such a convincing and effective way, represents a big success for the BC initiative, and for the concept of community translation.

Similarly, even though not completely translated from the ground up, the “completion” of French as a language already shipping, indicates that the community contributed quickly to close the gap between strings already translated (referring to already existing functionality) and strings yet to-be-translated (to describe BC functionality added in the latest version). Another part of the activity around French, was to review existing translations and to submit alternative or better ones.
The summary here is that, in addition to completing translations into new languages, the review of existing translations for both “old” and new languages turned out to be a task that the partner community actively engaged in.

BC partners are now finally getting into a position where they can start marketing their customized sites, built using Business Catalyst, into additional countries or regions. From their business perspective, it hopefully pays off that they invested time in the translation effort. Over time and where it makes sense, Adobe will open up more projects to the community and allow both review and translation for even more languages, be it “traditional” or new ones.

Takeaways: Why Did This Go Well?

There are a number of components that need to be in place to be successful in a project like this. Two of them have already been mentioned:

  • Required is a community that is willing to engage in such a collaborative translation effort.
  • It may go without saying, but since it is so crucially important, we are mentioning it again, a motivation or incentive for anybody willing to contribute must exist. Motivation can differ widely between different communities, and in this case of a comparatively small group (of BC partners), the incentive was to have the product in a new language, the potential reward being to increase revenue through providing a additional language interface to target an expanded market.

Business Catalyst Language Selection

There are more factors that had a crucial impact on the project’s success:

  • The single biggest motivational force that drove the partners to contribute until completion was achieved, is depicted in the screenshot to the left. In the language selection drop-down menu, you can read (in Dutch) “Dutch (translated by the community)”. Only if the community contributions eventually make their way into an application, does the community start to feel a sense of achievement. And only when progress becomes visible in this rewarding way, will it have be worthwhile for contributors to invest time (and their time is their money!) in translation.
  • Last, but not least, there is, of course, the architecture required to enable community translation. For that, Adobe is leveraging a data center in Los Angeles, California, as a link between the users and some Adobe-internal databases to retrieve project-specific information and to receive community translations. This architecture is not project-specific, but can be re-used for similar projects, independent of their size and scalable to the number of of community participants.

Other Adobe translation pilots that are currently open for user contributions are Adobe Story with 5 existing languages (German, UK English, Spanish, France, Italian), and the Flex SDK with one existing language (Brazilian Portuguese). In the future, the number of products opening up to community translation workflows will grow, and so will the number of languages included in this effort.

A Tool Always Helps: Adobe Translator

AT Dashboard

Since it will be described in a future blog article, here only a brief description of Adobe Translator (AT), Adobe’s own community translation tool.

After logging in with your Adobe ID (you may have to create one first), Adobe Translator presents a dashboard showing all projects in which a product allows users or translators to contribute user interface translations or corrections for a given language. Just select your favorite project and explore the tool’s functionality. The process should be pretty self-explaining, but a brief help can always be accessed from the About menu at the top.

AT Translation Screen

On the translation screen, translators can start contributing right away. Just select a source string and enter a translation in the text field. There may or may not be a translation proposal that AT is providing with the help of machine translation or translation memory (“in the past, this string has been translated as …”). Submit your suggestion and move on to the next string.

Adobe Translator is being developed in an agile fashion in frequent, short “sprints”. In order to leverage the opportunity we had with Business Catalyst, the team’s decision was to expose the application early and listen to user feedback in order to rank its feature development priorities. After the successful pilot with BC, the focus will now be on developing “social”, motivational, and informational features.

More To Come …

For the sake of this article’s brevity, we are not going into further details describing the translation workflow in Adobe Translator: It will be part of a future write-up that will focus on our tool exclusively. In the meantime, if you want to take a test drive using Adobe Translator (maybe your favorite product is already available for community translation), feel free to access and explore it. If you don’t mind sending feedback via email, please use the mechanism in the About menu: We would like to hear from you and are listening.

Rest assured that we continue to work on improvements, especially to make the translation workflow easier and more intuitive. In order to make translating more fun as a group or community effort, we will also do more in “social” areas. We will provide features that will motivate users to contribute (commenting and voting on translations, for example) and those that will allow them to see data about themselves, the communities, and the project(s) they are involved in (for example, through a leader board or project statistics pages).

Again, by all means, please access the application at http://community.translate.adobe.com/translator/ or track our activities on the Adobe Community Translation page at Facebook to read important announcements about Adobe Translator and other community translation efforts.

Dynamic Language Delivery for Adobe’s Mobile Applications

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

Recently, at Adobe’s developer conference Adobe MAX 2011 in Los Angeles, representatives of Adobe Globalization group had the opportunity to present – for the first time publicly – how we are envisioning the deployment of localized resources (texts, user interface strings) to mobile applications in the field.

In their presentation “Dynamic Language Delivery for mobile applications” (here as an Adobe MAX video), Daniel Nay, engineering manager, and Dirk Meyer, product manager, demonstrated how language updates or entirely new languages, can be delivered to applications on mobile devices in a matter of seconds. (In the presentation video, you can find demo sequences at 7:00 and 35:50 on the timeline.)

Localization Of Mobile Applications

Like in all other areas of software creation, the development of mobile applications, too, is increasingly applying “agile development” principles: Short “sprints” are helping to implement specific features in a targeted fashion and to deliver them into the hands of users and customers faster, compared to desktop software products. At the same time, and as a consequence of the new development paradigm, the time between the frequent “pushes” of new product versions become shorter and is often measured only in weeks. As a consequence, an end-user is receiving updated product versions more frequently. Fortunately, their installation only takes a minute or less, and (most important for some!) they can be skipped, if they don’t seem attractive or if there is no time for the update.

Dynamic Language Delivery (DLD): Localization’s answer to agile development

In the world of short development cycles and frequent updates, the differences between versions of a mobile application often consist only of a single feature, or some fixes for software bugs. Accordingly, from a localization perspective, the delta between the localized strings from one version to the next, is often only a small one. There might even be cases, where it is merely a fix for a localized string that constitutes an update. In situations like that, it may look a bit out of proportion to initiate a complete localization cycle for such a small change. Because no matter whether changes are big or small, translators, build engineers and testers, all have to follow a complex workflow with many mutual dependencies before the product finally can reach the app(lication) “stores” or the “markets”. Starting such a powerful machinery, designed to flawlessly localize the most complex desktop applications, for only small changes, and doing so even more frequently than in the “non-agile” past? Again, a bit out of proportion, it seems …

Here now, DLD provides a new way to deploy language resources, like user interface strings or other texts used in an application. And it does so without hindering the fast and agile engineering workflows and without slowing down the subsequent application delivery. Instead, DLD workflows are designed to match agile development cycles, including rapid and frequent deliveries to end-users. DLD enables the testing of improvements and modifications instantly, and allows for approved deliveries to be performed in real-time, be it in staging or production environments.

Principles Of DLD

DLD technology effectively decouples the delivery of the the mobile core application (plus one or more core languages) from the deployment of subsequent language deliveries (like UI string fixes or new languages). It does so by using two completely independent avenues to get those resources to a customer. Here is how …

DLD enablement & deployment

First of all, a DLD-enabled core application takes the usual route and reaches the customer as a fully tested and functional product through being downloaded from a website, “store”, or “market”. DLD-enabled means that an application should integrate a DLD library to perform DLD-related tasks (this integration is very lean and can often be achieved with a single line of code). The other requirement for an application to be prepared for DLD is that it should be architected in a “world-ready” fashion: Strings should be replaceable, variable interface string lengths should be possible through dynamic UI layout capabilities, and more. The good news here: It is already an accepted best practice to write any software – no matter whether it supports DLD or not – in a “world-ready” way so that it supports internationalization features and easy localizability.

If, at a later point in time, new or updated text strings or a new language altogether need to be delivered, a second deployment path through the “localization cloud” will be used, completely independent from the application deployment avenue. The localization deliveries will be held available on servers, queried by the application from time to time for language updates. The frequency of these queries can be set with the help of preferences in the application and, of course, a user should always be able to opt-out of this functionality completely.

Customizing multilingual applications in user-friendly ways

In addition to non-intrusive, instant language updates and the option to add new languages when an application is already in the hands of users, there are more ways how we can see DLD supporting new features of multilingual mobile software.
For example, if an application does not come in the language preferred by the user, DLD functionality can be used to check whether this language might be available from the “localization cloud”. More intelligent applications might actually notice that among its current languages there is none matching the (user-preferred) system language … and trigger an alert to download a “language pack” in the system language, if it is available. Thus, DLD can be used to improve a multilingual user experience, where languages and language updates are available at any time: For those, the need to locate, download or install a complete application bundle does not exist anymore.

Finally, it is important to note (the presentation video shows this), that the language updates are available in the running application right away, without having to restart or perform another type of user action: new resources are loaded in the background and appear seamlessly, once they have been downloaded and integrated.

DLD’s Benefits

In summary, DLD comes with a number of benefits for consumers of mobile applications:

  1. “Instant, real-time” delivery and integration of localization updates and fixes for mobile applications in the field.
  2. Language updates can be configured per user preferences, ranging from completely “transparent” to “fully informed”.
  3. Additional languages desired by a user after an application install, can be added on demand, without having to download and install another complete application package.
  4. Missing languages complementing a local device environment, for example, after switching the system language, can be discovered and installed if the user so desires.

Moreover, software development teams are also among those that save time and effort through DLD technology:

  1. DLD library integration is “minimally invasive” (often, only a single line of code is required).
  2. Leveraging the localization cloud, “world-ready” applications will be able to receive language updates whenever they become available during the development process.
  3. DLD separates application development from localization workflows. By doing so, it removes many process and scheduling dependencies between the two.
  4. Development work can continue until late in the cycle and for as long as the application maintains a state ready to receive strings of multiple languages with different properties.
  5. Development work can continue until overarching milestones are requiring it to get ready for the push live. A user interface does not have to be “frozen” with the arrival of localization resources.
  6. Testing work becomes more efficient and will not be accompanied anymore by repetitive tasks of building and installing the application, before testing it for every language or localization fix. Instead, as long as language fixes are involved, they can be delivered to the application instantly and the testers can verify their integration into the application without delay.

In Short …

DLD is the first workflow allowing for immediate, dynamic, and on-demand localization of an application during post-development states. This is possible through making localized resources available as updates, without the need to re-deploy combined application-language packages as a whole.

Among the advantages of the DLD approach, an almost instant “time-to-market/user” and a much simplified development/localization interplay, are probably the two most valuable ones. From many angles and perspectives, DLD is a fast and resource-saving  way to perform localization deployment for mobile applications running on a variety of devices.

Expect to see it in your favorite Adobe mobile application at some point in the (near?) future.