W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > August 2012

RE: [ISSUE-34]: Revised description and example

From: Yves Savourel <ysavourel@enlaso.com>
Date: Mon, 6 Aug 2012 05:43:06 -0600
To: "'Felix Sasaki'" <fsasaki@w3.org>, "'Arle Lommel'" <arle.lommel@dfki.de>
CC: "'Multilingual Web LT Public List'" <public-multilingualweb-lt@w3.org>
Message-ID: <assp.0565936024.assp.05655f1c84.007601cd73c8$a52792e0$ef76b8a0$@com>
Hi Felix, Arle, all,

A few notes on your example for the languageTool entry:

-- 1) its-translation-quality-code value

I'm not sure we should allow a content that is everything and anything like in the example.
To me its-translation-quality-code is a for a code that is basically a sub-type, a label that allow a finer granularity of classification of the top-level value.
This way, even if they do not know what the actual value means, tool can make a limited use of the data, like present it to the user.

If we allow anything in the attribute, and use it like a bag of tool-specific data it loses all meaning. It seems to me that tool-specific data which cannot be mapped to an ITS attribute should be coded by the tool using "data-" in HTML5 and a different namespace in XML.

-- 2) Referenced information vs. inline information

The LanguageTool element <error> is a good example of why it is important to resolve our on-going discussion about how to represent the quality information other than inline.

Arle used <span> to illustrate his mapping, but if LanguageTool was using ITS directly it couldn't do it in an XML return file the way it works today. Currently our attributes' scope is the content of the element in which the attributes are define. In <error> it is not the case. It's more like the XLIFF 2.0 case were we must use some non-inline representation that refers to the marked up content.

We need to have either a set of pointers attributes (a lot of added complication), or allow the scope of the attributes be interpreted either as inline or pertaining to the content that refer to the holding element where the attributes are located (or its parent to allow multiple entries for the same span of content).

Maybe it is as simple as to provide the official holder elements like this:

<its:locQualityNote id='qa123'>
  locQualityComment="This sentence does not start with an uppercase letter"

And say that within such construct the attribute don't have an inline scope but pertains to the content pointing to that construct.

In HTML5 we would use the attribute as inline.

I'm all for using the data category directly in HTML5 documents, but we have to realize many tools that produce such QA information are working with XML and often bilingual documents, not HTML5.

-- 3) Replacements

I've noticed the "replacements='This'" attribute in LanguageTool.
This is something we've talked about as well. It seems the attribute didn't make it to Arle's table.
But I believe it is an important information fairly easy to use across tools.
One thing we should maybe take into account would be to allow for multiple proposals (e.g. for spell-checking).

Received on Monday, 6 August 2012 11:43:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:50 UTC