ICU-20187 remove obsolete locale ID canonicalization mappings#418
ICU-20187 remove obsolete locale ID canonicalization mappings#418markusicu merged 1 commit intounicode-org:masterfrom
Conversation
|
How does this affect handling of the en_US_POSIX locale which is still supported by CLDR and imported into ICU, and which is still used (by Apple, for one)? Will it affect the ability to use that locale with that locale ID? Will that locale still be included in eg. getLocales()? How will the changes affect canonicalization of that locale ID? |
I am not changing anything about that locale, except:
ICU uloc_canonicalize() will no longer map "C" or "POSIX" to "en_US_POSIX", but uprv_getPOSIXIDForCategory() still does so. |
FrankYFTang
left a comment
There was a problem hiding this comment.
comments about all the tests. will look at the implementation next.
FrankYFTang
left a comment
There was a problem hiding this comment.
about the implementation.
9b35ea6 to
ca72da3
Compare
|
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
|
sorry, did a rebase on reflex... will address feedback in a few minutes |
|
PTAL |
b4d62d8 to
cb71cbc
Compare
|
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
| */ | ||
| static const CanonicalizationMap CANONICALIZE_MAP[] = { | ||
| { "", "en_US_POSIX", NULL, NULL }, /* .NET name */ | ||
| { "c", "en_US_POSIX", NULL, NULL }, /* POSIX name */ |
There was a problem hiding this comment.
This is the cause of regression https://unicode-org.atlassian.net/browse/ICU-20575 - "c" should NOT have been removed here.
There was a problem hiding this comment.
ICU uloc_canonicalize() will no longer map "C" or "POSIX" to "en_US_POSIX", but uprv_getPOSIXIDForCategory() still does so.
two different comparisons were conflated. the strcmp("C") was to check whether the posix layer was returning real data or not. The mapping still needed to be done in uloc_canonicalize()
Regression was in 1afef30 PR unicode-org#418 [ICU-20187] - We dropped the mapping from "C" in uloc_canonicalize, but then putil did not handle cases where a codepage was set (such as C.UTF-8). - Add an additional check in uprv_getDefaultLocaleID() for locales that end up as "C" or "POSIX" after removing codepage suffix. - Also fix regression where aa@bb would become aa__BB__BB (incorrectly doubled __BB)
Regression was in 1afef30 PR #418 [ICU-20187] - We dropped the mapping from "C" in uloc_canonicalize, but then putil did not handle cases where a codepage was set (such as C.UTF-8). - Add an additional check in uprv_getDefaultLocaleID() for locales that end up as "C" or "POSIX" after removing codepage suffix. - Also fix regression where aa@bb would become aa__BB__BB (incorrectly doubled __BB)
Regression was in 1afef30 PR unicode-org#418 [ICU-20187] - We dropped the mapping from "C" in uloc_canonicalize, but then putil did not handle cases where a codepage was set (such as C.UTF-8). - Add an additional check in uprv_getDefaultLocaleID() for locales that end up as "C" or "POSIX" after removing codepage suffix. - Also fix regression where aa@bb would become aa__BB__BB (incorrectly doubled __BB) (cherry picked from commit 075cefb)
Regression was in 1afef30 PR #418 [ICU-20187] - We dropped the mapping from "C" in uloc_canonicalize, but then putil did not handle cases where a codepage was set (such as C.UTF-8). - Add an additional check in uprv_getDefaultLocaleID() for locales that end up as "C" or "POSIX" after removing codepage suffix. - Also fix regression where aa@bb would become aa__BB__BB (incorrectly doubled __BB) (cherry picked from commit 075cefb)
https://unicode-org.atlassian.net/browse/ICU-20187
approved:2018-11-14 remove obsolete locale ID canonicalization mappings
drop mappings for