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.
Tags: Language, localisation, localization, survey, terminology, terms, translation
We received the following request from the STC’s International Technical Communication SIG.
Han Yu, Assistant Professor, English Department, Kansas State University, and Gerald Savage, Professor, English Department, Illinois State University, are looking for interesting stories from technical communicators to publish in “Negotiating International and Cross-Cultural Technical Communication: Stories of Technical Communicators”.
Summary
We request story proposals of 300 words for an upcoming collection Negotiating International and Cross-Cultural Technical Communication: Stories of Technical Communicators. This collection is designed for technical communicators to tell their stories working in international and cross-cultural contexts, working for/with clients/colleagues from diverse cultural backgrounds, or writing/designing for audience from diverse cultural backgrounds. We hope this collection will be a venue for contributors to share their experiences and lessons-learned, to inform and educate fellow practitioners, and to demonstrate their value-add to employers and clients. Submissions that meet the scope of the collection will be followed up for full-length stories.
For more information on this and how to submit a proposal, read the full request on the ITC SIG website.
Tags: call for contributors, cross-cultural, international, publication, storytelling, technical communication
by Jen O Neill
I’ve been reading up recently on agile environments. I don’t work in such an environment but have been struck at how often they discuss the importance of the office layout to encourage collaboration in a team. The preferred layout always cited is the open plan office.
The layout of the workplace does impact productivity. An open layout encourages communication between people. It’s a more dynamic place to work as it allows team members to interact more easily. The downside is it can be distracting if you need to concentrate. Cubicles encourage solo work, where less interaction is required. However, cubicles can discourage that cross-fertilisation of ideas and exchange of information that comes with close teamwork. Another disadvantage of cubicles is the potential risk, “Out of sight, out of mind”.
The culture of the workspace
There is also a cultural aspect to office layout to consider. Most Europeans work in open plan and most Americans work in cubicles. I’m not sure why this is. Which office layout you prefer may well depend on which you’re used to.
I’ve never worked in a cubicle. I’ve only worked in an individual office or in an open plan layout with up to six people. I’ve never worked in offices with large areas of open plan (+40 people).
Team benefits
In the agile environment you are located in your team. As my projects are determined by Product Management, I’m physically located with that team (I actually report to them). However, I don’t feel isolated from the other writers in the company, who are all located in other countries anyway. I’m in frequent contact with them by Instant Messenger and we chatter about tech comm. related topics and what work is like at our respective sites.
I’m an open plan person. I savour the opportunities to have ad hoc conversations with people, eavesdrop on the telephone conversations of the product managers around me and exchange ideas. I hear about customer evaluations as well as learn about the wider picture of product development and on doing business with suppliers (whose manuals I will be rewriting and with whom I will also be contact). I believe that this helps me collect a wide range of information to better focus the manuals I write and localise. I don’t want to work in a cubicle as I would find it isolating.
In my opinion, an open plan layout of, say, up to eight people is great for encouraging team collaboration. A larger team would probably need a careful review of the different types of workspaces that should be provided to balance team needs and solo work moments (for example a mix of individual desks, meeting desks, places for quiet work, hot desking…).
Coping with noise
Open plan can sometimes be distracting. There are four of us in the office and between us we have six mobile phones and four landline phones. We’ve reached a “gentleman’s agreement” not to use loud “amusing” dial tones on our mobile phones and to use the headsets provided for teleconferences (unless others are invited to listen in). If I really do need silence to concentrate when working on a project, I stay home that day and work from there.
Which layout do you prefer to help you do your work: Open plan or cubicle? What different types of office layout have you work in and which have helped you feel part of a team?
Tags: cubicles, offices, Work, work environment, workplaces
by Jen O Neill
Gripe no. 1. Where did “Why?” go?
Nothing is more frustrating when reading a manual than when the instructions only seem to focus on “How” to do something without telling me “Why” I need to do it.
Gripe no. 2. Receiving a manual for localisation that has serious usability problems.
It really is a waste of time and money getting such documents translated. Good translators will pick out inconsistencies and ask how to handle them (try answering such a question about a product you didn’t document but need the answer quickly.) There’s the real risk that in-country reviewers will then rewrite the translated manual to try to improve the content with the result the translated manual no longer matches the English source one and you may well incur extra charges from the translation agency as the translator now has to do extra work to update the translation memories. And then the customer probably won’t use the manual and will phone Tech Support instead. I can think of better ways to blow several thousand euros without annoying customers.
Gripe no. 3. Poor public signage.
Street names are like chapter titles for streets. They tell you where you are. Some cities are terrible at placing street names on every street corner and placing them so they can be easily seen by pedestrians and drivers (not two stories up the side of the building or just simply missing, for example.) Of course, once you do find that elusive street, you’re assuming the buildings are then clearly numbered…
Gripe no. 4. Why does it rain once I clean the windows?
I have to have some reason why I don’t clean them.
Tags: musings
by Karen Mardahl
Wow! An STC event that is covered by the Huffington Post. Wow! STC France and STC Transalpine deserve a round of applause louder than exploding volcanos for putting together such an excellent event! I didn’t attend, but I can feel the waves of excitement pouring out of Paris. It seems everyone had a fantastic time. Diana Railton tweeted:
The Content Strategy Forum in Paris was the best conference I’ve ever been to. Many thanks to @stcfrance @Wion and all presenters #csforum10
It wasn’t all cruises and champagne, however. It was also a matter of getting smarter about content strategy, as Rahel Bailie says in this CMS Wire article – It’s Time for a Strategic Content Lifecycle.
If you are in technical communication and know nothing about content strategy, you would do yourself and your career and your workplace a favor if you sat down and read – and studied – the articles and slides coming in the wake of this amazing conference. Rahel Bailie’s discussion of the content lifecycle is the perfect place to start your studies. That’s because her focus is on the beginning – the strategic analysis. The reason that this analysis is so important is because it kicks off the content lifecycle. Yes, there is a lifecycle to your content! Go read what she says, and then you’ll be just as eager as others are to see her slides from the conference as well as the future discussions that post promises.
(If you need a break from the reading now and then, get the visual experience from the pictures in the Flickr CS Forum 2010 group.)
If you are wondering what content strategy has to do with technical communication, let David Farbey share the messages that he took away from csforum10 – and we’re not talking about the ones from a ouija board! Keep an eye on David Farbey’s blog for future meditations about content strategy and technical communication. Like many attendees, he’s been overwhelmed by all the energy pouring out of the conference and needs a moment to digest. We’re just jealous and eager to hear his reflections!
Exploring Editorial Strategy is a topic that will make you sit up and take notice. You’ll be shouting hallelujah when Jeffrey MacIntyre, Predicate LLC sings the “content strategy gospel”.
It’s so good to see mobile addressed in Erin Scime’s presentation about the possible return of shovelware. I see so little discussion in technical communication circles that it makes me fear the topic of “mobile” is being neglected. It mustn’t be! Erin Scime’s presentation should clarify why.
As Eyjafjallajökull calms down and people arrive home, more articles will be written and more discussions will be started. Monitor this SlideShare collection from the conference and Rachel Lovinger’s Delicious bookmarks to collect all your favorite news from CS Forum.
Finally, here’s the link from Steve Rosenbaum’s article in the Huffington Post as Content Strategists Gather in Paris, which was originally published in Fast Company as Filter or Be Flooded: Do You Need a Content Strategist? – exposure of the good kind!
Take another bow, STC France and STC Transalpine. You have triggered a vibrant kind of seismic activity in the technical communication world this month!
Tags: content strategy, Content Strategy Forum, csforum10, stc france, stc transalpine, strategy
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.
Tags: Language, localisation, localization, rewriting, translation
We have received an exciting announcement from our colleagues in TCeurope!
The organisation representing national technical communication associations in Europe invites you to its Colloquium 2010.
This year, to offer maximum benefit for technical communicators in Europe, the TCeurope Colloquium A new decade for technical communication: 2010 and beyond is scheduled to follow the STC’s Content Strategy Forum 2010 in Paris in April, creating a unique double event.
TCeurope’s exciting programme brings together experts from many countries in Europe to present a broad range of stimulating topics for today’s technical communicators. Speakers include Paul Strickland from the European Commission and Michel Lanque from Alcatel.
Subjects include:
- E-collaboration
- A European Commission case study on clear writing
- Writing English for non-native speakers
- Preparing for the future of the profession
- New applications and methodologies
- and much more.
Anyone interested in technical or business communication, including professionals, students, teachers, and translators, is welcome to attend.
Saturday 17 April, 2010 from 09.15 to 17.00
FIAP Jean Monnet, 30 rue Cabanis, 75014 Paris
Enquiries: colloquium@tceurope.org
Register online for FREE admission.
Tags: TCeurope, TCeurope Colloquium
by Jennifer O Neill
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.
Tags: localisation, localization, measurements, metrics, numbers
by Jennifer O Neill
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:
- Legally required languages
- Legally recommended languages
- 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.
Tags: law, legal, localisation, localization, requirements
by Jennifer O Neill
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?
Tags: linguistics, localisation, multilingual, technical communication