using xlocale to implement std::locale class

[Sam Varshavchik]

François Dumont writes:

> On 05/04/2011 02:18 PM, Paolo Carlini wrote:
>> Hi,
>>> Constructively, I would also encourage you to submit fixes, preferably of a  
>>> sort not breaking the binary compatibility (otherwise, we can still look  
>>> into the patches now, but would be targeted at the ABI breaking branch  
>>> opened by Francois)
>>>
>>> … but Francois's more recent patch in that bug seems to work without  
>>> changing the ABI. I must've missed the notification from Bugzilla.
>> Indeed, I remember Francois made very good progress on those issues, then  
>> something tricky surfaced (recently, on this mailing list). It would be  
>> great if you two could collaborate...
>>
>> Paolo.
>>
>>
>     If you want to help you are welcome Sam. I have problem with usage of  
> message catalogs on my platform, I never understood why and I remember that  
> I was quite disappointed that the dgettext do not give any diagnostic  
> regarding issue in load of catalogs. It is designed this way of course but I  
> would appreciate an other method to check for the existence of a catalog.

I don't think there is a way to do it, as far as my understanding of the C++  
library, or POSIX goes.

The fallback for gettext() and friends is to punt back the unlocalized  
string as the default. If no such message catalog exists, you get the  
unlocalized string. If the catalog does not have the message listed, you get  
the unlocalized string.

So, if you don't have your text catalog installed in the right directory and  
gettext can't find it, you'll just get back the unlocalized string, with no  
indication of what happened. That's just the way that POSIX/C++ has  
standardized the API.

Then, just to make thing more interesting; if you use, say, the latest and  
greatest GNU gettext to compile your message catalogs, and you use the wrong  
feature which your platform's gettext() does not recognize, you'll most  
likely get back the untranslated string as well. I note that std::messages  
does not appear to export functionality that's equivalent to dngettext(), so  
you can't access those localized strings via std::messages, no matter what  
you do. It would be nice to have that, of course, even if it's just a  
libstdc++ extension.

I don't think it's your platform that's giving you issues. That's …just how  
it behaves. On Linux, I just use strace to see where libc is trying to open  
the catalogs, then keep munging the environment variables until it looks in  
the right place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20110505/0759bd86/attachment.sig>