I recently went to an excellent talk on how to work with translations. I thought my notes could be of interest to anyone thinking of getting their documentation translated. The talk focussed particularly on working with translation companies, which is the best route when working with lots of languages and frequent updates. Other processes could be better if you only work with a couple of languages.

I’d be interested to hear anyone’s thoughts on other ways of working with translation. Wikis and large community websites, for example, can harness the power of their users to translate and check their UI and their documentation. I’ve never personally seen this work as a process within a company, but it is very interesting as an idea.

Here are my notes. I’m hoping to put a shorter, more digested version of these notes up soon:

How do translation companies work?

They don’t necessarily have lots of in-house translators.

They have:

• Project managers – who liaise with translators who work in their own country.
• Tech support – who work with software to get the text out of files to be translated.
• Desktop Publishing – who work on the layout of the translation in the doc.

Basic process:

1. Work with source files
2. Manage the translation
3. Do DTP (desktop publishing ie design)

Point raised: DTP of the translation doesn’t always end up the same as in the source file.
Response: Make sure you agree on a spec and make sure everyone signs it off. [point made later: There are also ways to create the source file so you know the DTP will work when translated. This isn’t so much of an issue when working with HTML]

As well as outsourced translators, a translation agency has in-house language specialist who have a general appreciation of languages and have experience working with terminology and glossaries.

How do you know you can trust the translation company?

One way is to find out whether it is 9001: 2008 accredited. It’s not a guarantee but at least it show that the company is established and has processes in place.

Why translate?

1. Want to be internationally recognised.
2. Be better than competitors.
3. Legal requirements, especially in EU, especially, for example, for medical devices.
4. Web users more likely to buy if website in their language

Point raised: What about dialects?
Response: For dialects of English within England, for example, this isn’t an issue. Internationally it is an issue. For example, is your doc in UK/US English? Spanish Spanish/Mexican Spanish? Brazilian/European Portuguese? Financial issues are usually the main drivers. The biggest market = use their ‘dialect’. It is less rude to deal with companies in their own language but, for example, English people are happier to use US English than vice versa.

What’s the difference between localization and translation?

Localization considers other issues, such as:

• Using graphics appropriate to cultures
• Date formats in different countries
• Reminder questions for passwords (in many countries mothers won’t have maiden names)
• Measurements (inches v cm)

• Use of punctuation in numbers (2,000.09 v 2.000,9)

Tips on writing with translation in mind

• Keep it short.
• When designing UI, prepare dialog boxes so their size can expand to take extra text automatically – include room for 30% extra. Most languages (except eastern languages) are longer than English.
• Tools: Catalyst and Passolo tell you if text doesn’t fit on a UI (usually translation companies work with these).
• No ambiguous text.
• Don’t embed text in translations

Point raised: What about screenshots which include text?
Response: From a translation company point of view, these aren’t necessarily an issue. If the UI is translated, the screenshots can be retaken using the translated UI. There can still be a lot of work for the technical author, however, to recreate these screenshots. It can be better not to include screenshots with text in manuals if you want to avoid lots of work recreating screenshots.

How companies (should?) work with translation

Dedicate enough time to localization. People expect you to do translation ‘yesterday’ when the original document took a long time to write, so why should the translation be quick? Identify that translation is needed early on.

Product managers should have an idea whether translation will be needed. Marketing teams are often the first people to deal with translation. This can be a sign that technical documents are going to be translated further down the line. Has the company taken into account how this could be done and how much it could cost?

Teams who may need translation: tech pubs, international sales, training team, HR, software development, purchasing dept.

Sometimes departments don’t work together on translation and end up using various companies, which leads to extra expense.

Don’t make these mistakes

• Getting an employee to do it: you won’t end up with a database of translated text
• In the long term, it’s more expensive
• Getting a non-native to do the translation
• Not setting up a process
• Not communicating with the translation company. Tell them when you want the quote, when you want the translation.

Ask these questions

• Have the translators got the right skill set?
• What projects have they worked on? 
• What translation tools do they use? 
• Will they be around to help you in years to come?

The process

• Write a clear brief
• Consider:  will there be future updates?
• Who is the audience? A ‘tecky’ translator might not be so good at translating marketing text.
• Do you just want a pure translation or do you want DTP and proofing?
• Provide reference materials if it’s the first time doing the translation.
• Make sure the translation memory will be yours.
• Create a DTP guide and a style guide.
• Create a glossary of terms to give to the translator.
• Images are better than words.

