I18N: Fix the lib/wp was called before locale data was ready

[arthur791004]

Part of I18N-217

Proposed Changes

• Referring to lib/wp: use Core i18n to read current locale, there was an issue where the locale data was not ready before calling the endpoint, preventing the _locale parameter from being injected correctly.
• This PR proposes waiting for the locale data before rendering, so that lib/wp receives the correct locale.
• An alternative approach would be to fallback to _locale: 'user'; however, it is unclear whether this might cause issues for logged-out users.

Why are these changes being made?

• We should display correct language to our users

Testing Instructions

• Switch your account to non-en language
• Go to /sites/:site
• Refresh the page
• Before this change, you may see the Plan is rendered as English
• After this change, you should see the Plan is renders as your current language

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 tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• 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-162110

Jetpack Cloud live (direct link)

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

Automattic for Agencies live (direct link)

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

[arthur791004]

@jsnajdr I would appreciate it if you could review this and share any concerns or feedback regarding this approach 🙏

[matticbot]

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

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

• notifications
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug fix/api-fetchers-locale on your sandbox.

[jsnajdr]

Yes, this makes sense to me 🙂

alternative approach would be to fallback to _locale: 'user'; however, it is unclear whether this might cause issues for logged-out users.

I agree, _locale: 'user' wouldn't work for logged out users, e.g., on the login and signup pages, and other "landing" pages like accept invite etc.

[jsnajdr]

Why did you change the order of switchLocale and dispatch in this function?

[arthur791004]

Previously, we couldn’t guarantee the order because switchLocale sends requests to fetch the locale data, but we weren’t waiting for the response. As a result, I’m not entirely sure this "changes" the order.

Do you think we should now ensure that the locale data is fully loaded before dispatching the action to update the locale in the Redux store?

[jsnajdr]

Yes, it makes more sense to me if the entire app state (i18n libraries, Redux, DOM state set in setLocaleInDOM) is switched synchronously at once.

With the flipped order, the Redux state would be set first and then the rest only after a while. That doesn't sound very reliable.

[jsnajdr]

As a code quality improvement, it would be nice to rewrite this await+then mix into pure try/catch/await code.