-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
i18n: fix custom formatted ICU within plurals #9460
Conversation
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.
thanks for cleaning this up for realz @exterkamp! :D
lighthouse-core/lib/i18n/i18n.js
Outdated
* Note: This function will recursively inspect plural elements for nested arguementElements. | ||
* | ||
* @param {Array<import('intl-messageformat-parser').Element>} parsedIcu | ||
* @param {Map<string, import('intl-messageformat-parser').Element>} elements |
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.
unexpected that this returned a map, can we add the return type explicitly?
Co-Authored-By: Patrick Hulce <[email protected]>
lighthouse-core/lib/i18n/i18n.js
Outdated
* | ||
* Note: This function will recursively inspect plural elements for nested arguementElements. | ||
* | ||
* @param {Array<import('intl-messageformat-parser').Element>} elementsList |
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.
typically we just use plurals for arrays of things unless the list
gives extra info about the value. I like @patrickhulce's earlier suggestion of icuElements
(or messageElements
...plain old elements
is confusing in web-related terminology :) for this, personally.
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.
some last naming things, but otherwise LGTM!
what do you think about a follow up PR to add a check in collect-strings
that there aren't strings that will run into the same issue as the one in resource-summary
so we don't have to wait for translation feedback that we messed up again? Not worth it or easy to check?
(we maybe also want to add guidance to the readme on how things should be nested)
@patrickhulce over to you |
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!
* @param {Array<import('intl-messageformat-parser').Element>} icuElements | ||
* @param {Map<string, import('intl-messageformat-parser').Element>} seenElementsById | ||
*/ | ||
function _collectAllCustomElementsFromICU(icuElements, seenElementsById = new Map()) { |
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.
what an awesome journey this function as had...
it's so. good. now :D
Summary
Allow custom formatted ICU
{var, number, bytes}
to be nested inside{var, plural, ...}
ICU blocks, and have it be formatted properlyRelated Issues/PRs
fixes: #9378