Mailman 3 December 2002 - Mailman-i18n

RU: translation
by DIG 11 Dec '02

11 Dec '02

Hi, All. I was wandering: is there any plan or hope to finish russian translation for MM-2.1 release ? I've done some translation and correction (in current CVS). What is best mean to share it ? Will ``diff -u'' be OK ? Best regards, -- DIG (Dmitri I GOULIAEV)

2 1

Re: [Mailman-i18n] Re: [Mailman-Developers] [ mailman-Patches-646884 ] HyperArch.py multibyte charset
by Martin v. L�wis 08 Dec '02

08 Dec '02

>Here is an example... >Before: >http://mm.tkikuchi.net/pipermail/mm-test/2002-December/000385.html >and after the patch was applied: >http://mm.tkikuchi.net/pipermail/mm-test/2002-December/000386.html > >You need japanese font installed to examine the difference. > >Utils.uquote() makes a multibyte character into two or more fragmants >of Latin-1 characters. I see. That shows that the bug is actually elsewhere: Utils.uquote is being passed a byte string. This is not supposed to happen, as Utils.uquote only works correctly on Unicode strings. While the patch is still correct, it only papers over the problems: the output will now be correct only if the message encoding is equal to the list's preferred encoding, since Util.unquote will still receive a byte string. In turn, it will see whether the byte string happens to decode correctly in the list's preferred encoding (which may or may not succeed by coincidence). If decoding succeeds, it will insert the byte string unmodified into the page; if it fails, it will fall back to uquote. I think the problem really comes from some encodings ignoring the Unicode facilities in Mailman, and being carried through the processing chain. This should be done either correctly (by always accompanying the byte string with its encoding), or not at all (by converting everything to Unicode). This is perhaps a little to much asked for Mailman 2.1, though. Regards, Martin =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ ===================================================================

2 1

Re: [Mailman-i18n] new translator guidelines; mailman.mo query
by Martin v. L�wis 08 Dec '02

08 Dec '02

>(a) I can't find msgformat, and What operating system are you using? It's supposed to be part of any GNU system. If you don't use a GNU system, either install GNU gettext, or use msgfmt.py from Tools/i18n of the Python distribution. > (b) I don't understand the purpose of this file. It is a machine version of the .po file (with binary-sorted keys, hash tables, etc). See the gettext documentation for details. Regards, Martin =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ ===================================================================

1 0

new translator guidelines; mailman.mo query
by Darren Wyn Rees 08 Dec '02

08 Dec '02

Where is the most current guidelines on adding new translations to mailman ? I could only find this : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mailman/mailman/README-I18N.… Assuming the above is still valid - please correct me if otherwise - I have difficulty understanding : Once you've added your translations, you can then run msgfmt over your .po file to generate messages/ha/LC_MESSAGE/mailman.mo (it would also be a good idea to donate your translated .po file back to the Mailman project!) (a) I can't find msgformat, and (b) I don't understand the purpose of this file. Thanks for any help. -- Darren

1 0

Re: [Mailman-Developers] [ mailman-Patches-646884 ] HyperArch.py multibyte charset
by Tokio Kikuchi 07 Dec '02

07 Dec '02

Martin, Since you are on this list I respond to i18n. > Comment By: Martin v. L?wis (loewis) > Date: 2002-12-07 17:10 > > Message: > Logged In: YES > user_id=21627 > > Tokio, can you please explain the problem in more detail? > Utils.uquote will always return 7bit strings only, > potentially with nested HTML character references. Why could > this cause a problem in a multi-byte encoding? Can you refer > to a page that looks incorrectly because of that? Here is an example... Before: http://mm.tkikuchi.net/pipermail/mm-test/2002-December/000385.html and after the patch was applied: http://mm.tkikuchi.net/pipermail/mm-test/2002-December/000386.html You need japanese font installed to examine the difference. Utils.uquote() makes a multibyte character into two or more fragmants of Latin-1 characters. Utils.uquote() makes all the 8bit-set character escaped while Utils.uncanonstr() checks if the character is within the charset and escapes only if the chatacter is not legal. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

2 1

Patch # 646884
by barry＠python.org 07 Dec '02

