Re: Doc Translations



danilo gnome org (Danilo Åegan) writes:

To avoid a wrong impression I must emphasize again that you are on a
very right train.  I appreciate your work a lot, I can only judge from a
translator's POV and as one who play with SGML and XML from time to
time.

> Yes, but that conflicts with the goal I mentioned earlier.  We've got
> one XML document split into several .xml files.  We want that entire
> document to be translated using *one* PO file, and later merged
> back.  If I let libxml2 replace entities automatically, DOM tree I
> get would be as if it was all in one file, and I won't be able to
> remerge them file at a time (since I modify in-memory DOM tree, and
> simply let libxml2 serialize it later on, thus ensuring correctness).

If nothing help, escape the entities early (&app; -> &app;), then it
should be possible to them later on.  To understand and talk about these
issues, I'll have to study an example more closely.

Before I forget another issue: Don't drop surrounding tags entirely;
esp. keep short tags like <title> or <caption> as comments:

    #. tag: title
    msgid "Installing Gnome"
    msgstr ""

    #. tag: caption
    msgid "Gnome Desktop"
    msgstr ""

> It's very hard to determine the sort of text contained in the
> entity.  It can be anything from simple text, well-formed XML,
> to non-well-formed XML.  It's a pain.  So, we'd probably need to
> assume it's at least well-formed XML.

Yes.  Reminds me...  We need a validator that can check the XML syntax
as encapsulated in the PO format.  If this is impossible (I'm inclined
to assume it), after conversion back into the XML format the validator
must provide a reference to the PO file as well.

> The simplest way to achieve this is to simply let translators add
> DTD extensions they wish themselves.  Eg. have something like:
>
> #. Translators: define any other entities you wish to use here
> msgid "<!ENTITY app "Bug Buddy">\n"
> msgstr ""

Yes, something along these line I have had in mind.  And yes, msgfmt
should learn to do some basic XML checking; it can derive the
surrounding tag from the comment I proposed above.

> This was the other way around: we have multiple XML files joined
> together using SYSTEM entities.  We want translations from single PO
> file with translations to go into multiple XML files which don't have
> DTD's and stuff.

It is not difficult to wrap the DTD stuff around the separate XML files
temporarily.  IIRC, using osx (from OpenSP) it is possible to expand
only soem types of entities.  Maybe, it is possible to use a tool liek
osx as a preprocessor.

> So, what would be the best for *translators*? Allow them to define
> DTD themselves?

Yes, and it might be the best to keep it separate from the PO file.
>From the translator's POV that's just a macro definition file; happily,
the syntax is not that clumsy:

<!ENTITY app "Bug Buddy">

> The current behaviour is what seems most sane to me in the sense that
> it works for everybody (every language), without complicating it too
> much.

Yes, it surely will work that way as well.

Another important issue is to show the user a diff in case a fuzzy entry
was produce while merging.  I always thought it could not be that
difficult to add either the previous (old) string to a fuzzy entry in
the PO file or a (w)diff output (using #| as a comment marker for the
old content):

    #. tag: title
    #, fuzzy
    #| Installing Gnome
    msgid "Installing GNOME"
    msgstr "Gnome installieren"

or wdiff like:

    #. tag: title
    #, fuzzy
    #| Installing [-Gnome-] {+GNOME+}
    msgid "Installing GNOME"
    msgstr "Gnome installieren"

The next step would be enhancing our PO file editors to display this
nicely.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)


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