-
Notifications
You must be signed in to change notification settings - Fork 182
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
Teach length::Bag how to switch hour cycles #840
Conversation
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Codecov Report
@@ Coverage Diff @@
## main #840 +/- ##
==========================================
+ Coverage 74.25% 74.78% +0.53%
==========================================
Files 211 207 -4
Lines 12416 12507 +91
==========================================
+ Hits 9219 9353 +134
+ Misses 3197 3154 -43
Continue to review full report at Codecov.
|
Pull Request Test Coverage Report for Build fa138f514a7750f40317feec08c698f8a8540a5c-PR-840
💛 - Coveralls |
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 |
Your new sets - |
I took a stab at de-duplicating it. The risk is that lengths mix a
|
… cycle transform code
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.
This looks good! I like how you were able to support the hour cycle preferences at runtime with a very small amount of code, front-loading most of the work to the transformer.
Just some nits.
I did an ugly fix due to merging in #832. The widths for hour cycles were expanding in ways I didn't want them to. The The skeleton fields do not match 1:1 with pattern fields, and I feel like I'm constantly designing around that. I wonder if I shouldn't file a follow-up issue to tackle this. |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Apologies for the force push, but I consolidated my changes after the approval to make it easier to review. The changes are only e7ee7e3. |
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.
Seems good; I defer to Zibi to review the details of the business logic
This assumption seems to break in CLDR 43
|
Possibly related: |
@robertbastian What is the locale causing the error? What change in CLDR between 42 and 43 is causing the error? That information can help us decide the best approach to fixing it. |
Do we consider this a CLDR bug, or is this mixed assumption something we can drop? |
As with some other issues, Looking at these specifically, the issue is that of the four timeFormats, two or three of them are unconfirmed—they need more votes. By default, unconfirmed are dropped from cldr-json. Therefore the patterns with I added a comment to https://unicode-org.atlassian.net/browse/CLDR-11836?focusedCommentId=168839 for this issue under logical grouping errors. That said, this is also probably a reasonable assumption that hourcycles are consistent. I don't know off hand whether there's a separate test or ticket for that. That would be fine to file as a ticket, for next time (Cross reference the logical group issue) |
Edit: This is now ready for review. Please ignore the first commit as it is #841, which I plan on landing first.
Resolves #671
Time zones are going to be required for full support here, as the generated patterns do not use the time zones. I commented out a check for unsupported symbols temporarily to make everything work, but the results can be seen in the generated data. What you'll see here is that I opted for generated 2 new sets of patterns, one for h11/h12, and one for h23/h24. This is in addition to the existing styles. the existing
time
style represents the localizer's choice for the best hour cycle. Thetime_h11_h12
andtime_h23_24
represent the patterns for those specific preferences. There is a bit of duplicated data doing it this way, but I felt it was more correct as it allows localizers to specify any preference for hour cycle, and it also allows for specific overrides.There is an assumption that a h11 and h12 symbol can be swapped out correctly in a pattern, as well as a h23 and h24 can be swapped. However, h11 cannot be swapped with with h23 etc.
I do the pattern generation code in the provider to pre-generate the data, rather than requiring the pattern generator to be run at runtime for styles. I anticipate a small regression to memory for this approach, as a trade-off of a bigger one if this pattern manipulation was done at runtime.