OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff-omos] Content of source/target


Hi Yves,

+1 for this suggested approach.  I wanted to make a few comments about the individual fields.

For whitespace preservation, I would like to see if we can get away with just specifying that JLIFF always preserves whitespace.  The xml:space behavior is an XML-ism that causes, in my experience, a certain amount of incompatibility due to implementation error.  Is there a downside to this?

The order attribute is difficult to work with in its current form.  A more intuitive way to represent that use case might be an explicit mapping from sources to targets, but this would require a pretty big shake-up to the unit structure, and the use case is obscure.

For source/target language, this goes back to our discussion on during the March 28 call regarding inheritance.  During that call David was expressing concern about the possibility of multiple source/target languages being expressed in a single unit, and was trying to think through the markup needed to prevent that.

I've always found this part of the XLIFF 2.0 spec weird, because although the format is clearly intended to be bilingual (Section 4: "XLIFF is a bilingual document format"), there is no language I'm aware of in the spec that prevents individual <target> elements inside a single <unit> from having different xml:lang values.  (This constraint does exist on the description of the <source> and <target> elements in the resource module in section 5, but not on the core elements!)

So if we need to preserve that flexibility, then I think we're trapped with putting it in the subunit as you suggest.  If there is some way we can get away with saying that within a single unit there can be only one language pair, we would have other options, but I'm not sure that's possible while maintaining XLIFF compatibility.










On Sun, Apr 30, 2017 at 4:57 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

After more tests, it definitely seems it would make implementations a lot easier to move the four fields: source-language, target-language, preserve-white-space, and target-order which are distributed in <source> and <target> in XLIFF to the segment/ignorable (sub-unit) in the object model:

 

·       This would allow source and target to use the same interface and implementation.

·       That would not prevent the XLIFF output

·       The JLIFF source and target objects could be just an array of text/tags like in the current example, without any other fields.

 

Thoughts?

 

 

Yves Savourel
Localization Solutions Architect
| t: 303.951.4523 | f: 303.516.1701 | ENLASO®

 

From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Sunday, April 30, 2017 3:56 PM
To: 'XLIFF OMOS TC' <xliff-omos@lists.oasis-open.org>
Subject: [xliff-omos] Content of source/target

 

Hi all,

 

Looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-example3-0.9.3.json

 

We have:

 

"source": [ { "text": "Quetzal" } ]

 

But shouldn’t that be the content set as a separate object in “source”?

Something like:

 

"source": {

  "cnt": [

    {

      "text": "Quetzal"

    }

  ]

}

 

The reason being that both source and target can have an xml:lang and/or an xml:space field in addition to their content.

Even if we decide that the xml:space field applies always to both and could be set on the parent sub-unit, we cannot do this for xml:lang, which is mostly set with different values. Or we would have to carry two sub-unit-level fields instead (e.g. srcLang and trgLang), which may be better.

But even in that case, target has also an order field in addition to its content.

I suppose that field could be also carried at the sub-unit level.

 

Cheers.

 

 

Yves Savourel
Localization Solutions Architect | ENLASO®
4888 Pearl East Circle | Suite 300E | Boulder | Colorado 80301
t:
303.945.3759 | f: 303.516.1701
An ISO 9001:2015 certified company

 

Confidentiality Notice
The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]