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

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

On Tue, Sep 04, 2001 at 02:18:57PM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> > > Adam, who is a dpkg developer.
> >
> > Ok, But why the dpkg so quiet?
> No one sees a need?  We all have to split our time different ways, and the
> current developers/authors/programmers don't see it as useful.

this is normal. But some comments (like your last mail) is better.

> If someone were to develope a patch, test it, show it in use, it would very
> likely get a good response.

Have you see the patch from martin (see the very proposal)? 

> > I only see some comments like: `I don't like this hack', 'This don't
> > work', 'Make sure people submit their translations in UTF8', ...
> So come up with a proper solution, not a hack.
> A proper solution, at the very least, invovles storing the data in the
> foo.deb{control.tar.gz/control} file.

gettext is not a hack. Gettext for translations and dpkg use gettext
is self for translation. Why re-inventing the wheel?

I propose to store the translations in a some po.files and store this
in foo.deb{control.tar.gz}. But not in the control file.

If you store the translation as normal field in the control file (like
Description-de: dff) you have outdated translations with the time.
And outdated translations is a very big problem. 

You have more than one encoding in this file. This can be a problem.
Maybe you make a hack like debconf-mergetemplates and save the
translations in some files and merge this later in one control file. I
don't see a advantage with this. 

> > But Adam and other dpkg/APT developer: some wishes
> >
> >   - If you have already some thoughts about the technical
> >     implementation of translated descriptions, give us some hints,
> >     URL, etc.
> Fetch the current locale, and when displaying a field(from a list of fields),
> look for the fieldname with the locale appended.  Note, this is not as easy as
> it may sound, because the description as stored by dpkg internally in memory
> does not make it immediately easy to generify.

this make the patch and the patch work. I don't stress the patch and
maybe it has one or two bugs. But it work with Descriptions on my

> There may be other fields that should be 'converted' to an alternate form,
> when displaying, not just Description(I'm leaving this open for other items in
> the future).

Maybe we can 'converted' other fields. But I don't see the sense?!

The other fields (like Package, Depends, Version, MD5SUM, ...) are all
more technical. The User need not to 'understand' the values of this
fields. The Package name is the package name, the version is the
version, ... Normal in RL you don't translate Names, etc. 

Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger grisu@db.debian.org  -- Linux Sysadmin   -- Use Debian Linux
Jaja. Die Heisenbergsche Unschaerferelation soll nur die Rechenfehler
der Simulationshardware verdecken.
  -- lutz@iks-jena.de (Lutz Donnerhacke) ueber simulierte Realitaet

Attachment: pgpbFbTC9EkPx.pgp
Description: PGP signature

Reply to: