Re: perror, gettext, question marks

[Chiaki Ishikawa <Chiaki dot Ishikawa at personal-media dot co dot jp>]

X-PMC-CI-e-mail-id: 14241 

Mark S. Brown said: 

>> I think it takes a little while before the general
>> computing community, especially the programmers, begins
>> handling these locale issues correctly.
>
>I think that some of us get frustrated, in that setlocale() has been around
>since at least 1992....

Yeah, right.

I don't recall when exactly, but 
I modified the localized xterm, called kterm,
so that it called setlocale().
Once it did, I could modify the menu items of the kterm menus 
(those familiar with xterms know those menus invoked by control-mouse
buttons) by means of X resources.
Some of the entries  showed Japanese strings.
I thought it was neat.

HOWEVER, when the next major X11 upgrade was released, the
kterm source files in the contrib section overwrote my local copy
by mistake and I found out that the kterm souce in the official source tree
didn't have setlocale() yet. 
Ouch. Back to square one.
(This all happened several years ago on my Sun boxes at the office.)

So, with this background, it was a pleasant surprise to see
kterm in action  when I installed 
Linux on my home PC a few years back. 
Once I copied the .Xdefaults, .Xresources and other setup files from 
the sun to my home PC, I realized that the kterm on Linux had 
automatically Japanese menus! 
This meant that between the earlier X11 release
and my encounter with linux (after 1995), 
the modified source files of the kterm, which has setlocale()
and other features, became dominant and whoever packaged the 
Linux distribution I used picked up the "right" version that called
setlocale().
I was very glad to see this happen because
many Japanese programmers all over Japan needed to add 
minor modifications before seeing Japanese menus eariler.

Now back to today.

With the introduction of glibc with I18N features,
many programmers (and the users alike) all over the world will learn
to use the new features in acceptable manners: I agree there
are subtle issues on various occasions and these need to be
analyzed and mostly acceptable solutions need to be found.
(Surprises regarding LANGUAGE environment variable can be
thought of as one such issue.)

Many programmers still may  find I18N programming beyond their scope
of programming, or for that matter, some of the so-called
standards/guidelines for I18N may not have foreseen all the glitches
of real-world application programs on Unix-like OS when it comes
to I18N usage. We need to fix these along the way.

So folks, let's have a little more patience for a while.

[ Yes, I have become a little jaded after all these years and
it is refreshing to see people agitated about these issues :-) 
We need more young turks if you pardon the expression.  ]

-- 
     Ishikawa, Chiaki        ishikawa@personal-media.co.jp.NoSpam  or         
 (family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
    Personal Media Corp.      ** Remove .NoSpam at the end before use **     
  Shinagawa, Tokyo, Japan 142-0051