i18n: add registerLocaleData() method #9638
Conversation
|
|
||
| // And confirm that's what is returned | ||
| const formattedStr2 = i18n.getFormatted(str_(UIStrings.title), 'es-419'); | ||
| expect(formattedStr2).toEqual('es-419 uses https!'); |
There was a problem hiding this comment.
one more assertion that some other string that used to be there is removed? would be nice to clarify in the tests that it's not merging or something it's just totally replacing
| /** @typedef {import('./locales').LhlMessages} LhlMessages */ | ||
|
|
||
| /** | ||
| * Populate the i18n string lookup dict with locale data |
There was a problem hiding this comment.
should we link off to that design and/or mention how this is expected to be used?
|
|
||
| it('overwrites existing locale strings', () => { | ||
| const filename = 'lighthouse-core/audits/is-on-https.js'; | ||
| const UIStrings = require('../../../../' + filename).UIStrings; |
There was a problem hiding this comment.
any reason this is dynamic? seems like a static string would be easier to refactor when file is moved, etc.
| /** @typedef {import('./locales').LhlMessages} LhlMessages */ | ||
|
|
||
| /** | ||
| * Populate the i18n string lookup dict with locale data |
There was a problem hiding this comment.
| * Populate the i18n string lookup dict with locale data | |
| * Populate the i18n string lookup dict with locale data. |
| /** | ||
| * Populate the i18n string lookup dict with locale data | ||
| * Used when the host environment selects the locale and serves lighthouse the intended locale file | ||
| * @see https://docs.google.com/document/d/1jnt3BqKB-4q3AE94UWFA0Gqspx8Sd_jivlB7gQMlmfk/edit |
There was a problem hiding this comment.
none of this is seen by users of the LH module, though. Does that matter?
There was a problem hiding this comment.
whatcha mean? it's exposed at the module level..
There was a problem hiding this comment.
it's exposed at the module level..
The doc strings, I mean. They aren't in the module-level file and tools like vscode don't forward the jsdocs
| * Populate the i18n string lookup dict with locale data | ||
| * Used when the host environment selects the locale and serves lighthouse the intended locale file | ||
| * @see https://docs.google.com/document/d/1jnt3BqKB-4q3AE94UWFA0Gqspx8Sd_jivlB7gQMlmfk/edit | ||
| * @param {LH.Locale} locale |
There was a problem hiding this comment.
this threatens the little LH.Locale house of cards types. We should either limit to overriding existing locales (verify that locale here is actually of type LH.Locale) or get rid of LH.Locale and type all our locale names as string. There might be some side effects of the second option, though, if we depend on that behaving well.
There was a problem hiding this comment.
We should either limit to overriding existing locales
in reality this will only be used to override existing locales
There was a problem hiding this comment.
in reality this will only be used to override existing locales
This is partly what #9638 (comment) is touching on. I don't think we can treat it as a private api
| * Used when the host environment selects the locale and serves lighthouse the intended locale file | ||
| * @see https://docs.google.com/document/d/1jnt3BqKB-4q3AE94UWFA0Gqspx8Sd_jivlB7gQMlmfk/edit | ||
| * @param {LH.Locale} locale | ||
| * @param {LhlMessages} lhlMessages |
There was a problem hiding this comment.
similarly we should shape check this (a la plugins/budgets.json). All our good locale error handling code assumes the type is correct (and isn't such good error handling code if it isn't)
| * @param {LhlMessages} lhlMessages | ||
| */ | ||
| function registerLocaleData(locale, lhlMessages) { | ||
| LOCALES[locale] = lhlMessages; |
There was a problem hiding this comment.
There was a problem hiding this comment.
I'm a little afraid to make
LOCALESa mutable singleton like this now, but it's hard to think through the consequences and if they matter. #9296 and #9043 (and wherever thefield-performanceplugin feedback is) point at the fact that people likely will use this outside of devtools, though.
if we don't want to expose this to anyone but devtools (I believe @exterkamp also preferred not to do that), another option (sorry I didn't think of until right now) is something like
https://github.com/GoogleChrome/lighthouse/blob/b2dfb06221249d86dab667c241303b53c66203ed/clients/devtools-report-assets.js
basically rewriting locales.js to instead access the assets in the module. We could be clever instead of having to do it manually
There was a problem hiding this comment.
We could be clever instead of having to do it manually
@connorjclark could even get to use a proxy to rewrite any getter on the locales.js object into a request for the resource :)
| 'message': 'es-419 uses https!', | ||
| }, | ||
| }; | ||
| i18n.registerLocaleData('es-419', localeData); |
There was a problem hiding this comment.
this changes es-419 for all tests run after this, FWIW. It's makes for a more fragile test, but should we reset after it's done?
see Audits Panel Localization Design
This method enables us to "install" new locale strings into our i18n string lookup.
Unrelated, but I added a few more tests to getFormatted as a driveby.