ITS 2.0 Localization Quality Issue data category and Localization Quality Issue Types - Input for possible future refinement

Dear all,

I had a chance to finish an additional look at the following:

1. ITS 2.0 Localization Quality Issue data category (http://www.w3.org/TR/its20/#lqissue)
2. Localization Quality Issue Types - Input for possible future refinement (http://www.w3.org/TR/its20/#lqissue-typevalues)

I started that a while ago but was unable to devote the needed time earlier.

The outcome are the two attached documents with observations/comments.

I understand that at this point in the W3C process the Working Group is not required to take these observations/comments into account. Nevertheless I wanted to share the observations since they could help to clarify the two sections. I don't see a need to change any normative parts of 
these sections, e.g. the value types we have in the "types" section. Thus, there is no need to go back to normal working draft since the types are already deployed (e.g. in the W3C validator).

A process to work with the observations/comments could be like what we did for the rewrite of the introduction, and the rewrite of what started as "disambiguation" and has become "text analysis": dedicated editing calls open to any member of the Working Group. We could discuss this possible approach during one of the next calls of the Interest Group and/or via a mail thread.

 Short explanations for related to the aforementioned documents:

a. Loc Quality Issue.docx pertains to 1.

b. Loc Quality Issue Types.docx pertains to 2. It comprises three parts:

	b.i a set of general comments
	b.ii answers to a little request for feedback related to the question "Which of the following localization quality issues are easy to understand?" 
	b.iii answers to a little request for feedback related to the question " Which of the following localization quality issues cannot be understood?"

I guess it's fair to summarize the documents as follows: 

	Content related to both "Loc Quality Issue" and " Loc Quality Issue Types " currently is not easy reading for everyone.

Since I have seen "hard to understand" morphing into "hard to implement or use" a number of times, I wonder on the hand whether others made similar observations, and - if the observations have been made by others as well - which options exist for improving the situation.

In case we still have the possibility to change parts of the text, I could imagine that we approach the matter like we approached for example the rewrite of the introduction, and the rewrite of what started as "disambiguation" and has become "text analysis": via dedicated editing calls open to any member of the Interest Group.
For your convenience, here is a more detailed list of observation categories (see comments in the attached documents for the specific text snippets to which these categories are related):

1. Terminology: 

	1.a The chapter uses terms such as "quality assessment", "quality issue", "quality model", "quality metric", "quality reference/model". Thus, I think it would be a good idea to provide an overview related to Quality Management/the corresponding terms (highlighted in the text) "as seen by ITS 2.0". Very often, there is a lack of understanding related to terms such as Quality Management, Quality Control, Quality Assessment, Quality Check etc. This very often leads to misunderstandings.
	1.b It would not be a helpful to have a definition for "translation specification", "profile", "model", specification"

2. Examples: Some examples and explanations could move beyond textual content. Localization quality does not only pertain to media such as graphics or audio. Locale-related considerations do for example often relate to pictures of persons that have to be adapted to be more appropriate for a certain geographical region.

3. References: 

	3.a Some reference documents are not easily accessible
	3.b Some reference documents may not be stable

4. Alternative wording:

	Examples:

		- Distinguish more clearly between formatting, layout and rendering.
		- Be more specific what should be referenced: a profile, a model, a specification

5. Spelling errors:

	Example: ITS Interest Group maintains _an_ informative mapping_s_ of tools

6. Consistency:

	The value "enabled" is only used for Localization Quality Issue. One could imagine that several of the ITS data categories would need it as well. Example: localizationNote may be enable or disabled

7. Table with Issues Types

	7.a  From my understanding, the values represent "best practice" and are to a large degree derived from existing models such as "LISA QA model". I think this should be mentioned to prove the relevance of the ITS 2.0 values.
	7.b I think the table's usability would be improved if it would have separate columns for S and T.
	7.c I suggest to have cluster the issue types into categories. Here's a suggestion

		linguistic
			terminology, inconsistency, grammar, register,  misspelling, typographical
		content
			legal, locale-specific-content, locale-violation, style, inconsistent-entities, internationalization, non-conformance
		technical
			characters, formatting, pattern-problem
		equivalence
			mistranslation, omission, untranslated, addition, duplication, numbers, markup, whitespace
		other
			length, uncategorized, other

		Aside: Some issue types seem to fall into more than one category. "whitespace" for example may be "content" (wrong in source) or "equivalence" (wrong since different in target than in source).

8. Misc

	Should " If a tool can map its internal values to these types it must do so and must use the value other," be " If a tool can map its internal values to these types it must do so and must _not_ use the value other,"?

Cheers,
Christian