[Extended Proposal] PGS module review feedback

[yumaoka]

Authors

Yoshito Umaoka

Area of Changes

• XLIFF specification document
• XLIFF schema
• XLIFF validator
• Example files

Detailed Description

Review comments for 5.9 Plural, Gender and Select Module

5.9.1 Introduction

This section may include generic description about

• What is plural, gender and select.
• Variation of linguistic expression depending on condition of variable parameters.
• Reference to Unicode CLDR/ICU specification (embedded link within description)

5.9.2 Module Namespace and Validation Artifacts

• "urn:oasis:names:tc:xliff:pgsm:1.0" - We may use "pgs" (same as prefix) instead of "pgsm". I assume "m" means "module". But other modules do not have "m".

5.9.5.1 switch

• The spec says "The text contains a comma-separated list of items". Examples in this section matches the description, but examples found in other section uses white space character as the separator instead. Because case uses white space character as delimiter, it's more consistent to use space as separator instead of comma.

5.9.5.2 case

• example is not matching the earlier definition. pgs:switch="plural:count gender:host_gender" uses space as variable separator. If we agree to change the spec of switch to use a space as separator, then we can keep this description.
• Valid gender keywords includes "anything else". For easier implementation, a token belong to "anything else" should be refined - such keyword should not contain any separator characters (space). Also avoid double quote, etc which may require escaping.
• Related to above - I understand there are more gender cases, but is it a problem if we limit gender keywords to only feminine, masculine, neuter and others? From implementator's point of view, "anything else" is not nice.

5.9.6.1 Plural

• "ICU" might be changed to "ICU MessageFormat" with embedded link.

5.9.7 Maximizing compatibility

• This section title might be changed to "Recommended practices". These notes are not limited to compatibility.

5.9.7.2 Keep the same order of the selectors

• "By keeping the generated text segments in the same order we can improve Translation Memory leveraging that relies on context..." - I'm not sure about this description. I agree consistent ordering can prevent unnecessary confusion, but most of translation memory implementations would not depend on order of "alternative" segments.

5.9.7.4 Generate separate localization packages for each language

• "In fact, some companies..." maybe more generic term instead of "some companies".

5.9.8 Annex, links

Some links might be moved to 1.2 Normative References / 1.3 Non-Normative Reference.

Example Use Case

No response

Compatibility Impacts

No response