How do you select a translation company?

• Do they use native speakers?
• Do you have an ongoing requirement? If yes, using translation memory will save lots of money.
• What are their processes?
• Are they accredited?
• How do they select the translators?
• What technology do they use?
• Do they use translation memory?
• Do they use terminology databases
• Do they use workflow portals – allowing you to see how the translation is progressing?
• Do they provide a full service – so you can use one company for everything?
• Do they give you a dedicated project manager so you don’t have to repeat your brief over and over again?
• References – who else have they worked for?
• Are their quotes transparent? Do they break down the quote so you can see exactly what you are spending on what?
• Can they cover all language requirements?

Kick-off meetings

Here everyone gets together. Here are some useful things that can be done.

Identify internal reviewer. Who will it be, who will follow up.

Points raised by the group about internal reviews: There can be problems, in company, with internal reviewers:

• Who will do the internal review? Can the translation company send docs directly to them?
• Will they actually do it?
• What happens if they don’t have time to review it? How should the translation company act?
• A reviewer, for example, in Italy might not like the translated text, but their problem might not be with the translation but with the tone of the original text.
• The ‘red lines’ need to be drawn when asking for feedback. Make sure reviewers are aware that this is a ‘company approved’ text – they shouldn’t rewrite the whole text.
• On the other hand, using reviewers is a good way to get people in-company to ‘buy into’ the documentation.

Forecasting – what is going to come up in future?

Agree milestones, perhaps they could do 10 pages of a test doc in the first instance.

About translation memory

A translation memory is a library.

It can save a fortune over time because repeated text is saved and won’t be translated again.

Point raised: Asked for details on how this works.
Response: There are three levels of ‘match’ found by translation software:

• In-context exact match: 100% ignored, no cost.
• 100% match: It’s the same text but in a different context. For example ‘It was dark’. In German the ‘it’ could be masculine, feminine or neuter in different contexts, so the translator needs to check whether work is needed on the phrase. Less cost (75% discount?).
• Fuzzy match: Translator needs to work on the words but there is less cost (75% discount?).

Question: Is it worth standardising phrases such as ‘Click Next’.
Response: Yes. Translation companies also work with terminology databases [?] that find these common phrases and suggest the translation to the translator. = less cost.

Principal tools: Trados [the de facto], Across, Transit

Cost: From 6-7p per word (eg French) to 19p per word (eg Japanese)

Point raised: When you know the breakdown of the translation cost, you can use it as an argument for moving to other tools.

What about other ways of translating?

The web can be good for very simple sentences. This is a growing area, and a reason why tech authors are looking at simplified English [a database of very few words and simple sentence structures used in English].

What is the future?

• The demand for translation will grow.
• Growth in multi-lingual websites.
• Increased use of technology.

Questions

How do you deal with updates?

When a manual has been translated and a translation memory is used, updates can be simple. Hand the source file over to the translation company and they will use the translation memory to find the translated text. They will just translate this. If there are a lot of changes, this is the best way. DTP costs, however, can be high if there are lots of changes to manuals created in InDesign/Framemaker etc. DTP costs don’t apply to HTML. If there are only a few changes, you can just flag up the few changes. This can be quicker and cheaper.

I have a manual that has already been translated. Can a translation company take this manual and create a translation memory with the translated text, and work with this for future updates.

Yes. This process is called alignment but you have to make sure that the translated text is good.

If you are interested in more details on who gave the talk, and the organisation they represent, please contact me on simon.green@authoriseltd.co.uk.

The website has grown to include many articles about the history of local landmarks as well as details about significant news events and the area’s wildlife. Many local businesses are now included on the website.

The first two years of ashtononribble.com have been enjoyable and rewarding, here’s hoping the next two years prove as successful!

Great fun for anyone who likes playing with words. They generate a cool summary of all the words on a blog etc.

You might have seen quite a few of these ‘wordles’ around. They always look cool. Trying to think of ways they could be useful for manuals or help files. Hmmm.

It’s an open source desktop publishing software. I’ve not even touched it but those words ‘open source’ always have a magic ring to them! Let me know what you think…

Simon

Or if you’re working with a particular software, and are struggling to find anyone who has the skills you want, let me know, I’m always happy to pick up new skills.