[xliff-tools] Another question on PO and XLIFF

[Karl Eichwalder]

Asgeir Frimannsson <asgeirf at redhat.com> writes:

> If you do some testing with using /* xgettext: no-wrap */, you'll see that 
> they always produce the same result, only different output layout. ..And 
> adding the --no-wrap command line flag when using e.g. xgettext is the same 
> as putting the no-wrap comment in all translation units - it only affects the 
> layout of the PO file, not the actual content.

Okay, using no-wrap in source files you can protect a message from being
wrapped.

> You say, no-wrap "signals line-breaks which are to be kept" - does this mean 
> it would do anything with the "\n" characters - or do you mean that this is 
> two lines?:
> msgid "this is line 1"
> "this is line2"
>
> And how would a translator use no-wrap?

xgettext never ever eats or moves "\n" characters.  The only thing it
does is breaking lines if necessary.  The example you posted is equal
to (with or without the ,no-wrap flag added):

msgid "this is line 1this is line2"

For the translator, the ,no-wrap flag is nothing more than a comment.

> Yeah, that is an issue with replacing '\' + 'n' with newline in XLIFF - but 
> only a cosmetic issue affecting the layout of the PO file - and not the 
> intended Translation Unit. But you have a good point when dealing with XML 
> files. Current xml/sgml-po filters does not honour the format of PO - in that 
> they treat:
>
> mgsid "<line1>text</line1>"
> " <line2>text</line2>"
>
> as meaning "<line1>text</line1>\n <line2>text</line2>" when they should be 
> writing
>
> mgsid "<line1>text</line1>\n"
> " <line2>text</line2>"
>
> to produce that result.

As far as the .po file format is concerned, "...</line1>\n <line2>..."
and "...</line1>\n" " <line2>..." are the same.  It is arguable, whether
they are allowed to add the "\n" at all.  If the msgid lacks the
,no-wrap or ,c-format flag, adding "\n" characters might be okay.  As we
know, some elements are white-space sensitive and, happily, Danilo's
po2xml tools (part of the gnome-doc or gnome-doc-tools module) already
honors this matter of fact up to some degree.

> - And this (intended) 'design-flaw' makes it much more 
> convenient to translate XML files in tools such as KBabel - and that's 
> perfectly fine.

Yes, as long as the the tools knows something about the elements
that are defined with the space attribute set to 'preserve'.

> How can we honour no-wrap in XLIFF? First of all, the most advanced PO tools 
> doesn't honour it (e.g. kbabel word-wrap text instead of providing a 
> scrollbar [or a visual word-wrap marker] to see the whole line), so should 
> we? Say we should: Doesn't xml:space='preserve' provide a way for XLIFF 
> editors to indicate to the users that lines are not word-wrapped?

Yes, for XLIFF please make use of xml:space='preserve'.

> The editor can happily word-wrap source/target (or consume extra
> whitespace) when xml:space is not preserve (good for xml based
> formats), but honour whitespace otherwise.

Yes.

> In addition, to honour the original intent of 'no-wrap', the filter can 
> provide the same flag when back-converting, using the same rules as gettext.

Yes ;-)

-- 
Key fingerprint = B2A3 AF2F CFC8 40B1 67EA  475A 5903 A21B 06EB 882E