Re: RFC: How to handle nested tags in xml2po?



Hi Funda,

Thanks for sharing your thoughts.

Today at 12:43, Funda Wang wrote:

> Danilo> xml2po sometimes needs to put placeholders in messages it extracts for
> Danilo> translation.  They usually end up being something like:
> Danilo> "Hello there: <placeholder-1 />"
> Danilo> Now, translators don't have too much clue on what is all this about.
> Danilo> With release notes, some even tried translating this tag name. 
> Then, a translator-note (#.) should be put before msgid. 

They should not be automatically provided this way IMO.  #. comments
are provided by documentation writers, and are completely supported
with xml2po.

I can extend them, but I don't like this approach.

> Or, why couldn't we just use the something like "%s"? I think most
> translators are familiar with %s already.

(The "big problem" would be here even if we go for "%s" approach:
all existing translations would have to be updated)

How about:

<para>This is blah<footnote><para>First footnote</para></footnote> and
foo<footnote><para>Bar footnote</para></footnote>.</para>

becoming:

"This is blah%s and foo%s" (ugly in my opinion, not very clear either)
vs.
"This is blah<footnote-1/> and foo<footnote-2/>"

If I go for "%s" approach, I'd also need to support POSIX-style
parameter reordering %1$s, %2$s, which complicates matters a bit.
Though, I can live with that if everybody else agrees, but first see
below.

(this means that I'm not at all opposed to using %s, but there are
more caveats below)

> Danilo> I'm considering changing this to include real tag name instead:
> Danilo> "Hello there: <itemizedlist-1 />"
> I don't like it, for the reasons you've listed. The main use of xml2po
> is to reduce the hard work of xml tags for the translators, rather than
> providing an easy way to translate documentations.

That should be the same.  Some tags simply can't be avoided (markup,
inline tags, such as those indicating emphasis), so I'm not so sure
it's wise to trick translators that they don't need to worry about
markup: all of these messages must be well-formed XML, so you *can't*
translate it to something like:

  "Since five < ten, I win"

We need translators to know that they're working on XML fragments,
each of which should be well-formed, and within certain restrictions,
should follow DocBook definition.

> Danilo> Now, please state your opinion on the issue, and whether you already
> Danilo> have used xml2po to translate some of the documentation (because I
> Danilo> think this will largely influence the response :). 
> I've already use xml2po in Mandrakelinux documentation[1] for two months.
> The biggest problem on placeholder issue the inconsistent behavior. i.e,
> some <para> within <footnote> are replaced with placeholders, others are
> not, which is very strange.

If that happens, I'd consider that a *bug*!  There were some bad bugs
(as you know, since you reported them :), but I hope they are all
fixed now.  If not, just go ahead and report more bugs, I should be
faster in fixing them now.  I fell pretty confident about what's in
xml2po CVS now, but I've been wrong before :)

Also, I'm certain that every <para> should be a separate message, and
you shouldn't ever see <para> appearing in any original message.  If
that happens, it's again a bug, and please report it. 

Also note that DocBook is quite a mess, and one can do too many things
with it for one's own good (basically, everything is allowed).  While
xml2po tries to do it's best, it's sometimes impossible to technically
decide what's actually "best".

> [1] http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/doc/po

Can I ask you for a favour here?  Since I can't install all the
required software from Mandrake packages, it's hard for me to get all
the files I'd be interested in: original, untranslated XML files,
untranslated POT and translated PO files, and resulting translated XML
files.  I want to use these as regression tests, so I'd love it if you
can tar-n-gzip 'em up all together for me, and send them to me privately?

Thanks,
Danilo


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