Re: More message encoding woes

Heikki Linnakangas wrote:
> Hiroshi Inoue wrote:
>> Heikki Linnakangas wrote:
>>> 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.
>>
>> First any combination of valid lc_messages and non-existent encoding
>> passes the test strcmp(gettext(""), "") != 0 .
>
> Now that's strange. Can you check what gettext("") returns in that case
> then?

Translated but not converted string. I'm not sure if it's a bug or not.
I can see no description what should be returned in such case.

>> Second for example the combination of ja(lc_messages) and ISO-8859-1
>> passes the the test but the test fails after I changed the last_trans
>> lator part of ja message catalog to contain Japanese kanji characters.
>
> Yeah, the inconsistency is not nice. In practice, though, if you try to
> use an encoding that can't represent kanji characters with Japanese,
> you're better off falling back to English than displaying strings full
> of question marks. The same goes for all other languages as well, IMHO.
> If you're going to fall back to English for some translations (and in
> practice "some" is a pretty high percentage) because the encoding is
> missing a character and transliteration is not working, you might as
> well not bother translating at all.

What is wrong with checking if the codeset is valid using iconv_open()?

regards,
Hiroshi Inoue