Hi Andreas, > I do not think that anybody should waste time with creating such lists. > There are better techniques available. Please consider the following > only as *demonstration* what is possible - not as finished work! I > commited three new tasks files: I'm not sure we're speaking about the same kind of lists. You seem to be speaking about making meta-packages lists while I was speaking about the list of packages available from our custom DoudouLinux repository, the candidates for upload into the Debian archive. That said your tool looks interesting. It reminds me things you may have told months ago, probably on the derivatives list. > I have no idea how the doudoulinux metapackages might be created but I > do any bet that you are doing it in a time consuming manual way. I wonder > whether you might want to do it the right way (tm)? Instead of making > lists of packages missing in Debian you can add these as prospective > packages described here: > > http://blends.debian.org/blends/ch08.html#edittasksfiles > > So everybody knows our TODO list and you can add the location of your > DoudouLinux inofficial packages as "Pkg-URL" field where we can grab > from and move it to main Debian. Currently we maintain several text files that are compatible with Debian Live package lists. These text files are then turned into Debian packages by a script. As I understand your notice, we should process in the reverse way: write the text file fitting the meta-package syntax for Debian blends tools then, eventually, turn them into Live lists if we don't want to use meta-packages in Live systems (but I can't see why as long as meta-packages get built within a short period). > Are these translations of package descriptions or translations of the > according software? In any case I think your translators would be very > well advised to work together with the according upstream. Having good > translations hanging around at "random places" (and DoudouLinux is some > random place) simply sucks and will trigger the need for duplicated > work. I agree of course, but this is not as simple. Most of translators just accept to translate (NB: applications, not descriptions of packages). We have around 75 user applications in DoudouLinux. Sending translations manually to every upstream project is a huge work. I believe this is the main reason why nobody has decided yet to do this job for the whole translation team. On the contrary, one reason why translators would prefer to come and translate for DoudouLinux rather than for each upstream project separately, is that they can access all of them from a single point thanks to our translation portal on Transifex: https://www.transifex.com/projects/p/doudoulinux/ We had an interesting discussion on this topic very recently on our lists: https://mail.gna.org/public/doudoulinux-lang/2014-01/msg00000.html We probably need to write additional tools to increase translators motivation as well as to improve the sharing of our work with upstream projects. > Reasonable upstreams have some bug tracking system. Please make sure > that your nice work becomes available for everybody! If it is about > package translations you can use straight DDTP server (see also links to > translations on the web sentinel pages I was linking to above). DDTP servers? What does DDTP mean? > As I said: Reasonable upstream usually have a bug tracking system or any > contact point you can send the translation to. This information should > be also in the according debian/copyright file. Yes, honestly we'd like, but we always need to find a good balance between perfection and action. Because of our limited resources, we always have to choose between making things better in the back-office or making things better for the end-user. As we don't know in advance how upstream developers will be interested in our work, it is very hard to decide to spend much time in sending upstream everything we do. Unfortunately we don't get a warm welcome every time. As a result, we partly share our work with upstream only, certainly too little. -- Cheers, JM.
Attachment:
signature.asc
Description: This is a digitally signed message part