This posting on Facebook about the video “Brackets: From Design Comp to Code” has generated hundreds of comments by Brazilian developers.
See original video here.
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
The Localization team at Adobe is continually working at enabling more avenues and channels for our international user to provide us feedback on the internationalization and localization aspects of our products. One such channel is Localized Prerelease Programs. Through these programs, we encourage our international users to provide feedback on UI, translation, and overall world readiness of our unreleased products. These localized prerelease programs allow you to test products in your native language and provide feedback in a structured manner through the prerelease site. We welcome any feedback on the language used throughout the UI, ensuring that the product functions and appears natural in your language. Feel free to give us feedback on truncations, overlaps, clippings, flawed UI geometry or any cross-product inconsistency that you observe in the product in your language.
You can show your interest in participating in Adobe’s Localized Prerelease Programs by filling this form. Make sure you select ‘Yes’ to the question ‘Would you like to participate in a localized Prerelease Program ?’ and specify the language that you are interested in.
Creating global-ready, internationalized applications requires many people: engineers, project managers, translators, and often in-country experts. If everything goes as planned, the final product is internationalized and localized to meet the needs of a specific market. The required teamwork is amazing, and sometimes the expense can be surprisingly large. The mistaken conclusion is that internationalization must always be expensive, and that the effort simply costs too much in terms of schedules, resources, and of course money. The worst part about the conclusion is that the expense can be minimized considerably by rethinking when and how internationalization is performed.
Two causes of expensive internationalization are the delays in actively thinking about it and thinking of it as a simple feature. Often product managers and engineering teams simply do not plan for localization from the beginning of their project’s lifecycle. This is common in product teams that target English-only regions first. Unfortunately, engineers and product managers mistakenly think that they will be able to add the internationalization and localization “feature” at a later time when needed. This is an expensive mistake, and it comes from thinking of internationalization as a feature instead of an architectural and design style. The result is that the final product does not contain any framework for localization and has not been designed with internationalization and localization in mind. Ultimately, it is difficult and expensive to retrofit or “fix” an application that has a single language architecture and design. Internationalization simply touches too many areas of a product to be considered as a one-time feature that can be added to the product sometime in the future.
You can save yourself the expense and difficultly of retrofitting or fixing an English-only product by thinking of the internationalization step as an architectural element rather than a feature. A feature can be readily added to a product often because it has limited scope within the application or has few dependencies. A new feature is often “low-touch” or only lightly coupled with other features or areas of a product. Internationalization, however, often affects all aspects of an application. Areas of the product that involve number, date, time and currency formatting can cut across many areas. Internationalization is a “high-touch” activity that affects most areas of an application because user interfaces, strings, icons and colors, numbers, dates, and time values are used throughout an application. Finding and fixing those areas so that they are internationalized and localizable is an onerous task once the product already exists and is in production.
If you architect your product from the beginning so that localizable elements are isolated from core business logic, you make the localization task easier later. How can you think about internationalization as an architectural task rather than as a feature?
First, understand that internationalization will affect many aspects of your system. Think about all the areas that utilize strings and other localizable resources. The list may be bigger than you first imagined.
Secondly, after identifying those areas, extract those text strings and other resources so that they can be translated independently without touching your application’s source code. Every programming platform has a means of isolating resources from the core application. Learn about that mechanism and use it. Think of this step as creating the generic, language-neutral scaffolding upon which the rest of your application will be built. You want to create a core set of business logic and user interface layout that is independent from language and culture. Later, the language-specific elements can be translated and added onto this core architecture.
Lastly, architect your application to load needed language modules at runtime rather than having them hard-coded into the application. Placing the right internationalization architecture in the product from the beginning costs little in terms of time lines and resources, and it pays off significantly over time when product teams discover that their “English-only” application is now desired in new language markets.
Adobe RoboHelp software is an easy-to-use authoring and multichannel, multiscreen help publishing solution.
Using RoboHelp 10 –
Adobe RoboHelp 10 supports output formats as shown in graphic below:
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 default Project 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?
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