ffeathers — a technical writer’s blog

This week I’m attending the 2009 Australasian Online Documentation and Content Conference (AODC) in Melbourne. Today is the second day of the conference.

Here are some notes I took from the session on best practices for translation and localisation, by Emily Cotlier of Harris Stratex Networks. I hope these notes are useful to people who couldn’t be at the conference this year. The AODC organisers will also publish the session slides and supplementary material once the conference is over.

Translation and Localisation Best Practices

Emily started by asking how many of us work for companies that sell products in other countries, and how many of us know that our content needs translation. Most of the room said yes to both questions.

Some concepts:

• Translation = Translating from one language to another.
• Localisation = Aligning a product with the culture of a particular country. Some examples are the use of language, use of colour, spelling, use of sensitive images.
• Internationalisation = Designing a product so that it can be localised relatively easily.

Would a technical writer or technical communicator be qualified to manage a translation project? Emily says Yes. She listed the skills required to manage translation and localisation projects:

• Research
• Organisation of the source content
• Scheduling of the content release, along with the translated content
• Managing of freelancers
• Communication
• Global thinking

Next she gave some answers to the type of questions we have when considering such a project. Here are my notes, but please refer to Emily or other sources for up-to-date and regional information:

• How long does it take? Emily’s experience is that a document of 1000-3000 words requires 1 week turnaround; a short manual takes 2 weeks to a month; over 50 000 words takes one to two months, depending on length and on whether more than one translator is involved. Other factors are the inclusion of graphics, review/approval process, etc.
• How much does it cost? Recently, a complex manual cost USD 6500 (translator in China) and another cost USD 35000 (translator in USA).
• How do you manage the project? If you outsource the work, the pros are expertise and speed; the cons are a higher cost. If you do the work in-house, the pros are lower cost and retention of knowledge; the cons are the time required and the challenge.
• Who’s going to pay? Emily says be sure to sort this out beforehand, because the cost can be quite a surprise.

We took a look at what the localisation management technology can do. Examples of such tools are Trados, the localisation module in Author-IT, and many more. They provide an interface for translating. For example, they may lay the original content on one side and the translation on the other side. They compare source with the previously-translated version and indicate any differences, via highlighting on the interface for example. Good software will provide a translation memory. This means that it “remembers” what has been translated, offers existing translations for terms in the source, and points out what has changed since.

Preparing for content localisation:

• Use clear language. Avoid colloquialisms, passive statements and long convoluted sentences.
• Prepare a glossary that you can give to the translators, and use it as a style guide for the rest of the translation.
• Link to graphics rather than embedding them. They need to be translated via a graphics editor, not in the text translation tool. So remember to save them in editable format. Use numbers instead of text for callouts.

To keep your costs down, use single sourcing, and don’t send topics that haven’t changed and therefore don’t need translating again. Keep track of your files and graphics, so that you know what has changed.

Always assess whether extra translation costs are worth it. For example, you will need someone to do a native language review of the translated content. You may be able to ask someone in-house to do this, if there’s someone who speaks that language. Or you may have to outsource this work too.

On a software GUI and on labels in diagrams, be aware that the translation can often take up extra space on the GUI or diagram.

When working with translators/localisers recommended by other people, do your research to see the work they’ve done and any other references. Check the software they use to make sure it’s compatible with yours. Also ask them if they use translation memory software. Many don’t, and this can increase your costs dramatically.

A question from the floor: Who owns the translation memory?

Emily’s answer: We always make sure we get the translation memory back. This helps if you have to start using a different translator. Most translation tools can read each other’s format.

Once you’ve chosen your translator, share knowledge with them. Bring them on board, so that they can produce quality work. Spend time with them reviewing the materials and setting the expectations.

Appoint a person in your company to be the liaison person between you and the localiser, especially if you want to build a long-term relationship with them.

Tools for localising a software GUI (as opposed to documentation): Passolo; WizArt.

Remember that you need to relate the documentation to the GUI, where one or both may have been localised. So your documentation, when translated, may still need to refer to the untranslated GUI terms if the GUI has not been translated.

Managing the completed localised files: Your computer needs the international fonts/languages used in the translated content. Your online help generator must be able to handle the new language too. You also need a good archive system, to keep track of the duplicate sets of files you will now have, one for each language.

Emily also gave us very useful tips about the administrative side of things e.g. keeping a job log and keeping track of the text on images for translation.

Question time produced some interesting questions and comments:

1) Are audio translations similar to document translations?

Answer: You would translate from the scripts. This is usually relatively cheap because they tend to be simple. Then there would be an additional cost if you want to record the voice audio or add subtitles to a video.

2) A hint about translating images: Export them in SVG format. That’s very easy to translate because it’s just XML. Then convert them back to raster or whatever is required for your documentation.

