RE: [ISSUE-34] Localization Quality

Hi Phil, Arle, all,

 

Thanks for bringing up the issue. My renaming is probably just a show of my lack of good understanding of the ‘profile’ that Arle and you have been championing.

 

It’s clear, I think, that we have two aspects to this quality:

 

a)  we want to annotate the content with quality notes/issues

b)  we want to be able to associate the document with a quality profile and a corresponding score.

 

The first applies to the content, the second to the document, hence our initial trouble mixing both in the same data category.

 

But both aspects, as far as I understand should be optionally associated to a given.

 

So, to me, it seems none of the data category is representing a profile, but only information that are derived from using tool with a given profile. In other words, the data categories represent two different outputs of the applying the profile to a document. So for both data category we have a pointer to the profile. Isn’t this covering the relation to the profile?

 

Or am I mist-understanding the intent and we should not have a profile option for the quality notes/issues?

 

 

 

For Severity: I don’t see a problem with decimal values between 0 and 100.

 

Cheers,

-ys

 

From: Phil Ritchie [mailto:philr@vistatec.ie] 
Sent: Monday, August 20, 2012 1:29 PM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org
Subject: RE: [ISSUE-34] Localization Quality

 

Yves 

I'm sorry but I really disagree with the renaming of "Localisation Quality Profile" to "Localisation Quality Score". To me the word "Score" represents a finite classification or measurement that is applied to an artifact. The original intention of "Localisation Quality Profile" was, in addition to document-level summary/aggregated information, to describe the characteristics of the quality measurement system being employed. Thus even if the quality system is not well-known, as LISA QA would be, it could be described in detail. Though the format of this profile is out of scope for this project, I think it would help with interoperability. Though the "Profile" allows for assigning an overall document score, to me, this is of lesser importance than the model characteristics as the overall score can always be derived from the individual quality scores. 

I can live with Severity being 0-100 for the benefit of interoperability provided that decimal values (55.25, 28.357) can be used. 

Phil.





From:        Yves Savourel <ysavourel@enlaso.com> 
To:        <public-multilingualweb-lt@w3.org>, 
Date:        20/08/2012 15:31 
Subject:        RE: [ISSUE-34] Localization Quality 

  _____  




Hi all,

The latest try for the quality-related data categories is here:
 <http://www.w3.org/International/multilingualweb/lt/wiki/LocQuality> http://www.w3.org/International/multilingualweb/lt/wiki/LocQuality

Below is a summary of the main changes and some notes/questions:


--- Two data categories:

As we've discussed, I've split the information into two data categories: Localization Quality and Localization Quality Score.

I've renamed 'Localization Quality Profile' to 'Localization Quality Score' because it seems that's what the second data category provides: a way to score a document.

I've renamed 'Localization Quality Issue' to 'Localization Quality' because the attributes names were consistent that way. But I suppose we could go the other way and rename the attributes instead.

What happened to the profile? Both data categories offer an attribute that point to it. It is a bit redundant but it allows to truly separate scoring a document from marking up issues.


--- Just 4 pieces of information:

The 'Localization Quality' data category carries four pieces of information: the type, the comment, the severity and the reference to the profile. I've dropped all the others--not quite stable--information. It seems we have support to implement those, and we should probably get those done before re-visiting possible additions.

By dropping the tool-specific code, we can also simplify greatly the profile reference: No need for QNames anymore. My solution for the tool-specific code is to use data- in HTML or a custom namespace in XML.


--- Required attributes

I'm still not exactly sure how to organize the attributes for the global rules.
For example, should we be able to mix pointers and values for the different information?
Also, technically, one could have a rule with just locQualityType='uncategorized', which wouldn't be very useful. So we may need additional constraints.


--- Severity

It seems the value for the severity information is the only one that is a bit controversial. I think we can map anything to 0-100, but that's just my opinion: others disagree. We should be able to come up with a solution for this. I think this is an important information that's worth the time.


--- Standoff local markup

As discussed, there is now a standoff way to provide local markup. We just use an attribute that points to another place where we can have a list of issues. We provide the elements for XML, and use special <span> in HTML.

The important part here is that, within this context, the scope of the attributes is different: it pertains to the content of the element where the reference is called rather than the content of the element where the attributes are defined.


--- Pointers and HTML

I wonder if the pointers mechanism really make sense in HTML (in general, not just for localization quality): Since HTML is a specific format we shouldn't have to provide a mechanism to map constructs that are equivalent to our its-... attributes.


Cheers,
-ys






************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.

www.vistatec.com
************************************************************