Standards Update, Recent Standards Activities [NLS stuff]

Kee Hinckley nazgul at alphalpha.com
Wed Jul 4 06:41:28 AEST 1990


From:  nazgul at alphalpha.com (Kee Hinckley)

In article <387 at usenix.ORG> From: <jsh at usenix.org>
>To help you think about the problem, here's the way you'll have to
>write the "hello, world" koan using the X/OPEN interfaces:
...
>          (void)setlocale(LC_ALL, "");
>          catd = catopen("hello", 0); /* error checking omitted for brevity */
>          printf(catgets(catd, 1, 1,"hello, world\n"));
...
>and using the alternative, proposed UniForum interfaces:
...
>          (void)setlocale(LC_ALL, "");
>          (void)textdomain("hello");
>          printf(gettext("hello, world\n"));
...
>I suppose if I had my druthers, I'd like to see a standard interface
>that goes even farther than the UniForum proposal: one that adds a
...
>          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
>          printf("hello, world\n");
...
>but that would still be untested innovation.

First of all, I don't think that either of these add enough of value to the
X/Open standard to make it worthwhile for those of using it to switch.
The use of strings as an index into the catalog though is definitely a BAD IDA.

Why?  A number of reasons.  First of all it's ethnocentric.  You've just told
every Easterner/MiddleEasterner that the default language is English.  Secondly
it's inefficent to and a pain to implement.  Thirdly it can produce results
which are just plain wrong.  I have different places in my application where
the English string is currently the same.  Using these schemes it would always
look up the same item in the catalog.  However in a different language the
string might well be different, but there would be no way of changing it one place
and not the other.

BTW.  Where can I get a specification of the Uniforum proposal (and comment
on it)?

The complexity of the X/Open stuff is easily hidden on a per application basis.
Anytime I want to reference a string in my application all I have to say
is MC(foo), where foo is #defined appropriately.

Where I *do* see room for improvement is in the definition of the catalog
file itself.  There is currently no specification for generating include
files or anything else, and hand numbering the strings is a royal pain.

If you consider the X/Open form:

$set 1 OmUA
$ #To
1 To:
$ #From
2 From:
$ #Subject
3 Subject:

(where '$ ' is a comment).  I've written a parser that
treats comments beginning with '#' as special and allows
'#' instead of the number.  Thus

$set 1 OmUA
$ #To
# To:
$ #From
# From:
$ #Subject
# Subject:

generates

#ifndef __msgsH
#define __msgsH

#define SETOmUA	1
#define OmUATo	1
#define OmUAFrom	2
#define OmUASubject	3

#endif

It would be nice to be able to rely on this kind of functionality.

-- 
Alphalpha Software, Inc.	|	motif-request at alphalpha.com
nazgul at alphalpha.com		|-----------------------------------
617/646-7703 (voice/fax)	|	Proline BBS: 617/641-3722

I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Volume-Number: Volume 20, Number 90



More information about the Comp.std.unix mailing list