A great presentation, Emily!

Part of our job as technical writers is to give our readers a smooth ride through the text. And it’s not a small part of the job either. It’s important, even if it means we spend a fair bit of time correcting other people’s writing. Or does that just turn us into glorified copy editors — what do you think?

This isn’t new to most tech writers, but it came to mind again recently when I was making a couple of very small corrections to a page in our Confluence documentation. A reader had added a comment to the page, saying that she had noticed a couple of typos. Thank you Rosie (The comment is still on the page at time of writing this blog post, but it will probably disappear in a couple of weeks.)

Rosie had picked up two spelling mistakes: “serch” and “mutliple”. I myself find the second one particularly bothersome, because my eyes don’t quite believe that they’re seeing it right. So they go back a couple of times just to check that the mistake really is a mistake.

Why is this important?

Because we don’t want to distract our readers from the important stuff just because it’s written funny

OK, so prove it!

It’s easy enough when we’re talking about simple spelling mistakes. “Serch” should obviously be “search”. And “mutliple” is just painful. But what about the more complex aspects of grammar, vocabulary and style?

When you read a sentence like this:

Sarah is eat a chocolate.

you’re hit by a LAN.

And this one:

On the way to work this morning I saw a goldfish swimming around the bus.

gives you an N400 when you read the word “bus”.

A “LAN” (Left Anterior Negativity) is a measurable blip in the electrical impulse which your brain emits when your internal language processor encounters something ungrammatical — like the word “eat” in the first sentence. The blip takes between three and seven tenths of a second to register on an EEG.

An “N400″ blip happens when you encounter a word which doesn’t fit the context – like the word “bus” above. This one takes about four tenths of a second.

This information comes from Steven Pinker’s book, Words and Rules. It was pretty cool to learn that there’s a measurable physical manifestation of that feeling of discomfort I get when a sentence jars.

But what is “correct” English anyway?

I might suffer a LAN zap when you write “Remember to invite Peter and I to your party”. But many people don’t!

(BTW, “Peter and I” is wrong in that sentence, and I’m ready to battle that one out to the end if anyone’s game to take me on )

Or you might get a LAN buzz when I start a sentence with the word “or”. But I think it’s OK.

Why does the tech writer get to decide what’s right and what’s not?

We don’t. Language is a living, changing thing. Different words and constructs will sound good or bad to different people and at different times in history. Consistency is the key. Provided a document or a documentation suite is consistent in its usage of grammar, style and vocabulary, the reader will get that fabled smooth ride.

So which standards do we use? It doesn’t matter all that much, provided you pick a standard that is recognised in your neck of the woods.

At Atlassian, where I work, we use these two guides:

• Style manual for authors, editors and printers (John Wiley & Sons Australia)
• Macquarie Dictionary, Fourth Edition of the Essential Dictionary (University of Sydney)

We’re based in Australia. Our US office has copies of these books too, and we’ve agreed to go with the Australian standard because we’re originally an Ozzie company. I suspect that many Americans think it’s cute

Taking standardisation even further…

Scott from DMN writes about a DocTrain West session he attended, given by Berry Braster and listing the advantages of Simplified Technical English.

A Scribbly Gum tree in my garden

Moving on to scribbles and smoothness of another sort… The Scribbly Gum tree is quite common in this part of Australia. It has a lovely smooth white bark which gleams silver in the wet.

A smooth ride through the text

As you get closer, you notice some weird zigzag lines marring the smooth surface. It’s just as if someone has scribbled on the bark.

A smooth ride through the text

The markings can be quite intricate and almost seem have some meaning which you can’t quite discern.

A smooth ride through the text

But actually, the “drawings” are tunnels dug by the larvae of the Scribbly Bark moth, known less intimately as Ogmograptis scribula.

A smooth ride through the text

I vote that we make the Scribbly Gum the mascot of technical writers. All in favour say “aye”

Some words are captivating. Here are a few I’ve come across lately. They’re all related to linguistics. Maybe that’s why they appeal to me. Or maybe it’s just the way they sound. I’d be interested to know if you think these words are cute, and whether it’s because you’re a linguaphile too?

Bahuvrihi — a compound word like ‘lowlife’ or ’sabertooth’, where the meaning of the word is not a type defined by one of its parts. A ’sabertooth’ is a type of tiger, not a type of tooth. A ‘lowlife’ is a type of person, not a type of life. This property is significant, because it affects how we use the word in a sentence. For example, when talking about more than one of these things, we automatically use the regular plural rather than the irregular. So we say ‘I went back in time and saw a lot of sabertooths’ — not ’saberteeth’. And we say ‘lowlifes’, not ‘lowlives’. Compare ‘workman’ (not a bahuvrihi, because a workman is a type of man) with ‘walkman’ (a bahuvrihi). We talk about many ‘workmen’. Can we say, ‘how many walkmen do you have’?

Dvandva – a compound word made of two equally-weighted nouns, like ‘girlfriend’ and ’singer-songwriter’. These words have a similarly intriguing effect on our internal language generator, but let’s not go there

Synechdoche – that’s when you use part of something to refer to its whole. ‘I got me a new set of wheels’ means I bought a car, not just the wheels. When you ‘count heads’, you are counting the number of people, not just their heads.

And my favourite: hapax legomenon — a word or term which is used only once in a particular body of text.

This weekend I’ve been writing some Christmas cards, and struggling as usual to find the right words. Maybe I’ll drop in the odd hapax legomenon to spice things up

Thank you to Kate for lending me Words and Rules, the book in which I found these words. And to Steven Pinker for writing it.

Some tree news:

Here’s a tree recovering from a fire in the Manly Dam reserve:

And here’s a grass tree (Xanthorrhoea) which survived the fire altogether:

At university, I studied English with a strong emphasis on linguistics. This week a colleague at work, after reading my recent blog posts about language, let me know that she had studied linguistics too. So why are we both now in Information Technology (IT)? Also, John R made a thought-provoking comment. So now I’m following up on those two comments. And at the end, I’ll tell you how my trees are doing.

First of all, exactly why is this sentence funny or at least quirky: “Drive carefully when wet”?

Secondly, John R’s comment got me to thinking about how, with my fascination for linguistics, I ended up in IT. What makes a technical writer tick, and is the tick-mechanism anything like the widget that powers a systems engineer? Do John R (a self-professed ‘computationist’) and I (a linguaphile) actually share a habit of putting brackets around things and even indulging in the odd XOR?

Linguists have spent a lot of time trying to describe the knowledge common to speakers of a particular language. Without a shared knowledge, we wouldn’t be able to communicate. Some linguists think that there’s even an innate structural understanding shared by all humans, irrespective of which language they speak. So our brains come pre-wired with the “deep structural” rules of language, and we just have to plug in the specific language we need.

It seems fairly obvious that a language has a structure, and that all speakers of the language are able to manipulate the structure to produce unique, never-before spoken sentences with amazing ease. But describing the structure and its ability to generate new sentences has proved quite tricky.

Still, there’s hope. Take our sentence “Drive carefully when wet”. You might represent it like this:

Read the diagram starting from the top: A sentence (S) may consist of a noun phrase (NP) and a verb phrase (VP). A noun phrase may consist of a pronoun (Pro). A verb phrase may consist of a verb (V) plus an adverb (Adv) plus another sentence. And so on.

Linguists have also created a way to describe phrase-structure rules, complete with brackets and symbols to keep computationists happy. For example:

• S –> NP VP (A sentence may consist of a noun phrase and a verb phrase)
• NP –> Pro (A noun phrase may consist of a pronoun)
• And so on.

And then you can add other logistical provisions, like:

• “You” deletion: In an imperative sentence (i.e. a command), omit the “you”.
• Pronoun matching: The second pronoun, also missing in our sentence, is assumed to be the same as the first pronoun.

……So…… that’s why it’s funny. Get it?

The design of computer languages, and other artificial languages, owes much to the work of linguists. Chomsky, in particular, is an easy mark. He’s the man everyone loves to shoot down. But his work on the theory of a universal grammar, transformational-generative grammars, the Chomsky hierarchy and the Chomsky normal form set the basis for much of what we do today.

So that may be why my colleague and I, linguists both, found our way into IT.

I think there are probably two sorts (or more ) of people. Those like me, who seem to organise things into groups automatically (yeah, those brackets). The groupings are fluid and flexible, but the fact remains that we like them to be there. And then there are the people who float much more freely in their ecosystems: go with the flow, synchronicity rocks, hey man what’s the odd misplaced pronoun between friends?

Sometimes it amazes me how many different world views there are out there, just walking down the street next to me. And that we actually do manage to communicate with each other!

Moving on to my two trees:

Two months ago, I planted two trees. I promised a progress report every now and then. The trees are about the same age as this blog. And they’re doing great.

Here’s the paperbark, now 50cm high. (Was 40cm on 1 September.)

Here’s the old man banksia, now 32cm. (Was 17cm on 1 September.)

Here’s the answer to the question posted in a previous blog:

Jack, where John had had “had”, had had “had had”. “Had had” had had the teacher’s approval.

Tangentially…

Coming home on the bus one day this week, I had a blinding flash of inspiration. This one’s for John R, who prefers computation to punctuation.

Add up the vital statistics of the answer given above:

So, in an awesomely insignificant way, the answer to the question is 42. As indeed it should be.

(Please note that this calculation uses base 10, not base 13.)