[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #7958(closed: fixed)

Opened 4 years ago

Last modified 4 years ago

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

Reported by: markus Owned by: markus
Component: xxx-spec Data Locale:
Phase: final Review: yoshito
Weeks: 0.1 Data Xpath:
Xref:

Description

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.

Attachments

Change History

comment:1 Changed 4 years ago by emmons

  • Owner changed from anybody to markus
  • Status changed from new to assigned
  • Milestone changed from UNSCH to 27

comment:2 in reply to: ↑ description Changed 4 years ago by yoshito

Replying to markus:

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.)


I think it should convert to the POSIX variant, not @va=posix.
ICU Locale parser should handle it now (IcuBug:7438).

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.


Right.

The -u-va-posix was invented because there is no good way to map the locale identifier into BCP 47 representation, unless we register 'posix' in the language tag registry. Because the purpose of 'posix' in CLDR does not meet the goal of language tag registry, we decided to make this special case. The locale variant 'posix' is only the exception - and other existing variants in old syntax are either 1) available in the language tag registry or 2) canonical mapping to BCP 47 is defined in the old syntax.

comment:3 Changed 4 years ago by roubert

  • Cc mpvl@… added

comment:4 Changed 4 years ago by emmons

  • Phase changed from dsub to final

comment:5 Changed 4 years ago by markus

  • Status changed from assigned to reviewing
  • Review set to yoshito

Mark's comment via email:

The whole purpose (at this point) of the old syntax is to reflect what works in old implementations, of which we can take ICU to be the prime example. So I would be guided by what works there.

We know that the POSIX works in ICU, and I am pretty sure that -u-va-posix would not work in some places. So this confirms what Yoshito said in comment:2.

I added text and examples about converting from POSIX to -u-va-posix and back, and pointers from the tables that mention variants.

comment:6 Changed 4 years ago by yoshito

  • Status changed from reviewing to closed
  • Resolution set to fixed
View

Add a comment

Modify Ticket

Action
as closed
Next status will be 'new'
Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.