xliff-comment message

Subject: Re: csprd01-27 Resource Data Module Design

From: Jörg Schütz <joerg@bioloom.de>
To: Ryan King <ryanki@microsoft.com>
Date: Fri, 19 Jul 2013 09:20:37 +0200

Hi Ryan,

Thanks a lot for the update.

The new description sounds reasonable in particular when taking intoaccount the famous "re-segmentation." It would be great if you/the TCwould consider to integrate in the specification a succinct descriptionof why you/the TC thinks that "re-segmentation" is a good idea. In doingso you should take into account the possible side effects this processmight cause on the update of already existing resources such astranslation memories, glossary entries, etc.


In your expamples, I have observed the following:

(1) When dereferences you should use the "#", e.g. <res:resourceItemRefref="#r1" />.

(2) In the code of the second example is a typo, i.e. </res:targete>which should be </res:target>

Last but not least, maybe it's time for a revision of your Germanterminology to avoid the uncomprehensible moster compounds... ;-)


Cheers -- Jörg

On July 17, 2013 at 18:40 (CEST), Ryan King wrote:

Hi Jörg,

Regarding the following comment you made during the recent XLIFF 2.0
public review:

The Resource Data module is yet another data container that specifically
can refer to external data, and might also present certain contextual
information (see Section 3.1). However, for employing this module to
provide guidance to the translator or the processing tool it might be
misplaced under the <file> element, and could certainly also useful on
the <unit> and <segment> level to provide preceding and subsequent
contextual content information. In addition, further examples should be
provided to clarify the purpose and rational of this module.

We are making the following change to the spec to address this and other
feedback:

·Allow <res:resourceData> at <file> and <unit>.

·We will not allow it at <segment> because the TC voted by ballot to
remove all modules and extensions from <segment> to help enable
re-segmentation.

·Allow <res:source> and <res:target> either to reference external
resources or to contain elements from any namespace.

The following examples will be provided in the spec:

In this example, the <reourceData> module at <file> level references
external XML that contains resource data for a user interface control.
The control is the container for the text “Load Registry Config” and
needs to be resized to accommodate the increased length of the string
due to translation. The <resourceItemRef> element contained in the
<resourceData> module at <unit> level provides the reference between
them. The name attribute of the <unit> element could serve as the key
for an editor to associate <source> and <target> text with the resource
data contained in the referenced XML and display it for modification.

<file>

   <res:resourceData>

     <res:resourceItem id="r1" mimeType="text/xml" context="no">

       <res:source href="resources\en\registryconfig.resources.xml" />

       <res:target href="resources\de\registryconfig.resources.xml" />

     </res:resourceItem>

   </res:resourceData>

   <unit id="1" name="130;WIN_DLG_CTRL_">

     <segment id="1" state="translated">

       <source>Load Registry Config</source>

       <target>Registrierungskonfiguration laden</target>

     </segment>

     <res:resourceData>

       <res:resourceItemRef ref="r1" />

     </res:resourceData>

   </unit>

</file>

In this example, the <resourceData> module at the <unit> level contains
elements from another namespace (abc), which could be displayed for
modification in an editor that understands how to process the namespace.

<file>

   <unit id="1">

     <segment id="1" state="translated">

       <source>Load Registry Config</source>

       <target>Registrierungskonfiguration laden</target>

     </segment>

     <res:resourceData>

       <res:resourceItem id="r1" context="no">

         <res:source>

           <abc:resourceType>button</abc:resourceType>

           <abc:resourceHeight>40</abc:resourceHeight>

           <abc:resourceWidth>75</abc:resourceWidth>

         </res:source>

         <res:target>

           <abc:resourceType>button</abc:resourceType>

           <abc:resourceHeight>40</abc:resourceHeight>

           <abc:resourceWidth>150</abc:resourceWidth>

         </res:targete>

       </res:resourceItem>

     </res:resourceData>

   </unit>

</file>

In this example, the <resourceData> module references multiple static
images that may be displayed in an editor to use as context while
translating or reviewing.

<file>

   <res:resourceData>

     <res:resourceItem id="r1" mimeType="image/jpeg" context="yes">

       <res:source xml:lang="en-us"
href="resources\en\registryconfig1.resources.jpg" />

       <res:target xml:lang="lb-lu"
href="resources\lb\registryconfig1.resources.jpg" />

       <res:reference xml:lang="de-de"
href="resources\de\registryconfig1.resources.jpg" />

     </res:resourceItem>

     <res:resourceItem id="r2" mimeType="image/jpeg" context="yes">

       <res:source xml:lang="en-us"
href="resources\en\registryconfig2.resources.jpg" />

       <res:target xml:lang="lb-lu"
href="resources\lb\registryconfig2.resources.jpg" />

     </res:resourceItem>

   </res:resourceData>

   <unit id="1">

     <segment id="1" state="translated">

       <source>Remove Registry Config</source>

