On Sun, Jan 23, 2005 at 02:37:56PM +0100, Denis Barbier wrote:
On Sun, Jan 23, 2005 at 03:54:01AM +0100, Martin Quinson wrote:
[...]
> The next issue to solve was to that po-debconf uses the debian/po directory,
> which I thus have to share with him. I decided not to share anything and
> play an embrace&extend game (*). The second module tries to do the
> po-debconf work of extraction. It is not really tested, but it's already too
> late. Let's assume it works for now and take is as a proof of concept.
Currently po-debconf is built on top of intltool. My intention was to
replace intltool-* scripts by po4a, but to not change its user interface.
So you can do what you want with PO files, we can always change
po-debconf scripts to match your needs.
At a later stage, these wrappers may disappear to call po4a directy, but
I prefer keeping these wrappers for now.
I also think that we need to keep those wrappers, but we have to make sure
that all kind of material are extracted at the same time so that we can go
with an uniq po file and still detect obsolete strings.
If we don't, I'll have a few hundreds convertion bugs to do. Again.
I wish cdbs would be more popular.
So, I was kind of thinking about asking debconf-updatepo to also extract
NEWS.Debian material when found. It could be done by letting this script to
exec po4a when a po4a.conf file is found or so.
I'm not sure about the details. I still think we should refer all this until
after the release, but I begun this implementation anyway just to see how
difficult the code would be (and because I'm addicted to coding and my
current activity doesn't involve enough coding ;).
I don't want to hurry but to find the right way to go.
The main show stopper for now is that po2debconf cannot be written with po4a
yet (multiple translations in the translated file). For that, I need to add
a multipushline() function to the TT. It would take a string as argument,
being the code to eval() for each language. The debconf module already
create such a string, but then it evals it itself.
The TT argument passing mecanism may need to be changed for this to become
real (po_in_name needs to be a hash 'lang_code' => 'file name'). This
would
also allow TT to know about the "lang_code" in use, which is needed to
produce "<book lang=XX>" in SGML (#263733 in Debian).
And while we're are reworking this args mecanism, it would be cool if
-updatepo and -translate could use a po4a.conf file.
There may be some implications with the encoding mecanism, I'm not sure. We
may have to use several contexts (create a $self->{TT}{ascii_input} and
friends for each language).
But the bad news is that I'm really out of time: I have to build from the
scratch a 20 hours class on various technologies such as rpcgen, java rmi,
corba, ejb, c# and erlang. begining of the class in 10 days...
Mt.