WELCOME TO THE RUBRIC NEWSLETTER

PM TIPS: Tips, tricks, and strategy from Rubric localization project managers.

RUBRIC NEWS: New talent comes to Rubric account management teams.

BUSINESS — 21st Century Globalization Issues — It's not just for High Tech: A panel of experts predicts the impact on localization in the 21st century. Rubric executives, customers and partners discuss what to watch for in the coming years.

TECHNICAL — Rubric, Toshiba, and WorldServer: A Rubric Senior Project Manager discusses how new processes and Idiom's WorldServer bring time- and cost-savings to Toshiba.

PM TIPS

RUBRIC NEWS

21ST CENTURY GLOBALIZATION ISSUES — IT'S NOT JUST FOR HIGH TECH

On May 9th, Rubric founder Ian Henderson led a panel of globalization experts at the Society for Technical Communications annual meeting. Ian's panel examined the new issues facing localization management in the 21st century. This is the transcript from that panel.

Our next panelist is Sarah Kittredge, the Localization Manager from yet another Rubric client, SumTotal Systems.

Our final panelist is Bill Rabkin, WorldServer Product evangelist at Rubric partner Idiom Technologies. Bill represents the tools vendor perspective. Bill, tell us about yourself and what challenges vendors in the localization tool world see coming at us in the 21st century.

Without further ado, let's get into our questions, starting with Claudia.

Rubric: For the panel — What are the top business pressures forcing new ways of internationalizing products, promotions and branding across the globe?

Claudia: Geopolitical events are very important. Two concrete examples in recent times are the "war on terror," which has made Arabic much more important, although the Arab markets in themselves might not justify it at the moment.

Also, the recent accession of 10 new countries to the EU (European Union), soon to be joined by Romania and Bulgaria. Estonian is an example of a language which has become much more important as a result of Estonia's inclusion in the EU.

Sarah: For SumTotal, pressures to grow revenue force us to look at more international markets; and to be successful there, we need to create more materials in more languages.

This can be expensive, and like everyone else, we have limited resources, so we are forced to prioritize which materials and which languages. We often have to decide to do some projects piecemeal.

We have also developed a Languages Club to try to meet these needs. In this club, our customers share our risks and share each others' benefits.

Unlike some other tech companies, we have not moved to single sourcing, but try to reuse as much materials as possible — one company glossary, one style guide, etc.

I guess our ever-changing political world requires us to be more culturally aware and geo-politically sensitive. We introduce new sample data with more diverse content all the time. We introduce new features such as regions to allow administrators to manage training and users. Yet we maintain our approaches for other features, such as not showing flags to change languages, or not labeling data as countries (rather, as countries/regions).

Bill: The volume of information is increasing substantially. We are seeing an increase in the speed at which new information appears. These two issues alone are a challenge when operating internationally; but there is a further complication, which is the increase in number of languages that the markets are now demanding.

We should bear in mind that this is not only a concern for companies operating internationally. Even companies catering only to the domestic US market have to recognize the huge opportunity amongst the Hispanic Americans. Telephone operators, for example, are now specifically targeting the US Hispanic market.

Government regulation is yet another area of pressure. For example, government information exchange now has to be communicated via defined XML structures, such as SPL. Naturally the Europeans have their own, different, standard — PIM. This multiplies the localization effort.

Rubric: What are the top changes you have faced over the past five years in communicating to international markets?

Sarah: It's difficult to keep it down to just five.

First, companies are becoming more global. This amplifies their expectations and their localization work. Because of this, there is a greater interest in a Learning Management System (LMS). LMS is becoming more mission-critical and is needed to deliver information globally.

Companies are realizing the value of training, and therefore, increasing focus on training and improved effectiveness of delivering info in people's native languages follows. This increases the localization work needed.

Next, the number of countries joining the European Union (EU) increases the demand to track training and adhere to local regulations.

Finally, I think the new markets emerging in China, Singapore, and other spots around the world open new markets, new profits, and new localization needs.

Rubric: I suggest, in jest, that documentation is dead.

Claudia: For products aimed at home users and/or people who interact infrequently with computers, that may be the case, but it is not the case for highly technical products. You can't use Photoshop, for example, without documentation. As these products become more and more complex the amount of documentation will increase rather than disappear. The reference guide therefore is essential for this type of product.

For a complex product such as Oracle database, a Getting Started guide will continue to be very important. Other types of documentation such as case studies and white papers are much less important, at least from a product documentation point of view.

Rubric: Like with Claudia, I suggest, in jest, that documentation is dead.

Bill: Documentation is not dead at all. It is just that the delivery mechanisms have changed. It has been a long time since we discussed whether 3- or 4-hole ring binders were better. Now the medium is definitely the Web.

Corporations such as Microsoft and Novell rely extensively on the Web for documentation, including their feedback mechanisms, which allow users to provide direct feedback on the documentation. Because the documentation is online it can be adjusted very rapidly. This rapidity impacts how localization is performed — less in batch and more in near-real time.

Rubric: Let's look ahead. What is the next big obstacle or opportunity in communicating to international markets?

Part two of this article will appear in the next edition of the Rubric newsletter.

Sarah Kittredge, Localization Manager, SumTotal Systems — With more than six years at SumTotal, Sarah has held many different positions including Training Manager, Program Manager, and Localization Manager. In her current position, Sarah directs localization of the SumTotal Enterprise Suite into 11 core languages for the Engineering team as well as custom language projects for the Services group.

Claudia Galván has over 20 years experience managing software engineering development teams for the successful launch of commercial software products, shared libraries and productivity tools. She is currently a Sr. Corporate Product Manager for Globalization at Adobe and is responsible for driving the cross-product technical initiatives to support the growing language support in Adobe product. In addition, she defined strategies and established leadership positions in Globalization and Electronic Software Distribution (ESD) technologies, and evangelized and driven technology initiatives across the company. Before Adobe, Claudia was at Oracle as their National Language Support manager where she managed software Globalization.

Bill Rabkin is the Globalization Evangelist for Idiom Technologies. Bill promotes the widespread use of XML and DITA-based publishing solutions to technical documentation organizations throughout the world. Before joining Idiom, Bill was a senior technical evangelist with Rational Software (now IBM Rational Software) as well as Sybase, Inc. He completed his Bachelor of Applied Sciences in Computer Sciences at Boston University and graduate studies in Business Administration at Babson College. Bill is a frequent speaker at content management industry conferences and Webinars.

RUBRIC, TOSHIBA, AND WORLDSERVER — SAVING TIME AND BUDGET

At Rubric our main focus is globalization services for the high tech industry, though we have clients from a wide variety of industries. Some of our better-known clients include Accenture, Bose, Toshiba, and Adobe.

At Rubric we are constantly evolving our processes, tools and technology to anticipate our clients' changing needs, and to continue providing a better localization experience. As part of our perpetual evolution, we are changing processes and technologies for one of our largest clients, Toshiba. In support of Toshiba, we are migrating from FrameMaker source to XML managed on WorldServer.

This has been a challenging, interesting and at times frustrating effort, and I would like to describe some of these elements.

Changing processes — if it ain't broke...

Any new process must have one criterion: do not break what works. Rubric delivers two key advantages to our clients: on-demand scalability — that is, the ability to instantly bring as many localization experts onto a project as needed — and delivering the highest quality in localizations. Our work for Toshiba had to maintain these standards as well as deliver new capabilities.

The areas I will discuss today are:

• Why Rubric decided to change a long established process
• How Rubric approached this migration
• What issues Rubric has faced during this migration
• The benefits of WorldServer
• Cost- and time-saving benefits for Rubric and Toshiba

Why change the process, then?

Why did Rubric decide to change a long-established process with a very important client? After all, we have worked with Toshiba for 12 years now, and our processes with them were well honed. We are responsible for documentation localization into 18 languages for Toshiba, and this includes multiple manuals and small documents. Each year we localize 150,000 pages and 500,000 new words for Toshiba.

"In order to deliver a better localization experience to our clients, we have to invest in R&D to reduce the effort involved in localizing their products."
—Ian Henderson, CEO, Rubric

This quote sums up our relationship with Toshiba. Rubric strives to anticipate our clients' needs and to plan in advance.

For example, this involved moving our DTP processes to China in 2000. This has allowed us to squeeze our DTP prices and keep client costs down. It has been very successful for the last six years, with all manuals delivered on time and to budget.

Allow me to describe our established project process for Toshiba at this time. Rubric operates a "distributed global project management model" which is totally decentralised. This means we use in-country translators and have project managers based in our London office.

The first step in a Toshiba localization occurs when we receive English FrameMaker files. We use S-Tagger to prepare the files for translation in Tag Editor using Trados translation memories. Rubric's project manager is responsible for file conversion, measuring Trados leveraging, and emailing files out to translators for translation. When translation is complete the project manager converts files back to MIF and emails these to our DTP teams. Afterwards, our translators do final QA and then they are shipped to Toshiba and the printers.

