report(flow): import lhr strings

[adamraine]

The report is borked if a navigation category has null score because Util.i18n is not initialized when rendering category gauges on the summary page.

This PR imports the UI strings from the first lhr and uses them to initialize Util.i18n.

#11313

[adamraine]

We can now use lhr strings pretty easily.

[brendankenny]

We can now use lhr strings pretty easily.

this is great

[brendankenny]

We can now use lhr strings pretty easily.

this is great

[brendankenny]

how hard would it be to test this fallback mechanism? Delete a string from a locale, load a report with that locale, check that all the strings are present?

[adamraine]

I think it's possible. Most annoying part would probably be mocking the localized-strings.js file.

[brendankenny]

I was just trying to think of how we can have a test catch regressions in this system, because even when you manually check a report in one language you may not notice a single missing string, and we don't look at reports in other locales all that often.

Since the flow report strings are all known at build time (unlike the report strings, which depend partly on what's in the LHR), another option is to just go through all the locales and check that all the strings are there. When you pose it that way it kind of reveals itself as not that strong of a test, but it would be exhaustive, it should still be pretty fast, and it wouldn't require mocking :)

[adamraine]

I'll add an item to #11313

[adamraine]

Looks like static i18n = null is causing issues for yarn build-devtools. Not sure exactly why, but I think reverting to the @ts-ignore will be fine for now if we plan to remove i18n from Util.