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: csprd01-27 Resource Data Module Design


Thanks Jörg for the reply and thanks for catching the typo. 

As for German terminology, I can get by, but I'm not a native speaker, so I usually mine an internal terminology database we have. Please feel free to suggest alternate translations for me to use in the specification :)

Thanks,
Ryan

-----Original Message-----
From: Jörg Schütz [mailto:joerg@bioloom.de] 
Sent: Friday, July 19, 2013 12:21 AM
To: Ryan King
Cc: xliff-comment@lists.oasis-open.org
Subject: Re: csprd01-27 Resource Data Module Design

Hi Ryan,

Thanks a lot for the update.

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

In your expamples, I have observed the following:

(1) When dereferences you should use the "#", e.g. <res:resourceItemRef ref="#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 German terminology 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%20
> submitted%__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=243
> 8>)
>
>  >         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/
>





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