splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Wed, Sep 12, 2001 at 03:50:16PM +0200, Wichert Akkerman wrote:
> Previously Martin Quinson wrote:
> > 1) Do the translation
> > 2) Put the translation in the Debian archive
>
> Wrong. `Make the translation available' would be better. Not all packages
> are in the Debian archive, and they have to be just as useful without
> being forced to be in there.
>
> > 3) Publish the translation, ie make sure it comes to the user hard disk when
> > the package gets available, even before it gets installed
>
> Not sure about that. `Make it possible to access a translation for a
> specific version of a specific package' would be better.
>
> > 4) Use the translation when environment variable is properly set, and when
> > the user ask dpkg & Cie about a package.
>
> > You want to handle 2 by putting the translation in the package.
>
> No, I want it to be possible to have it in the package, but it might
> be elsewhere as well. Putting all translations in all packages doesn't
> scale, but having multiple translations in a package can be useful (think
> packages not in a full archive, for example a vendor shipping debs on a
> CD).
So, you want to make possible for a package to contain meta-data about
another package, am I right ? Or are you thinking about a separate file, not
in a package, like the Packages.gz is ?
> > That's ok, but with which form ? There is at least two solutions: in a
> > po file located somewhere in debian/ dir, or directly in the control
> > file. You prefere the second solution, am I right ?
>
> For translations inside the package, yes, definitely.
But if you put the translation in the control file, you have to add almost
hundred fields, on per locale: Description-fr ; Description-fr_FR ;
Description-fr_CA ; Description-fr_BE just to have the more used french
variants (and no, it would not be acceptable to merge all country variant of
the language in the language. Think about pt_BR and pt_PT).
http://www.debian.org/intl/l10n/l10n-lang shows that 96 languages are used
somehow in [po files of] Debian. And this list does not contains wa, for
example, which is offen used to design wallon (AFAIK, dutch spoken in
Belgium). http://www.debian.org/intl/l10n/l10n-errors#guess give a list of
refused language codes because they are not part of ISO639. And by the way,
this specification contain much more language, which are not used in Debian
yet.
Would we declare one new field in <dpkg>/lib/parse.c:fieldinfo for each one,
choose the most used one, have a new kind of 'variable field', designating
the Description, allowing a parameter designing the language used ?
> > As far as I understand, you want to take the descriptions aways from
> > the /var/lib/dpkg/status file, and make several files, one per
> > language. this would make the status DB lighter, and ease the handle
> > of several languages.
>
> I want the status file as it is to change, it contains much more
> information then dpkg needs to do most of its work. Non-essential
> data such as descriptions, maintainer info, etc. can be moved to
> a seperate new file that tools like dpkg-query and frontends can
> access (dpkg still needs to update it of course).
That sounds great. For example, I'm sure 486 or PentiumI users will love
this idea.
Should we make two files, like status-essential and status-extra, or split
it further ? Moreover, what should be the format of the new file(s) ? Also
rfc822-complient, or something else ?
For example, for descriptions,
file:///usr/share/doc/gettext-doc/gettext_7.html#SEC36 gives the format of
the binary file used by gettext. It is pretty clear and well documented. We
could use it to store descriptions. Not only translated one, but also
original one. I'm thinking about a mo file associating 'package-version' to
the description in the given language. You could have dpkg writing directly
this file (gettext is GPL, and could be borrowed).
Then, given the face that any user add a fallback to english, the use of
these data in dpkg & Cie would be easier. But that's just an idea I wanted
to propose, I'm not sure at all that's the best way to do things. (I tend to
think the contrary)
Bye, Mt.
--
Un clavier azerty en vaut deux.
Reply to: