Re: po-debconf patches and woody backportability (was: Re: [VAC] 25 july - 26 august)
Quoting Colin Watson (email@example.com):
> This approach is a little more complicated, but it seems very robust in
> practice, and makes backports perfectly smooth. I recommend it for
> people converting packages to po-debconf before the release of sarge.
This is a very interesting approach. I will certainly adopt it for my
own package which uses (po-)debconf (geneweb).
On the other hand, I'm quite skeptic for adding these changes to the
"po-debconf switch" bugs. This would make these patches quite
"intimidating" for the average DD (no offense here....this is based on
the input I often receive after sending those bugs)....and would probably
delay (or even prevent) the adoption of the patch...
This would also slow down a lot the systematic work we're doing : we
produce patches which need to be adapted to each package...this is a
*manual* work...and we try to do correct work.
The first goal of the BR we send (this includes myself, but also
Michel Grentzinger, Andre Luis Lopes and probably others) is having as
many DD as possible, who currently use debconf, go towards po-debconf
in order to speed up the translation process.
100% use of gettext'ed templates for user input is The
Target....because this is one of the keys for 100% translated user
We currently do not have statistics about the delay between the BR and
the po-debconf adoption by the maintainer. I keep a record of the
debian-l10n-french team in this particular field...but as soon as a
package has switched, I drop the corresponding entry....
We only have a subjective feeling :
-translation only bugs are mostly quickly closed (this concerns
packages already using po-debconf, for which we just send a translated
-po-debconf switch bugs take significantly longer to be closed. Of
course, they are more "invasive" bugs, so that's perfectly
This is why I think than even more invasive bugs would probably
frighten some DD's.... :-) (not counting all people with sophisticated
methods for repetitive templates generation, or people who do not want
to use debhelper because hand-crafted unreadable scripts are better
and so on.. :-))
I'm considering adding a mention to the standard text we currently
use. This mention woudl then be compething like this :
"Please note that the suggested modifications will make your
package a little bit harder to backport to earlier Debian releases. If
this is a concern to you, you may try to adopt the method used by the
openssh package and detailed by Colin Watson in