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

CLDR Ticket #10822(new unknown)

Opened 5 weeks ago

Last modified 5 weeks ago

Add missing defaultContent locales

Reported by: mark Owned by: anybody
Component: unknown Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

I noticed a problem in TestBasic.TestDefaultContents: it wasn't testing all the locales for default contents. When I fixed it, I got 5 errors.

My suggested change is:


1. If a locale has a country-region, it is ok for it not to have a default content locale as a child.

What we are thereby saying is that once we get down to the country-region level, a locale is its own DC.

Error: (TestBasic.java:781) Locale has children but is missing default contents locale: pt_PT, children: [pt_AO, pt_CH, pt_CV, pt_GQ, pt_GW, pt_LU, pt_MO, pt_MZ, pt_ST, pt_TL]; fyi, empty children: []

Error: (TestBasic.java:781) Locale has children but is missing default contents locale: zh_Hant_HK, children: [zh_Hant_MO]; fyi, empty children: []

Note that if we expand this pattern, that also frees us up to have inheritance relations like en_NZ inheriting from en_AU. But see caveat in #3.


2. If a locale has a macroregion (eg 001, 419, 150), we may want to treat them differently.

It is clear that 419 is substantially different from any of its sublocales, and purposefully so. And in user interfaces it is treated as a separate animal. So I think we want to treat that like #1.

Error: (TestBasic.java:781) Locale has children but is missing default contents locale: es_419, children: [es_AR, es_BO, es_BR, es_BZ, es_CL, es_CO, es_CR, es_CU, es_DO, es_EC, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR, es_PY, es_SV, es_US, es_UY, es_VE]; fyi, empty children: []

I'm less sure about the English cases, which are "fake" locales for our convenience in managing data, and I'm not sure that people really surface them in UIs (or should). Especially en-150, which is very thinly populated. The simplest thing to do would be also to treat them like #1 for the purpose of the test, but we may want to add some information that tells implementers that these are special.

Error: (TestBasic.java:781) Locale has children but is missing default contents locale: en_001, children: [en_150, en_AG, en_AI, en_AU, en_BB, en_BE, en_BM, en_BS, en_BW, en_BZ, en_CA, en_CC, en_CK, en_CM, en_CX, en_CY, en_DG, en_DM, en_ER, en_FJ, en_FK, en_FM, en_GB, en_GD, en_GG, en_GH, en_GI, en_GM, en_GY, en_HK, en_IE, en_IL, en_IM, en_IN, en_IO, en_JE, en_JM, en_KE, en_KI, en_KN, en_KY, en_LC, en_LR, en_LS, en_MG, en_MO, en_MS, en_MT, en_MU, en_MW, en_MY, en_NA, en_NF, en_NG, en_NR, en_NU, en_NZ, en_PG, en_PH, en_PK, en_PN, en_PW, en_RW, en_SB, en_SC, en_SD, en_SG, en_SH, en_SL, en_SS, en_SX, en_SZ, en_TC, en_TK, en_TO, en_TT, en_TV, en_TZ, en_UG, en_VC, en_VG, en_VU, en_WS, en_ZA, en_ZM, en_ZW]; fyi, empty children: []

Error: (TestBasic.java:781) Locale has children but is missing default contents locale: en_150, children: [en_AT, en_CH, en_DE, en_DK, en_FI, en_NL, en_SE, en_SI]; fyi, empty children: []


3. Elevate awareness of parentLocale to implementers.

People who filter CLDR data must recognize that if they filter out locale X, then they also have to filter out all of X's descendants. Or to put it another way, if they include locale X, they have to include all of X's ancestors.

For example, if they filter out pt_PT, then it invalidates all of its children [pt_AO, pt_CH, pt_CV, pt_GQ, pt_GW, pt_LU, pt_MO, pt_MZ, pt_ST, pt_TL], and they need to filter each of them out also.

I doubt that this is clear implementers who might be filtering data. I strongly suspect not: the parentLocale data is treated like something simply internal to CLDR or ICU, and not surfaced clearly. We are probably only saved by the fact that many people don't filter them out, or if they do, they are unlike to keep the child but not the parent in these cases (pt_PT, zh_Hant_HK).

Ideas for how to do this?

Attachments

Change History

comment:1 Changed 5 weeks ago by mark

See also ticket:10777

View

Add a comment

Modify Ticket

Action
as new
Author


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

 
Note: See TracTickets for help on using tickets.