[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Inconsistent use of case in acronyms
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2004-08-29 10:29:30
Message-ID: 200408291229.32986.caslav.ilic () gmx ! net
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> [:Vedran Ljubović:]
> However, it seems that some people think that all upper case text looks
> "scary" and so they write their acronyms in sentence case then it
> somehow looks "less scary". The problem is, sometimes the new word has
> an entirely different meaning, for example MIME (short for Multipurpose
> Internet Mail Extensions) is *not* mime  [...]

There might be more to this than it seems at first sight (due to some other
considerations, we at Serbian translations had frequent talks about
spelling of acronyms).

In Serbian, one can write acronym without all upper cases if it can be
*pronounced as a word*, i.e. not spelled out. Frequently we write "Unesko"
instead of "UNESCO", "Nato" instead of "NATO", etc. I don't know what are
the English spelling rules on this matter, but it seems it frequently goes
along same lines, especially with back-formed acronyms (backronyms):
"Gnu", "Gimp", "Gnome", etc. Or take "radar", nobody writes it as
"RADAR" (Radio Detection and Ranging) any longer.

As for MIME, I suspect that it actually is pronounced like "mime" instead
of being spelled out. Since it is frequently changing spelling, something
could be prescribed in this case as a measure of style consistency; but I
don't think there should be a general rule, as it might confuse people in
other cases (like with backronyms). I agree that "MIME" is a better
alternative as it is more conservative, though I find that real meaning of
"mime" is not so far from that of "MIME type" -- a quick gimmick to pass
some important info :)

> For example, instead of "MIME type" you might want to say "file type",
> or "document type" or just "type".

Just for the record, should it come to globally throwing out mimes :), I
think that the right substitution where mere "type" is not sufficient, is
"content type".

> Another situation comes when there's a console command to do something
> that happens to be an acronym or a program name. So, for example, CVS
> stands for Concurrent Versioning System, but in context of actions a
> developer will usually write "cvs" to be consistent with the console.
> What's the purpose of stating console commands in a GUI? Then just use
> the console, right? Or, a menu option might say "mutt", but I would
> prefer "Mutt" cause it's a program name afterall and not an English
> word which again is a source of potential confusion and blahblah.

I do not think that shell commands should not be mentioned in a GUI,
especially because there may be other commands as well (like IRC, TeX,
etc.) On the other hand, I do think that it would be nice if developers
would refer to commands only when they really have to, and use proper
names of programs/packages with normal casing otherwise. It would be very
convenient for Serbian translators, as we might both transliterate (in
case of Cyrillic script) and add case ending to a proper name, but not to
a command. However, having in mind the liberal interchange of these in
world of Unix, it will be a cold day in hell before developers start
adhering closely to such a distinction.

- --
Chusslove Illich (Часлав Илић)
Serbian KDE translation team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBMbAMMSGXgigGr3ERAot4AJ4h6GbLFNnV0UC/8CJXWgrS4eN5TgCeMQu/
Szv7AC9rrP8oiyXcHh8NKGs=
=HHVZ
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]