| ID | {{ID}} |
|---|---|
| Definition | {{Definition}} |
| MQM Core? | {{Core}} |
| Automatable? | {{Automatable}} |
| Parent | {{Parent}} |
| Children | {{Children}} |
| Applies to | {{Applies}} |
| Example(s) | {{Examples}} |
| Note(s) | {{Notes}} |
'.$id.")");
} else {
echo('FIX ME!!');
}
}
?>
This document is for public comment, with comments due June 30, 2015 at 23:99 CET. Comments will be used to create future versions. Comments can be made via the MQM definition’s Github repository at https://github.com/multidimensionalquality/mqm-def/issues.
| This version: | 0.5.1 (2015-06-16) (issues-list-2015-05-27.html) |
| Latest version: | issues-list.html |
| Previous version: | 0.5.0 (2015-05-27) (issues-list-2015-05-27.html) |
| Diff from last major version (0.4.0): | diffs/issues-0_4-0_5_1.html |
Copyright ©2015, Deutsches Forschungszentrum für Künstliche Intelligenz GmbH / German Research Center for Artificial Intelligence (DFKI)
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License. Note that implementations based on this document are freely permitted as are derivative works provided they do not use the names “MQM”, “Multidimensional Quality Metrics”, “DQF”, or “Dynamic Quality Framework” or otherwise imply endorsement of the derivative work.
Special thanks are due to the following individuals for their contributions:
This document contains a draft list of the MQM issue types. It is subject to frequent and substantial revision and should not be relied upon for implementation.
Feedback on this document should be submitted to info@qt21.eu.
This document defines the issue types used by the Multidimensional Quality Metrics (MQM) framework. It contains a description of the issue types. For a full definition of MQM, please read the MQM definition file at .
This version contains major changes from previous versions. Please consult the change log at the end of this document for a detailed listing of changes.
MQM defines a total of over 100 issue types, as defined in this section. They are derived from an examination of major quality assessment systems, both ones based on automatic detection of issues and ones based on manual assessment by reviewers. As quality assessment systems differ considerably in the issues they check, the MQM issue types represent a (non-strict) superset of issues found in translations (as product, as opposed to process). The superset is non-strict because it represents an abstraction of various systems and, in some cases, is less granular than actual systems. For example, an existing system might distinguish between four kinds of issues related to whitespace, but MQM would categorize all of them as . Information on extending MQM is available in the MQM definition.
In this document MQM issue types are referred to by name followed by the MQM ID value in parentheses on a gray background, e.g., Issue name (issue-name). The issue ID values are linked to the full description of the issue below.
MTM issues exist in a hierarchy, with more specific issues lower in the hierarchy constituting “subtypes” of their parents. For example the issue type is a subtype of the more general issue type . Because the issues exist in a hierarchy, rather than as a flat list, MQM can be realized at any level of granularity. At one extreme an MQM-compliant metric could check only two high-level issues, and ; at the other extreme a metric could check all issues defined in MQM. In most cases the number of issues checked will be somewhere between these extremes. Guidance on selecting issue sets can be found in MQM definition. As a general rule, metrics should check the fewest number of issues possible to achieve the requirements of users.
This section presents the hierarchy of MQM issues, followed by the detailed description of each issue type.
At the top level, MQM issues are grouped into eight major branches or “dimensions”: , , , , , , , and . It also contains , used for issues that cannot be assigned elsewhere, and , a branch that contains deprecated issues that are retained for compatibility with legacy systems, notably the LISA QA Model. These seven dimensions represent the top level in the MQM hierarchy and themselves may serve as issue types in cases where no further granularity is needed.
These dimensions may be graphically represented as follows (dimensions in bold are in the “MQM Core”):
Issue type names are not case-sensitive (i.e., “Mistranslation”, “MISTRANSLATION”, “mistranslation”, and “MiStRaNsLaTiOn” are all equivalent). The ID values, however, are case sensitive (and are always lower-case) and do not contain spaces. As a result, implementers should ensure that they do not confuse the two, even though in most cases they are nearly identical.
The following list of issue types presents the full list of MQM categories in hierarchy. Clicking on any issue type name in the lists will take the reader to the definition of the issue type in the next section. The list is separated into sections by dimension. For those dimensions where current sub-issues are defined, a “mind map” shows the hierarchy of the dimension. Clicking on the embedded image will open and SVG version in a new window. Issues in bold in the graphics or the list are part of the “MQM core”. The graphical versions include both the issue name, which might be localized or displayed in some other fashion in an application, and the ID, which MUST remain as given to provide an unambiguous reference to a particular issue type.
Accuracy issues address the relationship of the target text to the source text and can be assessed only by considering this relationship. Changes in intended meaning, addition and omission of content, and similar issues are considered in it.
The Compatibility dimension includes issues taken from legacy metrics that are not considered appropriate for general use in MQM (because they are related to areas not covered by MQM, such as deadlines, software functionality, or physical production). They are included only for compatibility with these older metrics and should not be used for new MQM metrics.
Design includes issues related to the physical presentation of text, typically in a “rich text” or “markup” environment.
Fluency includes those issues about the linguistic “well-formedness” of the text that can be assessed without regard to whether the text is a translation or not. Most Fluency issues apply equally to source and target texts.
Internationalization covers areas related to the preparation of the source content for subsequent translation or localization. Internationalization issues may be detected through problems found in the target (particularly from those included in ), but an Internationalization audit is generally conducted separately from a general assessment of translation quality.
Issues in Locale convention relate to the formal compliance of content with locale-specific conventions, such as use of proper number formats. If content is otherwise correctly translated and fluent but violates specific locale expectations (as defined in the translation specifications), it is addressed in this dimension. This dimension does not cover issues related to whether the content itself is appropriate for the locale (these issues are covered under .
Style issues relate to what is commonly known as “Style”, defined both formally (in style guides) and informally (e.g., a “light style” or an “engaging style”). These issues are closely related to fluency, but are often treated separately by tools and quality processes and so are grouped as a separate dimension in MQM.
Terminology issues relate to the use of domain- or organization-specific terminology (i.e., the use of words to relate to specific concepts not considered part of general language). Adherence to specified terminology is widely considered an issue of central concern in both translation and content authoring. Issues in this branch should not be used for general language mistranslation (e.g., translations that would not be considered correct under reasonable circumstances), and should be reserved for issues related to terminology (e.g., a translation is reasonable but incorrect in the context of specific technical domain or for a particular organization).
Verity issues relate to the suitability of content for the target locale and audience. They do not relate to fluency or accuracy since content may be fluently written and accurately translated and still be inappropriate for the target locale or audience. For example, if a text translated for Germans in Germany refers to options available only in the UK, these portions will likely be problematic. For more details on Verity, see the discussion below.
As is a relatively new concept in translation quality assessment, some examples may help clarify its usage and how it differs from general or . Note that issues in this branch may be checked in separate processes relating to market compliance before translation begins or may be subject to discussion and negotiation between the requester and the provider.
The examples are:
This dimension is used for issues which cannot be otherwise classified into a dimension of MQM. In cases where an unforeseen issue can be classified as belonging to a dimension, it should be classified in that dimension under the top level or using a custom issue type. In practice Other should be used extremely rarely.
This section lists all MQM issue types in alphabetical order, with the following information:
The name is the English name for the issue type. This name may be localized in other languages or may be changed in a UI to reflect application-specific preferences. (For example, if an existing system is being converted to use MQM categories and already has an issue type called Terminology problem that corresponds to , the UI may display the existing name but refer to the ID value terminology internally for mapping purposes. For new English-language implementations, however, it is recommended to use the existing name to prevent confusion.)
| ID | An XML identifier for the category. This ID is used to refer unambiguously to each issue type and does not change, even if a UI may display other names for the category. |
|---|---|
| Definition | A definition of the issue type |
| MQM Core? | (yes|no) Specifies whether the issue is in the MQM core (see the definition of the MQM Core) or not. |
| Automatable? | (yes|no) Informative: Indicates whether the issue may be automatically detected. Users interested in fully automatable subsets of MQM may wish to limit themselves to issues marked with “yes”. This specification does not provide any guidance on how to check issues automatically and detection may require language-specific modules or development. Success in detecting issues depends on factors outside the scope of this specification and individual systems may be able to identify issues not identified as automatable in this specification. |
| Parent | The parent of the issue type in the hierarchy. Each issue can be understood as a type of its parent. |
| Children | A list of any children to the current issue type. |
| Applies to | Whether the category applies to target, source, or both |
| Example(s) | One or more illustrative examples of the issue type |
| Note(s) | Any notes on usage for the issue type. |
'.$parent[$id].'';
}
if (preg_match('//',$children[$id])) {
$theseChildren = $children[$id];
} elseif (!$children[$id]||$children[$id] == "none") {
$theseChildren = "none";
} else {
$tempChildren = explode('|',$children[$id]);
$allChildren = array();
foreach($tempChildren as $thisChild) {
$allChildren[] = ''.$thisChild.'';
}
$theseChildren = implode(', ',$allChildren);
}
if ($examples[$id]) {
$theseExamples = '
\\1", $thisItem);
echo($thisItem);
}
?>
style).register into style and separated out the grammatical issues of register into grammatical-register. The MQM Core contains grammatical-register and register has been removed from the Core. This is a major semantic change, but the core issue of register had focused on the grammatical aspects before.
Locale-specific punctuation as an issue under Locale convention and moved Quote mark type under it in response to industry feedback.Offensive in response to GALA survey data.Terminology and Locale convention. These dimensions take issues from other dimensions, as noted below.Accuracy:
Mistranslation loses Terminology as a daughterMistranslation:
Mistranslation of technical relationship (from DQF)Overtranslation and Undertranslation) for compatibility with LQAMechanical and Content division dropped. While theoretically nice, in practical terms it caused problems.Style guide and Stylistics recombined (they had been split to deal with the Mechanical/Content division) back into Style. Within Style:
AwkwardStyle guide and replaced with Company style and Third-party styleInconsistent style.Unidiomatic from being a child of Content to being a child of StyleCohesion and CoherenceInconsistency:
Discourse (it is replaced by Coherence)Terminological inconsistency to the Terminology dimensionInconsistency with external reference (request from TAUS)Monolingual terminology (it is now handled by issues in the Terminology dimension)Internationalization:
Verity:
Locale convention issues to the new dimension Locale conventionCulture-specific reference (from DQF)Terminology dimension. Notes:
Locale convention dimension. Notes:
Locale convention takes all of its daughter issues from its old location in FluencyInternationalization.Style into Stylistics and Style-guide.locale-violation to Locale-conventionlocale-applicability to Locale-specific-content