Está quase tudo pronto para começar o Front In Bahia. Inscrições no site do evento. www.frontinbahia.com.br.
Sponsored by Adobe.
Está quase tudo pronto para começar o Front In Bahia. Inscrições no site do evento. www.frontinbahia.com.br.
Sponsored by Adobe.
Illustrations by Julia Feng (OhISeeItNow.com)
Over the past decade, many software development teams have switched their development methodology from a waterfall model to something much more agile such as Scrum. Through this transition, their expectations towards other teams such as Localization have changed and these teams have had to improve their agility too.
At Adobe, we have a centralized Localization group that currently supports 135 product and functional teams. Most of these teams have adopted some form of agile development methodologies and have reduced their development cycle from 18-24 months to yearly, quarterly, monthly and, these days, bi-weekly releases. A couple of Adobe product teams and other companies are even releasing updated versions of their product multiple times per day, making it imperative for Localization to keep improving its agility.
Drawn from our experience, this article presents Five Golden Rules that need to be satisfied in order to achieve optimal agile localization.
Within many companies, Adobe included, Localization is a centralized function serving all product and functional (e.g. Marketing, Sales, Legal, etc.) teams. This structure makes sense because localization is a specialized field, therefore resources (people, tools) and processes can be leveraged across the company. Nonetheless, localization should still be everyone’s concern. The Localization team can come up with many solutions, but the best ones originate when there is a true partnership between the product/functional and localization teams.
The most agile teams treat Localization staff as if it were part of their own team.
A core aspect of Scrum is to include all skill sets, including localization, required to deliver a product to users. Therefore, Localization team members must be included in all development aspects – from backlog review to retrospective – so they could plan and address international issues early on. Strong partnerships also need to be established with localization vendors when companies, such as Adobe, engage with partners and vendors for their translation and testing activities.
Customer engagement is a key aspect of agile methodologies as it validates the quality and usefulness of the work performed thus far. We recommend engaging with international customers too, because their issues increase awareness around internationalization.
In summary, all stakeholders (development teams, functional teams including localization, vendors and customers) need to collaborate closely in order to achieve great agility.
In our Globalization Myth Series, we defined Internationalization (commonly abbreviated as i18n) as an engineering exercise focused on generalizing a product so that it can handle multiple languages, scripts and cultural conventions (currency, sorting rules, number, date and time formats…) without the need for redesign.
In other words, the better internationalized an application is, the easier it will be to localize.
In the waterfall model, teams could possibly work around some of the internationalization deficiencies because of longer development cycles. Unfortunately, in the agile world, there is not enough time to look for work-around solutions anymore. The code needs to be internationalized from the get-go.
There are various approaches to improve internationalization in a company, which includes the following:
To release a new product, development teams have many high-priority tasks and usually prefer not to have to worry about localization until necessary. As a consequence, localizability issues are often discovered too late and encounter the risk of being deferred to a future release. Product teams don’t always anticipate the impact of a particular task/feature on localization, and quite often, the Localization team isn’t able to influence design or development until the feature is already implemented.
In an agile process, features and development tasks are tracked in a backlog and reviewed at the beginning of every sprint. To eliminate the side effects of the “throw-over-the-wall” model described above, it is critical to include Localization representatives during these sprint-planning meetings so more visibility and importance are given to the localization tasks. This also provides great educational value to all stakeholders who can then understand the impact of their decisions on the localization process. Localization or a proxy should also attend the daily sprint meetings to keep up with the development pace and decisions. By attending these meetings, Localization team members can be much more proactive and influent.
Adobe Revel and Photoshop.com are examples of teams that integrate localization into their development process. They also prioritize localization intensive features/tasks upfront – carving enough time for the Localization team to run its process and deliver high-quality localized releases.
In a recent Localization World event, Amrit Singh (International Program Manager for our Installation technologies) presented LocBan (Kanban applied to Localization). Just like in a Toyota factory, the Localization team maintains a board of “To Do”, “Work In Progress” and “Done” tasks which provides great visibility on the localization “conveyor belt”. Similarly, it would be beneficial to maintain Kanban boards for each translator. In the waterfall model, translators used to receive large localization kits, which they had to scramble to complete within the deadline. In the agile world, translators are now able to “pull” work as their bandwidth opens up.
By using an integrated Kanban board, everyone has a clear understanding of all the various dependencies and accountabilities, resulting in stronger collaboration and higher success rate.
Localization can generate a lot of waste if not planned properly. So, it is key to become “green” in order to become more “agile”.
It is clear that reducing the localization effort will have a positive impact on a team’s agility. This could be achieved in 2 ways: by validating the localization scope and by reducing the translation waste generated during the localization process.
The Localization Manager’s job is to ensure the company localizes the right product and content into the right language set. At Adobe, we have had situations in which we were localizing too much content. For example, using Adobe’s Digital Marketing Suite, we discovered that Russian customers prefer reading Development documentation (such as API descriptions) in English rather than in Russian. We were able to save a lot of time and cost by removing this component from our localization requirements.
Similarly, through market research, we discovered that most Middle-Eastern Creative Suite customers prefer to use an English user interface with Arabic or Hebrew documentation. This combination makes English content such as videos and tutorials more accessible to them.
In short, tracking web analytics and engaging with customers, power users, pre-release testers and geos constitute a great way to validate the localization requirements and improve agility.
Once the localization requirements are confirmed, it is key to limit the translation waste generated during the localization process. This obviously impacts the translators’ work but also the bandwidth of the localization staff.
An effective way to reduce localization waste is by understanding its root cause. At Adobe, we categorize all localization defects through a common set of keywords, which provides us with a good picture of the issues faced across products. We can then develop solutions to reduce, if not eliminate, these defects.
Localization waste sometimes originates from English strings -assuming English is the source language. Indeed, translations created before English strings get finalized will need to be revisited and will likely generate some waste.
In the agile world, we can’t afford that extra time, so it is important to validate the English content before handing it off to the translators. Doing something as simple as spell checking can help to reduce a lot of localization waste. In a product such as InDesign, about 3% of the English user interface strings are updated once they get reviewed for spelling and grammatical mistakes. For a product that is localized into 25 languages, this represents a waste equivalent to 75% of a single language scope!
Also, many of the software localization testing activities are necessary because localization is happening out of context. Solving that problem can tremendously speed up the localization process. In an ideal world, localization should be a product feature that allows translators to translate the user interface in-context. Facebook did a great job in this area by enabling translators (in this case its user community) to translate and provide feedback within the application itself. Alternatively, translators should be provided context information through builds, screenshots or meta-data information (e.g. developer comments, feature name, expected delivery time, etc.).
To reduce waste, it is also recommended that localizers develop glossaries, style guides and tools that leverage previous localizations.
Ultimately, it’s critical for translators to validate their work as they translate. That way, activities down the production line can be eliminated or reduced, which makes the entire process more agile.
Reusing strings can sometimes be a source of challenging defects in software localization, so it has to be handled carefully. For example, the English string “none” could be translated as “aucun” or “aucune” in French based on the gender of the noun to which it refers.
That said, reusing strings – in the same context – could also help to improve agility, since these strings won’t need to be translated multiple times.
An area where Adobe has experienced positive results with reducing and reusing English content is in our instructional content. In documentation, Adobe relies on Acrolinx to control the quality of the English (source) content. Authors need to use a certain authoring style (e.g. shorter sentences) and are encouraged to leverage existing paragraphs (e.g. legal disclaimers). This improves consistency in the English documentation and has the great benefit of reducing the localization workload too.
Similarly, DITA (read Reduce, Reuse and Recycle: Developing a Reuse Strategy for DITA) and Content Management Systems such as Adobe Experience Manager (formerly known as Day CQ) are designed to reuse/share content across multiple channels and publications.
Recycling is the process of transforming existing materials (or waste) such that they could be reused again – sometimes for a totally different purpose. Creating polar fleeces from used plastic bottles or isolating walls using old denim jeans are classic examples of recycling.
Such transformations can apply to translations too. Translators don’t need to translate every sentence from scratch. Translation technologies such as Translation Memories and Machine Translation engines can help translators recycle previous translations and speed up the translation process. At Adobe, we have experienced dramatic productivity gains when we used these technologies. In general, a translator supported by these technologies will deliver in an hour what other translators would deliver in a day. These are impressive gains that contribute to localization agility too.
The last requirement to achieve agile localization is automation. With agile, you can’t afford to send translation requests through e-mails or cut and paste strings from a spreadsheet to a source file. All translation hand-offs should be automated and managed through a centralized system. Over the years, Adobe’s Globalization team has developed such a platform. This system is able to connect with various source control systems, manage translation jobs, leverage existing translations across projects and content types and provide machine translation engines. In the Globalization Myth 4 article, Guta Ribeiro introduced Airport, our new system to automatically connect with our vendors and help us march towards our lofty one-hour translation goal.
Beyond translation, it’s also important to automate other aspects of the localization process, such as build, quality assurance, bug fixing, screenshots and distribution of the localized releases. We can only go as fast as our slowest component, which is why it’s critical to automate all aspects of the localization process.
Localization agility can be achieved as long as all stakeholders work as a unified team. It is critical for core engineers to develop well-internationalized code from the get-go. This can be achieved via training, code reviews, usage of (Open Source) internationalization libraries and globalization report cards.
The localization process should be fully integrated within the overall development process so that all dependencies and accountabilities are clear. We recommend using Kanban boards (via tools such as Trello) to raise this visibility. To become agile, it’s also important to act “green” (i.e. reduce, reuse and recycle). Doing so represents an effective way to control waste generation before and during the localization process. Finally, all efforts should be made to automate all parts of the streamlined localization process.
At Adobe, not all localization projects are handled with great agility – yet! Some projects are more agile than others. However, based on our experience, we believe agility can be achieved by adopting these Five Golden Rules:
Special thanks to Rob Jaworski, Amrit Pal Singh, Ashish Saxena, Janice Campbell, Leandro Reis, Peter Green, Julia Feng and Quynn Le for their invaluable feedback on 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:
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.
A Adobe Brasil ‘fan page’ é uma ótima iniciativa da comunidade brasileira. ‘Like’ it! “Curtir!” como o fizeram os 15,018 usuários até hoje.
I had the opportunity to attend Adobe MAX last week in Los Angeles, California. It’s called the Creativity Conference, and in my opinion, the organizers delivered.
A few of us from the Adobe Globalization team established a presence at the Community Pavilion as we actively sought to engage with our customers and users from around the world. We were successful in that and I will post more information about that in the coming days.
In the meantime, please watch the following intro from Adobe TV, and keep a watch for me at 43 seconds in (I’m on the left, listening intently).
I have been asked lately to talk to a couple of peers in the industry about Marketing Localization at Adobe and thought this would make an interesting blog post as well.
At Adobe, Marketing Localization is centralized and consists of a team of International Program Managers, which I manage.
I believe this is still the right model for us. Adobe has offices all over the world and decentralizing marketing localization would actually introduce inefficiencies. That said, the challenge with a centralized model is to balance productivity with the ability to provide GEOs with the right process and tools so they can participate and provide valuable input around GEO-specific nuances, country specific content, etc. This is an on-going challenge and we work very closely with our Marketing Managers worldwide to conquer it.
The challenge here is the balance between giving more flexibility and freedom of expression to the regions and the use of productivity tools such as Translation Memory. If we want to leverage the savings that TMs and other tools offer to localization (and we do), we can offer some flexibility in the target content but not as much as sometimes the regions would like to have – for instance, complete re-writes of segments.
At Adobe we are aware to these issues and the key here is to work closely with the regional offices and offer them opportunities to provide feedback early on, directly into the source content, before localization starts. It also means providing opportunity for reviews on localized content that is presented in context in a process that allows for easy feedback. Our GEOs are Field Marketing Managers and we are sensitive to the amount of time spent in reviews.
There are always challenges in localization and in particular in Marketing localization, where ‘good translation’ is just not good enough.
Take the Digital Marketing BU for example. Worldwide campaigns around the digital marketing solutions have to appeal to ‘marketers’, to professionals that create marketing content, and so the ‘localization quality bar’ for the content we provide to our GEOs has been raised significantly.
Here’s an example of a recent campaign that was particularly challenging for localization due to the use of the very US centric expression “ticks them off”. For translators is not always a clear choice of words for the target language. The ‘weight’ of the expression and what it conveys need to be taken into consideration.
Regional offices are free to create their own marketing materials – International Brand Guidelines are in place and Adobe’s Brand team works directly with the GEOs to ensure a consistent interpretation and use of our brand.
We are very protective when it comes to the Adobe brand and although the regional offices are given some flexibility in terms of creating some of their own marketing materials (in their original language), Adobe’s Brand team normally is involved to make sure the materials follow the established international brand guidelines.
What regions or international markets are most difficult or challenging for localization?
I think anyone that works in localization would start by saying that Japanese is a very challenging language to localize. The idea of ‘translation’ is already something that is not appreciated by the Japanese market. A very good ‘translation’ still means ‘it’s translated’ and so it has a different flow and feel than the content that is originated in Japanese. This becomes an even greater challenge around marketing content.
At Adobe we do have a successful program for localizing marketing campaigns into Japanese and that involves working very closely with our in-country product marketing managers and employing in-country copy editors when necessary.
That said, every language and every country present challenges. We recently had to deal with orthography changes in Brazilian Portuguese, tonality changes in Spanish (formal to a more informal tone), imagery issues in the middle east, different ‘flavors’ of a single language, and so on. I guess I would say that there are no ‘easy’ regions. Our work is always interesting and we look at these challenges with a very positive attitude – these challenges are what differentiate translation from localization and it’s always exciting to be part of this process, where you see the source messaging deployed all over the world and having the intended appropriate impact in every region, around the globe.
What aspects of branding are most important to localize for regional audiences? What channels are most important?
The emphasis has greatly shifted to online content (web pages, multimedia content and social), the larger part of the content we now localize will end up on Adobe’s 57 international sites. The need for printed content has decreased but there are still certain regions that need to be supplied with printed content. We try to listen to our GEOs and provide relevant localized materials.
The Adobe ‘look and feel’ is very homogeneous in all our sites. Our regional offices have the flexibility to add country specific content but the site template is the same for all locales and all international sites are centrally managed.
Regional offices are also free to create some of their own marketing materials – International Brand Guidelines are in place and Adobe’s Brand team works directly with the GEOs to ensure a consistent interpretation and use of our brand.
I believe the big challenge now is the creation of a strong and successful Creative Cloud brand worldwide – and we are well underway
The regional offices should be an extension of your team and taken into consideration in every step of your processes and tools.
One of the great things about being part of the globalization team here at Adobe is that we get to work regularly with people around the world, on an on-going basis, as if they are down the hall from us rather than well over the earth’s horizon. It becomes second nature to just know what time it is now in Tokyo, Beijing, Noida, Bucharest, or Brno, all relative to each other. It’s a known fact that if you must to schedule a live meeting with people in North America, East Asia, and Europe, someone will be stuck with a very inconvenient time slot.
These differences in time zones work for and against us, too, when it comes to project schedules, whether handing off files for localization, or delivering the final product. Where you are in the world can be an advantage or disadvantage, depending on where your stakeholders are located.
My main job at Adobe has been program management on the product localization team. That means that I have done my share of project schedule development and maintenance. One of the early lessons I learned being in the business, in this position, is that the details in the schedule matter, especially those that define when a task is supposed to actually happen, or rather, when it should start or be completed.
The schedules that I manage assume that the finish dates associated with any given task is relative to end-of-business-day local time for whomever the task is assigned. For example, if the task “Deliver Translated Files” is scheduled for Tuesday and is assigned to the team in Beijing, they have all day Tuesday, local time, to finish the task. If they are delivering it to a team on the west coast of North America, then they actually have longer than that since there probably won’t be anyone in the office in San Jose to take delivery at 6PM Beijing local time (unless we’re in end-game, crunch time, of course!).
Because my team and I are on the west coast of North America, we realize that having until the very end of the day to get things done cuts into the working day for those folks in East Asia. Therefore, we typically will account for that by adjusting the start date of the subsequent task for the folks in Asia to be their next working day. That adds a bit of flexibility for us since we then have more time to get our task done, which equates to a bit of slack in the schedule in case things don’t go as planned, a not uncommon occurrence.
This strategy seems to work out pretty well. The key is that the details must be laid out explicitly and be well known and understood. I make it a point to discuss this schedule rule exhaustively during kickoff meetings, ensuring that everyone understands. In fact, it is mentioned in the footer of my schedule files, just to be sure it gets proper ongoing visibility.
Certainly, all the details of the project should be well advertised and universally understood to ensure project success and to minimize risk. That’s what good communication among project managers and the projects teams can do for you. But I’ve seen the this time zone caused task deadline confusion trip people up enough to know that it’s important.
Time zones differences can be tough to get used to, especially for those who are new to working with people in various, greatly varied regions. Time zones can help or hurt, provide you with a slight cushion or cut your day short. But if the rules are defined with your teams and stakeholders, geographical differences should not be something that slips you up.
I’d be interested to hear stories about how time zones have helped, hurt, or simply confused. I invite you to leave your experiences in the comments section of this blog post.
International Program Manager
image: flickr user triciawang