From: shot@hot.pl (Shot (Piotr Szotkowski))
Subject: [sup-talk] System encoding versus messages encoding
Date: Tue, 22 Apr 2008 13:39:59 +0200 [thread overview]
Message-ID: <20080422113959.GA20034@durance.shot.pl> (raw)
In-Reply-To: <691d00b80804211337h32fe47b0l7c5ab0b331ae71af@mail.gmail.com>
Israel Herraiz:
> As far as I know (considering what I have read in the documentation
> and in the archives of this mailing list), Sup determines the encoding
> using the environment variables and tries to decode all the messages
> using that encoding. For people working in different languages and
> environments (like me, I write in English and Spanish, some people
> send me messages in UTF-8, some other in ISO-88159-1), having an
> overall encoding for all the messages is not a good solution.
I agree wholeheartedly ? I tried to use Sup a couple of weeks ago, but
this issue made it unusable for me (I planned to hack on this some day,
but my work and uni obligations do not leave any free time lately). :(
To make matters worse, the relevant RFC actually requires emails to
be encoded in the ?tightest? encoding possible ? when I?m writing an
email in Polish without any non-US-ASCII letters, it should be sent
as US-ASCII; if I include Polish diacritical characters, it should be
encoded as ISO-8859-2, but if I add some characters outside of it (say,
ellipsis) it should be sent in UTF-8.
As a result, I regularly receilve emails in US-ASCII, ISO-8859-2 and
UTF-8 ? but also in ISO-8859-1, ISO-8859-15, as well as some cyryllic
encodings. I remember Mutt going through some growing pains to
accomodate this, but has it all sorted out now (there is an issue
of recoding the email one replies to to the encoding expected by the
editor, for example).
I?ll be more than happy to test any work done in this regard and I offer
any knowledge that could be useful; unfortunately, I can?t promise any
hacking time (I just got accepted for this year?s Summer of Code to hack
on CiviCRM internationalisation ? maybe Sup could apply to be a project
in next year?s SoC edition?).
-- Shot
--
I grew up in Europe, where the history comes from. -- Eddie Izzard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080422/9e7cc1bf/attachment.bin
next prev parent reply other threads:[~2008-04-22 11:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-21 20:37 Israel Herraiz
2008-04-22 11:39 ` Shot (Piotr Szotkowski) [this message]
2008-04-22 23:18 ` William Morgan
2008-04-23 0:09 ` Israel Herraiz
2008-04-23 2:03 ` William Morgan
2008-04-23 1:08 ` Israel Herraiz
2008-04-23 1:53 ` William Morgan
2008-04-24 19:36 ` Marc Hartstein
2008-04-24 23:10 ` [sup-talk] [PATCH] fixed dlopen of libc for os x Grant Hollingworth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080422113959.GA20034@durance.shot.pl \
--to=shot@hot.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox