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