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.

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.

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

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 <locale>.json translations with the browser's resource system, which are fetched when an Audit is generated. Thoughts on how the requestedLocale's LocaleMessages would be set by the DevTools?

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.

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.

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.

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

We were thinking from the point of view of including the <locale>.json message translations with the appropriate .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-<locale>.js.

If we were to segment the lighthouse/<locale>.json to the matching browser locale .pak files, then we'd need a way to pass that to Lighthouse to perform the appropriate translations. Initially, we were thinking something of like runLighthouseWorker(..., locale, localeMessageJsonObject) or a helper that would accept localeMessageJsonObject.

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.

@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.

Technically possible with #9638