Alain Bench <[EMAIL PROTECTED]> writes:
> Call setlocale(LC_ALL, ".OCP") which will select the default OEM
> charset of the current Windows language. OCP means "OEM Code Page",
> and console apps by default need to use this OEM charset: Probably
> CP-852 for you, CP-850 for me, and so on. Here this setlocale .OCP
> returns "French_France.850".
>
> Another possibly better way, able to follow the current charset of
> the console (not only the default):
Is the "current charset of the console" ever really different than the
"default OEM charset"? How does one change the console charset,
anyway?
> Call GetConsoleOutputCP(), get example 850, build a string ".850"
> with the dot, and call setlocale(LC_ALL, ".850"). Problem: Not every
> combination of language, country, and charset is possible. So deal
> with errors (setlocale returns NULL), and fallback to ".OCP".
Thanks for the detailed description. In that case, the setlocale
invocation should look like this:
#ifdef WINDOWS
{
char console_code_page[32];
snprintf (console_code_page, sizeof console_code_page,
".%u", GetConsoleOutputCP ());
if (!setlocale (LC_ALL, console_code_page))
setlocale (LC_ALL, ".OCP");
}
#else
setlocale (LC_ALL, "");
#endif
But I've now noticed another issue: Wget is calling setlocale(LC_ALL,
"") only if HAVE_NLS is defined, which is typically not the case on
Windows, as HAVE_NLS implies existence of gettext, textdomain, and
bindtextdomain.
Along with the above patch, someone should also try to move the call
to setlocale() outside #ifdef HAVE_NLS -- maybe that would be enough
to fix the problem. Testers able to compile Wget and reproduce this
problem would be much appreciated.
