Tagged: translation

Untangling Chinglish

by Jen O Neill

The development and manufacturing of many of the hardware products I document have been outsourced to Chinese companies. They work closely with our in-house engineers and product managers to develop customised products for our global customers. We release dozens of such products a year. The technology of these products is changing so quickly that it would be difficult for us to develop so many products in-house ourselves. Competitors also outsource their development and manufacturing for these products. See our earlier blog post “Working with OEMs”.

The Chinese engineers write generic manuals, which they then send to us to customise for our versions of the products. Their manuals are written in Chinglish. English strongly influenced by Chinese. They can have strange terms, long-winded sentences, missing grammar, simplistic mixed up verb formats, curious word order.

I’m working with an English that’s been contaminated by a language I don’t know: Chinese.

The infamous web photos of China’s Chinglish signage are amusing to read. A 70-page manual of it can be challenging. And fascinating.

So I’ve been reading up on how Chinese is written. Knowing some basic Chinese grammar helps to untangle the Chinglish and makes it easier to rewrite it into English. I’ve become curious about Chinese.

General information about Chinese

Chinese doesn’t have an alphabet. Instead it uses characters, called hanzi. There are around 40,000 characters in the language and as a beginner you need to learn around 2,000 to 3,000 just to be able to read a newspaper, for example.

No articles or prepositions. No plural or singular either

Chinese nouns don’t have articles such as “the” or “a” so they can be often missing in Chinglish. Nor does Chinese have a plural form. It’s implied in the context. As a result there are often mistakes in number in the Chinglish:

Chinglish: Can’t Add More User!
English: You can’t add any more users.

What’s with all the commas?

When you look at a text written in Chinese you’ll notice that there are a lot of commas as shown in this image.

Unlike English, the comma splice is frequently used in Chinese. Clauses are linked by commas where in English we’d use separate sentences. This means that when Chinese is poorly translated, we can often have a long paragraph of just a single sentence. Chinglish can be full of commas:

Chinglish: The enable status of camera already changed, device will reboot automatically, please enter the remote configuration after reboot is complete.
English: The camera reboots automatically when its parameters are modified. When rebooting is complete, configure the remote parameters.

(You’ll also notice that there are no breaks between words in Chinese.)

Another example of Chinglish written as a single sentence:

Chinglish: The whole screen is divided into 22*18 panes, you can use “ ↑ “ “ ↓ “ “ → “ “ ← “ keys to move the yellow pane to your hope position and press “ EDIT “ key, the yellow pane will be turned into red, then you can use “ ↑ “ “ ↓ “ “ → “ “ ← “ keys to extend the red pane.

Often the first thing I’ll do when I receive a text from the engineers is to quickly look through it to see if there are a lot of commas. This gives me a rough idea of the state of the “English” and how much rework may be required.

Past, present or future? It depends on the context

Chinese has no verb tenses. The tense depends on its context. To indicate that something has happened in the future or past, for example, time context words such as “yesterday” or “next year” are often added to the sentence. And unlike English, the time words come before the verb in Chinese.

Verb errors are common in Chinglish:

Chinglish: This action trigger local audible on box.
English: This action will trigger the unit’s buzzer.

Chinglish: The log items are more than 200 pieces, please short query range!
English: There are more than 200 log items. Please specify a smaller query range.

Chinglish: ESC button represents “Cancel”.
English: Press ESC to Cancel.

How did “Rule” become “Handle”?

The Wikipedia web page on Chinglish cites several possible causes for texts being written in Chinglish such as errors in Chinese dictionaries, no native English speakers checking the text, and the use of translation software.

None of our Chinese engineers are fluent in English. Their English is often a literal translation of the Chinese. They’re clearly thinking in Chinese when writing English, which produces Chinglish. Although I’ve never asked, I assume that they use translation software when writing their text as they often use the wrong synonym of a term or simply use a term that apparently has no logic for the context.

Chinglish: Modem drop off.
English: The modem is disconnected.

Chinglish: The image sticks.
English: The image freezes.

Each Chinese character represents a word or concept and often serves multiple purposes. Their meaning depends on context. So translating each character individually can easily produce an inaccurate or confusing result in English.

This excellent article by Mark Liberman discusses literal translation and explains the process of how “Disposable coffee cup” on a sign became translated as “A time sex thing” using translation software.

The biggest problem I have understanding Chinglish is with such mistranslated terms. One example is “handle” being used instead of “rule” in the manuals (such as when you configure the rules for how a system should respond to an alarm situation). One example:

Chinglish: View Tampering Handle.
English: View tampering rules.

I couldn’t see the link between “rule” and “handle” until I read Mark’s article. I entered the Chinese term for “rule” (taken from a software string) into Google Translate and it proposed the English term, “Deal with”, and several synonyms (processing, handling, handle, process). No “Rule” but a probable explanation as to why “Handle” appears in the manuals.

So I’m now wondering if the Chinese translation software tool used by the engineers lists “Handle” at or near the top of the English term options provided, making it an easy selection. If you don’t really know the target language well, you tend to select the first word the translation tool proposes.

I’ve tried this test with other peculiar English terms in the manuals when I have the corresponding Chinese term. I now have a better understanding of why some strange English terms have probably been used. Google Translate and the other translation software tools available on the web are useful tools and are continually improving. But they aren’t infallible.

In the meantime, my interest in Chinese grows.

For more information on Chinese grammar, see Wikipedia’s entry on Chinese grammar, grammar information from chinesenotes.com and a learner FAQ from the Chinese Grammar Wiki.

And what’s my elevator speech?

I enable English, natively.

Localising Graphics

by Jen O Neill

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.

A recent survey on terminology management

by Jen O Neill

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.

Happening times

by Jennifer O Neill

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.

Producing documentation for the Japanese market

by Jennifer O Neill

Although my focus at work is producing documentation for the EMA market (Europe, Middle East and Africa), it’s always interesting to learn about what’s happening in other regional markets. At the 2009 tekom conference in Weisbaden, Germany, a speaker from the Japan Technical Communication Association gave a presentation on frequent problems encountered in the Japanese market with manuals written in Europe.

A frequent problem is that of non-compliance with national standards, such as those related to safety. As EU directives are an important legal issue for the European targeted manuals that we do in my company, I can well understand the importance of complying with Japanese requirements. It is also important to clearly state when information in the manual does not apply to Japan. Around 70% of Japanese people read the manuals when they buy a product. Since 2007, product accidents are now publicly reported in the press.

Another problem encountered is that of using English terms in translated manuals or doing a phonetic translation where the English sound is preserved but the meaning lost. Translations for the Chinese market must use approved terms.

Recently a consumer magazine in Japan conducted a survey of its readers, asking them what were the most important items they wanted when using printed product manuals. The top 10 answers were

  • Larger font size
  • More illustrations and visual explanations
  • Fewer pages
  • Friendly explanations for beginners
  • Fewer foreign terms used in the text
  • Easy-to-use instructions
  • Fewer technical terms
  • Better explanations for elderly users (Japan has an ageing population)
  • Clearer separation between basic functions and advanced ones
  • Manual has a table of contents and an index

The desires of readers seem similar worldwide.