Language check list? (Take II)

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Brad Jensen responded to my original suggestions:

<<If you can write a one page or two page do's and don'ts list, get each
programmer to read it and sign it, you will prevent a lot of
the problem in the first place.>>

Not in my experience. Maybe your programmers are easier to train? <g>

<<This idea is okay, provided that the programmers get a final say on
anything you edit.>>

Of course. I did note in my original message that if you're not certain,
you'd better discuss your changes rather than simply imposing them. The
context of the original message seemed to be more concerned with typos and
punctuation errors and suchlike trivia; I merely broadened my answer to
include editing in general.

<<You had better review it with them before you send the software out, and
not after the angry customers storm the marketing department.>>

Users as barbarians at the gates? Love the image! <g> What I didn't go into
in my original response was that you can easily do the work in Word, using
revision tracking, so the programmers can review your changes, then resave
the file as a text file. (Assumptions: That you can obtain the text in a
text file and save it back into the same format. Test this!) I've done that
successfully in the past. I've also edited the language paper in red ink on
paper and let the programmers make the change. Both approaches let the
programmers review what you've done.

I'd also noted that you can edit user-interface terms at the same time, to
which Brad replied: <<You do that and you will have crosses burning in your
front yard... the user interface is not something that should be edited
outside the programming environment... You edit the word or phrase, and it
suddenly doesn't fit any more, the user sees half of it. Or you make it
shorter, and now the user isn't sure what data entry field it refers to.  Or
you change the name of a field that is called one thing on 245 other
programs, but is now labelled 
differently on this screen.>>

All excellent points. I did assume that the editor/writer was working with a
current build of the software and could thus see space constraints in the
interface, and that being the documentation person, they were sufficiently
familiar with the interface to understand consistency issues, but that
assumption should have been made explicit. It also introduces a third
possibility for editing: working directly in the programming environment.
But that requires much tighter integration with the development team,
something that isn't always possible.

<<Or maybe you edit for style, not realizing that the term being used is a
well-known and expected one in the industry, say grocery
supply companies.>>

In focusing on the technology rather than the subject of editing, I didn't
comment on such issues, but any competent editor would take the time to
learn the jargon. Again, though, that was an assumption that should've been
made explicit. See my sig. <g>

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

“Every man is a damned fool for at least five minutes every day. Wisdom
consists in not exceeding the limit.”--Elbert Hubbard, author, editor,
printer (1856-1915)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Attention ForeHelp and Doc-to-Help Users! Upgrade your existing product to
RoboHelp for only $299, through January 31st. RoboHelp can import your
existing Help projects! Learn how else RoboHelp can benefit you. www.ehelp.com/techwr

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.