#4 wrong codepage used by gettext

[vassily ragosin]

Gettext version: all gettext releases up to 0.13.1 have
this bug.
Concerned platforms: WinNT console, maybe Win95 console
as well
Background information: As usual with Microsoft, for
"historic reasons", different codepages are used by
win32 gui and win32 console when working with Russian
8-bit text. Console window uses cp866, GUI uses cp1251
as a native encoding.
Description: When gettext performs the output to win32
*console* stdout, wrong (cp1251) codepage (instead of
cp866) is used for Russian locale. As a result,
localized messages output to win32 console from
gettext-enable console programs are not usable, because
most of the mature Russian-speaking population do not
have the ability of builtin libiconv in their brains to
be able to decipher wrong codepage messages on the fly.
Solutions: gettext need to convert text to cp866 when
output is on windows console stdout or when trying to
set a title of win32 console with a localized russian
string.
Patches: sorry.

[Bruno Haible]

At the moment a program asks for a translation
from gettext(), it is not yet clear whether that
string will be piped into an Emacs buffer (GUI
codepage) or to a console (console codepage), or
written into a file or pipe that will then be
viewed through the GUI (GUI codepage).

For this reason, the best possible implementation
of this feature would be an iconv-on-the-fly
inside stdout, if stdout happens to be directed
to a console. But this is hard to do portably
(and for every program!), and also does not work
well for commands like
$ foo --help | head -n 20

In summary, there is no good solution. Blame
Microsoft or use a console replacement that
does not have this problem.