[SystemSafety] Transcending the bounds of sub-literacy

Littlewood, Bev Bev.Littlewood.1 at city.ac.uk
Wed Oct 24 19:52:53 CEST 2018


Hi John

I think I can top that! My experience concerned a translation from English into what I suppose could be called Engl-ish.

Some years ago I chaired a study group commissioned by the UK Health and Safety Commission to report on safety-critical computing in the nuclear industry. Some of the members of the group were members of this list. All were experts in their fields - not to mention literate people. We laboured for a couple of years, enjoyably, with many meetings, to arrive at a consensus document. This consensus concerned not only the technical issues, but also how these should be expressed in order to be understandable by our target audience. For the definition of the latter, I had taken on board the advice given to me by John Rimington, Director General of HSE: "Well, Bev”, he said, templing his fingers in true mandarin style, “think of your reader as a good A level student ... or one of our brighter back-bench MPs.”

I thought the final version was rather a good read. So, with the agreement of my colleagues, I pressed Send and it went off to be - as I innocently expected - published by HM Stationery Office, and delivered to the HSC.

A couple of months passed, and I received the proofs for checking. About 100pp of them. To my horror it had been completely rewritten, and turned into a complete dog’s breakfast. Some poor bastard had been tasked with transforming it into “Plain English” - which was a particular Civil Service obsession at the time. Much of our consensus text had become technically meaningless. Some of it was simply gibberish. And it was now a horrible read for that target MP. And I won’t tell you about the mangling of my gerunds, gerundives, and subjunctives...

Eventually, but only after threats from us to dissociate ourselves from it, our original version was restored. We eventually got a handsome apology from the chairman of the HSC. This whole debacle, of course, arose from good intention. “Plain English” has improved income tax forms….

If anyone is interested in reading the report, it’s available at http://openaccess.city.ac.uk/1955/. I think it’s still rather good, even after 20 years!

Cheers

Bev


On 24 Oct 2018, at 10:05, SPRIGGS, John J <John.SPRIGGS at nats.co.uk<mailto:John.SPRIGGS at nats.co.uk>> wrote:

I have, on more than one occasion, been asked to translate documents ostensibly written in English into English  - and not all of them originated from authors for whom English is a second language...

Once I even had a deadhick manager ask me to replace a sentence in one of my own documents with a construction that contained no verb!

I once had a paragraph in a document for a Scandinavian Customer replaced by such a manager, because, "They will not understand the way you put it".  When the Customer's review comments came back, they had highlighted that new paragraph asking for it to be rewritten "to correct the grammar".  They accepted the original paragraph...


John

-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Olwen Morgan
Sent: 24 October 2018 09:08
To: systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>
Subject: [SystemSafety] Transcending the bounds of sub-literacy


A few years ago, I had to supervise the translation of around 100,000 words of technical documentation from German into English. Two translation agencies declined to translate one particular 25,000 word user manual document, so I did it myself.

Normally I expect to translate at a rate 2000-2500 words per day. On that document, I averaged 850 words a day. It was by far the most difficult technical translation I've ever done. Linguists here will appreciate that technical German has an impersonal style that often defies direct translation into English - typically there is much sentence reorganisation to do. In this case things were made worse because the original document had been written by an Iranian in none-too-succinct German to begin with. Some years earlier, I had a similar experience translating a similarly-sized testing manual from French into English.

Ironically, one can have almost as much trouble "translating" insuccinct technical English into something better. Over the years I have seen many items of technical documentation that were appallingly written. Sadly, it's very common in s/w engineering.  AFAI can see, the majority of (not
just) s/w engineers write excruciatingly bad technical English.
(Translators often complain about it.) Doing this in a critical system's requirements specification is akin to shooting yourself in the foot before you start a marathon.

There are some things you can do about it. In one company, I recommended that engineers use the readability metrics in MS Word. If you kept the Flesch-Kincaid grade level no greater than 8 and the Flesch reading ease no less than 60%, the results tended to be markedly better than usual.
Another approach is to follow BS0, which sets out editorial requirements for British Standards. Once you're used to it, you can gibber BSI English in your sleep.

On the other hand, I suspect that most people who do technical subjects at school do so, at least in part, because they are uncomfortable in the more touchy-feely area of language. To my mind, it shows in the quality of their writing. (Once I even had a deadhick manager ask me to replace a sentence in one of my own documents with a construction that contained no verb!)

IMO courses in writing clear technical English (or whatever language you
use) should be mandatory and have to be passed in all engineering degrees and equivalent professional training. Forget requirements management. With a little discipline, you can produce perfectly manageable requirements specifications simply by writing decent English into the cells of a spreadsheet - and if you can't, an RM tool is limited in what it can do for you.


Having a foggy-headed morning and yet another grumpy-old-woman moan,

Olwen



_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email information.solutions at nats.co.uk
immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose
their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to
secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses
caused as a result of viruses and it is your responsibility to scan or otherwise check this email
and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd
(company number 4129270), NATSNAV Ltd (company number: 4164590)
or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218).
All companies are registered in England and their registered office is at 4000 Parkway,
Whiteley, Fareham, Hampshire, PO15 7FL.

***************************************************************************
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________

Bev Littlewood
Emeritus Professor of Software Engineering
Centre for Software Reliability
City, University of London
EC1V 0HB

Phone: +44 (0)20 7040 8420  Fax: +44 (0)20 7040 8585

Email: b.littlewood at csr.city.ac.uk<mailto:b.littlewood at csr.city.ac.uk>

http://www.csr.city.ac.uk/
_______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181024/ed8dea16/attachment-0001.html>


More information about the systemsafety mailing list