On Wed, Jun 10, 2009 at 5:31 PM, F Wolff<[email protected]> wrote:
> Op Wo, 2009-06-10 om 08:11 +1000 skryf Asgeir Frimannsson:
>> On Wed, Jun 10, 2009 at 2:42 AM, F Wolff <[email protected]>
>> wrote:
>>         Op Ma, 2009-06-08 om 11:04 +0800 skryf Aijin Kim:
>>         > Thank you Friedel!
>>         > I'll try the patch once I get it and let you know the
>>         result.
>>         >
>>         > Thanks,
>>         > Aijin
>>
>>
>>         Hallo Aijin
>>
>>         Did you make any change to the file? I just looked again
>>         through the
>>         specifications, and it seems that our old handling of
>>         whitespace was
>>         actually correct all along.
>>
>>         My understanding is that unless xml:space="preserve" is
>>         specified, the
>>         application can do what it wants (the XLIFF specification
>>         talks about
>>         "default white-space processing modes" of the application). In
>>         the case
>>         of xml:space="preserve" the application must do what we have
>>         been doing
>>         all along anyway. For now I think we will start to specify
>>         xml:space="preserve" more often in the files we create, but we
>>         will
>>         probably not be changing our behaviour yet, unless there seems
>>         to be
>>         good motivation.
>>
>>         Where does this file come from? My guess is that XLIFF files
>>         should
>>         always specify the spacing as they want it to be interpreted,
>>         otherwise
>>         it will be left to the application's default behaviour.
>>
>>         For reference:
>>         http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#xml_space
>>         http://www.w3.org/TR/REC-xml/#sec-white-space
>>
>>         Any comments? Asgeir?
>>
>> It's a bit of a tricky subject, have a read through this for a bit of
>> a longer explanation:
>> http://lists.oasis-open.org/archives/xliff/200802/msg00012.html
>>
>> To summarize, if translate-toolkit schema-validates the file when
>> opening, there should technically be an xml:space='default' on the
>> translation units, and whitespace should be collapsed. This was
>> however not the intent of the specification authors. However, if
>> translate toolkit doesn't validate the file against the schema, then
>> the xml parser should honour the xml:space attribute and not mess with
>> whitespace anywhere below the <file> element (unless xml:space is
>> overridden further down the DOM tree).
>>
>> Hope this helps, although I wish there was a simpler answer!
>
> But does xml:space="default" necessarily mean that the whitespace should
> be collapsed? My understanding is that it is left up to the application
> (which is not great, but it seems that our default behaviour up to now
> of preserving the whitespace and using it literally might still be the
> best choice).

Yes, this is correct. For example, some DOM parsers allow you to do
something like setPreserveWhitespace(boolean) before parsing, which
would control the whitespace handling for elements where xml:space is
not set to preserve.

cheers,
asgeir

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Translate-pootle mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/translate-pootle

Reply via email to