-
Notifications
You must be signed in to change notification settings - Fork 407
CLDR-18369 Update era names #5048
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
</dayPeriods> | ||
<eras> | ||
<eraNames> | ||
<alias source="locale" path="../eraAbbr"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot add or remove aliases without TC approval. Affects all of inheritance.
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for making the change more narrow!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are past data freeze. This will need approval from both the CLDR and ICU TCs at this point in the release or you can wait until CLDR 49.
So the first CLDR-JSON we could use to test with ICU4X was released after the data freeze, so now I have to go begging to two TCs for any issue we find? |
I think this means that we need to refine the schedule to consider ICU4X. Historically ICU4X's release timelines were not aligned with the CLDR or ICU timelines but were independent. |
ICU4X has tested every CLDR release since I've been on the project as soon as a CLDR-JSON was available. This has always been way later than ICU could start integration, which I point out every time, but I don't think it has ever been after data freeze. |
It has always been after data freeze at least according to the CLDR BRS. In general we only start generating CLDR JSON data after alpha2 and sometimes after public alpha but always before public beta. It may have been happening but since it isn't currently reflected that way in the BRS checklist, we should make sure that is updated so that you can test earlier. Otherwise it's likely to get missed if we are running late for any reason. |
Moved to draft to avoid getting inadvertently merged before we settle remaining issues. |
Saka change was discussed in https://unicode-org.atlassian.net/browse/CLDR-18487 |
common/main/root.xml
Outdated
</eraNames> | ||
<eraAbbr> | ||
<era type="0">ERA0</era> | ||
<alias source="locale" path="../../../calendar[@type='ethiopic']/eras/eraAbbr/era[@type='0']"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked this over, and I think it is ok if we change to:
<alias source="locale" path="../../../calendar[@type='ethiopic']/eras/eraAbbr/era[@type='0']"/> | |
<alias source="locale" path="../../../calendar[@type='ethiopic']/eras/eraAbbr"/> |
The aliases take the asked-for path, plus the location of the alias itself, in order to construct the new path. You can see that in the other cases. That being said, I haven't tested this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to pull in both eras, just the one with type=0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not the way that they work: https://unicode.org/reports/tr35/tr35.html#Alias_Elements
That would map any missing item (eg type='1') to the 0 value.
However, I see that you've removed this, so it's moot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it from this PR so it can get merged, but we need to figure out some mechanism to keep these era names in sync.
We might be able to just remove translations for ethipic-amete-alem
altogether if patterns also match ethiopic
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we do that for the Islamic variants!
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're now removing all the values, even those that change script. I understand that they are probably incorrect in that they include "0", but the Latin abbreviation is probably no better. However, to get this moving I'm approving.
This comment was marked as spam.
This comment was marked as spam.
ping @AEApple |
autosubmit please |
CLDR-18369
Now that we've aligned all the codes with the correct abbreviations, we should also align the names in root. This finally gets rid of ERA0 and ERA1 for Ethiopic.
The Coptic era was already updated in #4620, that should have probably been a separate PR.
ALLOW_MANY_COMMITS=true