-
-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not supporting en_001, en_150 or en_US_POSIX locale #58
Comments
This addresses boostorg#58, by allowing 0-9 in the range of characters for the country of a locale.
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
You could run into this on Linux or when using |
@Flamefire Thanks for coming back on this! Yes I think that would be right for |
This addresses boostorg#58, by allowing 0-9 in the range of characters for the country of a locale.
This addresses boostorg#58, by allowing 0-9 in the range of characters for the country of a locale.
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.The text was updated successfully, but these errors were encountered: