Re: xml2po



El lun, 07-06-2004 a las 00:11, Danilo Segan escribió:

> > Working with kbabel has a nice feature: is docbook aware so it detects
> > the markup segmentation and can translate automatically segments if they
> > are collected in the glossaries you can use.
> 
> That wouldn't work too well for many languages, and surely not for
> Serbian :)  So, I believe it's better to make it harder for some, yet
> possible for everyone :)

Maybe I'm not explained well or I don't understand you. What is the
problem with segmentation? Indeed one of the main problems in the
translation efforts is the segmentation. If you have it solved for free,
why not to use it? :-?

> > Sorry, I can't reproduce it... the problem is with tha main file, but
> > with the same file but different directory... it works! I'm amazed.
> 
> Ok, if anything comes up again, do send me all the output and
> relevant files (just tar 'em up and gzip 'em and send them privately
> to me if they're bigger than 10k or something).

I'll do.

> > SUGGESTION: The cli options are confusing IMO. I don't have a proposal
> > yet but maybe could be interesting to remove the gettext operations to
> > simplify it. Maybe could be better to decompose into simplier tools or
> > add actions like cvs does.
> 
> Well, I built options step-by-step, maintaining backwards
> compatibility at all steps.  The idea is that regular users
> (i.e. translators) won't even need these options: it should be
> integrated into documentation build system (gnome-doc-utils is all
> about it and shared stylesheets), and everything should be done
> behind the scenes.  Just like translators don't need to know
> intltool-merge options in order to make use of intltool -- it works
> transparently and in the background.

I know is a must to simplify the volunteering work. ATOH tools should be
simple as unix tradition recommends. If the tool is for moving data
xml<->po should do only this. New simplify shells should be over it,
maybe creating a new wrapper, maybe with a very easy to use Makefile,
etc. In my experience is better to do in that way because we are in a
methodological change for maintaining doc translations and we need some
time fighting with the new tools to find what and how should be done and
what not.

> Of course, any suggestion on this is very much welcome.  In practice,
> I recommend using only three variants of the command:
>   xml2po -o template.pot file1.xml file2.xml # extract PO template
>   xml2po -u sr file1.xml file2.xml           # update translation
>   xml2po -p sr.po -o sr/file1.xml file1.xml  # merge translation

But is a bit messing: -o works sometime for .pot and others for xml. The
parameters of the second use don't seem to be so similar the third. This
is what I tried to say before. It not seems to be a so much coherent
interface. Maybe this is the reason the poxml author choose to write
several simpler tools :-?
 
> > SUGGESTION: Do you know the KDE's poxml tools? It have a really
> > convenient tool called split2po. It let to create a translated po file
> > from both xml source and translated. Then you can update the previous
> > translation with a new xml source. It's the way to reuse/update legacy
> > translations.
> 
> That's planned, and it shouldn't even be hard if we make some
> assumptions:
>   1. There's the original untranslated XML available (so we can
>      assume that messages can be extracted in the same order)

Right.

>   2. There was no reordering of the "messages" (whatever it is for
>      the desired mode) in the translation as compared to original

Not sure to understand you. With split2po the two files are expected to
have the same XML structure. Is this what you mean?

> Then, we can simply rerun the xml2po machinery on each file, and
> merge the two lists of messages one-for-one based on the order of
> appearance.

Yes. If I'd have a little bit programming skills I've just tried to do
by myself :-D

(I've asked a friend to write it. I'll inform you if he release
something.)

> It will surely be done before first stable release, since all
> translated Gnome documentation shouldn't be wasted.

Great!

Is good to see you have clear targets for xml2po :-D

-- 
        A.Ismael Olea González

        mailto:ismael olea org  http://www.olea.org
        http://aduaneros.olea.org, la ONG sin futuro.

        El mundo debe empezar a tener miedo a un planeta OLEA



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