During discussions about collation with Markus Scherer (Google) and others, we realized that the Unicode locale extension keys "kc" (case level in collation) and "kh" (hiragana quaternary in collation) are not really useful within the context of the ECMAScript Internationalization API, and support for them should be removed from the specification.
The "kc" key lets applications select a mode in collation that recognizes case differences but ignores all other differences. The Collator API lets applications do the same by setting the sensitivity option to "case", so the key is redundant.
The "kh" key lets applications modify the interpretation of hiragana characters in collation. The feature only works properly when using a collator that implements the Unicode Collation Algorithm and is set to the quaternary level provided by that algorithm, and also depends on the specifics of the collation data used. The Collator API doesn't require a collator to implement the UCA, doesn't provide a way to specifically select quaternary level, and doesn't specify the collation data used, so there's no real basis for this feature.
If you have concerns about the removal of these features from the internationalization API, please speak up.
,
Norbert
During discussions about collation with Markus Scherer (Google) and others, we realized that the Unicode locale extension keys "kc" (case level in collation) and "kh" (hiragana quaternary in collation) are not really useful within the context of the ECMAScript Internationalization API, and support for them should be removed from the specification.
The "kc" key lets applications select a mode in collation that recognizes case differences but ignores all other differences. The Collator API lets applications do the same by setting the sensitivity option to "case", so the key is redundant.
The "kh" key lets applications modify the interpretation of hiragana characters in collation. The feature only works properly when using a collator that implements the Unicode Collation Algorithm and is set to the quaternary level provided by that algorithm, and also depends on the specifics of the collation data used. The Collator API doesn't require a collator to implement the UCA, doesn't provide a way to specifically select quaternary level, and doesn't specify the collation data used, so there's no real basis for this feature.
If you have concerns about the removal of these features from the internationalization API, please speak up.
Regards,
Norbert
During discussions about collation with Markus Scherer (Google) and others, we realized that the Unicode locale extension keys "kc" (case level in collation) and "kh" (hiragana quaternary in collation) are not really useful within the context of the ECMAScript Internationalization API, and support for them should be removed from the specification.
The "kc" key lets applications select a mode in collation that recognizes case differences but ignores all other differences. The Collator API lets applications do the same by setting the sensitivity option to "case", so the key is redundant.
The "kh" key lets applications modify the interpretation of hiragana characters in collation. The feature only works properly when using a collator that implements the Unicode Collation Algorithm and is set to the quaternary level provided by that algorithm, and also depends on the specifics of the collation data used. The Collator API doesn't require a collator to implement the UCA, doesn't provide a way to specifically select quaternary level, and doesn't specify the collation data used, so there's no real basis for this feature.
If you have concerns about the removal of these features from the internationalization API, please speak up.
, Norbert