Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Thu, Sep 13, 2001 at 04:25:43PM +0200, Wichert Akkerman wrote:
> Previously Michael Bramer wrote:
> > wordperfect is no free software and they can only support some
> > languages. Get KDE, we have 38 kde-i18n-* packages. This is the
> > _minimum_.
>
> This is not just about Debian. It is about the dpkg packaging system,
> which can be (and is) used outside Debian just as well.
Fine, but that's an argument to say dpkg support of description translation
must scale in number of languages, too.
> > You say 'few important'. But what languages is important? Somebody
> > say: throw away English and get Russian. Others like (or better
> > _need_) Polish, german, Japanese, China, ...
>
> That's decided by whoever makes a package. I don't expect everyone
> to feel the same way about translations as Debian does.
Nobody using dpkg can choose what kind of description translation they want
as long as there is no support in dpkg.
> > And if we get translators, why not add a some more languages. We have
> > now in the ddtp only 11 languages at the beginning and we don't have
> > real support in the project, in dpkg etc.
>
> Debian can do that. Other might not be able to do that. The world is
> bigger then Debian.
Even Debian can't do that for now, because nobody know how to deal with
description translation in a scalable manner.
We proposed a first solution (the one with translation package) which did
not scale well in number of package. We changed it (with translation in
package or in extra file), but it did not solve the publishing issue. You
proposed a solution (translation in control file) which does not scale in
number of language, and makes the translator job hard (keeping track of
outdated solutions).
>From there, we have two solutions. First, we say we have no Perfect Idea,
forget about it, and wait for others to try in a few years, or we search
further.
I'm ok with your solution, but we have to search a scalable way to put
translations in the control file, and then in the status files after
parsing. So, yes, the format matter to thing about a scalable implementation.
Mt.
Reply to: