po4a-dev
[Top][All Lists]
Advanced

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

[Po4a-dev]Status report of po-dpkg


From: Martin Quinson
Subject: [Po4a-dev]Status report of po-dpkg
Date: Tue, 3 Sep 2002 14:59:23 +0200
User-agent: Mutt/1.4i

Ok, I guess it's my turn to make a status report about my work here.
So, here we go, here is the current situation in my effort to get dpkg
handling localized package description. Note that it's not really related to
the work of this group yet since we have to get dpkg i18n'ed to that concern
before we can think about using po files to help the translators here. But
in the long term, I naturally plan to do something like Denis did for
debconf templates.

Here are the problem we have to solve to design and implement a solution
concerning debian package description translation: 
 1) How are handled translations in the source package
 2) How are stored the translations in the binary package
 3) How are stored the translations on the user machine
 4) How do dpkg handle the translation
 
The result of the discution on debian-dpkg (which may be very animated ;)
are that we will solve these problems in the reverse order. Not from the
translation to its use, but from the most fundamental changes (dpkg and
policy changes) to the less ones (new tools to help the translators and
developpers).

For 3, Adam Health recently reported that he's thinking of not storing the
description in memory anymore, to save memory, but in a file (with only
start offset/length stored in memory). That way, handling translation could
be done by handling several files of description. Adam's work is not even
commited to the CVS yet, but since also the standard version of dpkg would
benefit it a lot, it may happen quite soon.

Once it's done, we can work on how to use this mecanism for i18n in order to
solve 4. If Adam's changes work like he says, this won't be difficult.

Then, for 2, I guess we will end with a situation like in rpms. Ie, the
control file will contain as many Description-$lang: field as languages. It
needs a modification of both the policy (which fields are valid) and the
dpkg tool chain (implementation).

Then, for 1, I intend to use the po4a approach. I guess it will happen after
the dpkg-source reimplementation in python (currently underway). 


As you can see, this branch of the project is far from being done, but at
least we are moving forwards again (after a long freeze due to the
accumulated frustations in the last mail flame war).

That's all I can report for now, stay tuned ;)

Bye, Mt.

-- 
Dans un pays d'extrême droite, On y parle beaucoup de Dieu, Parce que ça
fait longtemps, qu'il a quitté les lieux.
   -- Frères misère




reply via email to

[Prev in Thread] Current Thread [Next in Thread]