[MPlayer-dev-eng] [PATCH] Use _NET_WM_NAME for UTF-8 title in X11 if supported

[Rich Felker]

On Fri, Jun 23, 2006 at 05:15:17PM +0200, Matthias Hopf wrote:
> On Jun 23, 06 11:05:21 -0400, Rich Felker wrote:
> > The rationale is to patch up a broken design (C/POSIX locale system),
> > and this is done with a whole secondary set of functions that are
> > nonportable and thus impossible to use in any serious program. A much
> > smarter system would be to abandon the locale system entirely and make
> > a (lightweight, not GNU bloatware style) library that's actually able
> > to support the needs of international programs (programs that deal
> > with datasets and input from more than one nation).
> 
> I don't think locale stuff can be done lightweight, too much stuff to be
> considered especially for arabian (right-to-left) and eastern (large
> charsets, combined characters, multiwidth characters) languages.

None of this requires significant special support by ordinary
applications. If you don't believe it can be done lightweight then try
out my 640k DOS UTF-8 terminal emulator with support for all scripts
once it's released. (Yes the 640k includes all glyphs. :)

> I think the POSIX way is pretty good, except for
> - being not thread safe

Yes, this is quite unfortunate. It's a result of locale being part of
ISO C, not POSIX-specific, and C not having threads (for good reason).

> - not being able to easily(!) switch between POSIX/C style and locale

Even if you could do this it's still broken, because all it can do is
make _localized_ applications, not _internationalized_ applications.
We do not live in a world of isolation anymore. Just because I'm in
country X does not mean I don't want to be able to process data from
country Y.

> - not having a POSIX/C locale with UTF-8 encoding (this actually works,
>   but is not officially supported). Which is basically what all
>   programmes will need sometime for writing out configuration / macros /
>   ascii based savefiles, so that they work with all locales and still
>   can contain strings with non-ASCII characters.

This is what my C library implementation provides, and nothing else.
UTF-8 will also mostly work with 'ordinary' C locale except that
character widths and such will be messed up.

> > > > The fundamental problem is simply that so many core library routines
> > > > depend on locale when they shouldn't. If this were fixed then the
> > > > issue would mostly go away.
> > > 
> > > So *printf shouldn't depend on locale? Which functions should depend on
> > > the locale setting then, if not printf?
> 
> Perhaps I was inserting too little <sarkasm> tags. In fact, I wanted to
> point out that *printf is perhaps the most important routine to be
> localized IMHO. You need locale dependent number formating. At least
> that is what customers say.

*puke* If this is really needed then all you need is a new format
specifier, or a separate function printf("%s", local_num(buf, sizeof
buf, locale, n)); Bloating printf up more and more is the stupid GNU
approach and it's the reason hello world is 400k with glibc!

> And - yes, I would *love* to have a posix_printf() that would use a
> POSIX/C locale,

No, this is backwards. The standard, classic function printf should
print in the standard, historical way always.

> maybe with current characterset encoding.

Idea of current charset is deprecated. Hopefully it will be gone in 5
years or so..

Rich