Outsourcing manufacturing is big business. Many companies today use the services of other companies to make, even design, some of their products as it can provide them with needed components or products without owning and operating a factory to do this work themselves. The benefits are cost savings, improving time to market, and access to a wider range of products than they could develop themselves in-house. Both hardware and software are outsourced.

What’s an OEM?

Companies to whom manufacturing is outsourced are called Original Equipment Manufacturers (OEMs). An OEM is a company that “manufactures goods that are sold to other businesses that might rebrand them and sell them at retail”. Source of OEM definition.)

An Original Design Manufacturer (ODM) is a company that “designs and manufactures a product which is specified and eventually branded by another firm for sale”. (Source of ODM definition.)

OEM and ODM products are used in many industries, but particularly so in electronics. These companies are located around the world but many are based in Asia. In this article “OEM” has been used to cover both OEM and ODM companies.

The OEM source files

If you are rebranding or rewriting OEM documentation, be aware that in the world of OEMs, Microsoft Word rules. As cost control is a big issue with many OEMs, few have technical writers in-house but instead get their engineers to write the documentation. They use Word.
And often they’re not writing in their mother tongue – most OEMs aren’t located in English-speaking countries. The documentation consequently can often be poorly written and riddled with an “English” contaminated by another language.

Rewriting OEM manuals can be challenging, particularly if you’re working to a tight deadline and the English is poor. If your company works with many OEM products, a further challenge is trying to keep the rewritten manual consistent with the content of the other manuals in your company. Reuse of content is particularly important to help control translation costs. Yet writing for reuse can at times feel a challenge when you’re struggling with reading to comprehend, particularly if you don’t have access to the OEM engineers to ask what they meant in the text they wrote.

Some companies just simply rebrand an OEM manual and leave the content as is. There are unfortunately many examples of such manuals on the internet. Lots of companies don’t have the services of technical writers. And don’t consider the business benefits of having them either.

Keeping terminology correct and consistent

Working with OEM software and documentation increases the need for terminology control as there’s a greater chance of unapproved, inconsistent, and incorrect terms being present than when content is developed in-house. Even when correct, terms may also not always be the same between companies.

Build a glossary of terms related to your OEM documentation and software that includes both the correct and incorrect terms. Include context of use, the definition of the term. So next time a writer in your group is working on an OEM manual and they come across “appearance time”, for example, they can quickly look it up in the glossary and see that this must be changed to “display time”. As with all glossaries, this is a living document and must be regularly maintained.

Fluency in other languages is certainly a help when working with OEM documentation as it can make it easier to spot problems with terminology. One example we had of “flavoured” English was in the software of a French ODM we used to develop a program for us. They used the term “equipments” throughout the English source software. We changed this franglais (English with French influence) term to “devices”. The word “equipment” exists in both languages but the context of use can differ. In French this is called a “faux amis” or “false cognate” in English. Be continually on the lookout for such faux amis when checking software and documents written by OEMs.

Where possible, give the OEM your company’s glossary of approved terms to use when customizing products for your company. But continually check that your company’s approved terms are indeed being used, particularly when the product is updated. A different engineering team perhaps might be put in charge of the product update and for whatever reason they could ignore or overlook your glossary. Stay alert.

Legal issues

Reuse as is or rewrite the OEM documentation? This question will be answered in the contractual agreement drawn up between the OEM and the company using their services. It will specify whether the product documentation will be handed over by the OEM to be customized. So if you have any specific documentation needs, such as you want to the source files in XML, FrameMaker, or HTML, for example, you should ensure that this is agreed upon before any contractual agreement is signed. But as stated earlier, most OEMS work in Word.

In my experience, many OEM manuals have incomplete or no regulatory information included, where required. If you are rebranding/rewriting OEM manuals, check that all required legal information is indeed included for your market. Although legally the manufacturer is responsible for placing the CE mark on the product, for example, once you rebrand it, you then become legally responsible. See an earlier blog on sharing source files with third party companies.

Localisation issues

