[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFD: translated description with dpkg

On Wed, Aug 29, 2001 at 03:48:24PM -0400, Joey Hess wrote:
> Michael Bramer wrote:
> >  With a hack, this translated description are now also suitable. Daily
> >  the server make translated Packages files on gluck and you can use
> >  this with apt-cache [search|show] and without other sources in apt's
> >  sources.list also with all apt based tools (dselect, gnome-apt, etc.)
> > 
> >  For more information, see the gifs, guides, faq's etc. on
> >  http://auric.debian.org/~grisu/ddts/
> FWIW, I think you all have done some very good work here, and done a
> masterful job of getting the ball rolling on this issue, that has been
> stuck far too long before. But, I agree with you when you say it's a
> hack.

sorry joey, I don't say, the proposal is a hack, I say the aptable
'translated Packages file' is a hack and we use it _now_ to test the
translations and use it. We propose this proposal as a solution and
kill this hack.

> [ putting translations in package ]
> > This has some heavy cons:
> >     - this way will by very slow. We will never get all translation in
> >       all packages. The maintainer will collect some translation
> >       before make a new upload. All packages must build from the build
> >       servers. This all delay the process. Every selling error
> >       generates uploades, builds, ...
> >     - No package maintainer can't speaking all languages. He can't
> >       check the translation, he can't improve the translation, he only
> >       add blindly the translation in the package source. This is 
> >       unneeded work for the maintainer.
> >     - The deb package is growing with the number of translations
> >       added.
> >     - unneeded translation on the system.
> I just want to point out that every single one of these cons applies to
> the standard mechanism used to translate messages in programs in Debian
> packages and in the GNU system in general. That is, po and mo files.


If we get more translation in the 'normal' Packages, we should maybe
seperate this translation in extra 'translation' packages (one per
languages and per package, like trans-debconf-de). Build this deb
packages from its own _debian_ source package (not from its own CVS!)
and improved the package management system. With this improvment a
root can config 'I would get german and french' and dselect/apt/...
will install this (and only this) translation packages on the system. 

This is all like a languages depends. But this is a other story (see
below) and maybe someone write a extra proposal for this story.

> I would think that translating programs themselves is of greater utility
> in the end that translating package descriptions[1]. And it tends to be
> more work to translate all the messages of all the programs in a package
> than it does to translate a single, simple, package description. So not

you say it yourself in the next section. The po files are normal from
upstream and upstream have maybe there own translation groups (like
GNU, KDE, Gnome, ...)

But the package description is write in the debian project and we (the
debian project) must translated it (or nobody will do the work). This
is one special with the description. And we must support our
translators with a working framework. 

And no, 'write Bug report' is not a working framework. And 'wait to
the agreement of the package maintainer' is not a working framework.
If we don't install a real framework, we don't get translators and we
don't get translated the description!

> Well, one reason is that many packages are translated upstream, and so
> we don't feel the weight of all the cons. The cons are still there;
> upstream gets to deal with some of them though. And they can still
> easily reach into Debian and bite maintainers: Fix a message -- oops,
> now you have to fix all the translations from upstream as well. And of
> course other cons like package bloat and unneeded translations on the
> system are still there, and we deal with them. Nobody said that
> maintaining a package would be a trivial job. You have to communicate
> with people. You will run into stuff you don't understand, and have to
> pass it to upstream -- and trust upstream. (Upstream for translations is
> the translators that provide them.)

yes. all right. but some points:
 - normal translation in the upstream source is a other problem. They
   have a own translation group and it own framework.
 - yes some cons applied to other translations too. But this is a
   other story. Some packages have split the translation in extra deb
   packages and maybe we need more. And maybe we need splited _debian_
   source packages too. And maybe we need this languages depenend
   dependences. But this is all a other story and a other proposal.
 - Normal a debian package maintainer, don't edit the textoutput in
   the upstream. This do the upstream and the uptream make the new po
 - If the maintainer use own text (like debconf, description, README,
   ...) he must search his own translators. This is IMHO not nice. We
   need real translations groups. And we must automated this 'I have
   change the text, please update the translation'. We make this the
   description. Maybe we add debconf (and other debian texts) in
   future and write bugreport with a framework...
   (I know, you ask if you change the po files or debconf in
   base-config package. And this work. But if all maintainer ask if
   some of the >300 packages with debconf templates changed, or if
   some description, README etc. has changed, we habe >100 update
   question on debian-i18n@l.d.o. We should automate this process.)
 - And yes you chould trust the translator. He make a voluntary job
   and normal he will not make bad things. Trust the translator and
   include his translation in a automated process.

> Another reason we don't split out mo files from debian packages is
> because we have a clear idea about what a debian package is[2], and mo
> files are clearly an appopriate part of a debian package. And it turns
> out that this concept of a debian package, that we use consistantly for
> all sorts of things throughout debian, makes debian a much more powerful
> system. Oh sure, we could ship kernels as build-your-own-source
> tarballs, and let users browse package documentation on
> http://docs.debian.org/ rather than include it in a package, and ship
> maintainer scripts outside of debian packages, and use LDAP to look up
> package maintainers, and provide yet another mechanism for downloading
> translations. And that would be an unholy mess, so instead we shoehorn
> docs and translations and everything else that fits in our concept of a
> debian package, in the package. And our users thank us for it.

yes you are right. But we will ship the translation in a debian
package, but in a extra separted package.

> I think that splitting mo files out of debian packages and distributing
> them seperatly would be insane[3]. I think it would create a level of
> confusion and mess that would make me very glad I am a mere mono-lingual
> 'merkin.

sorry, we proposed:
!The ddts can provide po files with all translated packages and build
!own deb packages with this file.

We propose to make a description-translation-de.deb, a
description-translation-ja.deb etc. and you can download it (per ftp,
per apt, receive it per mail, ...) and install it. After this you have
translated descriptions...

> insane, but have you really thought it through? What makes package
> descriptions so special that they must be treated in such a different
> way? How does treating them in such a different way gain us much of
> anything, when we still have to deal with all of your cons as applied to
> po and mo files?

I say it above: some things are the same with 'normal' po files,
translated man-pages, etc. But we have with description two
 - first we are the 'owner' of this description. We write it and we
   must translated it. (see above)
 - and this are descriptions. 

The second point is new, and I must explain it:

If you install a  programm you use the po file only after the install.
You need not read the po file first. The package description is
differenced. You need the description before the package is installed.

If you will make apt-cache show or apt-cache search or if you will use
dselect you need all package description. Now we use the Package file
with this. But what is _your_ proposal with translated description?

 - should we put all translations in the package controll file (with
   the tag 'Description-XX:'?) 
   (btw: with this we need the debconf-mergetemplate 'hack')
 - make a Packages file with all translation?
 - make a Packages file without descriptions and some Descriptions-XX
 - make some Packages-XX files (like the files on gluck)
 - ???

If you don't use our proposal we must
 - store the description in the packages and in the
   Package/Description files 
 - the user must download more bytes, the /var/lib/dpkg/status file
   will growing and dpkg will lost speed...
 - have the other crons (see other mails and the proposal)
 - in the result you kill the translation project.

If our proposal we need some nice patches in dpkg and apt, no other
changes and one po/mo file per languages. 

Please dpkg and apt maintainer, please joey speak up and make a better
proposal. Sorry I don't see now a better way, but maybe I only stupid.

Maybe we can combine something and we need a framework with a low

Thanks for the comments. 

Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger grisu@db.debian.org  -- Linux Sysadmin   -- Use Debian Linux
Schlag mich! Kratz mich! Nenn mich OE-Nutzer!

Attachment: pgpYZ6mXfzi9Y.pgp
Description: PGP signature

Reply to: