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.