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. second. 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. 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 files. - 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 firstname.lastname@example.org. 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, 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. 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 specialities: - 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 files - 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 delay. Thanks for the comments. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger email@example.com -- Linux Sysadmin -- Use Debian Linux Schlag mich! Kratz mich! Nenn mich OE-Nutzer!
Description: PGP signature