[Mailman-i18n] HTML entities (é) in es, it, no translations

[Martin von Loewis]

Ben Gertzfield <che@debian.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.

Regards
Martin