TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Technical name for the #? From:Janine Griffin <janine_griffin -at- MAIL -dot- TAIT -dot- CO -dot- NZ> Date:Tue, 1 Dec 1998 14:20:09 +1200
John Hoppe wrote on Tuesday, 1 December 1998 3:54 >>>
>I must agree with Wes Tracy on this. Though I too believe that one
>should not clutter the landscape by making up new words or phrases when
>perfectly accurate ones already exist, it seems that comprehension is
>the ultimate goal here, and "octothorpe" is so arcane that it will
>likely cause more confusion than clarity.
Agreed. We have to use terms the majority of people in our target
audience are going to understand otherwise we will confuse them rather
than inform them.
>"Pound" is so commonly used in
>phone messaging systems (e.g., "For flight information, press pound")
>that it may be the new standard term, since we all have such vast
>familiarity with these messages now.
Yes, it would be a standard term if it were used that way all over the
world. It isn't. When I go to collect messages from voicemail, the
Telecom New Zealand voicemail recording tells me to "Enter your password,
then press the hash key". Should I therefore jumped to the conclusion
that the # is called hash everywhere??
Please, people, do not assume that just because something is called X in
the US that it is called X everywhere. Sorry, John, I'm not picking on
your message in particular, but on the general assumption expressed
throughout this thread that because something is one way in the US, it's
that way everywhere else. It's like saying people all over the world
celebrate Christmas on the 25th of December or Thanksgiving on the last
Thursday in November, and that UKish TV viewers don't titter when a
character in an American TV show is called "Fanny" or "Randy". People all
over the world use and understand words in different ways, and this
probably has a lot to do with why there is a craft called "technical
communication". Technical communicators need to remember what audience
they're communicating to, and if this audience is international, that has
to be taken into account. We can't be ignorant of international
differences. At the same time, however, we can't know everything, but we
can make the effort to know enough that we can do our job well. This list
is one of the tools for broadening our understanding.
I can say nothing with certainty except what I know from direct
experience (even that is sometimes questionable). All I can say from my
part of the world is that the # symbol is commonly referred to as "hash",
infrequently as "number" and not as "pound", and even that last one I
have to qualify with "not that I've heard or read in my 12 years in NZ".
Because I've lived in the US for 13 years, I can also say that "In the
US, it appears to be called pound or number". I can't speak for any other
part of the world, but I do know that the MPT 1343 spec (a British
standard) refers to the # mark as "number", and information posted to
this list and the number of poms working here indicates that "hash" is
probably quite widely used.
The radios I write documentation for have a # key. Since our markets are
primarily UKish, we haven't had a problem with misunderstanding that I'm
aware of. But I always write "press the hash (#) key" when I refer to the
hash key. This is for clarity, because I also say "press the star (*)
key" when I refer to the star key, not because there are different terms
for the * around the world but simply because it makes things clearer for
the user.
So we can't make assumptions about what our audience does and does not
know. For example, I know that the F1 key is the "standard" key for
accessing online help, and it appears that all the engineers around me
know that too. So I might assume that *everyone* knows that the F1 key
accesses online help and so it would be patronising to describe that in a
software manual. Wrong. We'd get numerous calls from our customers saying
"How do I read the online help?".