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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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


Subject: RE: [xliff-comment] Re: A few questions about XLIFF standard


Hi Elena,

I'll try to answer as best as I can:

> 1. Some declared tags have the ‘clone’ attribute which 
> indicates whether this tag can be copied several times or not. 
> But what about tags without this attribute: <bpt>, <ept>, etc.?
> Are they ‘clonable’ by default?

The clone attribute exists for <g>/<x>/<bx>/<ex> not for the <bpt>/etc. ones: that was an oversight of the specification (few implementations were using that attribute and nobody caught the issue).
This has been fixed in 2.0.


> 2. It is also not clear why the <bx/> tag has the ‘clone’
> attribute, but <ex/> does not have it? 

<bx/> represent the start part of the paired tag and <ex/> the end part, so end part has the same property as always the start part.


> a. What is the purpose of this tag? Could you please provide 
> an example which shows its usage? 

<bx/> is the equivalent of <bpt> and <ex/> is the equivalent of <ept>. The difference is that <bpt>/<ept> normally hold the native code in their content (e.g. <bpt>{b </bpt> and <ept>}</ept>). <bx/> and <ex/> are for when you don't store the native code in the XLIFF document.


> b. Should the related <bx/>/<ex/> tags be within one <source> 
> element or it is allowed to have them occur even in 
> different <trans-unit>-s?

They should be in the same trans-unit.


> 3. Could  a <target> element contain tags which are not
> present in the corresponding <source> element? 

Yes.


> Here is an example (tags not present in <source> are 
> highlighted): 
> <source>The <x id="1" />formatted<x id="2" /> <bpt id="1" 
> ctype="italic">{}</bpt>sentence<ept id="1">{}</ept> <bpt 
> id="2" ctype="bold">{}</bpt>with<ept id="2">{}</ept> 
> two fields.</source>
>
> <target>The <x id="1" />formatted<x id="2" /> <bpt id="1" 
> ctype="italic">{}</bpt>sentence<ept id="1">{}</ept> <bpt 
> id="2" ctype="bold">{}</bpt>with<ept id="2">{}</ept> two 
> <bpt id="3" ctype="italic">{}</bpt> another <ept id="3">{}</ept> 
> <bpt id="4" ctype="bold">{}</bpt>fields <ept id="4">{}</ept>new 
> <x id="3" />text<x id="-1" />.</target>
>
> If this situation is possible and is considered valid, can 
> you please tell us whether this behavior applies for all 
> XLIFF tags or for a subset of them only? 

I have not run a checker against it, but I think it should be valid. The issue will be with the extra inline codes such as <x>/<bx>/<ex> because they have no corresponding native code. Some tools allow to duplicate the codes (so they re-use the native codes of the original one). But 1.2 has no specified behavior for all this. That is one of its shortcomings and one of the reasons why 2.0 is worked on.


> We would also like to ask you to recommend a reliable 
> tool for XLIFF validation, if it is possible.

XLIFFChecker is good: http://www.maxprograms.com/products/xliffchecker.html


I hope this helps,
-yves




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