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

xpath

None

locale

None

Status

Assignee

Markus Scherer

Reporter

Markus Scherer

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