December 2003/January 2004

Volume 44, Number 3

Trends in writing for translation, part 1

by M. Katherine Brown
Reprinted with permission from MultiLingual Computing and Technology

Internationalization is not rocket science, nor does it necessarily require a significant capital expenditure on the part of the technical communication team. It does, however, add a layer of complexity to the content development process, and it does require planning, communication, time and effort to implement.

Much of content internationalization involves adapting processes to accommodate the needs of the localization team and following the basics of good technical communication — keep it simple, concise and clear; avoid jargon and acronyms; be consistent; understand the audiences; avoid text in graphics; and so on. Because these recommendations are so conceptually simple and so practical and cost primarily time to implement, managers often dismiss them immediately as ignoring the real-world issues. Ironically, issues of clarity, consistency and terminology in the source content, as well as insufficient or inefficient processes, are precisely the causes of significant and unnecessary costs in localization.

Several trends, both in business and in writing for translation, are changing the impact of these issues on the localization process. The economy, along with the current business focus on return on investment (ROI) and offshoring of professional jobs, pressures product development teams to create products better, cheaper and faster than ever before. Increased demand for products and services by non-US customers and the more restrictive regulatory environment that has developed in the European Union (EU) force simultaneous releases in the local language and require US-based companies to better understand their global markets. This increased demand, in turn, forces US-based companies and workers to recognize the need for process development, for training and for the development of new metrics for quantifying their work. Also, as a result of these increased pressures, technical communicators have had to develop creative solutions for producing large quantities of content in a myriad of formats, which has led to structured content and single sourcing content management. Structured content and single sourcing, as well as improved workflow technology, are then driving the move toward a streaming development model where the product and content are in constant flux rather than having specific releases of new versions.

Business Climate

Everyone has heard the economists' doom and gloom statements for the past couple of years. The bursting of the "dot.com bubble" made investors wary and led to thousands of layoffs in the United States and elsewhere. Now, economists are saying that the United States is in a "jobless recovery," meaning that the economy is improving, but new jobs are not being created. The economists attribute this to offshoring, which means professional jobs are being sent out of the United States to countries such as India where the average professional makes one-fifth the salary of an American in the same job. This phenomenon has been going on for several years in the manufacturing sector, but its application to professional jobs, such as engineering and technical communication, has investors worried and some Americans panicking about the potential brain drain. Offshoring may be less of an issue in Europe, where more stringent labor rules apply, but the implications are clear. In this economy, professionals must be able to quantify their value to the company if they are going to keep their jobs.

More than ever, companies are focusing on cost control and ROI. Product development teams, including technical documentation, need to understand their direct impact on the company's bottom line, particularly to the cost of localization where an average of $4 is spent on localization for every $1 spent on technical documentation. In other words, if a company is spending $10,000 to produce the source documentation for a product, on average, the localization of that documentation will cost $40,000.

By internationalizing the documentation and product, product development teams can significantly reduce the cost ratio between technical communication and localization without significantly increasing the documentation team's budget. This works because internationalization, in most cases, involves a modification of existing processes and an improvement in consistency in the source content. With improved editing, change management and error checking, problems are prevented (or caught and fixed) in the source before it goes to localization, rather than having to be fixed in every language into which the content is being localized.

For example, an error requires one hour to fix in the English source, the content is being translated into 34 languages, and it costs $50/hour for the localization engineer to fix it. That one error has added 34 hours to the localization schedule and will cost $1,700 to fix. If that same error is caught and fixed before it goes to localization, the error takes one hour to resolve and costs $50. It doesn't take long for such errors to significantly impact localization costs.

In addition to internationalizing the product and documentation, product development teams need to automate their processes to stay competitive. Automation accomplishes several things when done appropriately. It enables skilled workers to focus on the more challenging and difficult aspects of a project that don't lend themselves to automation which, in turn, can lead to greater innovation and improved market share. It reduces the likelihood of human error by removing the people from the more repetitive, mindless tasks in the process. It reduces costs by enabling the same number of people to complete more work in a shorter period of time, and automation improves consistency and quality by ensuring that steps are performed the same way every time the process is used.

For example, IBM asked Lionbridge to help develop an internationalized multilingual support system for IBM. Within 18 months, IBM had saved 30% on localization costs for technical support and calculated that it only needed to deflect 45 calls per day to recoup the cost of maintaining the system in each language. Those kinds of cost savings make a huge difference to a company's bottom line and may mean the difference between success and layoffs.

In this business climate, service companies, including localization companies, are feeling the pinch as well. The localization industry is just coming out of several years of significant consolidation where many small companies have become several big ones. As these companies have consolidated, they have needed to integrate their infrastructure and to consolidate their assets, all while trying to meet the demands of skeptical investors who, having been burned by the dot.com bust, are wary of investing in companies that aren't yet showing a profit.

A side effect of being a public company is that decisions often get made based on what will look good on the next quarterly earnings report, rather than what is good for the long-term health of the company. As a result, it is often easier (in the short term) for service companies to reduce head count, which is an immediately obvious expense, than it is to fix the infrastructure redundancies and inefficiencies that occur when companies grow by acquisition. Since people are the primary asset that service companies offer to their clients, injudicious choices in the culling process result in a brain drain that can make it more difficult for these companies to meet their deadlines and to accommodate their clients' needs, particularly in a time of growing demand for localization services.

Increased international demand for localized content

Not so very long ago, non-US customers had to wait months after the English release of a product for it to become available in their languages if it ever did become available. Today, regulations require and customers worldwide demand simultaneous release in their local languages, particularly for highly regulated products such as medical devices.

For many US-based companies, 40% or more of their revenue comes from non-US sales, further driving the demand for localization (Morgan Stanley presentation, 2003). This business reality is forcing many US-based companies to reengineer their products, processes and business approaches so that the needs of their international customers are considered as an integral part of the product development cycle, rather than as an afterthought to the English release.

While process reengineering has been going on for several years and many multi-national companies have become quite sophisticated at integrating localization into their processes, most US-based companies are just now becoming aware of this need. To quantify the costs associated with this endeavor, documentation managers need to treat it like a project and set it up as such in the project accounting system.

The MultiLingual Computing & Technology survey on writing for translation shows a wide range of experience related to this reengineering process. Some respondents have no idea where to even begin to look for resources on internationalization, while others are involved in developing sophisticated multilingual content management systems (CMS).

Most internationalization efforts fall between the two extremes, with the process reengineering taking the form of stronger editing processes, robust change management processes, some kind of version control, redesigned templates and content models, and more detailed style guides. None of these solutions requires a sophisticated technology-based CMS, a large usability testing lab or even a large capital expenditure. Any documentation team that has the commitment and the wherewithal to put in the time can develop a low-tech solution that will at least get the team started on the internationalization path.

The software development teams also show a wide range of understanding about internationalization, despite the fact that localizing the code is a significant part of product-related localization costs. Elements such as hard-coded strings, non-dynamic field labels and lack of white space on the screen significantly increase localization costs and yet are relatively easy to prevent and, if necessary, to fix (though retrofitting is often time consuming).

The localization industry, of course, has long been aware of the need for process integration as it responds to increasing pressure to shorten the localization cycle without sacrificing quality. Industry pundits lament the commoditization of localization as they scramble to find ways to consolidate their positions in a volatile market, to automate their processes, to educate their customers and to accommodate the move from the traditional localization cycle, where the end of the cycle is clear-cut, toward a streaming release model, where the projects often have no clear end point. Bert Esselink touches on these issues in his article "The Evolution of Localization" (MultiLingual Computing & Technology #57 Supplement).

Process and metrics

Many technical communicators are frustrated by the process of creating global content. Localization is still an unknown quantity for most US-based documentation managers. They finish the English product and documentation and hand it off for the localization team to translate and develop multilingual versions, but in many cases these managers have no real understanding of what information, resources and schedules are needed to produce a quality language variant.

Conversely, localization teams often don't fully understand what feedback is useful to the documentation teams, are so overwhelmed with work that they don't take the time to provide it, or fail to recognize the unique expertise of their documentation team counterparts. One survey respondent said, "Localization project managers don't believe that technical writing is a specialized discipline. . . . Technical writers are considered no more than desktop publishers who understand grammar." This attitude prevailed at the localization vendor despite the fact that over half of this person's documentation team hold master's degrees in technical communication.

Overriding themes from survey respondents were more and better communication with the localization team; additional training on internationalization, both for working professionals and for the technical communication students who will soon be in the field; better customer service from the localization vendors and more transparency in the localization process; and improved standards, processes and guidelines, particularly regarding change management and editing.

Even the metrics used to measure output and to develop project estimates are different so project managers end up comparing results for measures that aren't completely related. For example, technical communication is estimated in hours per page while translation is typically estimated on a per-word basis. Technical communication estimates typically include the research, desktop publishing (DTP) and writing/revising time, while translation estimates typically have those efforts broken out as separate line items.

There are other issues as well. While both technical communication and translation require similar skills in writing, editing and research, these skills are applied very differently. Technical communication tends to be a highly iterative process that involves a great deal of interaction with the product development team and, particularly with new products, starts from a concept and moves through several iterations before being finalized.

Technical communicators spend, on average, less than a third of their time actually writing. Much of their time is spent working with the product development team on product design, informal product testing, interviewing subject matter experts, investigating tools, developing templates, designing help systems, DTP, testing compiled help, performing peer edits, mentoring other team members and so on. Because technical communicators typically work closely with the product development teams, they develop a deep knowledge of the product and often have a more holistic view of it than do the engineers, who typically focus on one or two aspects of the product. However, technical communicators rarely have control over the last-minute product design changes that inevitably cause significant issues in the content and cause consternation for the localization team. As one survey respondent said, "The process of educating writers, engineers, product and project managers about translation requirements is ongoing."

Localization, on the other hand, is a production-oriented environment with specialists performing each function. Unlike the technical communicator who is frequently creating original content to explain a particular concept, the translator starts with existing source content and, therefore, has a limited number of ways to interpret those concepts, just as the output requirements, such as templates, limit the variation on the overall look and feel of the language variant.

While translators must transfer the meanings to another language, they do not typically translate word-for-word, but conceptual unit for conceptual unit so that the meaning of the concept is preserved in the translation. In addition, reputable localization companies use translators who are native speakers of the language being translated into (the target language) so that nuances of meaning are maintained and more accurate translations are developed.

Though translators must frequently research the context of something or may need clarification when the localization kit or glossary is incomplete, they have the source content, templates and structure to use as the basis for the language variant they are creating. The translator uses translation memory (TM) tools to facilitate consistency and focuses on the linguistic aspects of the content, and, while they may have a deep knowledge of the industry for which they are translating, translators typically do not possess the depth of product knowledge required of a technical communicator. DTP specialists and localization engineers put the translated content back into the desired output format. This task separation creates a more production-oriented environment for the localization team.

Both technical communicators and translators are highly trained professionals with significant expertise in their chosen fields. When technical communicators and localization team members fail to understand these fundamental differences in approach, communication failures can occur and frustration may ensue.