OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all, to get this going I looked at the archives on what we discussed. One question I have: in the wiki we say there are three types of processors that use the information An XLIFF Extractor aware of both ITS and the ITS module for any data coming from the original source document. An XLIFF Modifier aware of the ITS Module for data generated during the life time of the XLIFF document. An XLIFF Merger aware of both the ITS Module and the ITS syntax if any of that data is merged back into the translated document. Does the information need to be written differently for these or in general? We touched upon this briefly at http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0018.html but I am not sure about the outcome. About the information itself, I think we have two aspects: 1) re-writing selected ITS attributes into the oasis namespace, with prefix „itsm“ as a good practice. 2) The handling of overlap as described in this thread http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0011.html anything else? Esp. for David: should I put the candidate content in a subsection of https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Implementing_and_testing_the_mapping ? Best, Felix 

Hi Felix, > to get this going I looked at the archives on what we discussed. > One question I have: in the wiki we say there are three types of > processors that use the information > > . An XLIFF Extractor aware of both ITS and the ITS module for any > data coming from the original source document. > . An XLIFF Modifier aware of the ITS Module for data generated > during the life time of the XLIFF document. > . An XLIFF Merger aware of both the ITS Module and the ITS syntax if > any of that data is merged back into the translated document. > > Does the information need to be written differently for these or in > general? I think it depends on each the data category: - Always: The description of how the data category is coded in the ITS module (or mapped to other core/modules) - The description of how to map existing annotations to XLIFF (if it's not obvious, for example: mention termInfoPoint for the value attribute in a term annotation). - The description of how to map the XLIFF data into the original document (if it's not obvious, for example the ref/value use case) > About the information itself, I think we have two aspects: > > 1) re-writing selected ITS attributes into the oasis namespace, > with prefix "itsm" as a good practice. > > 2) The handling of overlap as described in this thread > http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0011.html I think this second part should have its own sub-section because a) it applies to pretty much all data categories and b) it doesn't concern XLIFF module processors per say: it's a 'pure-ITS' issue. We could: - describe the issue - provide the algorithm to do the transformation - if possible provide the XSLT to do the transformation? (maybe as a separate thing) BTW, I'm not sure following the same outline as the other modules will work well for the ITS module. As a user I'd like to see a single place to go get the information. And see it per data category (regardless how it's done: mapped, mixed, using the ITS module) We would probably also need a section of the itsm:annotarorsRef. Cheers, -yves

Thanks for the feedback, Yves. Am 12.11.2014 um 21:38 schrieb Yves Savourel <ysavourel@enlaso.com>: > Hi Felix, > >> to get this going I looked at the archives on what we discussed. >> One question I have: in the wiki we say there are three types of >> processors that use the information >> >> . An XLIFF Extractor aware of both ITS and the ITS module for any >> data coming from the original source document. >> . An XLIFF Modifier aware of the ITS Module for data generated >> during the life time of the XLIFF document. >> . An XLIFF Merger aware of both the ITS Module and the ITS syntax if >> any of that data is merged back into the translated document. >> >> Does the information need to be written differently for these or in >> general? > > I think it depends on each the data category: > > - Always: The description of how the data category is coded in the ITS module (or mapped to other core/modules) > > - The description of how to map existing annotations to XLIFF (if it's not obvious, for example: mention termInfoPoint for the value > attribute in a term annotation). > > - The description of how to map the XLIFF data into the original document (if it's not obvious, for example the ref/value use case) > >> About the information itself, I think we have two aspects: >> >> 1) re-writing selected ITS attributes into the oasis namespace, >> with prefix "itsm" as a good practice. >> >> 2) The handling of overlap as described in this thread >> http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0011.html > > I think this second part should have its own sub-section because a) it applies to pretty much all data categories and b) it doesn't > concern XLIFF module processors per say: it's a 'pure-ITS' issue. > > We could: > > - describe the issue > - provide the algorithm to do the transformation > > - if possible provide the XSLT to do the transformation? (maybe as a separate thing) > > BTW, I'm not sure following the same outline as the other modules will work well for the ITS module. > As a user I'd like to see a single place to go get the information. > And see it per data category (regardless how it's done: mapped, mixed, using the ITS module) This sounds like one separate section and the data category section refer to it. I will give that separate section a try, also the conversion. > We would probably also need a section of the item:annotarorsRef. Makes sense, I will try to do that too. Expect a draft by the weekend. Best, Felix > > Cheers, > -yves > > >

Hi Yves and all, this was a long weekend … and here is a first version of the section on handling ITS and XLIFF: https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#General_considerations_for_ITS_2.0_and_XLIFF You will still see some „to be done“ marks. I was esp. not sure about the requirements for creating a global rule discussed here http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0026.html So comments and also direct edits are very welcome. Cheers, Felix Am 12.11.2014 um 23:11 schrieb Felix Sasaki <felix@sasakiatcf.com>: > Thanks for the feedback, Yves. > > Am 12.11.2014 um 21:38 schrieb Yves Savourel <ysavourel@enlaso.com>: > >> Hi Felix, >> >>> to get this going I looked at the archives on what we discussed. >>> One question I have: in the wiki we say there are three types of >>> processors that use the information >>> >>> . An XLIFF Extractor aware of both ITS and the ITS module for any >>> data coming from the original source document. >>> . An XLIFF Modifier aware of the ITS Module for data generated >>> during the life time of the XLIFF document. >>> . An XLIFF Merger aware of both the ITS Module and the ITS syntax if >>> any of that data is merged back into the translated document. >>> >>> Does the information need to be written differently for these or in >>> general? >> >> I think it depends on each the data category: >> >> - Always: The description of how the data category is coded in the ITS module (or mapped to other core/modules) >> >> - The description of how to map existing annotations to XLIFF (if it's not obvious, for example: mention termInfoPoint for the value >> attribute in a term annotation). >> >> - The description of how to map the XLIFF data into the original document (if it's not obvious, for example the ref/value use case) >> >>> About the information itself, I think we have two aspects: >>> >>> 1) re-writing selected ITS attributes into the oasis namespace, >>> with prefix "itsm" as a good practice. >>> >>> 2) The handling of overlap as described in this thread >>> http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Oct/0011.html >> >> I think this second part should have its own sub-section because a) it applies to pretty much all data categories and b) it doesn't >> concern XLIFF module processors per say: it's a 'pure-ITS' issue. >> >> We could: >> >> - describe the issue >> - provide the algorithm to do the transformation >> >> - if possible provide the XSLT to do the transformation? (maybe as a separate thing) >> >> BTW, I'm not sure following the same outline as the other modules will work well for the ITS module. >> As a user I'd like to see a single place to go get the information. >> And see it per data category (regardless how it's done: mapped, mixed, using the ITS module) > > This sounds like one separate section and the data category section refer to it. I will give that separate section a try, also the conversion. > >> We would probably also need a section of the item:annotarorsRef. > > Makes sense, I will try to do that too. Expect a draft by the weekend. > > Best, > > Felix > >> >> Cheers, >> -yves >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >