On Wed, Jan 07, 2004 at 12:26:44AM +0100, Dominique Devriese wrote:
> Petter Reinholdtsen writes:
>
> > [Dominique Devriese]
> >> PROPOSED DEBIAN SYSTEM
> > [...]
> >> 2. The translators don't try to get their work included in Debian
> >> packages. Instead they provide one package of their own, that they
> >> can occasionally release in sid if they want to.
>
> > We discussed something like this for the new installer, making it
> > possible to update/add translations independent of the "real"
> > packages. For this to work, one need to be able to add translations
> > to the debconf database.
>
> Perhaps debconf could be changed to use gettext instead. I.e. when it
> sees a translatable string in a template, it calls gettext on it.
> That way, all the translation packages have to do is to put the .(g)mo
> files in the right location.
It was discussed around August 2002, IIRC, and the objection to that
proposition was that debconf needs its feeding before the package is
installed (obviously), ie before it gets any chance to put any file in the
right location.
I didn't find any good solution to that issue since then. Maybe hack a bit
gettext to give it the possibility to load a file providing the exact path
(and not letting it guessing the path in between the installed files the way
it's done now).
As expressed elsewhere on this thread, we could also try to split the
translations out of the packages. Ie, make a foo-XX for each foo being the
name of an existing package, and XX being a language code. That way the new
package could feed the debconf database with the appropriate translation (no
matter if we use gettext or something else).
But the conclusion we cam with last time we spoke about that is that dpkg
would be unable to handle to tremendous increase of packages number. And
even if dpkg could handle this, I'm not sure it would be wise. See below.
Another solution would be to use a jumbo package for each language,
containing the translation of each possible string. But this would only be
possible easily for stable releases, since the content of the strings
changes so often. Ie, this solution is doomed to be outdated for unstable.
Moreover, what to do with packages not released by Debian itself, but
directly by their authors? An example comming to mind is CrossOver, from
CodeWeaver (TM), which comes packaged as deb file once you've paid the
licence.
If well appliable in a context as much centralized as KDE, jumbo package
won't work well with Debian, imho.
I think that your analysis is biased because you try to apply unchanged the
methods which worked in the area regular program messages to the area of
package configuration messages. This area has specificities that you have to
take into account.
I mean that I plainly agree when you say that po files are perfect for
translators (ask google about po4a), but they may not be adapted to users
nor developpers in some cases. You are trying to solve several hard problems
at the same time. See graal.ens-lyon.fr/~mquinson/l10n.html#l10n_pb
At first, I'd say that we need a solution allowing to get translations from
several sources (the user's configuration, the package maintainer, the
translation team or whatever), what does not exist ATM to my knowledge.
I guess though that it would be easier to add this feature to gettext than
reinventing all what gettext does in a brand new system.
Providing the possibility to anyone to add new source of translation is IMHO
the only solution to make anyone happy.
Then, the solution I prefer to publish the translations to the users is
neither the jumbo package, nor the myriade of micro packages, but what is
sometimes refered as "atoms": Instead of making a full-featured package to
put the translation in it, we could pack several files in the ar archive
composing the deb file (ask 'ar t any_package.deb'), one of them being the
translation of the debconf templates to french, the other one being the
documentation in spanish, and so on.
It could also be used to replace the -dev, -doc (and so on) packages.
Advantages, and disavantages (imho, of course):
+ translators can add their work after the maintainer is done without
interfering with him (using a managing script like the TP robot?)
without always dangerous NMUOTLC (NMU of the last chance ;)
+ each part can be signed separatly
+ extensible to documentation and any other material within package
+ lets the will of translators and embeeded solution designer fit together
- needs to come up with a practical yet extensible set of attributes for
the atoms, so that the packaging tool can choose which one they need to
unpack, and which one they can trash.
- Then, almost every package management tool would have to be modified to
use this. Plus the package generation solutions. Plus the policy itself
(since it is where the package format is described).
The amount of work it would need leads me to think that it will never be
done because that's a deadly overengineered design. Yet, that's the best I
can imagine.
Bye, Mt.
PS: thanks for pushing me into redoing
http://graal.ens-lyon.fr/~mquinson/l10n.html#l10n_pb to present my answers
to this FAQ.
--
The tragedy of modern man is not that he knows less and less about the
meaning of his own life, but that it bothers him less and less.
--- Vaclav Havel
Attachment:
signature.asc
Description: Digital signature