So if it ain't broke why fix it? The second biggest cost to Toshiba after translation is still DTP, despite our price-squeezing efforts. The XML file format is a way of greatly reducing that cost and the time spent.

To earn these savings, we developed a tool to convert the unstructured FrameMaker files supplied by Toshiba to XML. These converted files can then be translated and processed into a final formatted PDF output with a minimum of manual intervention.

The second target for optimizing Toshia's work involved how time was spent by project managers on certain tasks. You can see (in red) the number of tasks the project manager is responsible for, and you can imagine how time-consuming this is when projected over 18 languages. For a typical 18-language project it can take more than 3 hours to do the setup tasks. Given the volumes and time constraints Rubric is working to, this puts great pressure on the project manager and adds unnecessary costs for our clients.

Rubric has been able to address a lot of tasks undertaken by the project manager through the use of WorldServer. Rubric's new process automates many of the tasks in red in WorldServer. This will take some pressure off project managers, reduce costs and speed delivery of the final products.

How Rubric approached this migration

Rubric took an incremental approach with the migration. We constantly assessed WorldServer and listened to user feedback. It is an ongoing and very complex process, as we are developing a new set of tools for FrameMaker>XML>PDF conversion alongside a process management change to using WorldServer, both of which are regularly throwing wrenches in the machinery.

WorldServer's flexibility and the fact it can be implemented gradually and in line with existing project workflows and tools has been hugely beneficial for Rubric. Throughout our investigation we asked "Is WorldServer doing what it needs to for Rubric?" I have reported back regularly to my colleagues on potential issues and benefits. I have also asked other Rubric WorldServer users the same question. Is WorldServer working for you?

The first step for me in the investigation was an initial assessment of the WorldServer tool. Having worked on Toshiba projects for so long, we have built up large translation memories, and the majority of the projects we do are updates to existing documents. It was imperative to check that we could import translation memories into WorldServer and use them effectively.

I got varied results with this testing, depending on the language. With some help from Steve Billings at Idiom Technologies I tweaked Trados and WorldServer settings and got slightly improved results. However, we did lose some leveraging — between 10 and 30% depending on language.

We decided that despite this it was worth continuing our investigation. Our next step was a test project using MIF files on WorldServer in "ad hoc mode." As our plan initially was to use WorldServer only to analyse the files and export assets for translation, we soon realised that this would not be a practical solution. We decided that MIF files should not be the focus for our investigations, as we planned to go the FrameMaker>XML>PDF route anyway, so we moved on to a second test project using XML.

We managed this XML project on WorldServer in "Project mode." Our users came up with a number of key issues while doing this. Despite lots of issues it was certainly more successful than the MIF project in ad hoc mode.

At this point our investigation split in two as the developers continued work on the FrameMaker>XML>PDF tools with the translated XML files. I continued investigating WorldServer with the goal of fixing all the "big issues" raised by myself and other users at Rubric, so that we could use WorldServer on a live project.

We did a third test project revisiting the XML using a Rubric Workflow, and I got further feedback from the translators on whether key issues had been fixed. Our next step is a live project using 300 HTML files in 6 languages; this begins later in May.

Issues faced in the migration

What issues has Rubric come across during the migration? I will divide these into 3 sections:

• Process issues
• Human issues
• WorldServer issues

Process-specific issues

The FrameMaker>XML>PDF tool
Initial testing of the translated XML files threw up some new problems, so this tool is now back with the developers, and we will have to wait until June or July before we can do our first full XML project. This meant we had to redefine our first live project to be managed on WorldServer.

Directory structure
We have well-defined methodologies at Rubric. This starts at the project scoping stage when we receive files from the client and a project is set up using the Rubric directory structure. This structure feeds into all Rubrics' tools, from quotation onwards.

We must be able to apply Rubrics' directory structure in WorldServer for it to be a usable solution for us. I was able to do this initially using the standard setup method in WorldServer, although it was very time consuming. When using the LSP tools I could not do this. With the support of the Idiom team we have had the LSP tool adapted specifically for Rubric's needs.

The second issue with the WorldServer directory structure is the exported ttx zip files. These do not include the Rubric directory structure in the zip's path; we feel this needs to be there, as it is integral to Rubric's structured methodology. We are working on a solution for this by adapting our own tool set.

Human issues