In my experience, few OEM companies consider the impact of localization on their software and documentation even if they are selling their products worldwide. And that includes OEMs with in-house technical writers.

If you will be translating the documentation you’ve inherited from an OEM, you should review it for potential localization issues such as embedded text in graphics (do you have the source graphic files or just the jpeg files?), terminology (mentioned earlier), and possible cultural issues in the content. One OEM my company worked with had in-house native English-language technical writers who targeted their documentation to the America market although the OEM sold its products in many other countries. They had, for example, used the term “Thanksgiving” in a section of a user manual on programming schedules instead of the generic “public holiday”. We had to carefully go through their manuals to ensure that the content was culturally neutral for our market in Europe, Middle East, and Africa.

In summary

• From the contractual agreement and your product managers, find out what has been agreed with the OEM with regards to the documentation.
• Develop a glossary specific for this OEM (or expand your group’s glossary) that includes correct and incorrect terms.
• Check that the legal information in your rebranded/rewritten documentation is correct and complete.
• If you translate, check for potential localization issues.

One of the biggest problems I have when planning the localisation of the documents that I receive is the issue of embedded text in graphics.

Embedded text is more expensive to deal with than using numbered callouts in a graphic. However, writers aren’t always keen on using numbered callouts with graphics as they feel they can make the graphics harder to read. So there can be a challenge between meeting localisation budget demands and producing documentation with easy to use graphics.

There is probably a cultural element here, too, as European readers may be more used to seeing numbered callouts used in documents than perhaps North American readers due to the number of languages that must be catered for in Europe.

But with careful planning, graphics can still be both cost and visually effective.

The cost implications

Localizing embedded text in graphics is expensive and time-consuming. Let’s say you have a graphic in Adobe Illustrator with some text embedded in it and you need it in 10 languages. Each language will be placed in a separate layer in the graphic file. To do each translated version of the graphic takes around 15 minutes per language. That’s 2.5 hours. For one graphic. The translation agency charges, say, 30 euros an hour for such work (this doesn’t include the actual translation which is a small cost).

This single graphic has cost 75 euros to put into 10 languages. If your document has, say, 10 graphics requiring similar work, you’ve spent 750 euros getting these 10 graphics into the required 10 languages. It’s taken 25 hours to localise the graphics in one document, around three working days.

It would cost much more, and take more time, if the graphics are jpegs with bitmapped text.

Using numbered callouts in the graphic with the associated text included in a legend underneath means that the text can be easily translated using translation memory tools along with the documentation. This improves consistency and reduces cost. And there’s no cost to modify graphics.

If you send dozens of documents a year for translation to an agency, the cost of translating embedded text in graphics quickly accumulates. Management may start asking why it’s spending such sums which could be reduced or avoided. We need to ensure that we’re using our localisation budgets wisely and diligently. The money spent dealing with embedded text could perhaps instead be used, for example, in releasing documentation in further languages for new markets.

Make room for the text

Translated text takes up more space than English, the usual source language. And the impact of text expansion is much more pronounced with short blocks of text, such as text callouts, than with long paragraphs. Leave room in the English document and graphic for the text to expand once translated.

Sometimes when working in Word, a writer may place text boxes on graphics to avoid using numbered callouts. This is not recommended. Translation memory tools can’t access text inside a text box. It must be manually extracted for translation, introducing a risk of error and inconsistency. There is also the risk that when a text box is placed on a graphic, the translated text may then hide much of the graphic due to expansion.

It’s also important to tell the translation agency which terms in a graphic-associated text are not to be translated. Some embedded text such as measurements, product names and text embossed on to the product itself can stay in English and needs no rework.

Screen shots

Ideally translated documents should have their screen shots in the local language. However, it’s expensive and time consuming to get all the screen shoots in the required languages.

Best practices

Try to limit the number of graphics that require localization in order to facilitate the localization process and help control costs. Before sending your documents to a translation agency for a quote, check the graphics for any potential localisation issues and either fix them in the English source file to avoid incurring extra costs or tell the agency what you expect them to do to the graphics and pay.

Use numbered callouts: Use numbered callouts with a legend underneath rather than embed text in your graphics. The text associated with a graphic is then translated as part of the main text of the manual. Numbered callouts are particularly cost effective when you are doing several languages.

Plan for text expansion: Plan for translated text to occupy 100% more space than the English. Leave plenty of white space around text callouts (if not using numbered callouts) and callout lines in the graphics.

Screen shots: Limit their use. If you are not translating the screen shots in a manual, tell the translation agency how to handle the English GUI text that appears in the main body of the manual. It helps users to have the GUI text translated so an effective way to do so in this situation is to include the translated GUI text in parenthesis alongside the English GUI text.

Even if you only produce documentation in a single language and don’t deal with an international audience, using consistent terminology matters.

SDL recently released the results of a terminology survey that they conducted earlier this year. The study is an interesting review on the trends and opinions on the subject of terminology management.

They asked two groups about terminology management: a business audience and translators.

When asked what they considered to be the most important impact of inconsistent terminology, the business audience replied the quality of the content, internal communication and customer satisfaction. Inconsistent terminology also impacts the cost of translation and branding.

Three departments are largely responsible for owning the terminology in a company: Technical Publications, Translation/Localisation, and Marketing. They’re responsible for the management, maintenance and approval of terminology.

The most common internal process they used for managing terminology were style guides and spreadsheets to store terms. Over 35% of the business respondents said that they keep their terminology in a style guide. However, only 50% shared their terminology lists with other departments in the company.

This lack of sharing with other departments obviously increases the risk that departments could be using different terms for the same meaning. And yet, as so many departments in a company use common terminology—not just technical publications and marketing—it’s a lost opportunity not to collaborate in sharing terminology to ensure consistency.

All parties taking part in the survey agreed that the problems related to inconsistent terminology start with the source documentation. Indeed 40% of translators said that they frequently encountered inconsistent terminology.
The translators said that the main impact of inconsistent terminology is on translation quality, style and consistency, client satisfaction and their productivity. These are the parameters often used to measure a translator’s success and performance. We can conclude from this that consistent terminology makes the translator’s work much easier as well as improving quality.

An interesting point shown in the survey is how few companies take responsibility for their terminology in the localization stage. The translators said that only 15% of clients drove terminology management. Terminology management just isn’t part of the localization strategy of many companies (they do have a localisation content strategy, right?). Indeed it’s more likely that the translator takes ownership of terminology than the company that created the source documentation being translated. We put all that effort in creating a document and then practically abandon control over it when it moves to another language.

An example: Same meaning, different terms

Over the years my company has been through various acquisitions and mergers. Being a global company, content is also created across the globe by different groups. The content is often then reused in different documents. All this has provided many opportunities for inconsistency in our terminology. For example, the following six terms have all appeared in our product datasheets.

• Operating temperature
• Temperature range
• Temperature
• Working temperature
• Operating temperature range
• Ambient temperature range

Unfortunately these terms all describe the same feature: the operating temperature of a product.

The datasheets were subsequently translated into multiple languages. The inconsistency in the English source terminology has bred inconsistency across the other languages—a domino effect. We’ve found that, for example, we have four different ways to say “operating temperature” in French and three different ways in Spanish (I gave up counting for the other languages). This inconsistency with just one term illustrates the widespread impact that poor terminology management can have across multiple documents and languages.

SDL’s survey clearly showed that terminology needs to be managed during the whole content life cycle, from the moment we decide a source document is needed through to the localisation of the content.

I work in the manufacturing sector and many of our products are outsourced to suppliers for development and manufacture, to be sold under our company’s brand name. The English terms I come across in the software and manuals that I check can often be amusing in their originality. A Chinese supplier with whom we work called the term “Event” in a product’s firmware “Happening Time”. I don’t know why but the term “Happening time” tickles me. I still changed it to “Event”.

I’ve no idea how “Rule” became “Handle”.

I may find amusement in such mistakes but on the down side….

