This speaks [heh] to one of the enjoyable vestiges of my time studying Linguistics: I like to guess at the native language of the author(s) of a manual. Even if the English is perfectly correct, English has several WAYS of being correct, and the details of the structure, the options used, the STYLE, hints at original language. The position of modifiers, verbs, and using or eschewing complex tenses or indirect objects or subordinate clauses, etc. are telling. If there ARE errors, it becomes easy.
Given the presumed national origins of documents, I can tell that Japanese is very polite, but has some kind of weirdness with verbs (relative to English), but different from German, and Romance languages handle adjectives differently. Germans love their modifiers, Chinese hate tenses, and Scandinavians might just consider getting rid of prepositions altogether.
I have a collection of hilarious accidents (as well as deliberate ones like the "Damn Fast Buffer Amplifiers" and "Write-Only Memories" of legend). There's plentuy of hilarity on "Engrish.com" but adding the geek factor by collecting examples from my field amuses me.
I love the notion of using lingusitics to deduce the root cause of garbled instruction manuals. That said, I can't comprehend why manuals are not submitted to a native reader for a final proofing step. Compared with the hardware and software development costs, the native reader review would cost nearly nothing. Furthermore, it would enhance the reputation and functionality of the device if the manual made sense. I'm sure that I'm only one of many scientists and engineers who would be pleased to provide their consulting services for the greater good.
@DrQuine: I can't comprehend why manuals are not submitted to a native reader for a final proofing step. Compared with the hardware and software development costs, the native reader review would cost nearly nothing.
I AGREE!!! I've never been able to understand this -- when you think og the time and effort involved in creating the product, why not go that one last bit and create a good manual.
@zeeglen: The system designers did not mention that important little fact in the user manual...
I'm happy to hear that th emanual itself was well written -- but you highlight another problem area in that manuals are often drafted by people who know the system intimatly -- it's always a good idea for someone who DOESN'T know the system to try using the manual to work out where problems may hide away.
I'd hate to think that the cost of having a native reader check a manual would be a factor for a corporation. The cost of having a reader review and correct the document is tricial in comparison to the product support costs of managing the mass of customers who require technical support because of an unintelligible manual and the lost sales from dissatisfied customers. Distributing an incomprehensible instruction manual is product marketing suicide.
"I can't comprehend why manuals are not submitted to a native reader for a final proofing step."
Having been tasked with translations on several occasions, things are slightly different:
Whether you have a native proof reader or a native speaker (writer) doing the translation, there is an additional require- ment for this person: knowledge of the matter handled. I had native speakers injecting 3 major contortions within a single paragraph - and this was one of the better cases...
On the other hand, when I was reading a lot of datasheets from Sie... and Bo..., it was clear that these documents were "thought" in German and spelled in English. As the swiss colleague already stated: you can understand them by translating word by word.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...