Contrib.social

[policy] Inclusion criteria for CLDR territories in CountryManager::getStandardList()

Open on Drupal.org →
Created on 6 July 2013, almost 11 years ago
Updated 22 February 2023, over 1 year ago

Problem/Motivation

#1938892: Switch from ISO-3166-1 country data to CLDR unicode data → converted Drupal core from taking 1-time imports of ISO-3166-1 country data into 1-time imports from CLDR data. Some people were concerned that since CLDR is more inclusive and has more records, that some people might dispute or object to the inclusion of specific territories. Drupal needs a policy for if/when the official country selector can/should deviate from the CLDR data.

Proposed resolution

Drupal should be inclusive and support diversity in this regard. Any region listed in the CLDR database deserves to be included as an option for Drupal. If specific sites require restricting the list, there's a hook for that, but the default list should have as many options as there are in the CLDR data.

Remaining tasks

  1. Get more proposals for criteria?
  2. Debate them.
  3. Get the appropriate governance signoffs.

User interface changes

API changes

Data model changes

Release notes snippet

Original summary from @Pancho

#1938892: Switch from ISO-3166-1 country data to CLDR unicode data → lead to the addition of some territories and a region, all of which don't represent countries. Specifically, the addition of:

  • Diego Garcia
  • Ceuta and Melilla
  • Canary Islands
  • Saint Martin
  • Outlying Oceania

was rightly disputed in #1938892-43: Switch from ISO-3166-1 country data to CLDR unicode data → .

So most urgently, we have to decide what to do with these specific territories, as these constitute a regression vs. D7 and therefore a critical bug.

Apart from that, we also have to figure out some criteria on which basis countries should be included or not. And we need to make sure these inclusion criteria are automatically enforced, whenever CLDR possibly decides to add another territory to the list.
This part is less critical, so might be spun off to a followup, or not.

📌 Task
Status

Active

Version

9.5

Component
Locale  →

Last updated about 1 hour ago

Created by

Pancho UTC+2 🇪🇺 EU

Live updates comments and jobs are added and updated live.
  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇺🇸United States dww

    I stumbled upon this issue with @quietone in Slack while trying to sort out some related policy questions. They suggested adding [policy] in the title here. At the very least, this seems to need a subsystem maintainer (@Gábor Hojtsy) and framework manager reviews so tagging as such. Probably also needs release manager, but @catch is already participating, and the other reviewers can escalate as appropriate.

    I agree with @catch in #7 that this isn't a critical bug, and personal preference is to have more choices, not less.

    Since inclusion and diversity are values of our community, I think we should be maximally inclusive here. If I'm from a "disputed territory" (aka a colony where the indigenous population is struggling to resist the imperial power), I want to see a distinct choice for my region, and it's not there, I'm alienated from your UI and I'm (rightfully) angry. If I'm from an imperial superpower and I look through the list and see "my country", I won't be pissed. I might demand it should be at the top of the list, but what's new? 😅 And if I'm scrolling through a huge list already, I probably won't get too bothered about specific additions that I don't recognize or agree with. And even if that happens, and I'm somehow convinced that "our (my?) colony" shouldn't have it's own choice on the list and people living there should be forced to say they're from the "mainland", I think as a community developing this open source software together, we need to "take the side" of the 100% of the people in "disputed territories" who are pissed and alienated, not the unknown (but hopefully small) minority of people in the imperial powers who are actively bothered by this list having 10 or 20 more entries than their "officially recognized list", imagined or UN or whatever.

    So my vote is for a policy of "If it's in the latest CLDR download, ship it!", more or less.

    Maybe we could add an "...and in cases where something is not in the CLDR list, if enough (TBD) active (TBD) community members from (TBD) that area (TBD) are supporting its inclusion..." clause of some kind. That could get messy and weird, so I'd be okay to punt that to a separate follow-up. We could try the simple "include everything in the CLDR list", and if that's not enough, revisit this in the future.

    Given all that, updated the summary, and including an initial proposed policy. Next steps (remaining tasks in the summary):

    1. Get more proposals for criteria?
    2. Debate them.
    3. Get the appropriate governance signoffs.
contrib.social Blog FAQ Discussions
Production build 0.69.0 2024