Taking a Comprehensive Approach to Developing Translation-Ready Standards

Home/Publications/Best Practices Newsletter/2007 – Best Practices Newsletter/Taking a Comprehensive Approach to Developing Translation-Ready Standards

CIDM

February 2007


Taking a Comprehensive Approach to Developing Translation-Ready Standards


CIDMIconNewsletter Tony Washington and Catherine Strange, LSI Logic Corporation

In early 2005, the technical publications department in the storage division of LSI Logic received a mandate to develop content for translation. Fortunately, this mandate applied initially to selected content: the online help, a setup guide for a hardware product, and a safety notices guide. This mandate came less than six months after we implemented single-sourcing to better support our OEM model, in which we develop information for our OEM customers.

Moving to single-sourcing established a foundation for supporting translation. We already had implemented the Darwin Information Typing Architecture (DITA) and purchased the Vasont content management system. Doing so helped us to more easily deliver content to our OEM customers.

Before single-sourcing, we delivered FrameMaker files to OEM customers, who then cut and pasted the content into their own documentation. Now, we provide XML files of only the content that OEM customers need. From a tools perspective, this new method had translation advantages. We could also give our translation vendor XML files of only the content that needed translation.

From a language perspective, however, our writing standards did not support developing translation-ready content. Our documents were long and full of inconsistent terminology. Procedures contained too much conceptual and referential information that was not required to perform tasks. Many times, our documents contained expressions acceptable to a US English speaker, but these expressions would not translate well to other languages.

Translation costs depend on the number of words in a document, and identical phrases or sentences can reduce the cost because of translation memory. Single-source reuse would help to reduce some of the inconsistency in our documentation, but if we continued with our existing standards, translation would be expensive.

Search for a Solution

The metrics team was tasked with defining metrics to measure how well we achieved the project’s objectives, which we defined as follows:

  • Improve information quality
  • Improve information development efficiency

We began by stating desired outcomes that supported the objectives. We then refined the outcomes to reflect what was feasible to test during the pilot phase of the project. By focusing on specific outcomes for the pilot, we eliminated duplicate or invalid metrics. (In some cases, the same metrics could support multiple outcomes.) The remainder of this article describes some of the metrics that we developed.

Metrics for improving information quality

We knew that superficial changes to our existing style would not give us the long-term support we needed to meet our new translation requirements. We could have developed only guidelines for word choices to comply with localization. But that approach did not address the usefulness of our document set as a whole or the verbosity in the documents themselves.

To be effective, any solution would need to address our development practices comprehensively, from how we plan and design our information to how we use terms and express ideas. In doing so, we would see opportunities to streamline our information.

One of our first tasks in developing our new standards was to identify the three major components of those standards. These components became the building blocks upon which we based our standards.

  • Architecture – We already had adopted a topic-based architecture to support our single-sourcing effort. We needed to formalize how this architecture could support our translation effort, for example, how we should break down our content into smaller, reusable pieces of text.
  • Design – We needed a design strategy that would help us to reduce the amount of content that needed translation without sacrificing usability. This strategy required a better understanding of the information needs of the user.
  • Style – We needed guidelines for writers on how to think globally when constructing text that would be translated. These guidelines also needed to address consistency. In addition, we would need a glossary that we could provide to the translation vendor for definitions of the terms we used in our documents.

After we were satisfied that these components addressed translation requirements comprehensively, we began researching the specific requirements for each component.

Our research took two main paths:

  • Vendor consultation – We consulted our translation vendor and reviewed literature from other companies and associations that specialize in translation and localization. The goal of this research was to better understand key translation principles and to identify best practices for implementing these principles. The information we gathered from this research helped us to identify new design strategies.
  • Usability research – We consulted our own in-house usability experts and reviewed literature from external usability practitioners. The goal of this research was to ensure that any strategy we implemented met usability standards. Although we were too early in the process to conduct actual usability tests, these consultations helped to ensure that we balanced business requirements, such as translation, with user needs.

Our New Standards Defined

From the analysis of this research, we used the building blocks of architecture, design, and style to create a comprehensive set of standards.

Topic-based architecture

Before the translation requirement surfaced, we already had identified a topic-based architecture to support our single-sourcing effort. We realized, however, that we could leverage this architecture in our translation effort.

We chose a topic-based architecture to help support how we develop, manage, and release information. Through this architecture, we focused on smaller chunks of information (or topics) rather than books. Because we chose DITA as the basis of our architecture, we could categorize all our topics into three major types—task, concept, and reference. Any information that we developed had to fit within one of these types of topics. This strict categorization helped us to identify and eliminate unnecessary or unclear content.

Additionally, we knew what structure each type of topic must follow, that is, what kind of content should appear in a topic. For example, we could specify that all task topics include pre-requisites or omit step results. We rendered this structure with XML tags that helped us to label the content for easier storage in our content-management database.

With its focus on type and structure, our topic-based architecture helped us to streamline our content. A strict structure helped to prevent clutter that could complicate translation. In addition, having topics in a content-management database helped us to better organize and track our content for reuse, which also significantly reduced the cost of translation. Because a topic that already had been translated did not need to be translated when reused, we were able to give our translation vendor batches of unique topics instead of entire documents for translation.

Minimalist design

Although our topic-based architecture specified the type and structure of any given piece of information, the architecture did not tell us what information we should include in any given deliverable. Instead, our OEM model dictated information requirements. Product specifications often dominated these requirements. With little access to users for proper analysis, we developed information under the assumption that including more information in user documentation was safer than including too little information.

Unfortunately, this assumption led to a large documentation set and verbose documents—both of which made our content potentially expensive to translate. We needed an approach that would help us provide just the information that users need to complete important tasks. Minimalism fit that kind of approach.

We chose a minimalist approach to help us align user information with user expectations. Through a stronger partnership with OEM customers and in-house usability experts, we analyzed user tasks to better focus our information on real user goals. From the user task flow, we identified the task topics that were essential to completing a task. Next, we identified conceptual topics and reference topics that supported the task topics. We removed any topics that did not support a real user task. Within the remaining topics, we identified opportunities to reduce the text that we use to convey information. These opportunities included replacing long explanatory text with tables, figures, and diagrams.

By beginning with what the user is trying to accomplish instead of what the product can do, we reversed previous assumptions about user information needs. Now, any information we develop must be linked directly to a goal that a user is trying to accomplish. In addition, by pursuing a more visual approach to conveying information, we reduced wordiness in our documents. By streamlining our content this way, we were able to reduce the cost of translation without sacrificing the usability of our content.

Translation-ready style

While our topic-based architecture and minimalist approach represent a fundamental shift in how we structure and design our information, the translation-ready style guidelines became the bulk of the sentence-level tactics that we used to develop text.

We chose a translation-ready style to help us standardize terminology and expression. This new style accomplished our goal by helping us to identify approved terms and ensure that words and concepts were expressed clearly, without having multiple interpretations. To help ensure that we used consistent terminology, we developed a corporate-specific glossary that the translators could use to find the definitions of terms. Our translation-ready guidelines helped our writers think more globally. For example, they knew that although an expression might sound unnatural to the US English ear (such as using “rear” instead of “back”), the newer expression helped with translation.

By standardizing the use of grammar and word choice and by creating a glossary of storage terms, we helped to ensure more consistency across all pieces of text. Consistency in text is a key component in reducing translation costs.

From Theory to Practice

After we defined our standards, we moved quickly to practical application. Our implementation included the following activities:

  • Updating our style guide to include real-world examples of the more stringent
    styles and annotated models of the types of content our writers needed to develop
  • Redesigning our templates to support our new standards
  • Developing new editorial review criteria to evaluate content at all levels
  • Providing departmental training and continued support, including regular department presentations

To help ensure successful implementation, we identified the three levels at which we could apply the standards: global, section, and sentence level.

Global-level strategies

At the global level, we look at how we can apply our standards within a document and across many documents. The goal at this level is to make sure that the information we provide is structured according to users’ true goals and tasks.

Here are some key questions that we ask at this level:

  • Have we documented user tasks instead of product features?
  • Can users instantly recognize instruction as genuine or do they have to read through too much text to get to real tasks?
  • Have we organized the information logically and consistently?

Section-level strategies

At the section level, we look at how we can apply our standards to topics and collections of topics, such as chapters. The goal at this level is to convey information more visually and with the least amount of text to get users to complete tasks.

Here are some key questions that we ask at this level:

  • Are information components, such as topics, linked to a real task sequence?
  • Have we kept paragraphs short, limiting each to one idea?
  • Are we using graphics and tables instead of long explanatory text?
  • Are we including only relevant information in graphics?

Sentence-level strategies

At the sentence level, we look at how we can apply our standards at the lowest level in which text is constructed. The goal at this level is to make sure that sentences use clear and concise language.

Here are some key questions that we ask at this level:

  • Have we used simple declarative and imperative sentences?
  • Have we replaced flowery words with concrete, meaningful ones?
  • Have we used terms consistently?

Results

Fortunately, we were able to apply these standards to selected content before we submitted the content for translation. The limited scope of our initial translation project allowed the necessary time to research, develop, and implement these standards. As a result, we have no before-and-after data to compare the cost of translating content that is translation-ready with the cost of translating content that is not ready for translation.

Nevertheless, research shows significant savings in preparing content for translation before sending that content to a translation vendor. For example, just by implementing internationalization recommendations and improving the editing process, a company can achieve a savings of up to 40 percent on localization. In addition, a company could expect increased customer satisfaction scores from the improvements in usability and readability.

Our next major step is to apply these standards to our remaining content. By taking a comprehensive approach to developing translation standards, we have increased opportunities to achieve cost savings and customer satisfaction. CIDMIconNewsletter

About the Authors

Tony

Tony Washington
LSI Logic Corporation
Tony.Washington@lsi.com

Tony Washington is a technical editor in the storage division of LSI Logic Corporation. Based in Wichita, Kansas, Tony brings more than 12 years experience as a writer and an editor. In his current position, he helped to define the rhetorical requirements for the department’s single-sourcing efforts and to establish the department’s minimalist strategies to support translation and localization.

Catherine_1

Catherine Strange
LSI Logic Corporation
Catherine.Strange@lsi.com

Catherine Strange is a technical editor in the storage division of LSI Logic Corporation. Catherine is located in Boulder, Colorado. She has worked as a technical writer and editor for 26 years. In her present position, she is responsible for maintaining the department style guide and glossary, as well as editing product documentation.

 

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close