<target>Registrierungskonfiguration entfernen</target>

     </segment>

<res:resourceData>

       <res:resourceItemRef ref="r1" />

       <res:resourceItemRef ref="r2" />

     </res:resourceData>

   </unit>

</file>

Thanks for your interest in XLIFF 2.0!

Ryan

-----Original Message-----
From: Jörg Schütz [mailto:joerg@bioloom.de]
Sent: Tuesday, July 2, 2013 9:42 AM
To: Chet Ensign; Schnabel, Bryan S
Cc: xliff-comment@lists.oasis-open.org
Subject: Re: [xliff-comment] Next steps regarding your very useful XLIFF
2.0 Public Review comments

Hi Chet and Bryan,

Many thanks to both of you for your very prompt replies, and the very
good explanation of the OASIS processes. This helps a lot in learning
and understanding the different steps to standardization of different
organization.

All the best,

Jörg

On July 02, 2013 at 15:29 (CEST), Chet Ensign wrote:

 > Hi Jörg,

 >

 > I'm Chet Ensign, the director of standards development at OASIS. I see

 > your question to Bryan and thought I would jump in with the answer.

 >

 > You asked: "How is the OASIS process with resolving comments, e.g. do

 > you need my "official" acceptance of the proposed solution(s), which

 > would be similar to the W3C process?"

 >

 > At OASIS, we ensure that there is transparency and visibility into the

 > work of Technical Committees so that stakeholders in the broader

 > marketplace can make their own decisions about the quality of the work.

 > It is up to each Technical Committee to decide whether and how to act

 > on comments received. TCs are required to acknowledge comments

 > received, to track them along with their decision on how to resolve

 > them, and to post these comment resolution logs at specific stages of

 > the process so that those providing comments can see what the TC chose

 > to do. There is no requirement that a TC obtain acceptance of a
proposed solution.

 >

 > You can find this explained in more detail in "Handling the comments

 > received during a public review"

 >
(https://www.oasis-open.org/resources/tcadmin/handling-the-comments-received-during-a-public-review).

 > Of course, TCs like XLIFF that care about the acceptance and adoption

 > of their work go beyond this to engage with those who take the time to

 > provide thoughtful feedback and seek the best possible solution.

 >

 > Thanks for providing your input to the XLIFF & let me know if you have

 > any questions on this. I'm happy to go into more detail.

 >

 > Best regards,

 >

 > /chet

 >

 >

 >

 > On Tue, Jul 2, 2013 at 5:31 AM, Jörg Schütz <joerg@bioloom.de

 > <mailto:joerg@bioloom.de>> wrote:

 >

 >     Hi Bryan,

 >

 >     Thanks a lot for your feedback. This looks very good indeed, and I'm

 >     looking forward to the revised version of the specification. And, of

 >     course, some of my comments are still open...

 >

 >     Regarding the Glossary module it will be also my pleasure to further

 >     discuss remaining issues with Ryan.

 >

 >     One question: How is the OASIS process with resolving comments, e.g.

 >     do you need my "official" acceptance of the proposed solution(s),

 >     which would be similar to the W3C process?

 >

 >     Thanks, and all the best,

 >

 >     Jörg

 >

 >     On July 01, 2013 at 23:30 (CEST), Schnabel, Bryan S wrote:

 >

 >         Jörg,

 >

 >         On behalf of the TC, I want to again thank you for the very
useful

 >         comments. As you know, we are tracking them here on our wiki

 >
https://wiki.oasis-open.org/__xliff/XLIFF%202.0%20Public%__20Review%20submitted%__20comments%20tracker
<https://wiki.oasis-open.org/__xliff/XLIFF%202.0%20Public%25__20Review%20submitted%25__20comments%20tracker>

 >

 > <https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20sub

 > mitted%20comments%20tracker>

 >

 >         In an effort to not fill your inbox with individual replies, I

 >         hope you

 >         don’t mind that I will reply to them, but comment number, in

 >         this single

 >         email.

 >

 >         Several were simply accepted at face value, and will be

 >         implemented (as

 >         documented on the wiki). Also, you and Yves have continued your

 >         discussions publically on the comment list.

 >

 >         I will address the remainder here.

 >

 >         csprd01 015 - Processing Requirements for XML PIs: This was also

 >         called

 >         to our attention in comment 013. We had an electronic ballot

 >         (https://www.oasis-open.org/__committees/ballot.php?id=2432

 >         <https://www.oasis-open.org/committees/ballot.php?id=2432> ),

 >         and voted

 >         to say the Processing Instructions SHOULD be preserved.

 >

 >         csprd01 018 - Structure and Structural Elements: Glossary

 >         module: This

 >         is also covered in comment 024. We are very close to resolving

 >         this. We

 >         discussed this at the Face to Face meeting in London and came to

 >         consensus

 >
(https://lists.oasis-open.org/__archives/xliff/201306/__msg00009.html

 >
<https://lists.oasis-open.org/archives/xliff/201306/msg00009.html>),

 >         We

 >         then held a ballot

 >
(https://www.oasis-open.org/__apps/org/workgroup/xliff/__ballot.php?id=2438

 >
<https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438>)

 >         and voted to remove Glossary from File. In summary: A] make
Glossary

 >         Module more expressive: 1) make <glossentry> extensible by both

 >         elements

 >         and attributes, 2) make children extensible by attributes, 3)

 >         Introduce

 >         id to be able to reference back from <mrk type="term">; B] Remove

 >         <glossary> from <file>

 >

 >         Ryan King is the owner of this topic and will be happy to follow

 >         up if

 >         you have further questions.

 >

 >         csprd01 025 - Format Style Module: I am grateful for this good

 >         advice. I

 >         will add a robust, more sophisticated example that supports
