Re: Asking for a new pseudo package in the BTS: l10n-french
On Thu, Feb 13, 2003 at 01:31:17AM +0100, Michael Bramer wrote:
> On Mon, Feb 03, 2003 at 05:10:24PM +0100, Martin Quinson wrote:
> > So, what do you guys think ?
> >
> > To sum up my point, the best solution would be that translators become the
> > same status inside Debian than maintainers.
>
> ack
>
> > One way to achieve that is that binary packages would contain not only
> > data.tar.gz, but also data-XX.tar.gz (and maybe doc-XX.tar.gz, but that's
> > another point), one for each language. Then, building a binary package would
> > build all parts. So, when the maintainer release a version, he release the
> > whole stuff. Then, translator would be provided a way to overide the data-XX
> > part with updated translation. That's a bit what's proposed in
> > http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02329.html
>
> I don't like this (if I understand it in the right way)
>
> I like more real packages with only translations in it. Like
> gmc (only code and english text)
> gmc-i10n-es (all translations for the bin-package gmc (po, man-pages,
> README-files, ...)
> gmc-i10n-de
> gmc-i10n-fr
> gmc-i10n-..
>
> The bin package 'gmc' have a 'Suggests: gmc-i10n-*' like dependence and
> the user can use apt pining to avoid some languages.
>
> The i10n packages have real package maintainers, we have a real
> BTS-package. Also we can make new i10n packages, without any delay from
> the bin package maintainer.
>
> Some translator can build a own aptable http server with his newest
> translations and maybe some DDTP-like system can build daily new i10n
> packages, if it has new translations...
Yes, it would be a good solution also. The only problem is that it will
multiply the number of packages by 10 or even more, and that dpkg's package
database is already suffering from the number of packages. That's why this
solution isn't possible right now neither.
Let's see the reaction of dpkg's maintainers to bugs like #139838 or #179296
or #179385.
When this gets implemented, I guess we could *think* about adding a few
thousend of packages. But even then i doubt that we can actually start to
implement this as is.
> > As long as this solution isn't effective (ie a loooong time), we have to
> > search for tricks.
>
> for this we must wait a looooooooooooonger time... :-)
>
> > Proposed solutions which does not work well IMHO:
> > - keep as we are: bugs are repported against the package containing it:
> > every translation team have to have the needed manpower to monitor *all*
> > bugs submitted against *all* Debian package.
> > - keep as we are, but use the 'upstream' tag for translations issues.
> > That means that translators are denied the use of the BTS and have to
> > handle bugs without the coresponding tools.
> > - don't use the BTS, but the bug tracking system from the DDTP:
> > works only for pkg descriptions, debconf templates (?), and so, but not
> > for man pages, program messages, and so on.
>
> one note:
> The bug tracking system from the DDTP work for debconf templates, but
> the package maintainers don't know all this translations and they
> don't use this translations.
What kind of debconf templates are you translating? The ddtp page is not
clear about that, and I seem to remember that you still translate debconf
templates of the old generation, ie, the ones handled by debconf-utils.
That's bad, you should move to po-debconf. For example, if someone
translated the templates of the debconf package that way, it is not far from
useless for the maintainer, since he have to convert your old generation
template to the new generation he is using.
Likewise, please don't offer support for man pages. Instead, please offer
support for po files. That way, you will gain a support for man pages in a
manageable way, thanks to po4a.
Thanks for your time and efforts, Mt.
--
Don't drink as root!
Reply to: