> From: Martin Quinson <[EMAIL PROTECTED]> > > 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
