Re: [Perkamon-fr] 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.
Afficher les réponses par date
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.
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
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\ B<pcpu>).\n" msgstr ""
And now the 0.45 version:
msgid "%cpu %CPU T{\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\ B<pcpu>).\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.
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
-
"David Prévot" -
David Prévot
-
Martin Quinson