We're updating the issue view to help you get more done. 

emphasize that the POSIX variant should be converted to -u-va-posix (and back?)

Description

Deleted Component: xxx-spec

http://www.unicode.org/reports/tr35/tr35.html#Legacy_Variants says that the POSIX variant should be converted to -u-va-posix, but

  • supplementalMetadata.xml also says that POSIX is a valid variant

  • when looking at a locale ID/language tag without extensions, it is ambiguous whether it is in old syntax or in BCP 47 syntax

  • therefore, it would probably be futile to declare that en-US-POSIX is not a valid Unicode Language Identifier

  • while in non-CLDR BCP 47, en-US-POSIX is not valid because POSIX is not a registered language subtag

Please note this conversion in http://www.unicode.org/reports/tr35/tr35.html#unicode_variant_subtag and at the bottom of http://www.unicode.org/reports/tr35/tr35.html#Key_Type_Definitions with a link to the Legacy Variants.

Please include examples, such as

  • en_US_POSIX -> en-US-u-va-posix

  • en_US_POSIX@colNumeric=yes ->en-US-u-kn-va-posix

  • en-US-POSIX-u-kn-true -> en-US-u-kn-va-posix

  • en-US-POSIX-u-kn-va-posix -> en-US-u-kn-va-posix

Some implementations convert to the old syntax. Should they convert -u-va-posix to the POSIX variant, or to @va=posix? If the latter, should parsers (such as ICU Locale) turn old syntax en_US_POSIX into en_US@va=posix? (That would probably break Collator.getInstance() for that locale.)

It looks like the other Legacy Variants mappings should not be reverse-mapped when converting to old syntax. For example, sv-AX NOT> sv_AALAND, el-POLYTON NOT> el_POLYTONI. Correct? Please clarify.

Environment

None

xpath

None

locale

None

Status

Assignee

Markus Scherer

Reporter

Markus Scherer

Labels

None

tracReporter

markus

tracOwner

markus

tracResolution

fixed

tracStatus

closed

Reviewer

Yoshito Umaoka

phase

final

tracCc

mark,mpvl@36e9498b339f6578,roubert,yoshito

tracCreated

Oct 01, 2014, 7:51 PM

Fix versions

Priority

medium