Best Practices for Localizing Measurements and Numeric Content

July 1, 2019by Ian Henderson
mika-baumeister-703680-unsplash-1280x855.jpg

This week we have a guest co-author, Michael Hall from Yaskawa. As Manager of Technical Communications, he’s responsible for all aspects of technical document production for the U.S. Market. Learn more below:

 

The destruction of the Mars Climate Orbiter is a notorious example of what can happen when numerical standards get confused. A programming error in one piece of software produced numeric results in United States Customary Units (USCS) instead of the intended Metric (SI). This error caused the $300 millon Orbiter to approach Mars at the wrong trajectory and be destroyed during orbital insertion. This was an error of software development rather than documentation, but the same principle applies – don’t let your technical writing lead to the next $300 million mistake!

Accuracy is the cornerstone of technical writing. Engineers and end-users depend on precise documentation to safely maintain and operate equipment. Mistakes in writing or localization can put lives in danger or lead to costly equipment damage. This is especially true of numeric content, particularly measurements, where even a single digit or symbol out of place can lead to wildly incorrect assumptions or calculations – with potentially catastrophic results.

With that in mind, ensuring the accuracy of numerals and measurements should be a top priority for every technical writer and translator, and for every organization where users depend on accurate technical documentation. In this article, we’ll take a look at some key considerations and best practices to guarantee numeric accuracy in documentation.

 

Know your standards

It almost goes without saying, but you should always be following the appropriate numerical standard – a system of measurement that clearly defines the name, symbol, and quantity of each unit.

The most common standard today is the International System of Units (SI), the modern form of the metric system. However, note that applicable standards do vary by industry and country. The most important example of this is the United States, where SI is used for science and medicine, but consumers and the manufacturing sector typically use the USCS instead.

The United Kingdom is another notably peculiar case. In the UK, SI is the official system, yet imperial units are still widely used in everyday life and in specific circumstances, such as road signage.

When creating technical documentation, ensure you are following the correct standard for your target audience and industry, and make it clear from the outset which system you are using. If multiple standards are included in a single document, consider which should appear first.

 

Keep it consistent

Accuracy and consistency go hand-in-hand, especially when translation and localization come into play. What this typically means is that it’s vital to handle all numerals and measurements in exactly the same way throughout each document.

Following a standard is a good first step, but manufacturers may have unique or specific requirements for numeric content in localized documents.

As best practice we strongly advise technical writers go a step further by creating a style guide that clearly lays out rules for dealing with numeric content. A good style guide is often the result of collaboration between the manufacturer and the language service provider.

For example, a style guide will help linguists with rules for rounding or unit conversion (the latter being particularly important when the audiences for localized documentation use different numerical standards).

You should work with marketing, legal teams and your translation provider to create style guides for each locale that you are targeting, taking into account all industry-specific standards and safety regulations. Building style guides can be a daunting prospect as they must contain more than simply rules for numeric content. Capitalization, word choice, punctuation usage are also key components of a good style guide. Writing source English content to a language standard such as Simplified Technical English (ASD STE100) can also dramatically simplify the process.

 

Check, re-check, and check again

Even the most careful writers following the most well-defined standards and style guides will occasionally make mistakes. That’s why it’s crucial to use a robust system of checks to flag any inconsistencies – both in the original and localized texts. Ask your language service provider about their quality control processes to ensure this crucial process is used to translate or localize your documents. This process can be largely automated, but it’s always worth including at least one human review.

When dealing with multiple languages, we suggest paying particular attention to the original version. Identifying issues in the original will help to anticipate and prevent issues in translation, while any mistakes or inconsistencies in the original will likely be carried over into localized versions.

 

Localize in bulk – but be careful!

Localizing your numeric content all at once can be an excellent way to ensure consistency and save time. That being said, be very careful about making global changes. For this reason, we recommend only making global changes to numerals, and not to measurements. Anyone who has ever used a “replace all” function knows how easy it is to inadvertently create gibberish words when making sweeping changes to text. It is similarly easy to accidentally break numbers and codes – and these mistakes can be much more difficult to spot. If global changes are made, we recommend a thorough comparison of the target to the source to expose unintended results if they exist. Then adjust the global replacement routine to eliminate these errors.

Also, remember that not all numeric content actually needs to be localized. Product and part numbers, for instance, will typically remain the same in all versions. Excluding this content from translation can significantly reduce the word count and, by extension, the cost. With the right tools and authoring architectures (such as Darwin Information Typing Architecture (DITA) it’s easy to flag specific numeric content for exclusion.

 

Putting it into practice

At Rubric, we recently put these principles into practice while designing a localization process for our client, Yaskawa America, Inc. – the world’s largest manufacturer of AC Inverter Drives, Servo and Motion Control, and Robotics Automation Systems.

Yaskawa’s technical documentation includes a large amount of numeric content. They use leading-edge database publishing tools to enforce strict control and consistency of content for product instructions. Yaskawa requires the same level of quality when product instructions are sent for language translation. To maximize accuracy and consistency, we created a process that enables the translators to identify and work on all the appropriate numerals at once by extracting the data from DITA and scalable vector graphics (SVG) – numeric content that does not require input from translators is excluded. We also implemented automated checks to flag up any anomalies after translation and established a final human review process to ensure quality.

These steps have relieved Yaskawa from the time-consuming burden of checking numeric content post-translation. Yaskawa’s quality assurance process for language translation enables them to review and approve final publications much more quickly.

If you’re interested in achieving similar results, consider partnering with Rubric. We’ve spent almost 25 years localizing technical manuals, developing bespoke tools, and building trust – we’ll work with you to transform your localization approach with robust processes for each project. Subscribe to our blog below to get the latest updates on translation and localization, and how they affect your business.

Subscribe to our blog

Updates on global content strategy, engineering tips, localization how-to and more - straight to your inbox!

Thank you for subscribing.
Ian Henderson

by Ian Henderson

Ian is co-founder of Rubric. During the last 25 years, Ian has partnered with Rubric customers to deliver relevant Global Content to their end users, enabling them to reap the rewards of globalization, benefit from agile workflows, and guarantee the integrity of their content. Prior to founding Rubric, Ian worked as a software engineer for Siemens in Germany.

Follow Our Activity

Stay up to date with our latest activity relating to Global Content.