We encountered some translator resistance. Rubric has worked consistently with many of the Toshiba translators for more than 10 years. Getting the translator to "buy in" to a new tool can be a management challenge.

Our translators are very familiar with the old system, and with the files, folder structures, and the types of process issues that occasionally arise. However, using a new tool such as WorldServer means lots of unknowns for the project managers and the translators, especially during the testing phase.

By carefully selecting translators for the test projects — ones who are known for their flexibility, knowledge of tools and for their good feedback — we have been able to uncover a lot of issues, and we have really focused on resolving these, as we see that fixing them will get the translators to buy in.

I think we have gradually got translators to take interest in the product and to see it as a tool they could work with.

There were some minor usability issues as well. Throughout the test projects I have been asking myself "Have I found this easy to use? Will project managers find this easy to use? Will it save them time?" If I cannot answer "yes" to these questions, adoption of WorldServer is of questionable value.

In the longer term I think this product will definitely be a time saver for our project managers. However there will be a learning curve and teething problems as people get used to it. I know it has taken me a lot of time to come to grips with WorldServer. I have already had positive feedback in the demonstrations I have given at Rubric; however there is a general suspicion, as with anything new, that it might bring new problems to an already complex, time-critical process.

But with a gradual implementation into suitable projects, I think we should be able to get people up and running relatively quickly.

WorldServer issues

There is a loss of leveraging with WorldServer. We found this an issue when importing existing translation memories into WorldServer and then applying these to previously translated MIF, as there was a loss of between 10 and 30%. With the XML we still found a loss of leveraging but the results were less frustrating, as the translators expected a loss of leveraging with the change of file format and so accepted the loss more readily.

At present it is not possible to have multiple 100% matches in WorldServer. Our lead German translator in particular found this a huge problem when looking at the files which I exported from WorldServer for translation in Trados as there were many incorrectly translated segments in the pre-translated files. I could not find a workaround to this problem apart from not pre-translating the German files. I know this is being addressed in version 8.0, so it is not a "show stopper" for Rubric, but it certainly made translator resistance harder to overcome.

I used the HTML filter to segment my XML file. I needed to do quite a bit of tweaking to the filter segmentation rules to get it working effectively for my files. I had quite a few teething problems with updating the filter, and spent a lot of time on this with the support of Steve Billings. Now that I know how to do it, it seems easy and I will make sure I document the process for other project managers at Rubric; but it took a lot of effort for me to get the filter right. My changes worked and the translators were very happy with the way the file segmented in our third test.

WorldServer works on the premise that the source and target should be exactly the same and contain exactly the same tags. However, we find this is not true in real localization projects. Each client has its own style guide for each language, and applies different rules.

I will give an example for German. Often, in English docs and help files UI options are not formatted in a special way. In German, all nouns are capitalized, so every sentence contains several capitalized words and the UI option does not stand out very well. Therefore it is usual to format these UI terms in bold or sometimes in a different font or color.

I raised this issue with Steve and we discussed it at length, but there did not seem to be an immediate solution. Rubric tried to work something out by looking at Trados and the Idiomini file.

One of our engineers was able to "hack" the INI file and get the bold and italic buttons to reappear as options in Trados when an Idiom file was being used. We then tested whether inserting bold and italic tags into ttx files caused issues when re-importing into WorldServer. No issues came up.

We then updated the translation memory with the segments containing the tags and then scoped a file which had been previously scoped. The leveraging did not seem to be affected by the new tags.

It seems as though we have a solution for this issue which should be useable by our translators. We just need to make sure the translators are using the correct INI file.

We have worked through a number of test projects and a lot of issues which have come out of the projects, and resolved these over time, and we are now preparing for our first live project.

We have found the flexibility of the WorldServer product fantastic, as it has allowed us to integrate it alongside our existing project management structure. It has also allowed us to move over incrementally, so there is very little pain with the addition of WorldServer to Rubric.

I think that, most importantly, throughout this investigation the Idiom team has given us excellent support. We have found everyone to be interested in the problems we have come up against and exceptionally helpful in working with us to resolve them.

We have found WorldServer very accessible for all our users, whether on the Web or using Desk Top Workbench. This is important, as Rubric localization and translation staffs are all over the planet, and their ability to use WorldServer without handholding is essential.

On the whole we found WorldServer intuitive, and we could get up and running relatively quickly. As a result of all of this we have been able to continue and progress with this migration.

Part two of this article will appear in the next edition of the Rubric newsletter.