images.

 >

 >         csprd01 026 - Metadata Module: This is also tied to comment 048.

 >         I think

 >         it is very good advice. I will add the example you suggest.

 >

 >         Prior to the second public review I will send you a link to the

 >         improved

 >         specification that incorporated the comments you sent, and I

 >         will ask

 >         for your opinion of the resolution of your comments.

 >

 >         Thank you,

 >

 >         Bryan

 >

 >

 >     --

 >     This publicly archived list offers a means to provide input to the

 >     OASIS XML Localisation Interchange File Format (XLIFF) TC.

 >

 >     In order to verify user consent to the Feedback License terms and

 >     to minimize spam in the list archive, subscription is required

 >     before posting.

 >

 >     Subscribe: xliff-comment-subscribe@lists.__oasis-open.org
<mailto:xliff-comment-subscribe@lists.__oasis-open.org>

 >     <mailto:xliff-comment-subscribe@lists.oasis-open.org>

 >     Unsubscribe: xliff-comment-unsubscribe@__lists.oasis-open.org
<mailto:xliff-comment-unsubscribe@__lists.oasis-open.org>

 >     <mailto:xliff-comment-unsubscribe@lists.oasis-open.org>

 >     List help: xliff-comment-help@lists.__oasis-open.org
<mailto:xliff-comment-help@lists.__oasis-open.org>

 >     <mailto:xliff-comment-help@lists.oasis-open.org>

 >     List archive: http://lists.oasis-open.org/__archives/xliff-comment/

 >     <http://lists.oasis-open.org/archives/xliff-comment/>

 >     Feedback License:

 > http://www.oasis-open.org/who/__ipr/feedback_license.pdf

 >     <http://www.oasis-open.org/who/ipr/feedback_license.pdf>

 >     List Guidelines:

 > http://www.oasis-open.org/__maillists/guidelines.php

 >     <http://www.oasis-open.org/maillists/guidelines.php>

 >     Committee:

 > http://www.oasis-open.org/__committees/tc_home.php?wg___abbrev=xliff

 >     <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff>

 >     Join OASIS: http://www.oasis-open.org/__join/

 >     <http://www.oasis-open.org/join/>

 >

 >

 >

 >

 > --

 >

 > /chet

 > ----------------

 > Chet Ensign

 > Director of Standards Development and TC Administration

 > OASIS: Advancing open standards for the information society

 > http://www.oasis-open.org

 >

 > Primary: +1 973-996-2298

 > Mobile: +1 201-341-1393

 >

 > Check your work using the Support Request Submission Checklist at

 > http://www.oasis-open.org/committees/download.php/47248/tc-admin-submi

 > ssion-checklist.html

 >

 >

 > TC Administration information and support is available at

 > http://www.oasis-open.org/resources/tcadmin

 >

 > Follow OASIS on:

 > LinkedIn: http://linkd.in/OASISopen

 > Twitter: http://twitter.com/OASISopen

 > Facebook: http://facebook.com/oasis.open

--

This publicly archived list offers a means to provide input to the OASIS
XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and to
minimize spam in the list archive, subscription is required before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
<mailto:xliff-comment-subscribe@lists.oasis-open.org>

Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
<mailto:xliff-comment-unsubscribe@lists.oasis-open.org>

List help: xliff-comment-help@lists.oasis-open.org
<mailto:xliff-comment-help@lists.oasis-open.org>

List archive: http://lists.oasis-open.org/archives/xliff-comment/

Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf

List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff

Join OASIS: http://www.oasis-open.org/join/

Follow-Ups:
- RE: csprd01-27 Resource Data Module Design
  - From: Ryan King <ryanki@microsoft.com>
- RE: [xliff-comment] Re: csprd01-27 Resource Data Module Design
  - From: "Yves Savourel" <yves@opentag.com>

References:
- csprd01-27 Resource Data Module Design
  - From: Ryan King <ryanki@microsoft.com>