Re: apache translator please hold on a few days
> From: Martin Quinson <mquinson@ens-lyon.fr>
>
> Would you mind if we go back to the ML ? It could be interesting for other
> people as well,
Of course i don't mind at all :-)
> But the point is that I tried to find a rapid fix for your perticular
> situation. Of course, fixing it for Debian as a whole needs a much more
> complete solution.
yes and thanks for your cooperation.
> My solution is to put all translatable material within Debian in a big CVS,
> and make the proper tools to ease first the interaction of the translators
> with this beast, and then the interaction of the DDs and this beast. The
> beast would allow to uncouple the interactions between DD and translators to
> allow each groups to organize their work in the much appropriated way to fit
> their needs. My thought are detailed in
> http://lists.debian.org/debian-i18n/2003/debian-i18n-200309/msg00077.html
I have been reading this message and this is my idea, that involves some
changes but might it be wise to evaluate it from a workflow point of view.
At this point in time the only certain thing is that a package has been
uploaded by someone. When this is uploaded noone other than the DD knows
if templates are changed and how (let's pick this as the "worst" common
case). So we have to start from it and see a possible workflow:
1) A DD upload a package
2) ftp-masters scripts could easily handle *.templates files in the source
package and could easily take care of interact with your CVS monster,
creating, updating or removing templates. (read my note below ;))
3) CVS at this point can do most of the job automatically. In which way:
if a template is new than it is automatically sent for english review, if
it is already there it gets updated (a hook here should be able to
understand if it is changed or not and take appropriate actions).
4) when the english review team commits back the changes or approve the
template via tagging (that can follow package versioning), the pot file
(?? i think is the one that interests translators) gets automatically
updated and the updates sent to the translation teams.
5) translation teams can at that point interact directly with the CVS to
update their translations and they will tag the .po file when the work is
complete.
6) a cronjob script can take care of checking the translation team work
and when all the existing translations are updated at the same tag level
it could simply send a notice to the maintainer on where to grab the new
translations. (like a tarball created directly via ViewCVS or something
like that). Of course the script should be able to understand and deal
with "translation teams timeout" and things like that in a reasonable way.
Now something like this might work in "normal" operations but point 2 is
still the "weakest link" because it will deal only with uploaded packages
and will exclude translators work prior upload.
A possible way to solve this problem is adding a flag to dpkg-buildpackage
or whatever tool related that DDs use to build that at final build time
(so prior upload) will tell the build system (via a "dh_fetchtranslations"
for ex) to download and show the templates and translations from CVS. The
only problem i see here is that a DD will have to be connected (only once
atleast) at the final build time prior upload (when the connection is
required anyway).
Note that we need to create a new tool to handle this situation in a clean
way since changing an existing one might give problems. Autobuilders for
examples do not need to fetch translations and packages have to build in a
non-interactive way. So the dh_fetchtranslations that might require DD
interaction has to be called in a build-indep: target. In this way
packages can do a smooth transition without breaking anything that is
already in place (and this has to be investigated deeply).
> I did not realize that this needs a way for maintainer to give advices to
> translators about the urgency of the translation, but I'll think about that.
> It sounds feasible if maintainer use a script to put their material manually
> to the DB (as opposed to getting the material automatically extracted from
> the packages).
The problem of urgency would be partially solved using this workflow
because the DD is more free to upload in case of emergency and still get
the latest templates/translations, in case of a "quiet" period the DD
him/herself can interact with the CVS and give time to people to react to
changes.
Fabio
--
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues
http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp00004.html
Reply to: