Denis Barbier wrote: > For translators having a development URL is also useful, because they can > then send up to date translations; it was said that it is then available > from package homepage, but some packages have no homepage and have a > public CVS repository. I'm not sure what a "development URL" is. You cannot really give an url directly to a cvs repository and surely it'd not be world readable anyway. > It would also be very helpful to know when packages have upstream > translation teams, e.g. in GNU, GNOME or KDE projects, so that Debian > translators do not interfere with their work. IMO a Project field is > enough, its value being either some known values or an URL. > Last point, it is frustrating to work on translations which are never > incorporated. For instance if you do not want to bother with the FSF > disclaimer, you might want to know whether an author mandates it or not. I guess I don't see any of these things being worth bloating Packages files with. You don't need them at install time; the info is probably not even needed in binary packages. If a translator needs the source package anyway to do translation work, such info could just be present in there. If you want to spec out a file that goes in source packages for this kind of structured data, fine. uscan files are a good example of something similar. -- see shy jo
Attachment:
pgpeBopBj_zWT.pgp
Description: PGP signature