[DITA Loc Wire series] In September 1999, Mars Climate Orbiter, a NASA uncrewed spacecraft, crashed after ten months of travel, coming up too close to the planet and hitting the uppermost atmosphere. The primary cause of failure was a discrepancy in the units between two pieces of software, respectively expressed in the International System and the US customary system. Measurement units in the documentation are a sensitive matter. Their translation in different languages for several countries should be considered carefully.
Although you can easily find conversion tables, we consider it dangerous to leave it up to the translator without any guidelines.
Data must be expressed in the target country’s unit
a 5ft. cable will be translated:
- Un câble de 1,5 m in French for France
- Un câble de 1.5 m (5 pi.) in French for Canada
In this instance, the units are adapted for two distinct French-speaking countries: France and Canada. Although general content doesn’t require adaptation to the French-speaking Canadian audience, specifications and relevant data should be.
Likewise, displaying inches in documentation for France clearly states “I am a North American company, and I don’t care about your market.”
Data must display the correct number of decimals
When writing this article, I remember the time I spent, as a technology engineer, explaining to my son, a student in science, that concentrations of 3.0 mol/L and 3 mol/L were significantly different or that when I was running 5.2 meters in 1.75 seconds, I was not running at 2.9714285 m.s-1 despite what his calculator was indicating.
When a translator has to translate a car fuel consumption of 52 MPG should he take the initiative of displaying 4.52 L/100 km or 4.5 L/100 km?
In this example, there’s a catch: if 52 MPG is a British, not a North American value, then the conversion is 5.4 L/100 km – a US gallon is larger than an imperial one.
Data must integrate the country’s standards
Sometimes localizing a measurement unit also requires applying the relevant standard. Here’s a real-life example:
Use 14 AWG wire size or larger
The version for France read:
Utilisez un câble de 2,08 mm² ou plus
Unfortunately, 2,08 mm² cables are not a standard size on the French market; the next size up is 2.5, so the appropriate translation is:
Utilisez un câble de 2,5 mm² ou plus
Use 14 AWG wire size or thinner
Should be published in France:
Utilisez un câble de 1,5 mm² ou moins
Best practices for unit conversion
Converting measurement units requires more than the translation by a linguist. A Subject Matter Expert should at least review the content. Ideally, the translation and review process should be laid out either when designing the source content or in the style guides.
Can the process be automated or assisted?
When you are using structured content and more specifically DITA, you can rely on the versatility and toolset of the standard to build efficient solutions.
If you have a limited number of values, you can list them in a table and localize the table for each language and target country pair. This especially applies to converting standards.
If the measurement units are correctly tagged, they can be automatically processed in the publishing stage.
Below is a very efficient implementation performed by Bob Thomas (Tagsmith LLC) for the industrial group Emerson. The measurement units are tagged with an outputclass called measurement, which is automatically processed during publishing by a stylesheet
17 psia to 100 psia at 68 °F
Please also note the use of the translate attribute to ensure that the translation will not alter the values.
For the U.S., Canada, UK and Australia it is published:
17 psia (1.17 bara) to 101 psia (6.96 bara) at 68 °F (20 °C)
They selected Imperial first since the U.S. is their primary market, but they could have published metric first for certain countries.
The same content, once translated, renders:
1,17 bara à 6,96 bara abs. à 20 °C for customers in France
117.2 kPa ~ 696.4 kPa (20 °C) for Japanese customers
Please note that the stylesheet also managed the formatting of decimal numbers based on the country. Designing such a process and stylesheet is an investment that is quickly offset by the cost of translation, the time spent on reviewing and correcting, as well as the liability risks.
This is one of the best practices we have encountered, but there might be other ways to publish country-specific values and units using DITA. For instance, with WhP, as part of our Localization-Ready Techno solution, we have developed a DITA specialization instead of an outputclass to perform the same processing as indicated here above.
Special thanks to Bob Thomas with Tagsmith and Emerson for sharing his approach.