Bug#786525: Disruptive changes should be loudly announced
Hello, On Sat, May 23, 2015 at 10:34:30PM +0200, Martin Quinson wrote: On Fri, May 22, 2015 at 05:14:20PM -0400, David Prévot wrote: Even if disruptive changes in the gettext/po4a toolchain (and underlined Perl handling) are always painful (one has to make sure every contributor is using the “right” version, the amount of changes in the PO files to cope with the upgrade can be huge), with my Debian packager hat on, I’d say that now (early in the development cycle) is exactly the right moment to make such change if it’s an improvement worthing the disruption. About this change, now. My current feeling is that it should be an optional behavior. It is very possible to pass options to the PO4A modules, so that users may choose how to handle tbl macros. David, do you think that it would do the trick? Ok. I found some time to dig into this issue, and implemented an option to choose between the old and new behavior. But I'm not sure I want to commit it. Robert's change is a great improvement. I tested on a chunk of ps.1 Here is the 0.46 version: msgid %cpu%CPU msgstr msgid cpu utilization of the process in \##.#\ format. It is the CPU time\n used divided by the time the process has been running (cputime/realtime\n ratio), expressed as a percentage. It will not add up to 100% unless you\n are lucky. (alias\\ Bpcpu).\n msgstr And now the 0.45 version: msgid %cpu%CPUT{\n msgstr msgid cpu utilization of the process in \##.#\ format. It is the CPU time\n msgstr msgid used divided by the time the process has been running (cputime/realtime\n msgstr msgid ratio), expressed as a percentage. It will not add up to 100% unless you\n msgstr msgid are lucky. (alias\\ Bpcpu).\n msgstr msgid T}\n msgstr Who on the earth would choose the second version? I think, David, that we have here what you call an improvement worthing the disruption. Do you agree, or would you insist on having an option? In any cases, many thanks to Robert. New translators will certainly love the new version of the thing. Bye, Mt. -- Chaque fois que je regarde la télé et que je vois ces pauvres enfants affamés à travers le monde, je me mets à pleurer sans pouvoir m'en empecher. Je veux dire, j'aimerais bien être mince comme eux, mais sans les mouches, la guerre et tout ca.--- Mariah Carey .\ This chunk comes from ps(1). It is intented to test .\ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748601 .TS expand; lB1 lB1 lBw(\n[ColSize]n) lB1 l1 l. CODEHEADER DESCRIPTION %cpu%CPUT{ cpu utilization of the process in ##.# format. It is the CPU time used divided by the time the process has been running (cputime/realtime ratio), expressed as a percentage. It will not add up to 100% unless you are lucky. (alias\ \fBpcpu\fR). T} class CLS T{ scheduling class of the process. (alias\ \fBpolicy\fR,\ \fBcls\fR). Field's possible values are: .br \- not reported .br TS SCHED_OTHER .br FF SCHED_FIFO .br RR SCHED_RR .br ? unknown value T} .TE .\ ### # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR EMAIL@ADDRESS, YEAR. # #, fuzzy msgid msgstr Project-Id-Version: PACKAGE VERSION\n POT-Creation-Date: 2015-06-24 21:43+0200\n PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n Last-Translator: FULL NAME EMAIL@ADDRESS\n Language-Team: LANGUAGE l...@li.org\n Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=CHARSET\n Content-Transfer-Encoding: 8bit\n #. type: tbl table #: data-23/tbl-textblock.1:8 #, no-wrap msgid CODEHEADER DESCRIPTION\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:10 #, no-wrap msgid %cpu%CPUT{\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:11 #, no-wrap msgid cpu utilization of the process in \##.#\ format. It is the CPU time\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:12 #, no-wrap msgid used divided by the time the process has been running (cputime/realtime\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:13 #, no-wrap msgid ratio), expressed as a percentage. It will not add up to 100% unless you\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:14 #, no-wrap msgid are lucky. (alias\\ Bpcpu).\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:15 data-23/tbl-textblock.1:31 #, no-wrap msgid T}\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:18 #, no-wrap msgid class CLS T{\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:19 #, no-wrap msgid scheduling class of the process. (alias\\ Bpolicy,\\ Bcls).\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:20 #, no-wrap msgid Field's possible values are:\n msgstr #. type: tbl table #: data-23/tbl-textblock.1:21 data-23/tbl-textblock.1:23
Bug#786525: Disruptive changes should be loudly announced
Hi Martin, Le 24/06/2015 16:40, Martin Quinson a écrit : On Sat, May 23, 2015 at 10:34:30PM +0200, Martin Quinson wrote: On Fri, May 22, 2015 at 05:14:20PM -0400, David Prévot wrote: Even if disruptive changes in the gettext/po4a toolchain (and underlined Perl handling) are always painful […], with my Debian packager hat on, I’d say that now (early in the development cycle) is exactly the right moment to make such change if it’s an improvement worthing the disruption. About this change, now. My current feeling is that it should be an optional behavior. It is very possible to pass options to the PO4A modules, so that users may choose how to handle tbl macros. David, do you think that it would do the trick? Ok. I found some time to dig into this issue, and implemented an option to choose between the old and new behavior. But I'm not sure I want to commit it. Robert's change is a great improvement. […] Who on the earth would choose the second version? I, for one, already moved the PO files from manpages-fr-extra to cope with the new behavior and have no intent to move backward. On the other hand, I haven’t dealt with perkamon for a while, where there might be a huge work to deal with (that can hopefully be mostly automatized as partly documented earlier [0]). Other projects may have another view on that (I can only think of those two projects using po4a for dealing with a big amount of manpages, but I only know those two from the narrow view of a French translator who happen to [have] be[en] involved). 0: https://bugs.debian.org/786525#20 I think, David, that we have here what you call an improvement worthing the disruption. Do you agree, or would you insist on having an option? Nobody else following up on that bug report might be a sign that having an opt-out is not really worth it. On the other hand, I have no idea if the latest po4a version is already widely spread among its users. Regards David signature.asc Description: OpenPGP digital signature
Bug#786525: Disruptive changes should be loudly announced
Hi Martin, About this change, now. My current feeling is that it should be an optional behavior. It is very possible to pass options to the PO4A modules, so that users may choose how to handle tbl macros. David, do you think that it would do the trick? Sure, making this new tbl handling optional (or adding an option allowing to restore the previous behavior), would make this change a lot less disruptive (allowing any project to adopt it or not at their own pace). Not making it the default for now, and announcing that the default will change in the future, would IMHO nicely address the loudly announce [future] disruptive change request. Regards David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786525: Disruptive changes should be loudly announced
On Fri, May 22, 2015 at 05:14:20PM -0400, David Prévot wrote: Hi Martin, On Fri, May 22, 2015 at 10:39:33PM +0200, Martin Quinson wrote: You could even raise the gravity of that bug to block the package transition to testing if you feel that this change should be reverted. Even if disruptive changes in the gettext/po4a toolchain (and underlined Perl handling) are always painful (one has to make sure every contributor is using the “right” version, the amount of changes in the PO files to cope with the upgrade can be huge), with my Debian packager hat on, I’d say that now (early in the development cycle) is exactly the right moment to make such change if it’s an improvement worthing the disruption. I completely missed the point that such a change would be very disruptive and thus not desirable when facing large text corpus. Sorry. Again, I'll try to launch the build of manpages-fr to check my changes before uploading. Not sure that I will manage to notice such massive fuzzing, but I will try. About this change, now. My current feeling is that it should be an optional behavior. It is very possible to pass options to the PO4A modules, so that users may choose how to handle tbl macros. David, do you think that it would do the trick? If so, I will do so in the next week (I'm currently out of town), but if someone manages to prepare a patch before me, I'd be really thankful. Bye, Mt. -- La joie d'apprendre est aussi indispensable aux études que la respiration aux coureurs. -- Maria Montessori signature.asc Description: Digital signature
Bug#786525: Disruptive changes should be loudly announced
Hi Martin, On Fri, May 22, 2015 at 10:39:33PM +0200, Martin Quinson wrote: You could even raise the gravity of that bug to block the package transition to testing if you feel that this change should be reverted. Even if disruptive changes in the gettext/po4a toolchain (and underlined Perl handling) are always painful (one has to make sure every contributor is using the “right” version, the amount of changes in the PO files to cope with the upgrade can be huge), with my Debian packager hat on, I’d say that now (early in the development cycle) is exactly the right moment to make such change if it’s an improvement worthing the disruption. CCing perkamon lists since the man-pages translation project may be even more affected by this change and is likely to have more to say about it (thinking about all the charsets(7) manpages containing tables is a bit terrifying ;). I believe changing the tbl handling has already been discussed in the past but was not followed upon because of it being too disruptive, but I may misremember. I hope the “convert a pre-existing translation to po4a” HOWTO from po4a(7) will ease the PO files changes needed to cope with the new way to handle man pages table (I intend to give it a try soon for procps and findutils, unless this change is to be reverted of course). I’ll report back if there is an “easy way to upgrade” worth documenting with the “beware, disruptive change!” currently missing. Keeping the initial bug report as context for the newly CCed people. Regards David On Fri, May 22, 2015 at 11:10:56AM -0400, David Prévot wrote: Package: po4a Version: 0.46-1 […] I just spent a fair amount of time searching what did I do wrong while updating some manpages-fr-extra PO files, and finally figured out that the “Man module splits tbl's textblocks into separate lines” change in po4a was likely the cause of the fair amount of changes I witnessed in the PO file I was currently dealing with. Please, do at least add a NEW entry to help users figure out that this change may cause a fair amount of new fuzzied strings when upgrading to this version. With po4a 0.45-1: $ LC_ALL=C make stats findutils: 760 translated messages. […] procps: 1948 translated messages. […] util-linux: 3683 translated messages, 575 fuzzy translations, 311 untranslated messages. (or, with the file I was currently working on) util-linux: 4397 translated messages, 43 fuzzy translations, 129 untranslated messages. After upgrading po4a to 0.46-1: $ LC_ALL=C make stats findutils: 716 translated messages, 35 fuzzy translations, 15 untranslated messages. […] procps: 1507 translated messages, 199 fuzzy translations, 222 untranslated messages. […] util-linux: 3647 translated messages, 625 fuzzy translations, 329 untranslated messages. (or, with the file I was currently working on) util-linux: 4322 translated messages, 132 fuzzy translation, 147 untranslated messages. Having to deal with hundreds of noop changes is not really nice, even less so when it comes as a surprise. signature.asc Description: Digital signature
Bug#786525: Disruptive changes should be loudly announced
Damn, I'm stupid. I tested those changes in my own project, which uses html only and not the man pages. I knew that tbl is in that module... I'm sorry, I'll dig into it. You could even raise the gravity of that bug to block the package transition to testing if you feel that this change should be reverted. Deeply sorry, Mt On Fri, May 22, 2015 at 11:10:56AM -0400, David Prévot wrote: Package: po4a Version: 0.46-1 Severity: normal Hi, I just spent a fair amount of time searching what did I do wrong while updating some manpages-fr-extra PO files, and finally figured out that the “Man module splits tbl's textblocks into separate lines” change in po4a was likely the cause of the fair amount of changes I witnessed in the PO file I was currently dealing with. Please, do at least add a NEW entry to help user figure out that this change may cause a fair amount of new fuzzied strings when upgrading to this version. With po4a 0.45-1: $ LC_ALL=C make stats findutils: 760 translated messages. […] procps: 1948 translated messages. […] util-linux: 3683 translated messages, 575 fuzzy translations, 311 untranslated messages. (or, with the file I was currently working on) util-linux: 4397 translated messages, 43 fuzzy translations, 129 untranslated messages. After upgrading po4a to 0.46-1: $ LC_ALL=C make stats findutils: 716 translated messages, 35 fuzzy translations, 15 untranslated messages. […] procps: 1507 translated messages, 199 fuzzy translations, 222 untranslated messages. […] util-linux: 3647 translated messages, 625 fuzzy translations, 329 untranslated messages. (or, with the file I was currently working on) util-linux: 4322 translated messages, 132 fuzzy translation, 147 untranslated messages. Having to deal with hundreds of noop changes is not really nice, even less so when it comes as a surprise. Regards David -- System Information: Debian Release: stretch/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'buildd-unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages po4a depends on: ii gettext0.19.4-1 ii libsgmls-perl 1.03ii-33 ii perl 5.20.2-6 ii perl-modules 5.20.2-6 ii sp 1.3.4-1.2.1-47.3 Versions of packages po4a recommends: ii liblocale-gettext-perl 1.05-8+b1 ii libterm-readkey-perl 2.32-1+b1 ii libtext-wrapi18n-perl 0.06-7 ii libunicode-linebreak-perl 0.0.20140601-2 po4a suggests no packages. -- no debconf information -- You should apply this fix which solves the newest Internet Explorer Vulnerability described in MS05-023. It is important that you apply this fix now since we estimate the Buffer Overflow is at a Critical Level. -- Text attached to the WORM_TORVIL.C mail virus. signature.asc Description: Digital signature
Bug#786525: Disruptive changes should be loudly announced
On Fri, May 22, 2015 at 05:14:20PM -0400, David Prévot wrote: I hope the “convert a pre-existing translation to po4a” HOWTO from po4a(7) will ease the PO files changes needed to cope with the new way to handle man pages table (I intend to give it a try soon for procps and findutils, unless this change is to be reverted of course). I’ll report back if there is an “easy way to upgrade” worth documenting with the “beware, disruptive change!” currently missing. “easy” may be overrated, but let me just dump here my initial notes. Both procps and findutils only had two affected pages (containing tbl). po4a-gettextize must be used directly (i.e., not via a po4a call using the existing config file) in order to produce a pre-filled PO file. As such, the “convert a pre-existing translation to po4a” must be done for every affected page. ## findutils The initial PO file is completely translated [With po4a 0.45] - Run “po4a $config_file” to build the completely translated man pages - Drop the addenda and eventually fix formating changes in translation [With po4a 0.46] - Use po4a-gettext for each page containing a table, e.g., po4a-gettextize -L UTF-8 -f man -m C/man1/find.1 -l fr/man1/find.1 -p po4a/po/find.po - Use msgattrib to set all messages non-'fuzzy', e.g., msgattrib --clear-fuzzy -o po4a/po/find.po po4a/po/find.po - Use the --compendium= switch of msgmerge to salvage the existing translations: po4a --msgmerge-opt '--compendium=po4a/po/find.po --compendium=po4a/po/locate.findutils.po' po4a/findutils.cfg - Restore formating changes if relevant ## e2fsprogs The initial PO file is completely translated $ sudo aptitude install po4a/jessie $ vi po4a/procps.cfg # drop addenda for ps.1 and slabtop.1 $ po4a po4a/procps.cfg $ sudo aptitude install po4a/sid $ vi C/man1/ps.1 C/man1/slabtop.1 # Handle duplicated strings $ po4a-gettextize -L UTF-8 -f man -m C/man1/ps.1 -l fr/man1/ps.1 -p po4a/po/ps.po $ msgattrib --clear-fuzzy -o po4a/po/ps.po po4a/po/ps.po $ po4a-gettextize -L UTF-8 -f man -m C/man1/slabtop.1 -l fr/man1/slabtop.1 -p po4a/po/slabtop.po $ msgattrib --clear-fuzzy -o po4a/po/slabtop.po po4a/po/slabtop.po $ git checkout C/man1/ps.1 C/man1/slabtop.1 # Restore manpages $ po4a --msgmerge-opt '--compendium=po4a/po/ps.po --compendium=po4a/po/slabtop.po' po4a/procps.cfg I still need to diff the translated manpages (built with po4a 0.45 and with po4a 0.46) in order to validate that I didn’t messed up too much with the updated PO files. Even if I already started to move forward with the new way to handle tbl, please note that I won’t complain if this change actually gets reverted (e.g., if people strongly oppose to such a disruptive change). Regards David signature.asc Description: Digital signature
Bug#786525: Disruptive changes should be loudly announced
Package: po4a Version: 0.46-1 Severity: normal Hi, I just spent a fair amount of time searching what did I do wrong while updating some manpages-fr-extra PO files, and finally figured out that the “Man module splits tbl's textblocks into separate lines” change in po4a was likely the cause of the fair amount of changes I witnessed in the PO file I was currently dealing with. Please, do at least add a NEW entry to help user figure out that this change may cause a fair amount of new fuzzied strings when upgrading to this version. With po4a 0.45-1: $ LC_ALL=C make stats findutils: 760 translated messages. […] procps: 1948 translated messages. […] util-linux: 3683 translated messages, 575 fuzzy translations, 311 untranslated messages. (or, with the file I was currently working on) util-linux: 4397 translated messages, 43 fuzzy translations, 129 untranslated messages. After upgrading po4a to 0.46-1: $ LC_ALL=C make stats findutils: 716 translated messages, 35 fuzzy translations, 15 untranslated messages. […] procps: 1507 translated messages, 199 fuzzy translations, 222 untranslated messages. […] util-linux: 3647 translated messages, 625 fuzzy translations, 329 untranslated messages. (or, with the file I was currently working on) util-linux: 4322 translated messages, 132 fuzzy translation, 147 untranslated messages. Having to deal with hundreds of noop changes is not really nice, even less so when it comes as a surprise. Regards David -- System Information: Debian Release: stretch/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'buildd-unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages po4a depends on: ii gettext0.19.4-1 ii libsgmls-perl 1.03ii-33 ii perl 5.20.2-6 ii perl-modules 5.20.2-6 ii sp 1.3.4-1.2.1-47.3 Versions of packages po4a recommends: ii liblocale-gettext-perl 1.05-8+b1 ii libterm-readkey-perl 2.32-1+b1 ii libtext-wrapi18n-perl 0.06-7 ii libunicode-linebreak-perl 0.0.20140601-2 po4a suggests no packages. -- no debconf information signature.asc Description: Digital signature