CLDR-19732 Update en_001 from en_GB

[AEApple]

CLDR-19732

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[AEApple]

Two changes in order to have consistent zero-padding in numeric date formats

[stenshamn]

Should the data that was copied "up" from en_GB also be removed from en_GB so it inherits it instead?

[AEApple]

Should the data that was copied "up" from en_GB also be removed from en_GB so it inherits it instead?

We can file a ticket to do that in future releases, but I don't want to block updating en_001 on that improvement.

[AEApple]

@DraganBesevic @srl295 - Is there an easy way to regenerate the test data without having to set up a development environment? It's been a bit since I've last updated mine, and this looks like it is currently failing due to the test data not matching the updated inherited values.

[srl295]

@DraganBesevic @srl295 - Is there an easy way to regenerate the test data without having to set up a development environment? It's been a bit since I've last updated mine, and this looks like it is currently failing due to the test data not matching the updated inherited values.

No but I can do it and push a commit.

We should do a vc and try code spaces.

[AEApple]

We should do a vc and try code spaces.

Yes, we should find a good time to try it and document the set up if it works. Or the gaps that we need to solve if it doesn't work.

[srl295]

@AEApple PTAL you may need to review it yourself

[AEApple]

Looks right to me, although I think someone else should also review.

However, I realized when reviewing the updated test data that it is changing the formatting for all the inherited values for the en child locales. Agree with Fredrik that longer term we should make sure that the en_001 upgrade tool keeps the current winning value when an English sublocale votes for inheritance, and changes to inheritance for en_GB and any other child locales when they have the same value.

The main one that concerns me is the removal of the . in the person name formatting. @mimckenna @richgillam @stenshamn

<personNames>
		<initialPattern type="initial">{0}</initialPattern>
...
</personNames>

I researched it a bit and it seems like AU, GB, NZ don't use punctuation on initials in names, while the US, CA, IN do, and Europe does both. Therefore should we add an override in en_IN to use the . on the initialPattern in person name formatting since it seems like updating en_001 to not have the punctuation is accurate for most of the English speaking world? I do think we need to switch to having more regional English since a lot of English preferences are shared regionally.

[macchiati]

Should the data that was copied "up" from en_GB also be removed from en_GB so it inherits it instead?

We can file a ticket to do that in future releases, but I don't want to block updating en_001 on that improvement.

We don't need to; the software will removed duplicates in production.
However, we should check that the CLDRModify pass to change value to ^^^ (or the reverse) is run. That doesn't need to be part of this PR.

[macchiati]

I also reviewed, and agree with Annemarie. All looks good except that we should fix en_IN to have period in initials, and regenerate test data.

[AEApple]

I also reviewed, and agree with Annemarie. All looks good except that we should fix en_IN to have period in initials, and regenerate test data.

Okay, I'll make the change in a couple of hours. I can just modify the test data to only keep what we care about based on the data Steven generated. I think we may want to update our tests though to watch for specific things in English sublocales.

[srl295]

+1 I can regen tomorrow if need be. Lmk

[AEApple]

Okay, I think it should pass tests now unless I missed something.