RE: Apostrophes, quotation marks, keyboards and typography

From: Addison Phillips (AddisonP@simultrans.com)
Date: Mon Jul 19 1999 - 21:50:12 EDT


Not to mention the very large number of boneheaded system designs in which
internal representations are ALSO displayed to the end user and which must
never be translated. Fine meaningful messages (from a real project being
worked on right now) such as:

"The LAST_NAME must not be longer than 30 characters"
"The DATE you entered is in an invalid format"
"Enter the SKU you wish to search on:" // SKU is a field name inserted via
%s... don't forget the gender/count issue either

And that's the tip of the iceberg--these are trivial examples. If you can't
localize *all* of the messages that the system generates then it's a bug!! I
can't tell you the number of systems where internal and external strings and
representations are used interchageably and no separation (let along
identification) is provided... or where the variable/field/internal name is
ALSO used to convey information to the user.

I recognize the Markus really means "in code" as opposed to external
structures, but many programmers already write their comments in language.
Why not variable names? I mean, if Plan 9's windowing system can be called 8
1/2 with a real fraction... it can't make the parser any harder to write!

Addison
        __________________________________________

        Addison Phillips
        Director, Globalization Consulting
        SimulTrans, L.L.C.
        2606 Bayshore Parkway
        Mountain View, California 94043 USA

        +1 650-526-4652 (direct telephone)
        +1 650-969-9959 (facsimile)
        AddisonP@simultrans.com (Internet email)
        http://www.simultrans.com (website)

        "22 languages. One release date."
        __________________________________________

-----Original Message-----
From: Murray Sargent [mailto:murrays@microsoft.com]
Sent: lundi 19 juillet 1999 18:16
To: Unicode List
Subject: RE: Apostrophes, quotation marks, keyboards and typography

Markus noted:

> > ... ASCII for
> > identifiers is just fine, and if it forces software engineers to stay
> > with English identifiers, then trust me, this is a feature, not a bug.
>
An example where nonASCII identifiers is really useful is in coding up
mathematical formulae that contain Greek letters. For example, a program is
much more readable if you use U+3B1 for alpha rather than spelling out the
name alpha. Similarly U+3C0 for pi. Hopefully C++ will follow Java's
excellent example and allow Unicode alphabetics in variable names.

One particularly intriguing possibility is the use of Chinese characters.
Imagine the expressive power of relatively short program statements if you
could use such succinct representations of ideas. Of course, you need to
read Chinese...!

Murray



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:48 EDT