On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote: > > > Gettext normally uses the entire untranslated string as the key in the .mo > > > file. This has many advantages when dealing with translation of strings > > > in > > > programs, where the untranslated string is actually present in the program > > > source, and this is a big reason the GNU project favors gettext over > > > catgets > > > systems found on other Unices. It makes less sense in the case of package > > > descriptions, however, because we're effectively doing two lookups -- > > > first to > > > find the English description in Packages.gz using the package name and > > > version > > > as a key, then to find the translated description in the .mo file using > > > the > > > English description as a key. > > > yes, you must two lookups. First in the package db (normal in the > > menory) and (if LANG is set) make a second lookup with gettext. > > > But this not a big problem, or is there a problem? > > It casts doubt on the argument that gettext is a good solution here. Just > because gettext is the optimal solution for translation of messages within > programs does not mean it's the best solution for package translations. I'm > personally willing to do a little wheel-engineering if it leads to a more > elegant result.
yes, maybe other technics like catgets, or own implementations are have in this special case more performance. But if such a solution more elegant? Other programs have also 'non static' output and use gettext. I don't see a real problme with gettext. Gettext work, you must not thought about it. It is like a VW Käfer, it is runing, runing and runing. IMHO it is elegant, if you get with a only -9/+30 clear patch translated description in dpkg. Reuse the code. If we have a real advantage with a re-engineering wheel, make a re-engineering. I have no problem with a special wheel, if we need it. > > If you put the translated text only in the db, and you don't use the > > english text as key (like gettext) you get maybe outdated translation. > > Only if the implementation is poor. The accuracy of a translation can be > verified in the process of assembling the file that is to be made available to > user machines (whether that file is Packages.gz, or debian-descs.mo, or > whatever). Obviously the /inputs/ used to create this file must include > mappings of English string -> translated string, but these mappings need not > be retained in the output file. We only need to make sure once that the > translation is up-to-date, not every time the user runs dpkg, because each > version of each package can have only one untranslated description associated > with it -- it's a unique key, by definition. > > If nothing else, perhaps you would consider that a .mo file containing > [untranslated string -> translation] mappings will on average be almost twice > as large as a .mo file containing [(package name,version) -> translation] > mappings. :) yes, you right in all point. I propose to use only .po files in the source with this thought. I use this [(package name,version) -> translation] relation also (to make a .po file from a Desription-XX and a Package file). This is possible, if we don't use gettext. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux "Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel." -- Jens Dittmar in de.comp.os.unix.linux.newusers
pgpVMuqK8fAyY.pgp
Description: PGP signature
