Re: [ISSUE-34] Localization Quality

Hi Yves,
One small query on the intent. Is this specifically targeted at 
_translation_ QA? This seems to be implied by the use of term 
'localization quality', but this doesn't seem to be made explicit, and 
one might consider source QA part of 'localization'.

Some of the locQuality type definitions, e.g. terminology, 
inconsistency, grammar, legal, register, style, misspelling, 
typographical, formatting, refer just to 'text' rather than 'target 
text'. They could  therefore usefully be (mis?)applied to source QA and 
arguably ITS conformant.

If the intent is specifically translation QA then perhaps make this more 
explicit in the definition, but if source QA is in scope also, again 
make that explicit.

cheers,
Dave



On 20/08/2012 15:30, Yves Savourel wrote:
> Hi all,
>
> The latest try for the quality-related data categories is here:
> 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
>
>
>

Received on Monday, 20 August 2012 17:12:02 UTC