Byrial Jensen <byrial(_at_)image(_dot_)dk> writes:
Well, gettext, xgettext etc. works fine with \r even though they
complain.
Maybe today, but looking at GNU gettext's version 0.10.something, will
that be the same tomorrow?
However one problem exists that is not just cosmetic. The messsages
which contain \r are texts which may be mailed to the user by
fetchmail. Fetchmail delivers the e-mails generated by itself in
the same way as it delivers fetched mail. This is a problem when
the translated messages are send by for example SMTP -- the used
charset often has changed from ASCII to something else which is
illegal to send without encoding etc.
The fix is simple: SMTP demands \r\n line endings, so don't expose these
to localization and internationalization. I have never looked really
closely into l10n and i18n issues, but I think there is a way that a
program chooses which messages to replace in a translation and which
not.
I suppose that the best solution is /not/ to handle this in
fetchmail, but to deliver self-generated mail to a MUA which knowns
how to treat messages in the local charset.
What should fetchmail care? It could get a parameter what to throw into
the charset tag of the Content-Type: parameter, which would be
localized. But then there is RFC-2822 for the content and RFC-2821 for
the wrapper. No need to bloat the list of dependencies.
--
Matthias Andree