[MPlayer-dev-eng] [PATCH] Fix dll loading with Turkish locales

[Vladimir Mosgalin]

On Wed, 19 Jan 2005, D Richard Felker III wrote:

DRFI>gettext is ok by me, but setlocale is never acceptable imo. all it
DRFI>does is break the expected behavior of all the standard c library
DRFI>functions.

Standart C library defines which functions change behaviour after
setlocale.. And they do it for a reason. You shouldn't assume that "they
work correctly only in C locale".

Besides, if setlocale call with LC_ALL will really break something, why
not call it with LC_MESSAGES for a while? (fixing bugs causing this in
the same time).

Maybe you don't understand this, but for example I have to convert
help_mp-ru.h from outdated koi8-r encoding to more widely used cp1251
each time I compile mplayer. Of course, script does this for me, but
this is stupid anyway! No other software has such kind of problems.
About 1400 packages are installed on my system and I can't remember
anything with such kind of problems. You can run any program in any
locale, and it just works.

You think that this is egoistical, because I should modify mplayer's
code to suit my needs instead of asking someone to do this? OK, forget
about me. Think about people who package mplayer for my distribution.
Officially, it supports koi8-r, koi8-u, cp1251 and iso-8859-5 encodings
for Russian and Ukrainian languages. No one uses iso-8859-5 here, but a
lot of people use cp1251, and a lot of people use legacy koi8 encodings
too. Users don't have to worry about this, though; all programs work
correctly in both ru_RU.KOI8-R and ru_RU.CP1251 locales, so they just
choose which one is more suitable for them.
Except for mplayer. It only supports one hard-coded encoding. And now
what should packagers do?  Surely they don't have time to fix mplayer's
code.

-- 

Vladimir