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.

We often hear about the advantages of being fluent in a second language such as when visiting a foreign country on holiday. It’s easier to eat, drink and be merry when you can speak with those around you. But what about the professional advantages?

I’ve been reading a few blogs and newspaper articles recently that discuss multilingualism.

• The Language Bridge
• Web pages for the EU Commissioner for Multilingualism
• Column in the Guardian about British linguistic skills

They have made me think about our profession, technical communication, and how it connects with other languages and cultures. We now work in a global marketplace and increasingly are involved with planning, writing, and distributing documentation that cross linguistic and cultural borders. Although most of us work and write in English, does it help us professionally as technical writers to be fluent in other languages? Are employers interested in such a skill?

If you’re based in Europe having another language certainly gives you more freedom to move between countries for work, particularly if you hold an EU passport. Fluency helps us deal with the various bureaucracies that invariably arrive when living in a different country. We become more aware of the diversity of life and can take part in it. We can speak with colleagues in their language. I’m fluent in French so can communicate with my colleagues in France, Belgium and Switzerland in their language, which they appreciate. Communication becomes more shared.

English today is the global linga franca. As a result many English speakers unfortunately don’t see the point in learning another language. Are many of the professional advantages of having a second language only apparent when you are the foreigner rather than the language? My last two jobs both preferred candidates to have a second language as well as good English. Admittedly both were in French-speaking countries.

Yet I think having another language is useful professionally even if you’re not based in a foreign country. We know what it’s like to read technical documents in a second language. Although such fluency isn’t a requirement when writing for a global market, it can help us to be more aware of the consequences of writing clear, concise, and direct information that is easy to translate as well as understood by those reading in their second language.

The practicalities of localisation can become more “alive”. Simply reading documents in other languages can help us appreciate the impact of such issues as text expansion due to translation (particularly around graphics) and inconsistent terminology. In some of my company’s datasheets I discovered that we had six different ways of writing “operating temperature” in English, which translated into four different ways in French and three in Spanish. Ouch!

If you’re fluent in more than one language, what advantages has it brought you professionally in your work as a technical communicator?

I oversee the localisation of my company’s video and an important part of the localisation process is the in-country review. This is where the translated material is sent to an individual in the target country to do a linguistic review. The in-country review plays an important role in ensuring the quality of the translated documentation. So it’s important to carefully plan for this stage.

Who should do the reviews

A good reviewer is a

• Company employee
• Native speaker of the target language
• Product SME
• Stakeholder in the process of producing quality translated documentation

In my company, we usually send the translations for review to a technical support colleague in one of our many sales offices located across Europe. Sometimes the sales people also help. What they all have in common is that they know the products, are mother-tongue in the language being reviewed, and know the customer so want documentation that helps them. Quality matters to them. Well written and translated documentation helps reduce the number of calls they receive from customers.

Develop localisation guidelines

Before the localisation project starts, you should work with your localisation vendor to develop localisation guidelines. The guidelines, a localisation style guide, will help the translators know how you want the text translated. It can include such information as fonts to use for specific languages, how to handle text that is not translated, stylistic issues. As the in-country reviewers are often the final judges of the quality of the localised documentation get their input in these guidelines so that they and the localisation vendor agree on standards. This joint effort will help minimise the number of revisions later.

Although many reviewers have in-depth knowledge of the product, they may not know how to review a translated document. It’s therefore important that you provide them with a clear set of guidelines or instructions to ensure consistent and timely feedback from them. It can be a simple list of do’s and don’t on a single page. Some guideline examples are

• Use approved terminology in your review (and use it consistently)
• Don’t try to rewrite the document
• Check that decimal and measurements notation is appropriate for your region or language
• Try to ensure that the same person reviews each translation project for consistency
• Mark your requested changes in the correct format (Track Changes for Word files or comments for PDF files)
• Contact the person overseeing the translation project if you have any concerns about the document content or translation quality

Don’t forget multilingual glossaries

We work with our in-country reviewers to develop our multilingual glossaries as some of our terminology is industry specific and we want to ensure it is translated correctly. These multilingual glossaries have more terms and acronyms in them than the English-only glossary used by our technical writers.

The localisation vendor SDL recently conducted an online survey which found that 36% of respondents stored their English terminology in a style guide, 33% in spreadsheets, and that 24% had no terminology list. I suspect that those respondents without terminology lists were not localising their documentation. However, if you are serious about quality in any language you must have a glossary of terms and acronyms. If you don’t have one for use during localisation, and don’t have in-country reviewers to help you develop one, your localisation vendor will be able to help you do one. Translators need approved translated terminology.

The reviewer’s changes

The translated document can be sent to the reviewer in different formats. It depends on what you’ve agreed with your localisation vendor. The most common file formats used for reviews are Word and PDF. Whichever format is used, the reviewer needs to clearly understand how to mark their changes in the file and why it’s important that the translator can easily see what changes have been made. This information will be included in your reviewing guidelines to them.

Their changes are then manually implemented from the Word or PDF file into the translation database by the translator. If there are many changes, this can take time. And if there are many changes, you need to find out why from the reviewer in order to reduce rework in later projects. Was it a poor translation, stylistic differences between the reviewer and the translator, or a new reviewer who has different expectations from the previous reviewer? Were some of the changes due to errors in the content of the document? If so, you need to know how to handle content errors at this stage in the localisation process.

A common problem with in-country reviewing is the late review. In-country reviewers have daytime jobs too to do. Reviewing translations is just one item on their long task list. Sending them a 300-page translation of a new product’s documentation to review in a week is often unrealistic. Review schedules need to be realistic yet fit in with the product release deadlines. Get to know your reviewers so that you know when potential delays may occur such as when they’re on holiday, attending trade shows, giving customer trainings. You can then plan the review schedule accordingly, perhaps even calling on the assistance of another reviewer if necessary. All the while keep working on updating your multilingual glossaries and fine tuning the localisation style guide so that translation quality continually improves.

Increasingly localisation vendors are developing online review tools that allow the in-country reviewer to review the translated text via the Web, which means no firewall problems and their changes are implemented immediately into the translation memory, saving time and streamlining the process. The translator no longer has to spend time transferring the changes from a marked up PDF, for example, to the translation memory. The reviewer is still provided with an English PDF of the manual in order to see how the text appears in the document. However, such online tools aren’t free. For example, one large localisation vendor charges around 100 euros a month per reviewer for their Web-based online review tool.

Become a close team

By planning ahead for in-country reviews you can help ensure that the translated documentation you release in the international market meets the expectations and needs of your customers.