hi all. I finished to translate the mailman 2.1beta in korean but not completely. find at http://igrus.inha.ac.kr/~andsoon/pds/mailman-2.1beta.ko/mailman.i18n.ko.tar....
"andsoon" == andsoon <andsoon@igrus.inha.ac.kr> writes:
andsoon> hi all. I finished to translate the mailman 2.1beta in andsoon> korean but not completely. Thank you very much! I've been wondering, which charset and encoding do you think we should use in Mailman for Korean in email? euc-kr with base64? I know euc-kr is probably best for web pages, but I get a lot of Korean spam in some Windows character set, so I don't know which people use for email in real life. Ben -- Brought to you by the letters N and O and the number 7. "What's different, Pete, about the 69 that makes it so exciting to you?" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
"BG" == Ben Gertzfield <che@debian.org> writes:
"andsoon" == andsoon <andsoon@igrus.inha.ac.kr> writes:
andsoon> hi all. I finished to translate the mailman 2.1beta in andsoon> korean but not completely. BG> Thank you very much! Yes, indeed! I've integrated your changes into CVS. BG> I've been wondering, which charset and encoding do you think BG> we should use in Mailman for Korean in email? euc-kr with BG> base64? Good question. We'll need to add that to the email package's Charset mapping. I'm assuming the Mailman add_language() directive should use euc-kr. BG> I know euc-kr is probably best for web pages, but I get a lot BG> of Korean spam in some Windows character set, so I don't know BG> which people use for email in real life. Another question for andsoon: what do you think of the Korean codecs in the python-codecs project: http://sf.net/projects/python-codecs Is it in a usable state? I'm happy to add this to Mailman if they are stable enough. -Barry
"BAW" == Barry A Warsaw <barry@zope.com> writes: "BG" == Ben Gertzfield <che@debian.org> writes: "andsoon" == andsoon <andsoon@igrus.inha.ac.kr> writes:
BG> I've been wondering, which charset and encoding do you think BG> we should use in Mailman for Korean in email? euc-kr with BG> base64? BAW> Good question. We'll need to add that to the email package's BAW> Charset mapping. I'm assuming the Mailman add_language() BAW> directive should use euc-kr. Actually, if there's no conversion performed like the EUC-JP -> ISO-2022-JP conversion for Japanese, you don't need to modify the Charset package. If you create a Charset("euc-kr"), you will get a Base64'd header and body, because the default for unknown charsets is to Base64 encode them: Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information.
from email.Charset import Charset from email.Header import Header from email.Message import Message c = Charset("euc-kr") h = Header("This is a Korean header", c) print h =?euc-kr?b?VGhpcyBpcyBhIEtvcmVhbiBoZWFkZXI=?=
m = Message() m.set_charset(c) m.add_payload("This is a Korean body") m["Subject"] = h print m From nobody Fri Mar 29 10:46:33 2002 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 Subject: =?euc-kr?b?VGhpcyBpcyBhIEtvcmVhbiBoZWFkZXI=?=
VGhpcyBpcyBhIEtvcmVhbiBib2R5 BAW> Another question for andsoon: what do you think of the Korean BAW> codecs in the python-codecs project: BAW> http://sf.net/projects/python-codecs I honestly have no idea how to test the stability of the Korean Unicode codecs, because I don't know how to input Korean. :/ Comments from other folks would be very appreciated. Ben -- Brought to you by the letters I and S and the number 8. "It should be illegal to yell 'Y2K' in a crowded economy." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
"Ben" == Ben Gertzfield <che@debian.org> writes: "BAW" == Barry A Warsaw <barry@zope.com> writes:
BG> I've been wondering, which charset and encoding do you think BG> we should use in Mailman for Korean in email? euc-kr with BG> base64? BAW> Good question. We'll need to add that to the email package's BAW> Charset mapping. I'm assuming the Mailman add_language() BAW> directive should use euc-kr. Ben> Actually, if there's no conversion performed like the EUC-JP Ben> -> ISO-2022-JP conversion for Japanese, you don't need to Ben> modify the Charset package. Of course, I forgot that EUC-KR is a multibyte charset; it's possible (although I don't know how email clients behave) that clients will screw up if we split an EUC-KR string between two bytes of a character when wrapping a long header line. We may need that Korean Unicode module after all. Ben -- Brought to you by the letters E and U and the number 14. "A baloo is a bear." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
Ben Gertzfield <che@debian.org> writes:
Of course, I forgot that EUC-KR is a multibyte charset; it's possible (although I don't know how email clients behave) that clients will screw up if we split an EUC-KR string between two bytes of a character when wrapping a long header line.
We may need that Korean Unicode module after all.
I think there are other reasons for that, as well. People may use multiple encodings when posting to a mailing list, so archiving needs to perform character set conversion (see patch 510415). Likewise, removal of duplicate list names needs charset conversion, see patch 498766. Is anybody actually looking at these patches? Regards, Martin
"Martin" == Martin v Löwis <loewis@informatik.hu-berlin.de> writes:
Ben> Of course, I forgot that EUC-KR is a multibyte charset; it's Ben> possible (although I don't know how email clients behave) Ben> that clients will screw up if we split an EUC-KR string Ben> between two bytes of a character when wrapping a long header Ben> line. Martin> I think there are other reasons for that, as well. People Martin> may use multiple encodings when posting to a mailing list, Martin> so archiving needs to perform character set conversion Martin> (see patch 510415). Martin> Likewise, removal of duplicate list names needs charset Martin> conversion, see patch 498766. Martin> Is anybody actually looking at these patches? I think there are a million issues with Pipermail that need to be solved for Mailman 2.2 (3.0?). These are two of them. The whole system needs to be overhauled, and lots of issues with multiple charsets in a list archive need to be dealt with. Ben -- Brought to you by the letters N and X and the number 17. "What's different, Pete, about the 69 that makes it so exciting to you?" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
I think there are a million issues with Pipermail that need to be solved for Mailman 2.2 (3.0?). These are two of them.
The whole system needs to be overhauled, and lots of issues with multiple charsets in a list archive need to be dealt with.
So what would be wrong with just applying the patches that are currently available? You can either ignore contributions and hope that you can find time to do it yourself, or you can cooperate with contributors. If you chose to ignore contributions, please atleast take the time to reject the patches that you certainly won't consider. Regards, Martin
"Martin" == Martin von Loewis <loewis@informatik.hu-berlin.de> writes:
Ben> I think there are a million issues with Pipermail that need Ben> to be solved for Mailman 2.2 (3.0?). These are two of them. Ben> Ben> The whole system needs to be overhauled, and lots of issues Ben> with multiple charsets in a list archive need to be dealt Ben> with. Martin> So what would be wrong with just applying the patches that Martin> are currently available? You can either ignore Martin> contributions and hope that you can find time to do it Martin> yourself, or you can cooperate with contributors. If you Martin> chose to ignore contributions, please atleast take the Martin> time to reject the patches that you certainly won't Martin> consider. Er, I'm not sure if you understand, but I'm not the Mailman maintainer, nor do I have CVS access to Mailman. I'm just letting you know that the entire system needs a huge overhaul, and that if those patches did the overhaul, I'm sure Barry would have applied them already. Ben -- Brought to you by the letters V and E and the number 18. "Elate means having wings." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
"Martin" == Martin von Loewis <loewis@informatik.hu-berlin.de> writes:
Er, I'm not sure if you understand, but I'm not the Mailman maintainer, nor do I have CVS access to Mailman. I'm just letting you know that the entire system needs a huge overhaul, and that if those patches did the overhaul, I'm sure Barry would have applied them already.
Then please take my apologies: from your response, I assumed that you would indeed co-maintain mailman. My original question remains, though: Is anybody considering these patches (not just my own; I notice that the oldest patch which had no review is dated 2000-09-21)? Regards, Martin
"MvL" == Martin von Loewis <loewis@informatik.hu-berlin.de> writes:
MvL> Then please take my apologies: from your response, I assumed MvL> that you would indeed co-maintain mailman. My original MvL> question remains, though: MvL> Is anybody considering these patches (not just my own; I MvL> notice that the oldest patch which had no review is dated MvL> 2000-09-21)? At present, I'm really the only one actually committing changes to cvs, although several people (Ben, Dan and Daniel, Ron, etc.) do provide very excellent patches. You too Martin. But this means I'm the bottleneck for getting fixes in, and that's subject to the vagaries of my "real" job. ;) One way to help out right now: I can add you as a tracker admin and you can help do triage on the bugs and patches. This actually would be an enormous help, because there's a lot of things to go through. Even weeding out those issues that are no longer relevant for MM2.1, and assigning everything that's left to me would help a lot. I'd also love it if someone would take responsibility for Pipermail. As crufty as it is, it's all we have, and it's good enough for many people. But it's a complicated system that needs its own steward. Anybody willing to put the time and effort into it, I'd be happy to add as a cvs committer (although we have to watch out about GNU issues -- but several people have already assigned their future changes to the FSF). As for the core system, I admit to being protective of it. I'm willing to loosen my grip if it helps Mailman development move along faster. There are folks in the community who know enough about the system, and whom I trust to make changes to the code. -Barry
On Thu, 28 Mar 2002, Barry A. Warsaw wrote:
Another question for andsoon: what do you think of the Korean codecs in the python-codecs project:
http://sf.net/projects/python-codecs
Is it in a usable state? I'm happy to add this to Mailman if they are stable enough.
sorry. i don't know details about python code. so don't know it's stable or unstable.
<andsoon@igrus.inha.ac.kr> writes:
On Thu, 28 Mar 2002, Barry A. Warsaw wrote:
Another question for andsoon: what do you think of the Korean codecs in the python-codecs project:
http://sf.net/projects/python-codecs
Is it in a usable state? I'm happy to add this to Mailman if they are stable enough.
The Korean codecs now live in a separate project, see http://mail.python.org/pipermail/i18n-sig/2002-March/001390.html Regards, Martin
On Thu, 28 Mar 2002, Ben Gertzfield wrote:
I've been wondering, which charset and encoding do you think we should use in Mailman for Korean in email? euc-kr with base64?
I think charset and enconding for Korean fits with euc-kr because most peoples use euc-kr in their mail agents
I know euc-kr is probably best for web pages, but I get a lot of Korean spam in some Windows character set, so I don't know which people use for email in real life.
be recommended set euc-kr in korea.
Another qeustion. I have as Korean champion song@yaimma.co.kr, but haven't heard much from them in a long time. Are you two working together? Are you aware of each other's progress? If song can't head up the Korean translation now, will you andsoon? -Barry
On Thu, 28 Mar 2002, Barry A. Warsaw wrote:
Another qeustion. I have as Korean champion song@yaimma.co.kr, but haven't heard much from them in a long time. Are you two working together? Are you aware of each other's progress? If song can't head up the Korean translation now, will you andsoon?
i don't know song@yaimma.co.kr. may be each progress.
participants (5)
-
andsoon＠igrus.inha.ac.kr -
barry＠zope.com -
Ben Gertzfield -
loewis＠informatik.hu-berlin.de -
Martin von Loewis