OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Internationalization and beyond related metadata for JSON - XLIFF perspective?

    Posted 10-15-2015 17:36
    Hi all, apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously. In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion http://r12a.github.io/docs/bidi-plain-text/index.html   I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here. Best, Felix


  • 2.  RE: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective?

    Posted 10-16-2015 22:37
    Hi Felix, I well aware of the issues caused by not having explicit language information and needing to fall back on heuristics for things like base direction. So I can see why there is a need for this. When it comes to JSON I personally prefer to have such features be part of the document specification instead of trying to add XML like features, type systems and constructs to JSON. If the problem need "heavy-weight" solutions like that XML is probably a better choice. The switch from XML to JSON in large areas of the Web space was to a large degree that XML became complicated as more and more standards and products started to make use of the more advanced parts of it. A lot of people wanted back to something simpler and smaller. Looking at JSON-LD for example I think the outside of the content parts are ok, like having per-document/per-nesting level "@context" sub objects that augment the main data without in any way modifying it or complicating use of it by someone who do not care about the meta-information. The inline "@value" objects on the other hand does not feel right to me in JSON as an example. I have essentially used completely document specific solutions when doing JSON. If I need to be able to tag a section of text in some way, be it language or something else I have broken it up into objects that have properties for the needed metadata, used custom span pointers for it or just added custom macros/codes in the text itself. Best Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Felix Sasaki [felix@sasakiatcf.com] Sent: Thursday, October 15, 2015 7:35 PM To: XLIFF Main List Subject: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi all, apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously. In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion http://r12a.github.io/docs/bidi-plain-text/index.html   I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here. Best, Felix


  • 3.  Re: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective?

    Posted 10-17-2015 04:04
    Hi Fredrik, thanks a lot for your detailed reply. Esp. your thoughts on a data type are interesting since https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion had as one suggestion to have a dedicated data type - which you have good arguments against (the complexity). Am 17.10.2015 um 00:36 schrieb Estreen, Fredrik < Fredrik.Estreen@lionbridge.com >: Hi Felix, I well aware of the issues caused by not having explicit language information and needing to fall back on heuristics for things like base direction. So I can see why there is a need for this. When it comes to JSON I personally prefer to have such features be part of the document specification instead of trying to add XML like features, type systems and constructs to JSON. If the problem need heavy-weight solutions like that XML is probably a better choice. The switch from XML to JSON in large areas of the Web space was to a large degree that XML became complicated as more and more standards and products started to make use of the more advanced parts of it. A lot of people wanted back to something simpler and smaller. Looking at JSON-LD for example I think the outside of the content parts are ok, like having per-document/per-nesting level @context sub objects that augment the main data without in any way modifying it or complicating use of it by someone who do not care about the meta-information. The inline @value objects on the other hand does not feel right to me in JSON as an example. I have essentially used completely document specific solutions when doing JSON. If I need to be able to tag a section of text in some way, be it language or something else I have broken it up into objects that have properties for the needed metadata, used custom span pointers for it or just added custom macros/codes in the text itself. Interesting approach. I am not sure what you mean by custom span pointers, do you have an example? Best, Felix Best Regards, Fredrik Estreen From:   xliff@lists.oasis-open.org   [ xliff@lists.oasis-open.org ] on behalf of Felix Sasaki [ felix@sasakiatcf.com ] Sent:   Thursday, October 15, 2015 7:35 PM To:   XLIFF Main List Subject:   [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi all, apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously. In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion http://r12a.github.io/docs/bidi-plain-text/index.html   I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here. Best, Felix


  • 4.  RE: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective?

    Posted 10-18-2015 14:36
    Hi Felix, here is a short example of what I mean with custom span pointers. {   "headline" : "Today Acme Inc is prod to announce that John Doe has joined the company as Vice President of Infinite Improbability drive development.",   "annotations" : [     { "type" : "date", "subtype" : "relative-issue", "ref" : "2015-10-18T14:19:54+00:00", "span" : [0,4] },     { "type" : "name", "subtype" : "company", "ref" : "http://www.test.org", "span" : [6,13] },     { "type" : "name", "subtype" : "person", "ref" : "http://www.allpeople.biz/Doe/John/123", "span" : [40,47] },     { "type" : "title", "subtype" : "business", "ref" : "https://en.wikipedia.org/wiki/Vice_president#In_business", "span" : [75,88] },     { "type" : "name", "subtype" : "product", "ref" : null, "span" : [93,120] }   ] } I have found this to be useful in the cases where adding or propagating annotations happens without changing the main content. Or where changing the main content is hard do, if it is signed for example. Best Regards, Fredrik Estreen From: Felix Sasaki [felix@sasakiatcf.com] Sent: Saturday, October 17, 2015 6:04 AM To: Estreen, Fredrik Cc: XLIFF Main List Subject: Re: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi Fredrik, thanks a lot for your detailed reply. Esp. your thoughts on a data type are interesting since https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion had as one suggestion to have a dedicated data type - which you have good arguments against (the complexity). Am 17.10.2015 um 00:36 schrieb Estreen, Fredrik < Fredrik.Estreen@lionbridge.com >: Hi Felix, I well aware of the issues caused by not having explicit language information and needing to fall back on heuristics for things like base direction. So I can see why there is a need for this. When it comes to JSON I personally prefer to have such features be part of the document specification instead of trying to add XML like features, type systems and constructs to JSON. If the problem need "heavy-weight" solutions like that XML is probably a better choice. The switch from XML to JSON in large areas of the Web space was to a large degree that XML became complicated as more and more standards and products started to make use of the more advanced parts of it. A lot of people wanted back to something simpler and smaller. Looking at JSON-LD for example I think the outside of the content parts are ok, like having per-document/per-nesting level "@context" sub objects that augment the main data without in any way modifying it or complicating use of it by someone who do not care about the meta-information. The inline "@value" objects on the other hand does not feel right to me in JSON as an example. I have essentially used completely document specific solutions when doing JSON. If I need to be able to tag a section of text in some way, be it language or something else I have broken it up into objects that have properties for the needed metadata, used custom span pointers for it or just added custom macros/codes in the text itself. Interesting approach. I am not sure what you mean by custom span pointers, do you have an example? Best, Felix Best Regards, Fredrik Estreen From:   xliff@lists.oasis-open.org   [ xliff@lists.oasis-open.org ] on behalf of Felix Sasaki [ felix@sasakiatcf.com ] Sent:   Thursday, October 15, 2015 7:35 PM To:   XLIFF Main List Subject:   [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi all, apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously. In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion http://r12a.github.io/docs/bidi-plain-text/index.html   I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here. Best, Felix


  • 5.  Re: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective?

    Posted 10-18-2015 20:50
    Very interesting, thanks, Fredrik. I like this, also because various other people look into similar mechanisms. The W3C annotation model has fragment selectors http://w3c.github.io/web-annotation/model/wd/#fragment-selector and the text fragment selectors is having pointers like in your example; and in the context of a european project we are implementation NLP APIs and services that also create similar pointers, see an example API call here http://api.freme-project.eu/0.3/e-entity/dbpedia-spotlight/documents?input=Welcome%20to%20Berlin.&informat=text&outformat=json-ld&numLinks=1&language=en&confidence=0.3 These formats provide a lot of information - probably too much. Your example is short and nice. Best, Felix Am 18.10.2015 um 16:36 schrieb Estreen, Fredrik < Fredrik.Estreen@lionbridge.com >: Hi Felix, here is a short example of what I mean with custom span pointers. {   headline : Today Acme Inc is prod to announce that John Doe has joined the company as Vice President of Infinite Improbability drive development. ,   annotations : [     { type : date , subtype : relative-issue , ref : 2015-10-18T14:19:54+00:00 , span : [0,4] },     { type : name , subtype : company , ref : http://www.test.org , span : [6,13] },     { type : name , subtype : person , ref : http://www.allpeople.biz/Doe/John/123 , span : [40,47] },     { type : title , subtype : business , ref : https://en.wikipedia.org/wiki/Vice_president#In_business , span : [75,88] },     { type : name , subtype : product , ref : null, span : [93,120] }   ] } I have found this to be useful in the cases where adding or propagating annotations happens without changing the main content. Or where changing the main content is hard do, if it is signed for example. Best Regards, Fredrik Estreen From:   Felix Sasaki [ felix@sasakiatcf.com ] Sent:   Saturday, October 17, 2015 6:04 AM To:   Estreen, Fredrik Cc:   XLIFF Main List Subject:   Re: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi Fredrik, thanks a lot for your detailed reply. Esp. your thoughts on a data type are interesting since https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion had as one suggestion to have a dedicated data type - which you have good arguments against (the complexity). Am 17.10.2015 um 00:36 schrieb Estreen, Fredrik < Fredrik.Estreen@lionbridge.com >: Hi Felix, I well aware of the issues caused by not having explicit language information and needing to fall back on heuristics for things like base direction. So I can see why there is a need for this. When it comes to JSON I personally prefer to have such features be part of the document specification instead of trying to add XML like features, type systems and constructs to JSON. If the problem need heavy-weight solutions like that XML is probably a better choice. The switch from XML to JSON in large areas of the Web space was to a large degree that XML became complicated as more and more standards and products started to make use of the more advanced parts of it. A lot of people wanted back to something simpler and smaller. Looking at JSON-LD for example I think the outside of the content parts are ok, like having per-document/per-nesting level @context sub objects that augment the main data without in any way modifying it or complicating use of it by someone who do not care about the meta-information. The inline @value objects on the other hand does not feel right to me in JSON as an example. I have essentially used completely document specific solutions when doing JSON. If I need to be able to tag a section of text in some way, be it language or something else I have broken it up into objects that have properties for the needed metadata, used custom span pointers for it or just added custom macros/codes in the text itself. Interesting approach. I am not sure what you mean by custom span pointers, do you have an example? Best, Felix Best Regards, Fredrik Estreen From:   xliff@lists.oasis-open.org   [ xliff@lists.oasis-open.org ] on behalf of Felix Sasaki [ felix@sasakiatcf.com ] Sent:   Thursday, October 15, 2015 7:35 PM To:   XLIFF Main List Subject:   [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective? Hi all, apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously. In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion http://r12a.github.io/docs/bidi-plain-text/index.html   I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here. Best, Felix