On Mon, Aug 22, 2005 at 01:51:46PM +0930, Clytie Siddall wrote:
> Hello again :)
>
> I remember mentioning this before, and another translator did so
> recently.
>
> How do we keep track of changes in the debconf list and current
> files, once we have worked our way from A-Zope?
>
> The status page for debconf [1] is of very limited help as yet,
> because I have found that:
>
> 1. files can stay in the update section for weeks, if not months
> after being updated and submitted!
Yeah, some developpers let the translations rotting in the BTS for long
times before integrating them. Sometimes, they even have good excuses to do
so. I personnaly hate doing a l10n update when I have a new upstream release
to integrate. I fear that the message to upstream is that I don't care about
their good new features.
> 2. so how can you tell if a file is in that list because it _needs_
> updating, or because it _has been updated_?
Impossible from this interface.
> 3. I usually do this in PO files by checking that my revision date is
> after the creation date, but
>
> 4. As far as I can tell, the creation dates don't change when the
> file is modified by the developer. Is that the case? It's certainly
> not the case in other translation projects.
If it is the case, that's a bug in the package in question. To make sure,
check the debian/rules file. That's a quite technical file, but don't be
afraid. Most of those files look the same to some extent. There is good
chances that there is a clean section (called "target" since this file is
indeed a makefile). The clean target looks like this
clean:
some stuff
some other stuff
So, the word clean at the begining of line, followed by one (or two)
columns. Then, the content of the target is a list of lines begining with a
tabulation char. What you are looking for is a call to "debconf-updatepo" in
this target.
This must be called from the clean target, otherwise the po won't get
updated, as you describe. Some broken behaviour may also result in the po
files being updated every second package upload.
That's the long answer. The short one is that you have some doubt about a
package, just get its source and run "debconf-updatepo -v" in it. It'll
update the po files, and display their status. If this exam shows that there
is a problem, just report it here, I'll take care of it, if nobody does so
faster than me.
> I've even tried making a database of debconf files I _have_ updated,
> but because the creation dates don't change, it's not useful.
> Moreover, the version number _can_ change without any alteration in
> the original strings, so it's not an effective indicator, either.
>
> So, how do we keep an eye on changes in debconf files? I would really
> appreciate some advice on this from more experienced translators. I'm
> currently wasting time opening each file in the update list, opening
> my translation and diffing them in detail. :(
The french team use two sources of informations, at least:
- the status page you spoke about
- the bugs in the BTS
Simplistic decision "tree":
Status indicates : BTS content: Action
translation outofdate: empty : translate and report as BR
translation outofdate: bug done : ignore, rumbling about DD
translation done : any : do a party, that's not often
In the french team there is another challenge we must tackle: coordinate
between members to avoid effort dupplication (plus peer review since our
damn language is so hard to write down that nobody can do it right). That's
done by exchanging huge amounts of mails on our mailing list. About 50 a
day, currently. To deal with this load, each and every title have a codified
title. See http://dutch.debian.net/ for the explanation of these
"pseudo-tags" that the dutch team also use now.
If you don't want to improve your coordination between team members, the
only interesting one is BUG. A title like
[BTS] po-debconf://openldap2.2/fr.po #320739
says that the debconf templates of this package was translated, and the
result was submitted as bug report 320739.
These mails constitute the third source of information for our coordinator
(Christian). He uses a little script called dl10n. This beast can fetch the
status database (the one used to generate www.debian.org/intl/l10n/*), it
can also parse the mailing list archive, looking for the pseudo-tags and
filling them in a database it has.
the dl10n script is also able to get in touch with the BTS itself to see
whether the bug was closed or not.
So, at this point, I'm sure you're jumping around, asking where you can find
this new script, aren't you?
cvs co -d :ext:anonymous@cvs.alioth.debian.org:/cvsroot/debian-l10n dl10n
cd dl10n
PERLLIB=lib ./dl10n-spider fr
[go get a coffee while the spider parses the french mailing list]
cd data
./fetch-pkg-info
cd ..
PERLLIB=lib ./dl10n-txt -taes --show=podebconf fr
Read the database... done.
Status of the packages to do in fr
______________________
__________________|_____po-debconf______|
|______name________|__%__|____details____|
|alsa-driver |85% | 12/0/2 |podebconf(rfr, 4 days)
|backup-manager |93% | 57/1/3 |podebconf(lcfc, 29 days)
|base-installer |98% | 80/0/1 |podebconf(hold, 344 days)
|facturalux |71% | 10/4/0 |podebconf(taf, 3 days)
|gcl | | 0/0/4 |podebconf(rfr, 1 days)
|initrd-netboot | | 0/0/22 |podebconf(rfr, 2 days)
|lyskom-elisp-clie |50% | 1/1/0 |podebconf(taf, 3 days)
|mysql-dfsg-4.1 |90% | 18/0/2 |podebconf(rfr, 4 days)
|mysql-dfsg-5.0 |85% | 17/1/2 |podebconf(rfr, 4 days)
|nttcp | | 0/0/3 |podebconf(itt, 14 days)
|qpsmtpd | | 0/0/22 |podebconf(rfr, 3 days)
|ssl-cert |90% | 18/1/1 |podebconf(rfr, 35 days)
|suphp | | 0/0/4 |podebconf(rfr, 1 days)
|totd |33% | 1/0/2 |podebconf(taf, 5 days)
|__________________|_____|_______________|
|TOTAL (fr) |99% | 10228/8/68 | Assuming that all bugs reported
|__________________|_____|_______________| were applied
If you decide to go that way, that'll be a good motivation for me to work on
this again. This interface is a bit odd, someone need to do the html output,
for example. Plus, another input method not being based on the mailing list
parsing would be welcome, too.
> As a suggestion, I find the Gnome status pages, which state the
> filename, version number and number of strings currently translated,
> fuzzy and blank, extremely helpful. All I have to do is run my eye
> down the percentage-translated column, and I can very easily spot any
> file that needs updating. I know the distributed nature of Debian
> (otherwise known as how long submitted translated files take to reach
> the status pages ;) ) means we won't get the almost-instant update we
> do at the TP and Gnome, but it would help to have the version number
> included in the update table .. unless that changes without change to
> strings...
Yeah, those other project have a very easy time to that extent. Translators
control the whole production->distribution chain. Since we don't, that's a
kid of nightmare for us here around. But keep faith, we know how to script
to you pleasure ;)
I'm dreaming of using pootle as a central database here, so that these
issues solve from themselves.
Will see what we manage to do, but that's all I have to offer for now.
Bye, Mt.
Attachment:
signature.asc
Description: Digital signature