Hi, I tired to contact former Polish translators but without luck so far. For mail.mozilla.org <http://mail.mozilla.org/> we needed Polish templates in unicode, so we created https://github.com/aviarypl/mailman-l10n-pl <https://github.com/aviarypl/mailman-l10n-pl> repository and it now contains message and template files converted to UTF-8, corrections and additional translations. I'm also planing to keep it updated for 2.1 branch (right now 2.1.19rc3). Would it be possible to use these files to update official pl localization? Stefan Plewako
On 02/16/2015 03:32 PM, Stef wrote:
Hi,
I tired to contact former Polish translators but without luck so far.
For mail.mozilla.org <http://mail.mozilla.org> we needed Polish templates in unicode, so we created https://github.com/aviarypl/mailman-l10n-pl repository and it now contains message and template files converted to UTF-8, corrections and additional translations. I'm also planing to keep it updated for 2.1 branch (right now 2.1.19rc3).
Would it be possible to use these files to update official pl localization?
I will be happy to update the current Polish translation, but I'm reluctant to change the character set for Polish from iso-8859-2 to utf-8. Mailman 2.1.19 will change the character sets for Romanian and Russian from iso-8859-2 and koi8-r respectively to utf-8, but these are special cases in that iso-8859-2 was never fully appropriate for Romanian and I've been convinced that koi8-r is not appropriate any longer for Russian, but there are serious issues for existing lists in these languages that may have string valued attributes in the old character set in their configurations. There is now code in Mailman/versions.py to attempt to find and convert such values, and the code is tested, but since I have no real world lists in those languages, I don't know how well it works in practice. I see your templates and messages are currently updated to the most recent revs in the upstream branch. I will pick them up, convert them back to iso-8859-2 (as long as there are no utf-8 characters unrepresentable in iso-8859-2) and install them for the final. If you want the final to use utf-8 for Polish, you can file a bug at <https://bugs.launchpad.net/mailman/+filebug> and argue for it there. There are pros and cons for converting Polish. I plan to upgrade all the mail.python.org lists as soon as 2.1.19 final is released, and there are actually a few Polish lists there. On the one hand, this would be a good real world test of my conversion, but on the other, I've promised to do my best to make the upgrade non-disruptive to existing lists. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Wiadomość napisana przez Mark Sapiro <mark@msapiro.net> w dniu 17 lut 2015, o godz. 02:08:
I will be happy to update the current Polish translation, but I'm reluctant to change the character set for Polish from iso-8859-2 to utf-8.
Mailman 2.1.19 will change the character sets for Romanian and Russian from iso-8859-2 and koi8-r respectively to utf-8, but these are special cases in that iso-8859-2 was never fully appropriate for Romanian and I've been convinced that koi8-r is not appropriate any longer for Russian, but there are serious issues for existing lists in these languages that may have string valued attributes in the old character set in their configurations. There is now code in Mailman/versions.py to attempt to find and convert such values, and the code is tested, but since I have no real world lists in those languages, I don't know how well it works in practice.
If you want the final to use utf-8 for Polish, you can file a bug at <https://bugs.launchpad.net/mailman/+filebug> and argue for it there.
There are pros and cons for converting Polish. I plan to upgrade all the mail.python.org lists as soon as 2.1.19 final is released, and there are actually a few Polish lists there. On the one hand, this would be a good real world test of my conversion, but on the other, I've promised to do my best to make the upgrade non-disruptive to existing lists.
It is a noble goal to make upgrades non-disruptive and I second that. That said, it would be hard to argue about potential configuration issues of lists probably using 2.1.15 version and not updating to 2.1.19 for years… as I simply don't know Mailman good enough for that. I can only remind that ISO-8859-2 is very limited character set that is continuously replaced by UTF-8 and not really good choice even for lists containing only messages in Polish. Stef
On 02/17/2015 02:19 AM, Stef wrote:
It is a noble goal to make upgrades non-disruptive and I second that.
That said, it would be hard to argue about potential configuration issues of lists probably using 2.1.15 version and not updating to 2.1.19 for years… as I simply don't know Mailman good enough for that. I can only remind that ISO-8859-2 is very limited character set that is continuously replaced by UTF-8 and not really good choice even for lists containing only messages in Polish.
There are many reasons why the python.org Mailman hasn't been updated, and I hope to change that going forward. I understand that ISO-8859-2 is limited, and Mailman 3 which is the current development focus is a Python 3 application and thus strings are all unicode internally. SMTP itself still has to be ascii bytes on the wire and will be, but essentially everything else will be unicode with utf-8 encoding (where possible) in Mailman 3. In Mailman 2.1 on the other hand, there is a hodge podge of different character sets for the different languages, and these affect things like the web UI, archives, plain format digests and Mailman generated notices, but messages passing through a list and in MIME format digests, for the most part are delivered encoded in the same encoding as the original message although a plain text body may sometimes be recoded due to things like msg_header and msg_footer being encoded in a different character set. Anyway, thanks very much for updating the translation. I have taken your message catalog and templates, changed some problem characters like curly quotes and ellipsis to ascii quotes and ... respectively and recoded them to ISO-8859-2 and installed them in the branch. Also, in running Mailman's bin/transcheck, I found and fixed the following two problems: --- messages/pl2/LC_MESSAGES/mailman.po 2015-02-18 12:48:07.990822542 -0800 +++ messages/pl/LC_MESSAGES/mailman.po 2015-02-18 14:27:23.939854634 -0800 @@ -2706,7 +2706,7 @@ #: Mailman/Cgi/rmlist.py:65 msgid "No such list %(safelistname)s" -msgstr "Lista \"%(listname)s\" nie istnieje na tym serwerze" +msgstr "Lista \"%(safelistname)s\" nie istnieje na tym serwerze" #: Mailman/Cgi/rmlist.py:83 msgid "You're being a sneaky list owner!" @@ -2742,7 +2742,7 @@ #: Mailman/Cgi/rmlist.py:191 msgid "Permanently remove mailing list %(realname)s" -msgstr "Usuń listę %(realname) (tej czynności nie można odwrócić)" +msgstr "Usuń listę %(realname)s (tej czynności nie można odwrócić)" #: Mailman/Cgi/rmlist.py:204 msgid "" -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Wiadomość napisana przez Mark Sapiro <mark@msapiro.net <mailto:mark@msapiro.net>> w dniu 19 lut 2015, o godz. 04:53:
On 02/17/2015 02:19 AM, Stef wrote:
It is a noble goal to make upgrades non-disruptive and I second that.
That said, it would be hard to argue about potential configuration issues of lists probably using 2.1.15 version and not updating to 2.1.19 for years… as I simply don't know Mailman good enough for that. I can only remind that ISO-8859-2 is very limited character set that is continuously replaced by UTF-8 and not really good choice even for lists containing only messages in Polish.
There are many reasons why the python.org <http://python.org/> Mailman hasn't been updated, and I hope to change that going forward.
I wasn't thinking about python.org <http://python.org/> but about linux distributions and their attitude to stable/2.1 Mailman releases - from that perspective 2.1.19 won't be that different form 3.0 as a release and trying to make upgrades non-disruptive has much less value.
I understand that ISO-8859-2 is limited, and Mailman 3 which is the current development focus is a Python 3 application and thus strings are all unicode internally. SMTP itself still has to be ascii bytes on the wire and will be, but essentially everything else will be unicode with utf-8 encoding (where possible) in Mailman 3.
Right, Mailman 3, I have a plan not to use it as long as feasible having seen test versions of archiver and requirements for l10n.
In Mailman 2.1 on the other hand, there is a hodge podge of different character sets for the different languages, and these affect things like the web UI, archives, plain format digests and Mailman generated notices, but messages passing through a list and in MIME format digests, for the most part are delivered encoded in the same encoding as the original message although a plain text body may sometimes be recoded due to things like msg_header and msg_footer being encoded in a different character set.
Public archive was the reason, it was unacceptable mess before switch to utf8.
Anyway, thanks very much for updating the translation. I have taken your message catalog and templates, changed some problem characters like curly quotes and ellipsis to ascii quotes and ... respectively and recoded them to ISO-8859-2 and installed them in the branch.
Thx!
Also, in running Mailman's bin/transcheck, I found and fixed the following two problems
Fixed also on github, thank you for pointing that out.
participants (2)
-
Mark Sapiro -
Stef