Bug#786525: Disruptive changes should be loudly announced

2015-06-24 Thread Martin Quinson
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

2015-06-24 Thread David Prévot
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

2015-05-23 Thread David Prévot
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

2015-05-23 Thread Martin Quinson
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

2015-05-22 Thread David Prévot
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

2015-05-22 Thread Martin Quinson
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

2015-05-22 Thread David Prévot
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

2015-05-22 Thread David Prévot
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