07 Dec '02

Tokio Kikuchi posted patch #646884 to fix some mojibake problems with the archiver (ooh, I just love throwing that term around :). I worked out a cleaner patch w.r.t. today's cvs and uploaded it http://sf.net/tracker/index.php?func=detail&aid=646884&group_id=103&atid=30… I'm not sure I'm testing it thoroughly, so I'd appreciate another set of eyes. Should I apply this patch? Thanks, -Barry

1 0

Japanese translation ready for RC1
by Tokio Kikuchi 02 Dec '02

02 Dec '02

Hi, Japanese translation is now up to date at http://mm.tkikuchi.net/mailman-2.1.ja/mailman.i18n.ja.tar.gz Cheers, -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

2 1

Re: [Mailman-i18n] sync_members, list_members problem
by Martin v. L�wis 02 Dec '02

02 Dec '02

>I've implemented a fix to first sys.getdefaultencoding() and then >actually print ustr.encode(enc, 'replace') to stdout. That fixed the >problem for me, but is it the right solution? If this is for printing to the terminal, using 'replace' seems fine. You could try to find out the user's preferred encoding, and use that instead of the system encoding, but that is difficult to do, and perhaps overkill. >On a related note, and I know this has been discussed on python-dev, >is it really not possible to call sys.setdefaultencoding() anywhere in >Python except by hacking site.py? Correct. >This seems quite shortsighted (maybe I should raise this on >python-dev). I believe this has proven to be quite foreseeing already. >Say my terminal can handle iso-8859-1. I'd like to be >able to set the default encoding to that somewhere that user-specific, >say PYTHONSTARTUP if I'm running interactively. But that seems >impossible It's not impossible. Just be explicit about your encodings, and use .encode whenever you want to convert Unicode strings to byte strings. Explicit is better than implicit. If you know that *your terminal* is Latin-1, and you want to output Unicode to the terminal, just do sys.stdout = codecs.getwriter("iso-8859-1")(sys.stdout) With that, you get transparent conversion to Latin-1 when printing to the terminal, without having to touch the default encoding. There is a patch python.org/sf/612627 which does this automatically, ie. it allows to print all Unicode that the terminal supports. >and I don't think hacking site.py is the appropriate >response. What if someone else at my site uses a different terminal >that can't print iso-8859-1? Correct. You should never change the default encoding; I consider it a flaw that you can. Even within a single process, changing the default encoding is wrong: What if you are printing both to stdout, and to a XML file, which has its standard UTF-8 encoding? The XML file will become silently wrong, as you have changed the default encoding. Likewise, if you write to a socket, you might silently write incorrect data, as the wire protocol surely uses an encoding different from the default encoding. So that you get ASCII enoding errors is a good thing; it tells you that you forgot to use a proper StreamWriter, or forgot to invoke .encode explicitly. HTH, Martin =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ ===================================================================

1 0

sync_members, list_members problem
by barry＠python.org 02 Dec '02

02 Dec '02

This is in reference to SF bug # 644005 http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=64… When there are realnames of members with "funny" characters in them, sync_members and list_members can throw UnicodeError exceptions because it's trying to print strings with characters ord > 128. I've implemented a fix to first sys.getdefaultencoding() and then actually print ustr.encode(enc, 'replace') to stdout. That fixed the problem for me, but is it the right solution? On a related note, and I know this has been discussed on python-dev, is it really not possible to call sys.setdefaultencoding() anywhere in Python except by hacking site.py? PyUnicode_SetDefaultEncoding() seems to only be exported to Python via sys, but that is deleted by site.py after being called once. This seems quite shortsighted (maybe I should raise this on python-dev). Say my terminal can handle iso-8859-1. I'd like to be able to set the default encoding to that somewhere that user-specific, say PYTHONSTARTUP if I'm running interactively. But that seems impossible, and I don't think hacking site.py is the appropriate response. What if someone else at my site uses a different terminal that can't print iso-8859-1? -Barry

1 0

new language for 2.1(b)
by Bojan Suzic 01 Dec '02

01 Dec '02

Hello. I have made Serbian translation of Mailman 2.1b templates (utf-8). Where I should send them? Regards, Bojan

2 1