On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote: > On Tue, Sep 04, 2001 at 10:39:00AM +0200, Chris Halls wrote: > > How will the translated Description be stored in the deb Package?
Sorry, I wasn't addressing that :-) I was expecting to use the solution that would need to be worked out as a result of your statement: > > > The more controversial point of our proposal is that we where planing > > > to centralize the translation in a way that keeps the maintainer out > > > of the loop. But it's not the key point, it's an add-on which ease the > > > work of translators. Each package can still provide the translation > > > and be 'self contained'. My proposal simply lets all packages be 'self contained'. > > You now have translated descriptions integrated into the .debs, > > and it is possible to generate the Packages.<lang> files for use by the > > modified dpkg/dselect as was originally suggested, except that the > > translations are coming from the .debs instead of a single server. > > Packages.<lang> are a hack. > > What are Packages.<lang> file? Files with the English and the > translated Description? Only the translated Description? With a > Description or a Description-<lang> tag? With the other tags? Oh yes, I was referring to the older solution. s/Packages.<lang>/Packages.po (i.e. use the Packages.po format you suggested - I'm just suggesting always generating them from .debs in the same way as Packages, instead of introducing a seperate centralised system) > some cons: > - apt-get don't know about the translation with this > - if you will use some languages, you must download some Packages > files with all the tags. > - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size > _without_ translation... > - you must patch apt in a whole I think your objections are because I didn't talk about Packages.po, aren't they? Do your objections still hold if you use Packages.po? > - maybe we get outdates translations (like debconf) Yes, the issue is not solved totally MIA maintainers, who never initiate a package rebuild. But at leat, any NMU rebuild by someone else (or qa?) would then automatically fold in your updated description translations to the package, compared to the sometimes hit-and-miss affair of a BTS request which the maintainer may or may not integrate into the package. Using this suggestion, the 'default case' of a maintainer doing nothing to the translations when rebuilding would pick up the translations (provided they at least did an apt-get update every now and then!). Compare this with the debconf template situation: If the maintainer does nothing, the translation rots in the BTS. Chris
