Re: About translating documents (.xml/.sgml) in GNOME

[Christian Rose <menthos menthos com>]

mån 2003-02-03 klockan 02.38 skrev Bernd Groh:
> >>This, of course, (and that's the reason I really don't like this idea) 
> >>brings all the problems. If translation is done in PO-style, you have to 
> >>create new entries. Entries for which there is no original. How do you 
> >>want to handle this? Make up unique dummy-strings to be used as msgid's? 
> >>These not only have to be unique to the file, but unique to the 
> >>database, since else you cannot really use a po-database, else you'll 
> >>get all the wrong placements. Alternatively, use the translation not 
> >>only as msgstr, but also as msgid? What do you do when you have an 
> >>update to the original and try a new merge? Place a unique character 
> >>sequence in front of the translation to be able to determine the things 
> >>you have to leave out? Like the opposite of not marking it for 
> >>translation? Well, it's doable but not very nice, as far as I can see. 
> >
> >I've yet to experience such a situation where extra paragraphs are
> >needed (perhaps because I'm only experienced with translating into
> >Swedish),
> 
> Me too. In some cases it might be helpful, but I believe that often 
> there's a way to avoid it. If you are a translator, for example, who 
> likes to add a lot of new major tags, then well, maybe PO is not the way 
> to go for you. That's the reason why I said that IMO, adding new 
> paragraphs, etc. by the translator shouldn't be allowed in the first 
> place (at least not by default). I know a lot of people doing 
> cjk-translations, and none of them requires any new tags either.

Ok.


> > but wouldn't it be possible to add extra paragrahps as needed
> >in the msgstr at the appropriate places, and have the conversion tool
> >accomodate for that when merging back? An example:
> >
> >msgid ""
> >"A paragraph in the original. Foo bar veni vidi vici etc."
> >msgstr ""
> >"Ett stycke i originalet. Apa veni vidi vici osv.\n"
> >"\n"
> >"Andra stycket i originalet, osv. Kan inte skriva bra exempel."
> 
> But how does the tool know it's a paragraph you want to add? What if you 
> are currently processing an entry? Does that mean you want to add 
> another paragraph in the entry, or do you maybe want to add another 
> entry? And what if you want to add another listitem, how do you 
> distinguish? With some new tags you introduce into PO-files? I 
> personally do not like this idea at all.

Neither do I, as 1) I don't see the need for it as mentioned previously,
and 2) I would be the first one to agree it's a very ugly hack :-)
My suggestion was just meant to illustrate that these kind of issues,
should they be for real and necessary to solve, doesn't rule out po
format entirely.


> The po-approach is so good, 
> exactly because you don't have to worry about any structural 
> information.

Exactly. It lets you focus entirely on the translation and avoids the
the issues pieces of layout and structure completely; stuff that's
completely irrelevant for the actual translating in most cases. I think
we're in violent agreement here. :-)


> You simply have text-items and you translate them. IMO, 
> structural change should not be allowed, since this exactly introduces 
> an IMO disadvantage of the entire approach.
> 
> That's why I'd go two ways. PO, exclusively for documents where the 
> translation process does not incur any structural changes to the 
> document itself (which are all the documents I am working with). For 
> others, I don't think PO is (or even should be) an option. There's too 
> much change involved to the PO-method itself.

Sounds like a good strategy.

[...]
> >>Next, you will have to extend your tool (we're using kbabel), since 
> >>adding new entries is generally not supported. That requires more 
> >>engineering effort on a third-party tool.
> >>
> >>IMO, if a document is anticipated to undergo quite a few such changes, 
> >>then I don't think PO-files are a good option.
> >
> >Why? Please don't throw the baby out with the bathwater. It seems to me
> >that this is purely a design issue with an infrequent issue, and an
> >issue that the conversion tool alone needs to handle. There's no problem
> >with the po format itself here, and no problem that any format (besides
> >XML or any other markup based format) wouldn't encounter aswell. And the
> >drawbacks of translating entire markup-based documents we already know.
> 
> Huh? I am completely PRO-PO. I am simply opposed to adding any 
> structural information either in the msgid, or the msgstr. If 
> translators want to add away (which IMO doesn't have to be a necessity), 
> then PO might not be the way to go for them. I believe structure should 
> not be an issue at all when translating PO's. I don't even want to know 
> what I am translating, other than that it is text.

I think we're clearly in agreement here. It seems I misinterpreted you
in that I thought you claimed adding additional elements would be a
necessity, and hence that you, based on this, thought po format was out
of the question. I see now that this wasn't the case.


Terribly sorry for the fuzz,
Christian