Over the years I’ve worked with over two dozen suppliers from around the world, most in Asia. Only two of these suppliers have used technical writers to do their manuals. One was in Canada and the other in Israel.

It was a few years back and at the time neither writing group in these two companies gave sufficient thought to the impact of localisation on their manuals (such as text expansion and embedded text in graphics) as they didn’t translate their work. Yet their companies were selling the products to other companies for resale under other brand names, and these companies often operate in multilingual markets. Such as my own company. I may have had to redo the layouts and graphics of their manuals for localisation, but the English was correct.

I hope that these two writing groups are now doing manuals that are easy to localise, even if they’re still not doing any translation themselves. Such a step would increase the value of their services to their respective companies, who are keen to expand internationally.

However, most of the “English” source documents I receive to customise for my company are written by engineers in non-English speaking countries. The level of English varies from “Nearly there” to “????”.

The standard localisation issues with text expansion, embedded text in graphics, and inconsistent terminology are obviously also present. The Tech Comm world may be a buzz with XML and DITA but Microsoft Word is doing great in the world of many companies. So is Normal style. These issues are easy, if perhaps time consuming, to fix.

What does shock me is how many companies release manuals and software with poor, at times incomprehensible, English. If you then plan to then translate the documents and software, poor English will then often mean even worse translations. And translating isn’t cheap.

Training technical writers isn’t the problem. It’s training companies to have higher expectations on the quality documentation and software they provide to customers. Customers matter. Being able to use a product easily matters. Crap English impacts your bottom line.

Companies also need to realise that being able to speak English sort of OK isn’t the same as being able to write it correctly. Users – and translators – can tell the difference.

I know that English-mother tongue or fluent writers aren’t easy to find in many of the new growing industrial areas of the world. One of our Chinese suppliers is now getting a Chinese engineer who lived in the US for several years to do their manuals. The English is better (from a low base line). It’s still foreign-flavoured English, but it is at least easier to understand and is a step in the right direction for the resources they have at hand. Realistically, the chances of them hiring a mother-tongue writer in their city are minimal. We still rewrite their documentation for our customers.

Last year, I attended the STC France annual conference. During the last session when the speakers were discussing how they thought our profession would evolve in the future, one speaker said that we would be spending more time rewriting other people’s work. I agree.

English is now the linga franca of international business. As a result, the quality of English is often suffering. The challenge we face is finding ways to improve written English in documentation, and to persuade companies it’s worth the investment. Let’s reduce the incidence of all those awful happening times.

We work with words. Yet we handle numbers too in our work. And what I’ve noticed from working with manuals written by both professional and non-professional writers across many countries, sometimes with English as second language, is that often the cultural roots of the writer can be seen in how they handle numbers in the document.

When checking for potential localisation issues in a manual, I first look at how the numbers have been written before reviewing the text and graphics. This gives me a quick feeling on whether there could be possible internationalisation issues to look out for in the document that may need further attention.

Text has spelling and grammar but many forget, or don’t know, that numbers also have their own “spelling and grammar”. And this “spelling and grammar” can differ between languages and geographic locations – number can have a locale. I find that people often write numbers for their own locale, which can introduce a foreign influence to the English-source manuals.

Here are some of the number issues that I look out for:

• Decimal comma/period: English uses a decimal period but most other European languages use a decimal comma. Seeing an English-language manual with decimal commas in the numbers tells me immediately that the document was written by a European with English as a second language. I’ve found that many colleagues who write in English as a second language can spend much effort on getting the text correct but haven’t noticed that numbers may not be written the same way in English as in their mother tongue. The decimal comma is a dead give-away that the document hasn’t been written by an English mother tongue writer. The text may need to be carefully checked too.
• No metric/imperial equivalent: Most of the world uses the metric system. Sometimes I receive a manual that’s been written in the US which may not include the metric equivalent for measurements. I need to ensure that all measurements in our manuals aimed at our EMEA market have a metric value provided. If the metric numbers are missing, then I need to also check if other metric measurements are missing. For example, in video manuals if NTSC values are listed then the equivalent PAL ones must be there too.
  However, if the manual I’m checking for possible localisation issues is to be released in the global market I need to ensure that manuals written in Europe and Asia have the imperial values of measurements included and not just metric.
• Unfamiliar with metric: Metric measurements with several redundant decimal places (such as 2.143768 cm) indicate that the writer was unfamiliar with the metric system and just copied the conversion number from the calculator. Numbers may need to be cleaned up.
• Telephone numbers: International contact details sometimes instruct customers to phone another country for assistance. But the phone number listed doesn’t include the country code.
• Order of metric/imperial: This item is simply a cultural difference. In manuals that show both metric and imperial measurements, the order in which they are listed tells me whether the manual was written in Europe or Asia, or in the US. European and Asian manuals tend to write the metric measurement first, followed by the imperial value (eg, 50°C (122°F)). It’s the other way round for manuals written in the US (eg, 122°F (50°C)).

There are other locale-related issues associated with numbers such as dates, currencies and time. These are infrequently encountered in the documents I check. I’ve only once come across the term “Military time” in a manual. Few outside of the US are familiar with this term for 24-hour time.

We added guidelines in our style guide a few years back on how to write SI measurements, which have ensured that measurements are written much more consistently.

I keep watching out for how numbers are written in our manuals as not only do they provide important information to readers but they also are a useful flag for potential wider problems in a document.

When selling products in Europe, how do we decide into which languages we should translate our user documentation? This is a potentially expensive, yet important, question.

In an ideal world, we would translate the documentation into the language of every country in which we sell our products. However, not only could this be prohibitively expensive, it might also be a waste of money and time. Not all products or audiences may require a translated user manual. Yet by not providing the documentation in a language of a country, we might be breaking that country’s laws. In this era of tight budgets and deadlines, it’s important to know how to select which languages are required for our markets.

When planning the localisation requirements of our documentation, we should consider the following criteria:

1. Legally required languages
2. Legally recommended languages
3. Commercial decision

Always seek the advice of the company’s legal department to get guidelines specific for your products and markets.

Legally required

What we’re selling will play a deciding role in determining which languages are provided to customers. Medical and life safety products, such as fire alarm systems, have much more demanding legal requirements for translation than products with no such impact. As a life safety product even if we sell only one smoke detector in Iceland, for example, we’d have to translate the user instructions into Icelandic.

And the law doesn’t stay still. Recently, the European Union directive for medical devices was updated, requiring software to be now translated. A useful article for information on the legal aspects of localisation is Who is afraid of clinical data requirements?

Regulatory information often must be translated. For some European Union (EU) directives, the information provided to end users must translated into the official EU languages. Examples of such directives are those for WEEE and battery disposal. So some regulatory information may need to be provided to users in more languages than the user manual itself. For more information on regulatory issues across many sectors in the European Union, go to the European Commission’s industry sectors overview.

Several European countries legally require user documentation for any product to be translated into the local language. If selling products in France or Germany, we must translate the software and instructions for use into the local language. The instructions for use can be in print or digital format (for example, PDF, Web, Help…) Further information on the French law can be found in this article about Toubon Law.

Russian and Ukrainian laws insist that the end user and installation documentation be translated into Russian for products to be legally sold in these countries.

And we also need to be aware if our company has any contractual agreements with customers to provide the product documentation in selected languages.

Legally recommended

Unfortunately, sometimes there can be grey areas surrounding translation requirements for some countries. In such situations, seek the advice from the legal department. Although a country may not legally require the user documentation to be translated, if that country’s market is commercially important to a company, the legal department may decide that user documentation must be translated.

Commercial decision

In this situation, languages are selected for purely for commercial reasons. Product managers select the languages required for software and documentation depending on market demands.

We need to know the impact of legal requirements when planning the localisation of documentation. Work closely with the product managers and legal department when selecting the languages required. And develop written guidelines to help all parties in the company know what legal requirements the software and technical documentation must meet in the international marketplace.