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

Re: new proposal: Translating Debian packages' descriptions

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. 

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: pgp5DfgAHTaTy.pgp
Description: PGP signature

Reply to: