[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 05:40:25PM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > > 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?
> 
> gettext can not really be used for this data.
> 
> It needs to be stored, in /var/lib/dpkg/status, as a single file.  This is so
> that dpkg can make safe updates to it.  Trying to sync multiple files is not a
> simple solution.

no, it does not store there. And I can explain it:

 The translation is no new information, it is not new package
 metadata. It is only a translation, a other form of the exact same
 information. 

 You can update /var/lib/dpkg/status, you can change the format, you
 can do all things with it. You and you don't break the system. The
 system use only gettext and get a translation.

I quote Wichert:
'It has nothing to do with package metadata and does not belong there.'

He don't mean translation, but he has right. No package metadata
should not in include in the controll file and not in
/var/lib/dpkg/status.
 
> > 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.
> 
> They must be stored inline inside status/available.  This is the only sane way
> to implement atomic file updates.

you don't need atomic file updates with the translations. 

See a other example: the menu system.

This information is not in the control file, but you can make updates
without problems.

The translation is only a other form of the same information. You
don't need this information while the update process. You need the
translation only 
 - after the installation/update process (like dpkg --list)
 - and before the installation/update with dselect, apt-cache show,
   seach. 

There is no need of a atomic file updates. 

> > 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.
> 
> zcat Packages_de.gz Packages_jp.gz | dpkg --merge-lang

and?

If in the dpkg database are changed description and in the Packages_de
file is one/some translation from the old description, you don't find
this this way. You will get outdated translation in the dpkg database. 

Only one number: in the last 10 days we have >50 changed description
                 in sid/main 
                   
If a description is already translated, we need 1-20 days to
change the translation also. You will have outdate translation all the
time in sid and testing. And we must handle this problem. 

Or didn't I understand your 'dpkg --merge-lang'?

> > 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
> > system.
> 
> Please stop just applying this to Description fields.  Make it generic.  dpkg
> supports user-defined fields, so this proposal/implementation should as well.

If we talk about translation, this is not a big problem. You must only
use gettext all the time. Maybe we can throw away the 'maintainer
name' problem with this. (You know it: maintainer fields with
ÖÄÜöüüßåñïééõú... in the name.)

We need only one .po file, like this 
 msgid "Werner Mueller <werner@debian.org>"
 megstr "Werner Mülller <werner@debian.org>"
And the german User see the 'right' Name of this maintainer all the
time. 

Gettext is generic with translations. You must only use it in the
output process of dpkg, dselect and apt. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger grisu@db.debian.org  -- Linux Sysadmin   -- Use Debian Linux
Und mit doppelseitig bestrichenen Sandwiches baut man das
Perpetuum Mobile nach Murphy. -- Kristian Koehntopp in dasr

Attachment: pgpyoRem7ehEb.pgp
Description: PGP signature


Reply to: