AODC day 2 – Translation and localisation
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.
- 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:
- Organisation of the source content
- Scheduling of the content release, along with the translated content
- Managing of freelancers
- 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!
Posted on 21 May 2009, in AODC, language, technical writing and tagged AODC, documentation, Emily Cotlier, language, localisation, technical documentation, technical writing, translation. Bookmark the permalink. 1 Comment.