[xliff-tools] Another question on PO and XLIFF

[Asgeir Frimannsson]

Hi Josep,

On Tue, 3 May 2005 02:28, Josep Condal wrote:
> Hi Yves,
>
> I think that what makes sense is to provide the string and let the
> editor decide how that is presented to the user (i.e. line wrapped).
>
> Therefore, the following string:
>
> Line 1\n line 2\nLine3.\n
>
> is the one that makes sense.
>
> The only drawback is that you don't have the convenience of round-trip
> testing of filters (mentioned by Rodolfo I believe) because the cosmetic
> line wrap in the PO source is gone forever.
>
> I think that since there is no functional effect at all, maybe it does
> not make sense to try to keep it, as it is only used for the "elegance"
> of being able to re-instating the original source bit per bit, so
> probably its practical application is a mirage, and on the other hand,
> normalizing the string to its one-line form per the representation
> guide, has some benefits for the tools who have to process them, and
> will avoid mix-ups with spaces in tag boundaries (as you can see in
> Rodofo's examples).
>
> Please keep in mind that XML is to a large extent a free flow format and
> tools tend to make assupmtions in that sense, so if we avoid
> (unnecessary) line-oriented restrictions by design (ie forced by the
> representation guide), probably the implementations will simply work
> better.

Yeah, I agree with you here on the round-trip testing. It's similar to XML 
roundtrips, you can't guarantee that the container format is identical, but 
the actual content. (E.g. some XML parsers would replace myattribute="x" with 
myattribute='x' - both have the same meaning, though they use different 
quoting styles).

Similarly with PO:
msgid "hello world"
is the same as
msgid "hello"
" world"

cheers,
asgeir

>
> However, just let me add that I think that C escape characters should be
> somehow tagged, at least by default. It helps many tools downstream
> (such as spellcheckers in XLIFF-aware tools, etc) make assumptions on
> what is text and what is code more easily.
>
> Regards,
>
> Josep.
>
>
>
>
> ________________________________
>
> De: xliff-tools-bounces at lists.freedesktop.org
> [mailto:xliff-tools-bounces at lists.freedesktop.org] En nombre de Yves
> Savourel
> Enviado el: lunes, 02 de mayo de 2005 14:55
> Para: xliff-tools at lists.freedesktop.org
> Asunto: [xliff-tools] Another question on PO and XLIFF
>
>
>
> Hi,
>
> I have a new question on XLIFF representation of PO.
> The guide
> (http://xliff-tools.freedesktop.org/wiki/Projects_2fXliffPoGuideDraft2
> <http://xliff-tools.freedesktop.org/wiki/Projects_2fXliffPoGuideDraft2>
> ) does not seem to say anything about multi-line entries.
>
> msgid ""
> "Line 1\n line 2\n"
> "Line 3.\n"
>
> How this should be represented?
>
> <trans-unit xml:space="preserve">
>
> Line 1\n line 2\n
> Line 3.\n</trans-unit>
>
> Or
>
> <trans-unit xml:space="preserve">
> Line 1\n
>  line 2\n
> Line 3.\n
> </trans-unit>
>
> Or
>
> <trans-unit xml:space="preserve">
> Line 1
>  line 2
> Line 3.
> </trans-unit>
>
> ?
>
> The third seems more logical to me, but it could cause issues too, for
> example if the line-breaks are not \n but \r or \r\n (if the PO file is
> used for a non-Unix application) how would we know which type of
> line-break notation to put ack when merging.
>
> Anyhow, a section on this topic would be good to have in the Guide.
>
> Cheers,
> -yves