Re: More message encoding woes

Hiroshi Inoue wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>>> Tom Lane wrote:
>>>>> Maybe use a special string "Translate Me First" that
>>>>> doesn't actually need to be end-user-visible, just so no one sweats 
>>>>> over
>>>>> getting it right in context.
>>>
>>>> Yep, something like that. There seems to be a magic empty string 
>>>> translation at the beginning of every po file that returns the 
>>>> meta-information about the translation, like translation author and 
>>>> date. Assuming that works reliably, I'll use that.
>>>
>>> At first that sounded like an ideal answer, but I can see a gotcha:
>>> suppose the translation's author's name contains some characters that
>>> don't convert to the database encoding.  I suppose that would result in
>>> failure, when we'd prefer it not to.  A single-purpose string could be
>>> documented as "whatever you translate this to should be pure ASCII,
>>> never mind if it's sensible".
>>
>> I just tried that, and it seems that gettext() does transliteration, 
>> so any characters that have no counterpart in the database encoding 
>> will be replaced with something similar, or question marks. Assuming 
>> that's universal across platforms, and I think it is, using the empty 
>> string should work.
>>
>> It also means that you can use lc_messages='ja' with 
>> server_encoding='latin1', but it will be unreadable because all the 
>> non-ascii characters are replaced with question marks. For something 
>> like lc_messages='es_ES' and server_encoding='koi8-r', it will still 
>> look quite nice.
>>
>> Attached is a patch I've been testing. Seems to work quite well. It 
>> would be nice if someone could test it on Windows, which seems to be a 
>> bit special in this regard.
> 
> Unfortunately it doesn't seem to work on Windows.

Is it unappropriate to call iconv_open() to check if the codeset is valid for bind_textdomain_codeset()?

regards,
Hiroshi Inoue