Closed mattjgalloway closed 1 year ago
Hi @mattjgalloway . I'm currently working on getting your PR fixing this into the next release (no worries about the conflicts, I'll resolve those)
I was wondering whether you had any expectation on how en_US_POSIX
is handled?
As far as I've understood this is basically the "C"
locale in C++, aka "POSIX"
. So I think it makes sense to treat it as an alias so the output would be:
LOCALE NAME: C
LOCALE LANG:
LOCALE COUNTRY:
LOCALE ENCODING:
LOCALE UTF8: 0
You could run into this on Linux or when using boost::locale::generator("en_US_POSIX")
as the WinAPI will not return that as the "system locale".
@Flamefire Thanks for coming back on this!
Yes I think that would be right for en_US_POSIX
.
Thanks @Flamefire for getting this merged!
I'm starting to use Boost.Locale in a project and I've hit up against a problem when the system locale is en_001. And I believe it will also be a problem with en_150 and en_US_POSIX as well. The problem is best described with the following test case:
If the system is in en_001, which on Windows is the "English (World)" region name, then the following will be output:
I would expect the output to be:
It's coming from the fact that in
boost::locale::util::locale_data::parse_from_country
, we are assuming the country needs to contain only 'a' to 'z' or 'A' to 'Z'. Buten_001
(anden_150
) are valid locales. Probablyen_US_POSIX
should be handled separately as it's special.