Internationalization of Lighthouse (Phase 2)

[paulirish]

Picking up after #5719

Known work

• bring back https://github.com/GoogleChrome/lighthouse/pull/5726/files#diff-4bcfedf0736e1cd08b26fe659537ad90 to avoid A11y i18n #7010. i18n: enable local debug locale, en-XL #9192
• figure out Node's ICU support on Travis/Appveyor (Number.toLocaleString appears to always use 'en-US' - Travis failure)
  • presumably the node install is system-icu or small-icu
  • can we resolve with an NVM flag or travis config?
  • or better polyfilling. Fix in core(i18n): improve Intl polyfill and use it in Util #9584
• revamp i18n.lookupLocale and locale list to better canonical lookups
  • Intl.NumberFormat.supportedLocalesOf(['no', 'tl']) === [], so even though we support those locales in translations they get the wrong (?) number formatting, plurals, etc by falling back to a default locale (en, probably). Why do these in particular fail but all the others work?
• text baked into the report HTML
  • export dropdown i18n(report): runtime settings and tools #9166
  • header metadata
  • footer runtime settings i18n(report): runtime settings and tools #9166
  • Number.toLocaleString all numbers in report
    • scorescale!
  • aria labels
• a11y manual audits
• Translating strings from gatherers (error messages, etc)

finish complete l10n of lighthouse

• localize error messages. Localize the error messages #6441
• localize remaining categories
  • seo
  • best-practices i18n: localize audits in best-practices #9092
  • pwa i18n: pwa #9105
• localize stack packs?
• move pwa audits to audits/pwa folder
• move best-practices audits to audits/best-practices
• RTL layout @paulirish
• lang attribute report(i18n): set lang attribute according to locale #5805
• include locale json files in build
• warnings
• Date/Time Locales Report generated time is always in en-US #1703
• PSI swap langs? 😮 this guy wants it
• proto refactor i18n section. @past-shane you really messed this one up.
• Placeholder syntax i18n: placeholders #9114 to prevent Translation messing up linked docs in dom-size #9000
  • fix i18n guffaws A Collection of i18n Markdown Guffaws 😭😭😭 #9197
• es-419
• viewer locale swap?
• read locale info from system? e.g. Report generated time is always in en-US #1703
• i18n concat'd lists, like this

ship it

• [ ] ship l10n'd lighthouse to extension
• ship l10n'd lighthouse in devtools audits panel
• enable web.dev to use full l10n'd lhrs if they want

Plz add anything else here

[exterkamp]

Added some things that are todo

[brendankenny]

Number.toLocaleString all numbers in report

Answer to this is
https://v8.dev/features/intl-numberformat#units

const formatter = new Intl.NumberFormat('en', {
  style: 'unit',
  unit: 'kilobyte',
});
formatter.format(1.234); // en
// → '1.234 kB'

const formatter2 = new Intl.NumberFormat('ru', {style: 'unit', unit: 'kilobyte'})
formatter2.format(123.4); // ru
// → '123,4 кБ'

Conveniently it's in V8 7.7, which is the version shipping with the new Node 12.13, which became the LTS release in October. When we switch to node 12 as the new minimum in the spring or whenever, we can start using that.

[brendankenny]

We should also investigate what of our ICU polyfills can be dropped now that nodejs/node#29522 has landed.

[connorjclark]

@exterkamp and I discussed a desire to move the localization into the report renderer. Involves the LHR strings always being english, bundling all the locales in the report renderer (we could look into code splitting too), and doing the swap locales logic in the report (done based on user locale initally, but also exposed via a setting within the report).

wins:

• allows for the same report to be shared in multiple languages
• allows for the user to easily override what the channel thought their preferred language was
• would allow us to drop the RendererFormattedStrings in the proto