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] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements


Thank you Josep for pointing this out. I agree with your logic on this point. In my original example, tools aware of xy:sourceUpdate could alert a translator to review and possibly re-translate the segment whether the state is translated or initial. However, tools not aware of xy:sourceUpdate would need to rely on state alone, and therefore, your example makes more sense here.

 

From: Josep Condal [mailto:pcondal@apsic.com]
Sent: Thursday, May 30, 2013 11:21 AM
To: Ryan King; David Filip; Yves Savourel
Cc: xliff-comment@lists.oasis-open.org
Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

 

Ryan,

 

An unrelated comment to this thread (but I think that yet important to point out) is that for the second handoff, the logical state of the changed segment should be reverted back to "initial", regardless of if <target> is primed with something potentially useful (or not) for the translator. 

 

Otherwise it will not be possible for a tool to tell if it makes sense to consider the segment as really translated or not. Please note that there are no differences in attributes for the first two stages of the second handoff, and tools cannot (yet) understand natural language well enough to infer the state of the segment in the same way a human being could do it.

 

<segment state=”initial” subState=”xy:sourceUpdate”>

               <source>hello world</source>

               <target>halló</target>

</segment>

 

Regards,

Josep.

 

 


De: Ryan King [mailto:ryanki@microsoft.com]
Enviado el: jueves, 30 de mayo de 2013 19:15
Para: David Filip; Yves Savourel
CC: xliff-comment@lists.oasis-open.org
Asunto: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

>> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

 

I’m not totally convinced that it MUST be dropped. As an example:

 

First handoff:

 

<segment state=”initial”>

               <source>hello</source>

</segment>

 

<segment state=”translated”>

               <source>hello</source>

               <target>halló</target>

</segment>

 

Second handoff:

 

<segment state=”translated” subState=”xy:sourceUpdate”>

               <source>hello world</source>

               <target>halló</target>

</segment>

 

<segment state=”translated” subState=”xy:sourceUpdate”>

               <source>hello world</source>

               <target>halló veröld</target>

</segment>

 

<segment state=”reviewed” subState=”xy:sourceUpdate”>

               <source>hello world</source>

               <target>halló veröld</target>

</segment>

 

 

If I understand ms:sourceUpdate, I could clear subState after setting the state to “reviewed”, however, if I don’t understand ms:sourceUpdate, couldn’t I treat it like any other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated and reviewed.  The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype is used, the attribute type must be specified as well.

 

 

From: David Filip [mailto:davidf@davidf.org]
Sent: Thursday, May 30, 2013 5:02 AM
To: Yves Savourel; Ryan King
Cc: xliff-comment@lists.oasis-open.org
Subject: Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

 

I think the update/drop of sub* should be enforced throughout the sub* attributes..

 

If you own the subtype, it is easy to know the invisible update, I would not be worried with that.

The PR is important to those who do not know the predefined subproperties.

If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed..

 

 

David Filip, Ph.D.
=====================
cellphone: +353-86-0222-158
mailto:davidf@davidf.org

 

On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote:

I tend to agree.

 

 

From: Ryan King [mailto:ryanki@microsoft.com]
Sent: Wednesday, May 29, 2013 11:19 AM
To: Yves Savourel; xliff-comment@lists.oasis-open.org


Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

 

All of the sub properties already have the a similar PR to the following:

 

·        If the attribute subtype is used, the attribute type must be specified as well.

 

So if your statement  “I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).” applies to subType in <mtc:matches> shouldn’t it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is enough to show the relationship?

 

Ryan

 

 

 

From: Yves Savourel [mailto:yves@opentag.com]
Sent: Wednesday, May 29, 2013 3:47 AM
To: xliff-comment@lists.oasis-open.org
Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

 

I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to the type (it complements it).

In your example, if a type can have the same subtype value you can have an “invisible” update: the updated subtype value simply happens to have the same value as before.

 

-ys

 

From: Ryan King [mailto:ryanki@microsoft.com]
Sent: Wednesday, May 29, 2013 2:05 AM
To: xliff-comment@lists.oasis-open.org
Cc: xliff@lists.oasis-open.org
Subject: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements

 

B.1.3.7 subtype processing requirements state:

 

If the attribute type is modified, the attribute subtype must be updated or deleted.

 

Is this always the case? What if I have a two types, e.g. “tm” and “mt”, that have the same subType? If my type changes from “tm” to “mt” there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes…

 

2.3.1.34 subType

2.3.1.35 subState

D.1.2.2 subFs

 

…do not have this requirement.

 

Thanks,

Ryan

 

 

 



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