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

[Bernd Groh <bgroh redhat com>]

Christian,

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

> 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. The po-approach is so good, 
exactly because you don't have to worry about any structural 
information. 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.

> The conversion tool would treat the single "\n" on a line by itself as
> the start of a new paragraph. Then you have solved the "translations
> need extra entries" problem (here illustrated by adding an extra
> paragraph), if I understand the description of the problem correctly.
> And you've also specified in which order and place the extra entry
> should occur. I doubt that adding anything besides extra paragraphs will
> be a common action.

I personally don't like this idea at all. And it doesn't solve the 
"translations need extra entries" problem either, since Malcolm 
rightfully said that sometimes, it might be helpful for the translation 
to add another step, i.e. listitem, or another footnote. I do not 
believe we should start to accomodate a few of them. Either we do it, or 
we don't. And I believe we shouldn't at all, not with the PO-method, 
exactly because it takes away the whole reason why I am using PO in the 
first place. I want to be able to translate, without having to worry 
about any structural layout of the document itself.

> > 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'd rather convert the 
> > whole thing into something that gives me something a little more 
> > WYSIWYG.
> >    
>
> Docbook isn't wysiwyg to begin with. ;-)

Neither is HTML, but we've got "WYSIWYG"-editors for HTML too. ;-)

However, I do not want my SGML DocBook documents in WYSIWYG, I want the 
text, and nothing but the text, in PO-Format. I don't want to care about 
what the structure looks like, I don't even want to know what a 
paragraph is. :-)

Cheers,
Bernd

--
Disclaimer: http://apac.redhat.com/disclaimer