> Date: Mon, 12 Jan 2026 18:50:10 +0200 > From: Eli Zaretskii <[email protected]> > Cc: [email protected], [email protected], > [email protected] > > > Date: Mon, 12 Jan 2026 17:25:10 +0100 > > From: Patrice Dumas <[email protected]> > > Cc: Gavin Smith <[email protected]>, [email protected] > > > > On OpenBSD, the only useful value for the category is LC_CTYPE. It > > sets > > the locale used for character encoding, character classification, and > > case conversion. For compatibility with natural language support in > > packages(7), all other categories -- LC_COLLATE, LC_MESSAGES, > > LC_MONETARY, LC_NUMERIC, and LC_TIME -- can be set and retrieved, too, > > but their values are ignored by the OpenBSD C library. A category of > > LC_ALL sets the entire locale generically, which is strongly > > discouraged > > for security reasons in portable programs. > > > > So, unless I misinterpret this, it seems that LC_CTYPE should be used > > instead of LC_MESSAGES on that platform. > > > > I tested, and indeed it worked to switch to a locale different from 'C'. > > "Cannot switch to a locale compatible with document strings > > translations" does not appear anymore, however, the strings are still > > not translated. > > > > I do not like the idea to use LC_CTYPE, but maybe others have other > > ideas. > > > > My feeling is that it works in C, because we do it a bit differently, > > like: > > > > setenv_status = setenv ("LC_ALL", "en_US.UTF-8", 1) > > || setenv ("LANG", "en_US.UTF-8", 1); > > locale = setlocale (LC_MESSAGES, ""); > > I don't know if it's relevant, but MS-Windows' setlocale also doesn't > support LC_MESSAGES.
Also, LC_ALL in the environment doesn't affect the MS-Windows' setlocale. Why does the code above go via the environment, btw? why not simply locale = setlocale (LC_MESSAGES, "en_US.UTF-8"); ?
