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] Follow up on your "Basic structure" comment, part [3]

Hi Chase,


There is no formal recommendation regarding the element contents should be rendered via FS, other than which elements allow @fs and @subFs.


Perhaps hints could be derived from the table of allowable attributes and the (recently made more robust) example.


I think in this case we struck the appropriate level of informality, given the fact that we specify that FS is explicitly not meant for roundtripping, and that we probably cannot imagine all the rendering use cases that the community will discover.


That said, I think this is a very good candidate for a future OASIS TC Note, once the use cases begin to be clear, and in the case that the community can benefit from a set of evolved best practices.


I hope this is useful. Please feel free to let me know if you have more questions or comments. And thanks again for the helping us with your very useful feedback.






From: Chase Tingley [mailto:chase@spartansoftwareinc.com]
Sent: Sunday, August 18, 2013 5:12 PM
To: Schnabel, Bryan S
Cc: xliff-comment@lists.oasis-open.org
Subject: Re: [xliff-comment] Follow up on your "Basic structure" comment, part [3]


Hi Bryan,


Thanks for your response.  I can see the utility in what you are saying.


Does XLIFF 2.0 make any recommendation regarding what element contents should form the basis for a rendered preview?  (Apologies if this is an obvious question; I'm a couple months removed from a thorough reading of the draft, and didn't see one when I glanced through it just now.)




On Tue, Aug 13, 2013 at 4:00 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

Hello Chase,


As you know from recent emails from us the XLIFF TC is working hard to incorporate all the great feedback, including yours, we received during the public review period for XLIFF 2.0. Once again, my sincere thanks for the especially useful feedback you submitted. We are quite sure feedback like this will ultimately lead to a better XLIFF 2.0.


I would like to address a point you made in your comments (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html) regarding the Basic structure, specifically "The notes element ( allow formatting style information (@fs:fs, @fs:subFs).  Why?".


We took a good hard look at the Format Style module, and its role relative to the whole XLIFF lifecycle, and its applicability to  part of the XLIFF file other than translation content. Your question (as I read it) is around why we would want to include information in a note in an HTML preview. It is our thinking that there could actually be value in including notes in the HTML preview. In some cases they could aid the reviewer in understanding some tricky aspect of the content or the workflow. The really good think about @fs in this context is that it is explicitly not meant for aiding in a roundtrip, and is only meant to provide a just in time preview. Therefore we see little risk that it would be (legally) abused, or that it would cause any issues around interoperability.


I hope this makes sense to you and that our thinking is not counter to your thoughts.


Please feel free to comment back if you have further feeling on this issue.


You are very welcome to follow the tracking of this and all the public review comments on our wiki tracker (this note is refers to comment #30): https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker


And again, sincere thanks for helping us to make XLIFF 2.0 a better standard.






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