Re: [boost] [locale] Custom Gettext paths.

Subject: Re: [boost] [locale] Custom Gettext paths.
From: Jookia (166291_at_[hidden])
Date: 2012-08-23 02:34:22

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_at_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.