Alberto Garcia <be...@igalia.com> writes: >>> > We do however have translations for a few simple strings for the GTK+ >>> > menu items, so in order to run QEMU using the C locale, and yet have a >>> > translated UI let's use setlocale() for LC_MESSAGES only. >>> > >>> Not sure why I noticed it only now and if it's related to any recent >>> package upgrade on my side (using RHEL 7), but I noticed that >>> non-ASCII characters in the GTK UI strings are broken for me and git >>> bisect pointed to this commit. >> >> I guess we need to set LC_CTYPE too. > > That affects functions in ctype.h (isalpha(), islower(), isupper(), ...) > I guess that's safe?
If we're guessing, then I guess it isn't. But we shouldn't be guessing. "LC_CTYPE affects the behavior of the character handling functions and the multibyte and wide character functions." I doubt there's much use for the latter in QEMU itself, but in libraries, all bets are off. I guess this is what actually screws up GTK. We do use the former. LC_CTYPE set to some sufficiently funky locale is bound to upset these uses. In short: nope, we can't just set LC_CTYPE, at least not without further analysis. We should've stayed out of the GUI business. [...]
