On Thu, Oct 08, 2026 at 04:08:07PM +0300, Eli Zaretskii wrote: > > Date: Thu, 8 Oct 2026 14:00:45 +0200 > > From: Patrice Dumas <[email protected]> > > Cc: Eli Zaretskii <[email protected]>, [email protected] > > > > We skip the code that sets a locale to something else than C for _WIN32. > > My feeling is that it is why it does not work. > > Could be, yes. > > > The MSYS2 mingw with ucrt gcc is probably more like traditional UNIX > > than what Eli tested on previously > > No, UCRT is just a more ANSI-compatible C runtime. It isn't more > Unix-like than the old MSVCRT, at least not significantly so, not > AFAIU.
Ok. I have no idea what else could be involved, but I am quite ignorant regarding those platforms. > Why did we decide to set the locale to C in that case? The tests are run under the C locale, which is done mainly for portability, as it is the onlt locale that is always supposed to be there. Regardless translations of document output strings should work in the C locale. > Also, does string translation in this case depend on the locale, or > does the code invoke gettext regardless of the system locale? The string translation does not depend on the locale, but on the document language. However, if the locale is the C locale, it must be changed first to any other locale such that LANGUAGE is obeyed, and it is this code that is skipped on _WIN32, which is probably wrong. > > Eli, would you know what #ifdef use to do something different on the > > platform you used previously (MSYS with mingw, maybe?) and this new > > MSYS2 with mingw ucrt gcc? > > The UCRT build defines _UCRT in the system headers, whereas a build > with the older MSVCRT runtime does not. Not sure that it is the definitive thing to do, but it should not break the other build and I can use that to experiment in the CI. -- Pat
