- From: Yves Savourel <ysavourel@enlaso.com>
- Date: Tue, 21 Aug 2012 08:32:34 -0600
- To: "'Dave Lewis'" <dave.lewis@cs.tcd.ie>, <public-multilingualweb-lt@w3.org>
Hi Dave, This sounds sensible. The extra column should be useful. I'll add it. As for the names, we probably just need For the issues/notes data category: - Localization Quality (probably not enough since we have two quality-related data categories) - Localization Quality Issue ? - Localization Quality Note ? For the 'other' data category: - Localization Quality Score ? - Localization Quality Precis ? (I like Précis/Precis more and more) - Localization Quality Précis ? We can still change things later obviously, but if we get at least one right before I start adding the text to the specification it would be nice. Cheers, -yves -----Original Message----- From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie] Sent: Tuesday, August 21, 2012 6:38 AM To: public-multilingualweb-lt@w3.org Subject: Re: [ISSUE-34] Localization Quality Hi Yves, On 20/08/2012 21:49, Yves Savourel wrote: > Hi Dave, > > Another good point. My viewpoint is that we should be able to apply > the data category to either source or target (when applicable). The > original Requirement was a 'Quality' data category. It was > 'language-oriented' but not necessarily 'localization'. > http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#Q > uality > > So I wouldn't see a problem with 'Quality Issue' and 'Quality Profile/Score(?)' data categories. (I'll get back to Phil's note ASAP). I wouldn't necessarily change the name. Given the need to now more clearly present the recommendation to the HTML folk, 'localization quality' is less ambiguous than just 'quality'. I'd just make this intent more explicit in the definition, saying something like: 'Localization quality assessment tasks can be conducted on the translation of some source text into a target language or on the source text itself where its quality may impact on the localization process.' I'd also suggest then adding a column to the LocQuality Type table indicating for each type if it is just appropriate only for target quality assessment tasks or for tasks that could operate on either source OR target. You, Arle and Phil would have a better idea, of which type would be target (T) only and which source or target (S or T), but to help clarify I had a first stab below (though for some I'm unsure as indicated): terminology - S or T mistranslation - T only omission - S or T untranslated - T only addition - T only (?) duplication - S or T (?) inconsistency - S or T grammar - S or T legal - S or T register - S or T locale-specific-content - T only localse-violation - T only style - S or T characters - S or T (?) misspelling - S or T typographical - S or T formatting - S or T inconsistent-entities - T only numbers - T only markup - T only pattern-problem - S or T whitespace - T only internationalization - S or T length - T only uncategorised - S or T other - S or T (?) cheers, Dave > -yves > > > -----Original Message----- > From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie] > Sent: Monday, August 20, 2012 11:13 AM > To: public-multilingualweb-lt@w3.org > Subject: 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 Tuesday, 21 August 2012 14:33:06 UTC