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. 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") == "" 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. 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. 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. Another small thing, which is probably intended in libstdc++, is that locale generation will break if you have junk in LC_MESSAGES. 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. 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.