Hosting Dashboard: Introduce I18nProvider to make translation work correctly

[arthur791004]

Part of DOTCOM-10589

Proposed Changes

• Introduce the I18nProvider under /dashboard to setup the locale
• Make the reduxStore argument in the setupLocale function optional, and have the function return the resolved locale.

Needs to be discussed:

• Whether we want to introduce the CalypsoI18nProvider?
• Whether we want to use i18n-calypso?

Both setupLocale and switchLocale functions are tightly coupled with i18n-calypso. If we don't want to use i18n-calypso, we need to decouple the logic that fetches the locale data (enabled or disabled translation chunks) and then initial the locale data by @wordpress/i18n on v2 dashboard.

Why are these changes being made?

• Fix the translation on Hosting Dashboard V2

Testing Instructions

• Switch your account language to any locale other than English
• Go to /v2
• Ensure the translation works as expected

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143654

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143654&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143654&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• command-palette-wp-admin
• happy-blocks
• help-center
• notifications
• odyssey-stats
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug feat/dashboard-v2-i18n-provider on your sandbox.

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~498 bytes removed 📉 [gzipped])

name                    parsed_size            gzip_size
entry-dashboard-dotcom    +362779 B  (+32.5%)  +101635 B  (+29.2%)
entry-dashboard-a4a       +362779 B  (+32.9%)  +101604 B  (+29.6%)
entry-reauth-required        -892 B   (-0.0%)     -727 B   (-0.1%)
entry-subscriptions          -773 B   (-0.0%)     -688 B   (-0.1%)
entry-stepper                -773 B   (-0.1%)     -703 B   (-0.2%)
entry-main                   -773 B   (-0.0%)     -699 B   (-0.1%)
entry-login                  -773 B   (-0.0%)     -695 B   (-0.1%)
entry-domains-landing        -502 B   (-0.1%)     -529 B   (-0.3%)
entry-browsehappy            -242 B   (-0.1%)      -83 B   (-0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[chriskmnds]

Both setupLocale and switchLocale functions are tightly coupled with i18n-calypso. If we don't want to use i18n-calypso, we need to decouple the logic that fetches the locale data (enabled or disabled translation chunks) and then initial the locale data by @wordpress/i18n on v2 dashboard.

I feel this may be the better direction. The switchLocale logic can/should be decoupled, also the whole fetching and caching translation chunks can be modernized e.g. perhaps via Query hooks.

I did a brief exploration recently to just take out the relevant bits that bring the translation chunks (not in a "modernized" way). I wanted to explore instantiating the translate hook for another locale. You may or may not find this informative: https://github.com/Automattic/wp-calypso/pull/101444/files#diff-d4183e821955b796c8041d31d47959116b9077af3ee4707a110703ef9ff8eed0 (and FWIW - it worked)

But overall, I think if we can isolate the "fetch and cache translations for a given locale" in a way that these can be loaded into / used for any ad hoc i18n provider, then I feel that would be gold.