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:
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
[…]
Afficher les réponses par date
On Fri, May 22, 2015 at 05:14:20PM -0400, David Prévot wrote:
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,
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:
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 :
[…]
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
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