Lighthouse: Custom locales

[connorjclark]

Was thinking about how to support lazy-locales in DevTools. What about adding "custom locales" via the plugin system? Would have to complete our plugins in DevTools story.

Would just add to LOCALES in ./lighthouse-core/lib/i18n/locales.js ASAP. So, in DevTools, the lazy module loading would pass in the extra locale for w/e the AuditPanel was configured to use.

Link to devtools-entry.

Also would enable my dream of making a pirate translation.

[lmitchell]

This seems like a reasonable approach. One note, we'll still want to package en-US.json with the bundle, so that it's picked up by default. The DevTools will not make a request for locale strings when the language is set to English, so they need to be baked in.

[brendankenny]

Another approach would be to make bundle(s?) of locales with whatever script comes out of #8755 for swapping LHR locales. Lighthouse would run as it does today (with the en-US.json strings default), then do a locale swap with the desired language before displaying the report.

A benefit of this would be that we wouldn't have to get clever with bundle splitting or triggering downloads in core...all of the locale stuff could be handled by Audits2Panel in DevTools.

[patrickhulce]

+1 to shipping #8755 bundles and still generating as usual. Though I called it a "locale rewriter" bundle, great minds think alike :)

[lmitchell]

To confirm, you're suggesting we do something like modify AuditsPanel2.js!_startAudit to call swapLocale(lhr, requestedLocale) before calling through to _buildReportUI(lhrReport). swapLocale would be included as part of lighthouse-dt-bundle.js, correct?

Assuming the DevTools package the Lighthouse \LocaleMessages would be set by the DevTools?

[patrickhulce]

To confirm, you're suggesting we do something like modify AuditsPanel2.js!_startAudit to call swapLocale(lhr, requestedLocale) before calling through to _buildReportUI(lhrReport).

That is roughly my suggestion. I was thinking this happens on the worker side before returning the result object so all the remote module code execution stays in the worker, but it's very similar points in the lifecycle. Based on @brendankenny's comments it sounds like he might have been thinking it happens in the Audits2Panel context though?

swapLocale would be included as part of lighthouse-dt-bundle.js, correct?

My proposal at least was that swapLocale would be provided by a separate, locale-specific bundle. This keeps lighthouse-dt-bundle.js generic to running Lighthouse, and the locale rewriting logic is relatively self-contained to the environments.

It's certainly possible to have the lighthouse-dt-bundle.js do this work but at that point there's not a lot of sense in having it happen post-run at all. If it's easier for clients to do 43 different lighthouse-dt-bundles in all environments than it might be worth absorbing this effort in core.

[brendankenny]

To confirm, you're suggesting we do something like modify AuditsPanel2.js!_startAudit to call swapLocale(lhr, requestedLocale) before calling through to _buildReportUI(lhrReport).

yes, I believe so

swapLocale would be included as part of lighthouse-dt-bundle.js, correct?

we'd have to adapt to what's feasible, but I was suggesting it be in a separate bundle. Basically (as a handwavy example) devtools could fetch a lighthouse-swap-fr-bundle.js which would have a single exported function swapLocale(lhr) that would take an existing lhr and localize to fr.

[brendankenny]

whoops, ninjaed :)

I was thinking this happens on the worker side before returning the result object so all the remote module code execution stays in the worker, but it's very similar points in the lifecycle. Based on @brendankenny's comments it sounds like he might have been thinking it happens in the Audits2Panel context though?

it was just an idea, I don't actually know all that much about how fetching remote modules works :)

I was thinking running them in two workers would allow DevTools to fetch the two bundles (lighthouse-dt-bundle.js and the locale bundle) separately and run them in succession. If that's easy to do in the one worker that's also totally fine from a Lighthouse-functionality perspective. If we can do it with split bundles like this, I think how exactly the two are run will come down to ergonomics in the DevTools codebase, which is a nice spot to be in.

[lmitchell]

I'm tracking with you now. Thanks for the clarification.

We were thinking from the point of view of including the \.pak in the browser, which would be loaded by the browsers resource system. In this case, it would be wasteful to disk footprint to include lighthouse-swap-\

If we were to segment the lighthouse/\

We'll have a look at using remote bundles for lighthouse-swap-fr-bundle.js. We'll have to consider the disk hit for bundling everything on builds (i.e. ChromeOS, others?) that can't pull from a remote server.

[lmitchell]

@JoelEinbinder, I'd like to get your take on using remote modules of lighthouse-swap-<locale>-bundle.js to enable localization of Lighthouse reports in the DevTools.

[brendankenny]

Technically possible with #9638