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.

[youknowriad]

One thing I want to note too is that all these tools were built in a time where switching local without reloading the page was deemed mandatory to support. I wonder if we could make things a lot simpler by avoiding this requirement.

[youknowriad]

@aduth @jsnajdr Would love your thoughts on this. What's the ideal way? Is it the same as the pragmatic choice? (Initialize localization and i18n properly in the new hosting dashboard where we don't want to inherit calypso's bloat)

[arthur791004]

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.

Proposed #103333 to isolate the logic for "fetching and caching translations for a given locale" by abstracting the i18n implementation.

With this change, we no longer need to rely on both CalypsoI18nProvider and i18n-calypso in the v2 dashboard.

Any thoughts?

[jsnajdr]

I think you shouldn't reuse the existing code in client/boot or i18n-utils. That's a very entangled code with long history: supporting two i18n libraries, storing locale state in Redux, interplay with server-side rendering... This PR and #103333, they add even more complexity: abstracting away the two libraries, making Redux optional...

You'll be better off if you do it from scratch for the hosting dashboard. You should understand from first principles what's really needed to set up a locale:

• fetch the Calypso translations .json from the right URL
• avoid the fetch when production server sends an inline JSON object as part of the page
• initialize the @wordpress/i18n library with the .json data
• initialize the number/currency formatting library with the locale name
• advanced: hook into webpack runtime and load translation chunks together with JS and CSS chunks

Setting up localization should be in principle very simple, so let's avoid all the unnecessary complexity.

As an illustration of the complexity, I still have three very old PRs open that tried to clean it up a little bit, but they all failed and I never finished them: #58172, #58343, #58345.

One thing I want to note too is that all these tools were built in a time where switching local without reloading the page was deemed mandatory to support.

The main part of switching locale at runtime is using reactive __() helpers in React components. Don't use the __ exported by @wordpress/i18n, but use the __ returned by the useI18n() hook exported by @wordpress/react-18n. You should use the reactive hook helpers, even though you're no used to that from Gutenberg. The main reason is not runtime locale switching, but server side rendering. If you want to have a chance at server-side rendering any of the Dashboard pages, they need to get __ from React context. Because on the server there's no valid global i18n object. The Node.js server is serving many users at once, from one process, and each of them needs to have their own i18n object in the request context, and also in the React context.

[tyxla]

Maybe @yuliyan might have some thoughts to add on this one.

[taipeicoder]

@arthur791004 @youknowriad I'm hesitant for Lego to rewrite the i18n given that we don't really have expertise in this area, and would rather see progress being done on the sites settings as discussed with the team. Would it make more sense to ask global team to pick this up? And what's the overhead of directly using i18n-calypso?

[yuliyan]

Maybe @yuliyan might have some thoughts to add on this one.

I think @jsnajdr's comment covers everything pretty well. I'd personally go with his suggestion about using our own implementation to set up the locale, rather than reusing the setup from the main app.

Happy to help if you need any directions or testing when you're ready with the implementation.

[jsnajdr]

I'll try to write some basic i18n bootstrap code, of the kind I recommended in an earlier comment. Let's see if it was really a good idea 🙂

[arthur791004]

You should understand from first principles what's really needed to set up a locale:

• fetch the Calypso translations .json from the right URL
• avoid the fetch when production server sends an inline JSON object as part of the page
• initialize the @wordpress/i18n library with the .json data
• initialize the number/currency formatting library with the locale name
• advanced: hook into webpack runtime and load translation chunks together with JS and CSS chunks

This aligns with my understanding as well. I initially considered starting from scratch, but I realized that's essentially what setupLocale is doing—it just consolidates the intermediate results together with i18n-calypso. Additionally, I wasn't sure whether we still need to support some older features like empathy mode, which is why I chose to abstract the i18n layer to avoid making big changes 😅

[fushar]

I checked out this locally. I found that the new language I set in /me isn't reflected here unless I comment this line out 🥲 are you experiencing the same?

wp-calypso/client/dashboard/app/auth/index.tsx

Line 29 in fa2bc0f

staleTime: 30 * 60 * 1000, // Consider auth valid for 30 minutes

[aduth]

We probably need to invalidate React Query caches for anything that depends on /me information when we know that we've changed that information (i.e. updated the language in the interface).

https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation

[tyxla]

The reduxStore optionality feels a bit suboptimal here 😬 It's not clear what it means: is it because the global Redux store has not been initialized yet, or because we don't intend to have one at all? Definitely feels like a code smell to avoid.

There could be some opportunities for decoupling and reusability, but in general, I agree with what @jsnajdr suggested above, which is, building a simpler version that works with the constraints at hand.

[arthur791004]

Closing this, as we’ve decided to rewrite the locale functionalities into smaller, composable pieces to better support Dashboard v2.