On Mon, Dec 09, 2002 at 09:50:22PM -0500, Joey Hess wrote: > 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.
Right, I was thinking of a cvsweb interface. > > 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. Agree. Again my only goal is to have more accurate links at www.d.o/intl/l10n/ I could maintain a database with the needed informations for each package, but it would be a lot simpler if developers provide them in a standardized way. > 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. Ok, will look at them. Please ignore my initial request, I no longer need extra fields in debian/control and will think of a new file in source packages. Thanks. Denis
