<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">Wiadomość napisana przez Mark Sapiro <<a href="mailto:mark@msapiro.net" class="">mark@msapiro.net</a>> w dniu 19 lut 2015, o godz. 04:53:</div><br class="Apple-interchange-newline"><div class="">On 02/17/2015 02:19 AM, Stef wrote:<br class=""><blockquote type="cite" class=""><br class="">It is a noble goal to make upgrades non-disruptive and I second that.<br class=""><br class="">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.<br class=""></blockquote><br class=""><br class="">There are many reasons why the <a href="http://python.org" class="">python.org</a> Mailman hasn't been updated,<br class="">and I hope to change that going forward.<br class=""></div></blockquote><div class=""><br class=""></div><div class="" style="margin: 0px;">I wasn't thinking about <a href="http://python.org" class="">python.org</a> 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.</div><div class="" style="margin: 0px;"><br class=""></div><blockquote type="cite" class=""><div class="">I understand that ISO-8859-2 is limited, and Mailman 3 which is the<br class="">current development focus is a Python 3 application and thus strings are<br class="">all unicode internally. SMTP itself still has to be ascii bytes on the<br class="">wire and will be, but essentially everything else will be unicode with<br class="">utf-8 encoding (where possible) in Mailman 3.<br class=""></div></blockquote><div class=""><br class=""></div>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. </div><div class=""><br class=""><blockquote type="cite" class=""><div class="">In Mailman 2.1 on the other hand, there is a hodge podge of different<br class="">character sets for the different languages, and these affect things like<br class="">the web UI, archives, plain format digests and Mailman generated<br class="">notices, but messages passing through a list and in MIME format digests,<br class="">for the most part are delivered encoded in the same encoding as the<br class="">original message although a plain text body may sometimes be recoded due<br class="">to things like msg_header and msg_footer being encoded in a different<br class="">character set.<br class=""></div></blockquote><div class=""><br class=""></div>Public archive was the reason, it was unacceptable mess before switch to utf8.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">Anyway, thanks very much for updating the translation. I have taken your<br class="">message catalog and templates, changed some problem characters like<br class="">curly quotes and ellipsis to ascii quotes and ... respectively and<br class="">recoded them to ISO-8859-2 and installed them in the branch.<br class=""></div></blockquote><div class=""><br class=""></div>Thx!</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">Also, in running Mailman's bin/transcheck, I found and fixed the<br class="">following two problems<br class=""></div></blockquote></div><div class=""><br class=""></div><div class="">Fixed also on github, thank you for pointing that out.</div><div class=""><br class=""></div></div></body></html>