Ben Gertzfield firstname.lastname@example.org writes:
As for the footer.. hm. Needs more thought. I doubt anyone wants to add an attachment for the footer; I think the best thing to do would be to look up the body's charset in a table and attach a properly localized footer if it's found. If it's not found, no footer is attached. If the charset is not specified, assume us-ascii.
What do you think?
Sounds good. If the necessary codecs are available, one might try to recode the footer in the charset of the message, if no properly encoded footer is available.
Martin> I'd encourage you to have a look at the iconv codec Martin> also. If the system iconv is powerful enough (e.g. on Martin> Linux glibc), all encodings of the world would be Martin> supported with that single codec.
Ah, if only all systems had such an iconv codec.
Should that stop you from using iconv where available? On a Debian system, you'll know it is present :-)
I'm surprised iconv is so powerful on Linux glibc, yet gettext does not support iso-2022-jp directly.
I'm not surprised. The traditional encoding on Unix is eucJP; and gettext/libc can transparently recode the message to any target format. So the catalog could be in eucJP, or utf-8, and you still could produce messages in iso-2022-jp.
I just tried it on a catalog; msgfmt complained about two problems: for one thing, it complains that iso-2022-jp is not a portable character set name, i.e. that many systems apparently don't recognize this character set name. The other problem is that it complains about illegal escape sequences. I don't know where this comes from; it might be a gettext mbcs bug, or a glibc bug, or an error in my data. If you have real data which are not properly processed by msgfmt, please report that bug to Bruno Haible.
I can't see any reason why gettext(3) would have any difficulties with iso-2022-jp.