Re: Working with translators

[Newton Vasconcellos <mendv -at- AX -dot- APC -dot- ORG>]

Hi, Geoff/All:

Geoff Lane and Reuven Frank had interesting comments on the topic.

Geoff said, among other things:

>If possible:
>1. Ensure that the translator will translate into his/her 'mother tongue'.

Very wise. But there are a few people who are fully bi or even
multilingual. So don't take this as an ironclad rule. There are exceptions.

>2. The translator should be familiar with the technology that you are
>   documenting.

Also very good. But notice the proviso he himself placed at the top of his
comments. With the technology available to translators nowadays, it is
perfectly possible for a translator, say, with some computer knowledge, to
translate a computer-run medical gizzmo. He would, of course, need the
backup of a medical specialist to oversee the translation, but it can be done.

>3. Always translate from the original source into each language.  For
>   example, translate direct from English to Russian (not via Hebrew).

There are lots of humorous (or tragic, depending on the point of view)
asides re this topic. Especially concerning machine translations, a topic
which wasn't covered but which is more and more a part of the subject matter.

>4. The translator must be able to meet any special requirements.  For
>   example, if you need output in Frame 5.5 then the translator must be
>   familiar with that software.

I myself started on Frame way back on Frame 3. This because that was when I
signed up on this list and quickly realized that the jobs of the future
were going to come in in FrameMaker format. It paid off. But it is not a
must. There are other options for translators without specialized knowledge
of desktop publishing. The more so if you are exporting the file into a
machine translation software and then exporting it back into the original
format.

>5. Before commissioning a large project, obtain some samples from the
>   translator and get them proof-read by a native speaker who is
>   competent in the technologies.  This will give you confidence in the
>   translator (or tell you that you should look elsewhere).

Yes, definitely. Here you should use almost the same set of tactics used to
choose a writer...

>6. Before publication, get the translated work proof-read by a native
>   speaker who is competent in the technology.  If your organization
>   hasn't got someone suitable, then get another translation bureau to
>   do the proof-reading.

If you did your homework under suggestion 5, this is less important. What
is important is that you have installed a set of procedures for QAing your
translations. And have them installed beforehand, so that they are part of
the whole process, and not just spasms of indecision.

>7. In addition to the translation, commission a translator's glossary.
>   This will help ensure consistency.  Insist that the translator uses
>   this and delivers it to you with the completed translation.  You will
>   find the glossary *very* helpful for translating other text or for
>   updating the existing translation.

Also very good. But, in the end, it depends on who will do the glossary.
And also remember that a glossary is a living organism. Constant reviews
are in order. If you can, establish a ritual for inclusion/review/exclusion
of glossary terms. It will pay when you get into -- as most of you will,
sooner or later -- machine translations.

>8. On the subject of glossaries, include a glossary with the source that
>   you pass to the translator.  Ensure that the translator has adequate
>   communication with yourself (or an appropriate SME) so that he/she
>   can obtain any definitions necessary.

Yes. But see 7, above.

>9. Write consistently in simplified English.  This will minimize the
>   chance of confusing the translator.

NEVER. If it is not clear in English, it will never be clear in any other
language. Strive for the usual requirements in English: clearness,
conciseness. The cultural adaptations of your text are part of the
translator's job. You shouldn't, for his sake, sacrifice the requirements
in your own language.

But omit colloquialisms, jokes and localisms. They rarely turn out well in
other languages.

Reuven Frank also commented:

>There are a lot of people nowadays, including some really fine technical
writers and engineers, who are fluent in both Russian and Hebrew.
>You would probably be best off finding someone who speaks Russian and
English, and asking him to read back to you what the document says.

That's an oversimplification of a complex situation.

> One of my biggest philosophies on writing is that: "Your result is the
reaction you get." You can get your message across with a lousy job,
sometimes.

It would take a Houdini to do it. GIGO is an apt saying to cover this
aspect of the problem. Don't saddle the translator with a problem that
belongs elsewhere.

>The job can be done the best way in the world and some bubble-brained
supervisor comes along, who wants to make a name, and who barely speaks
English, and cuts your work to shreds.

This is a real-world comment. S. happens. But remember that it happens in
both sides of the fence. Bosses also take a well-written text and change it
into something that is not. Before the translators get their hands into it.

Try to find out what they are receiving and hearing on the other side, and
you'll know if you're getting through or not.

Excellent advice.

But there are lots more questions to be covered on this subject. To name
only one:

I just received a fully DTPed text to translate into Portuguese. One of the
characteristics of English into Portuguese text is that the text grows. 10%
to 12% on an average. So, if we receive a 20-page original text, we would
normally be returning a 22 to 23-page text. But no, many times the
requirement is that the text fit page by page.

Now, when we talk of internationalization of texts, most people don't
discuss this very prosaic but vital segment of the problem. For
internationalization means that there must be harmony in the requirements
from one language to the other. And the final look depends on the changes
to be made because the text has changed in length.

So, you get a requirement to translate so it fits page by page. You either
throw away 10/12% of your translated text (and most times you throw the
baby out with the bath water...) or you change the DTP originally
established. The easiest change is type size. Bringing down a 12-point type
to an 11-point will do wonders to solve this problem.

However, when you get Warnings, Tips and Caution paragraphs written in
9-point type (italicized), then you are left minus this solution to the
problem.

It is clear to me that internationalization of texts take in much more than
just questions on language translation. I would suggest that those who are
steeped in experience in managing this very complex question speak out
here, so that we all -- taking all sides into consideration -- come out
with some rules and procedures which, no doubt, will improve the results at
the translated end of this extremely interesting subject.

[]
Newton
mendv -at- ax -dot- apc -dot- org
Rio de Janeiro