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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers