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 grisu@db.debian.org -- Linux Sysadmin -- Use Debian Linux
"Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel."
-- Jens Dittmar in de.comp.os.unix.linux.newusers
Attachment:
pgpgogmK9AVNK.pgp
Description: PGP signature