Re: xml2po



El sáb, 05-06-2004 a las 19:53, Danilo Segan escribió:


> Hi Ismael,
Hi!


> > I've got some questions/suggestions for you:
> 
> Rock -- xml2po is currently still new, and I do need questions and
> suggestions.  Thanks for checking it out.
Great :)


> > SUGGESTION: when creating a po file, should be a gettext header output
> > for adding credits and charset definition.
> 
> I was basically just lazy to do that: I'll add that as well (actually,
> Emacs po-mode adds the header automatically if it's missing, with all
> the appropriate data, so I imagined other PO editors do it as well --
> guess I was wrong :).
> 
I think is better to work in the most standard way possible.

> > SUGGESTION: add an option to change the output charset (you know, for
> > being able to use latin1 instead of utf8), I suppose it should be very
> > easy to do with libxml2.
> 
> Sure, though I don't consider it a top priority (if someone insists,
> "iconv" is just a command away; yeah, there're entity encoding issues
> remaining, so such an option would be useful). 
> 
Yes, and remember the charset declaration on the gettext metadata. Using
iconv/recode could work for the content but no with this.

> > SUGGESTION: I'm very interested in your docbook "mode". Is it finished?
> 
> Nope, it's not yet finished.  I just made up a list of tags based on
> the Quick Reference list I found for DocBook tagging.  It could
> surely use a lot of love.

Maybe you can reuse the tag classification I show you in my tidy conf
file. I don't study what convention used the KDE's poxml people (could
be but I think you can start using the empy-tags and inline-tags as
«final» as you say and discard the blocklevel and the pre-formated ones.


> "Final" marks are those which will direct all it's content in a
> separate gettext message: i.e. if <para> is "final", it's going to be
> separated into a single message in PO file, whereas it would
> otherwise be recursed like everything else
> (i.e. "<para><strong>This </strong><em>works.</em></para>" would
> otherwise output two messages: "This " and "works." -- you can see a
> pattern here, and this is with "automatic" detection).

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.

[indenter]

> I'll look into all of these when my exams are over -- sorry for
> lacking the time to do it right away -- I really do appreciate your
> input!

Don't worry. Is a nice feature but it can wait.

> > OBSERVATION: did you realized that xml2po crashes with the Evolution
> > help?
> 
> No, and I cannot reproduce it: can you please send me the relevant XML
> file and PO file (your translation, if the crash occurs while you're
> merging it back) which is causing the crash?

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.

> I plan to do that soonish (most of the stuff is already there,
> there's a bit of polish to do, just like you noticed), and to name
> that version 1.1.  If gnome-doc-utils doesn't come up with a tarball
> soon (it should get one in Gnome 2.7 release cycle, which has just
> started), I'll resume standalone releases.

Great.

I have two new comments:

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.


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.



-- 
        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]