Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

How to handle bad source texts in technical translation?

+0
−0

In technical translation (e.g. of manuals), the quality of the source text often is not very high. This concerns not only the language used, but also the structure of the whole document.

Should technical translators rearrange the structure and overall layout of a document or should they keep the original structure and simply provide a sentence-by-sentence translation (as happens automatically when using translation software like OmegaT or SDL Trados Studio)?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/33540. It is licensed under CC BY-SA 3.0.

0 comment threads

1 answer

+0
−0

In the translation work I've seen for user-facing documentation, the translators stuck to the organization of the source but sometimes rephrased entire paragraphs, particularly if the source used idioms. This is particularly important if those translations need to be maintained over time as the source text is updated -- applying those updates to a translation that was rearranged will be both more expensive and more error-prone.

If there are problems in the source (you mentioned poor organization, for example), the best way to respond is to try to get those problems fixed in the source. This has the benefit of fixing it in at least two languages -- maybe more, if yours is not the only translation being done. My doc team occasionally receives requests for changes to make translation easier. We write with translation in mind to begin with, but nobody's perfect.

The general principle is to fix the problem as close to the source as possible. This is true whether you're talking about translation, formatting (single source, multiple outputs), or code.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »