----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 9:34 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 16:17, Artyom Beilis wrote:
After this happens I look forward to fixing a few other things, which I've found lacking.
What things?
Right now I'm trying to refrain from trying to suggest solutions to problems I don't fully understand. That said, right now there's no way to tell what locale you get out of Boost.Locale. You can pass in a bad locale and get out a good one, while still under the guise of a good one with no way to tell.
For example, if I pass an ICU calender variant and it doesn't work (probably because the backend isn't ICU or some other matter), Boost.Locale still returns the locale with the variant name in it. This all works fine, and is expected behaviour in ICU from what I've read, but due to it it means I can't tell bad locales from good locales in my program.
So if I write 'gen("BAD_US")' or something along the lines (my application test cases found this), chances are it'll come out fine.
Boost.Locale tries to gradually fallback to some supported locale, for example of you use Boost.Locale on FreeBSD without ICU using libstdc++ that only supported locales would be C or POSIX. On the other hand you should still be able to use encoding conversions and dictionaries. Maybe the numbers and dates would not be formatted according to the locale, but the messages would still work.
I don't know if it's possible, but I'd propose a function like get_real_locale_name which returns the 'real' name, as in the actual locale that's being used (as in a fall back if parts of the locale are valid), or an empty string if the locale is invalid all together.
get_real_locale("en_US.UTF-8") == "en_US.UTF-8" get_real_locale("en_US.UTF-8@calender=asdfbadinputjkl") == "en_US.UTF-8" get_real_locale("zh_CN.UTF-24") == ""
"Real-locale name" is backend dependent and not always 1-to-1 conversion. So you can assume that the name you had given is the locale name, however some flags may be ignored.
It seems fine, but I'm not sure if it's implementable. Briefly looking through ICU's documentation I don't really know if there's a way to get results like this.
Even with ICU the locale name would not be 1-to-1 conversion
Now, this may seem irrelevant. But my second problem is being able to figure out the fields of a locale. Currently we have loc::info, but that returns garbage in, ICU falls back, garbage out despite ICU falling back and everything behaving nice.
What do you mean, do you have an example? locale::info parses locale names syntactically.
Also for brownie points, I'm not sure exactly how to get Gettext information from a locale that already exists, since it's not really documented from what I know. I'm still a newbie to the library.
boost::locale::info gives you this information.
Another small thing, which is probably intended in libstdc++, is that locale generation will break if you have junk in LC_MESSAGES.
Boost locale does not use environment variable LC_MESSAGES, unlike POSIX locales Boost.Locale does not break down to different categories. The order the locale name is taken is LANG, LC_ALL, LC_CTYPE (if I remember correctly)
It's kind of a far out thing, but I like to be able to set my translations separately to my locale, so I use the LC_MESSAGES environmental variable to read in to my messages_info. I'm pretty sure this is application-specific, but at this point I'm just reading through my code to see what workarounds I have.
The tiniest thing that I can even think of is that I have a method like this in my application's code:
string makeLocaleName(string const& language, string const& country, string const& encoding, string const& variant) { string name = language;
if(country != "") { name += "_" + country; } if(encoding != "") { name += "." + encoding; } if(variant != "") { name += "@" + variant; }
return name; }
For convenience. It kind of compliments loc::info.
Good point.
So yeah, that's just just a bit of a garbled response because I'm not sure about any of it, and I'm sure a lot of it is by design, and it's probably just my nitpicking.
Thanks, Jookia.
Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/