February /March 2004

Volume 44, Number 4

Trends in writing for translation, part 2

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

Structured content, single sourcing, and content management

Interestingly enough, however, the move toward structured documentation and content management is pushing technical communication toward a production model, as industry moves away from the book paradigm and toward a more fluid view of content as a unit of information where each module represents a particular concept. Modules can be as small as a paragraph or as big as a section.

In this scenario, senior writers and editors work with the document type definition (DTD) designers and software engineers to develop the XML content model, information product design and metadata. Junior and mid-level writers become responsible for writing particular content modules and assigning the approved metadata tags, but no longer worry about the layout and design, the structure of the information (which is predefined by the DTD), or in which medium the content will appear. Instead, they focus only on developing the content, much as a translator working in a TM tool does today.

When such systems are fully implemented, content is completely divorced from the layout and design of the final information product, with the content being stored in a database or other repository. The content is then pulled into a particular format by XSLTs (Extensible Stylesheet Language Transformations) and/or scripts that dictate its final form. Such templates, style sheets and scripts associated with structured documentation dictate the structure, metadata and output processing in addition to the layout. With the push of a button and the selection of the appropriate metadata, the writer can produce on-line help, Web page or printed documentation in hours instead of months, assuming the content has been previously developed and is stored in the database, thereby maximizing content reuse. The writer still has to perform the production edit to ensure that nothing has gone awry with the automated DTP process, but the structure and overall look-and-feel are dictated by the predefined formats and DTDs.

This methodology has huge implications for localization as well where much of the cost and time associated with localizing content falls into the DTP and localization engineering phases of the project. Because XML and tools associated with it are in their infancy, not all of the tools support all code pages (despite the fact that XML itself is fully Unicode compliant). This means that localization teams must devise custom scripts and other workarounds in order to meet their deadlines. However, assuming that the team has done the appropriate planning and preparation, has developed robust change management and editing processes, and has created and tested the scripts and automated processes with localization in mind, companies could shave three to six weeks or more off of their localization cycle (the time typically required for final DTP). But it may take a release to realize these time and cost savings as the bugs are worked out of the process. The savings don't stop there, though.

Because such systems have many team members creating and editing content, it becomes necessary to implement stringent controls over the development, editing, storage/ retrieval and change management of the content. Style guides, terminology management and strong editing processes are vital to success in such environments; otherwise, content developed by different writers and pulled together into a single deliverable may not flow correctly, thereby reducing its usability. In addition, if it takes the writers more than a few minutes to find an existing content module, they will simply write another one, so the content must be structured, indexed and tagged with metadata in such a way that the writers can enter a keyword and find the content they need immediately.

Quality metadata, stringent editing processes and robust change management processes are vital to the success of these systems. Quality metadata enables the writer to quickly determine whether or not a content unit exists in the system, to retrieve and use that content unit as needed in whatever format it is needed in and to properly store the content module once it has been created.

Stringent editing ensures consistency, prevents redundancy, reduces errors and improves quality. Editors in this environment are typically senior-level team members who have deep product knowledge as well as an eye for detail and good grammar skills. They ensure that each content module flows smoothly and sounds as if one person created all of the modules, even if 20 different people worked on the content. They also prevent preferential changes from creeping into the system. Such changes can significantly increase localization costs because each variance from the originally translated text must be verified by a translator in each language into which the content is being translated.

Robust change management processes prevent the introduction of preferential changes late in the product development or localization cycle. All team members are taught the cost of changing previously translated materials so that they can accurately determine the cost vs benefit for a particular change. The team leads rank each change request as vital, important, nice to have or cosmetic. These rankings determine when and if the change is implemented. In early stages of product development, most changes are implemented (unless it's determined that a cosmetic change will significantly impact existing translation memory assets). However, if the content is in the final QA stage for localization, only vital changes are made, and then only after the team has completed a cost/benefit analysis (which can be as simple as saying that there is an unacceptable risk of death or injury if this change is not made).

All of these process improvements not only improve the quality of the source content by making it more consistent but also have a direct impact on localization costs. Esselink provided the following example: if a customer has a document that is currently being updated and does not have a CMS, the customer typically pays for verification checks on full matches and fuzzy matches. (Fuzzy matches occur when some of the text in a segment is identical to previously translated source text, but other text is not.) On the other hand, with a CMS, only new text is sent to the translator, so the translator doesn't see the existing, unchanged text. This process can save significant localization costs in terms of file preparation, translation time, match payments and so on.

Even if the documentation team is not ready for single sourcing, XML or a technology -driven CMS, implementing robust change management and editing processes and improving consistency will better position the team for making the transition to such systems. At the same time, these processes will provide immediate cost savings on localization. For example, just by implementing internationalization recommendations and improving the editing process, one client achieved a 20% savings on localization with the next release and increased customer satisfaction scores at the same time. While other teams may not see such a high return immediately, internationalization is still worth the effort as the ROI becomes apparent over time.

As mentioned in Donald DePalma's article, "Establishing Key Performance Indicators for Localization" (MultiLingual Computing & Technology #57 Supplement), one of the roadblocks to doing this is that localization and documentation typically come out of different budgets within a company, so unless the two teams work out a cost-sharing agreement, the significant savings are reaped by the internal localization management team, while the costs for implementing the processes come out of the documentation team's budget. And because most companies haven't developed the metrics for quantitatively correlating the internationalization process with savings, it's difficult for the documentation team to quantify their value. Looking holistically at the problem, this issue all seems rather silly since ultimately all the money involved comes from the company's pocket, but this is a business reality. The caution here is for the documentation manager to work closely with the internal localization budget manager to ensure that cost-sharing is in place and that the metrics quantify the cost savings once internationalization processes are in place.

Streaming development model

The traditional development model meant freezing the code and documentation at a point in time and shipping it to the customer. Only when the source code and documentation were finalized were they sent to localization.

With the streaming development model, the content and product are continuously updated with little concern for a specified release schedule. This methodology is possible because of the more sophisticated tools for content management, as well as for automating workflow.

What frequently happens is that the content is evaluated for stability, and the most stable content is approved and sent to the localization team, while the more volatile content is still under review. As each batch of content is approved by the product development team, it is sent to the localization team via automated workflows in a continuous update cycle.

While these processes primarily apply to multilingual Web sites with database-driven content, there is potential for these techniques to be applied to more traditional documentation, as tools become more sophisticated and as more companies adopt technology-based CMS.

The implications for both localization and content development are clear. Both teams must become comfortable working with content that is in greater flux and where product release is not the driving factor in the deadlines, but customer need is. These teams must work closely together to develop efficient processes for transferring content in a continuous flow, while stringently managing costs and changes.

Conclusion

These days, everyone wants a quick fix, but not every problem has one. Unfortunately, there are no magic potions, no real shortcuts to ensuring that internationalization is done effectively. Internationalization and writing for translation have many variables associated with them, even without considering the scope and schedule issues that inevitably arise. Tweaking even one of these variables can significantly impact localization costs.

So, how does one get started? First, educate the documentation team members on the need for internationalization. Help them to understand the business drivers for such changes. Then analyze and revise the style guide, templates and processes so that they better accommodate localization. Identify areas where similar content is used over and over and then standardize it so that it can be reused more effectively. Build robust editing and change management processes and use at least a basic version control system.

As Paula Berger, a technical communication consultant, points out, "Writers are learning that modularizing, standardizing and reusing content benefits their writing in terms of quality improvement as well as time and cost savings. It's not a big leap for them to then see how they can reap those same benefits by extending their use of modularity, standardization and reuse to their localization process, their document management process and eventually to a CMS."

Internationalizing content doesn't require a huge capital expenditure or fancy CMS. All it requires is good processes, team commitment and a little ingenuity. The reward is in the significant cost savings to the company in terms of localization, and internationalization positions the team for moving toward a more sophisticated CMS. That's a story every manager likes to hear, especially in today's economy.

SIDE BAR TEXT

Tips for Better Localization Projects

AUTHOR'S NOTES:

Just as there is no magic pill for weight loss, there are no magic pills that will make your teams work more effectively with each other and your projects run more smoothly. The following recommendations don't require a significant outlay of capital, but they do require some time and effort to implement. However, the time you spend working on these recommendations will more than pay for itself in terms of better-functioning teams, fewer problems and better products which, in turn, lead to higher profits and faster time-to-market.

These two checklists are steps localization vendors can take to work more effectively with documentation teams and steps allowing documentation teams to work more effectively with localization vendors.

The key idea for localization vendors is customer service. The key idea for documentation teams is appropriate planning.

LEFT COLUMN: Working Effectively with Documentation Teams: Tips for Localization Vendors

Establish a rapport with the documentation team. Take time to understand its processes, limitations and needs. Spend time getting to know clients. A good relationship with the client enables you to resolve problem situations more effectively. Follow up conference calls with e-mails confirming understanding of the action items.

Educate your clients on what you need from them to be effective. Many US-based documentation teams have little understanding of localization processes and what your team needs to produce a quality product. For new clients, use the first project meeting to provide them with checklists and training on your processes and set their expectations accurately.

Identify where your processes intersect with the documentation team's processes and work to ensure smooth handoffs to reduce last-minute crunches. Show the client your process and explain where it is most cost-effective to introduce changes. Understand the client's product development process and suggest ways to make it more efficient.

Work with your clients to create measurements of success. Learn your client's language of business and help them quantify cost savings. Show them where internationalization efforts are providing payoff in money and time savings. If their templates contain issues that add to DTP time, explain how this adds to costs. Help the client improve time-to-market.

Be responsive to requests from your clients to help ensure localization requirements are included as part of the overall project plan. Respond to inquiries in 24 to 48 hours. If you need to research a response, let the client know when you will get back to him or her. Ask clients to prioritize requests. If the client is asking for information from you, take it as a good sign.

Provide your clients with lists of what they need to include with handoffs, the information you need and in what format. Take time to explain what you need and why. It will make handoffs more efficient and reduce time-consuming re-drops.

Be responsive to requests for input on tools and processes. This indicates that the client is considering your needs when making buying decisions.

Plan for late-breaking changes, scheduling issues and scope changes. Much of localization depends on getting source content from the client on time. Delays and changes lead to last-minute crunches and stress for team members. Discuss change management, including costs, so clients can evaluate the cost/benefit ratio of changes they are considering.

Close the feedback loop. Proactively identify problem areas in the source content. Most localization vendors use some sort of issue tracking, so make sure the client is in the loop for issues that stem from the source content. Explain why it's an issue and suggest solutions. Taking an hour early in the project to provide this information could save a week's worth of work later on.

Communicate, communicate, communicate. Every project post-mortem I have attended has listed communication as an issue. It is virtually impossible to communicate too much. Request that your client provide you with a primary contact for technical questions. If you see a problem, be proactive and let the client know as early as possible. Provide solutions.

RIGHT COLUMN: Working Effectively with Documentation Teams: Tips for Localization Vendors

Establish a rapport with the documentation team. Take time to understand its processes, limitations and needs. Spend time getting to know clients. A good relationship with the client enables you to resolve problem situations more effectively. Follow up conference calls with e-mails confirming understanding of the action items.

Educate your clients on what you need from them to be effective. Many US-based documentation teams have little understanding of localization processes and what your team needs to produce a quality product. For new clients, use the first project meeting to provide them with checklists and training on your processes and set their expectations accurately.

Identify where your processes intersect with the documentation team's processes and work to ensure smooth handoffs to reduce last-minute crunches. Show the client your process and explain where it is most cost-effective to introduce changes. Understand the client's product development process and suggest ways to make it more efficient.

Work with your clients to create measurements of success. Learn your client's language of business and help them quantify cost savings. Show them where internationalization efforts are providing payoff in money and time savings. If their templates contain issues that add to DTP time, explain how this adds to costs. Help the client improve time-to-market.

Be responsive to requests from your clients to help ensure localization requirements are included as part of the overall project plan. Respond to inquiries in 24 to 48 hours. If you need to research a response, let the client know when you will get back to him or her. Ask clients to prioritize requests. If the client is asking for information from you, take it as a good sign.

Provide your clients with lists of what they need to include with handoffs, the information you need and in what format. Take time to explain what you need and why. It will make handoffs more efficient and reduce time-consuming re-drops.

Be responsive to requests for input on tools and processes. This indicates that the client is considering your needs when making buying decisions.

Plan for late-breaking changes, scheduling issues and scope changes. Much of localization depends on getting source content from the client on time. Delays and changes lead to last-minute crunches and stress for team members. Discuss change management, including costs, so clients can evaluate the cost/benefit ratio of changes they are considering.

Close the feedback loop. Proactively identify problem areas in the source content. Most localization vendors use some sort of issue tracking, so make sure the client is in the loop for issues that stem from the source content. Explain why it's an issue and suggest solutions. Taking an hour early in the project to provide this information could save a week's worth of work later on.

Communicate, communicate, communicate. Every project post-mortem I have attended has listed communication as an issue. It is virtually impossible to communicate too much. Request that your client provide you with a primary contact for technical questions. If you see a problem, be proactive and let the client know as early as possible. Provide solutions.