FIX: Phone Field frontend translations now follow WordPress locale https://github.com/Crocoblock/issues-tracker/issues/19665

[Gawuww]

Issue

• https://github.com/Crocoblock/issues-tracker/issues/19665

[github-actions]

🤖 AI PR Review

Risk level: medium

Review

Summary

• This PR updates the built Phone Field JS bundles so frontend country name translations follow the WordPress locale. The main runtime change is in modules/blocks-v2/phone-field/assets/build/frontend/field.js: locale detection/normalization now prefers a new window.jfbPhoneFieldLocaleContext (pageLocale/pageLang/siteLocale/siteLang), normalizes to WP-like locale formats, and loads the corresponding i18n chunk dynamically. The editor build also has minor accessibility/ID changes for BaseControl elements and other build-output renames.

What I checked

• Files changed (built assets):
  • modules/blocks-v2/phone-field/assets/build/frontend/field.js (+ many frontend i18n chunks)
  • modules/blocks-v2/phone-field/assets/build/editor/index.js and index.asset.php
  • other frontend asset *.asset.php versions changed
• Behavior: frontend now attempts to determine locale from window.jfbPhoneFieldLocaleContext (if present) -> falls back to document.documentElement.lang -> window.wp.i18n previously used -> then 'en'. Locale strings are normalized and mapped to available locale chunks; chunks are cached once loaded.

Positive

• Locale detection is more robust and aligned with WP environment when the theme/plugin provides window.jfbPhoneFieldLocaleContext.
• Dynamic imports are cached (s[t]) so repeated loads are avoided — good for performance.
• Editor accessibility: adding id attributes to BaseControl containers improves a11y of inspector controls.

Security

• I see no new server-side or submission endpoints touched. The JS reads client-side globals (document.documentElement.lang, window.*) which are expected; nothing is being posted or used in SQL. No nonce/capability changes necessary.
• Ensure any server-side injection of window.jfbPhoneFieldLocaleContext does not include sensitive data — it should only contain locale/language context (pageLocale/pageLang/siteLocale/siteLang).

Potential issues / suggestions

1. Built assets only in PR

   • This PR changes built JS files. I do not see the corresponding source (ESNext/React) changes. Please ensure the source files are updated and committed, then rebuild assets so the source -> build mapping is reproducible. Committing only build artifacts makes future debugging and code review harder.

2. Server-side injection of locale context

   • The new runtime prefers window.jfbPhoneFieldLocaleContext. If this is not set by the server, the code falls back to document.documentElement.lang and existing fallbacks. For reliable WP locale behavior (especially for backend-rendered pages, multilingual plugins, or multisite setups), please ensure the plugin prints the page/site locale into the front-end via wp_add_inline_script/wp_localize_script (e.g. set window.jfbPhoneFieldLocaleContext = { pageLocale: get_locale(), siteLocale: ... } or similar). Otherwise some pages may still rely on document.lang which can be different from WP locale in certain setups.

3. Mapping / normalization correctness

   • The PR adds normalization and mapping logic to derive a short-code locale (e.g. 'fr'/'en') and then map to chunk names. Please double-check the mapping table covers all WP locale codes you support (including region variants) and that the normalization function handles edge-cases properly (e.g. languages with script subtags, or uncommon locale formats). Consider adding a few more fallbacks for non-standard locale strings.

4. Tests

   • This affects locale logic that matters for many users. Please add at least one automated JS unit test (or e2e) that simulates different values of window.jfbPhoneFieldLocaleContext, document.documentElement.lang and window.wp.i18n.getLocaleData to assert the correct locale chunk is loaded and i18n strings used.

5. Multisite / multilingual plugins

   • In multisite and where WPML/Polylang are present, page language/locale can differ from site default. The PR already supports a context object (window.jfbPhoneFieldLocaleContext) with pageLang/pageLocale/site values — ensure WP-side integration populates this appropriately. Also verify behavior on cached pages/CDN where document.lang may not reflect the user/requested locale.

6. Graceful failure and logging

   • The dynamic import catch simply console.error and returns {} — which is fine, but consider a debug flag or more descriptive error in dev mode to ease debugging when a locale chunk fails to load.

7. Caching & performance

   • Good: locale chunks are cached client-side in module-level cache. No extra perf concerns. Just ensure that larger sites do not eagerly load many chunks; dynamic import is fine only when needed.

8. Minor: file endings

   • Several built files report "No newline at end of file". Not a functional problem, but tidy to add final newlines.

Acceptance checklist before merge

• Confirm source files corresponding to build output were updated and committed, or regenerate builds from updated source and include both.
• Add server-side injection of jfbPhoneFieldLocaleContext (PHP) so WP locale/page locale are reliably passed to frontend (multisite/multilingual aware).
• Add at least one JS test (unit/e2e) for phone field locale resolution and i18n chunk loading.
• Smoke-test various locale/site-language combinations (admin/editor pages, frontend, cached pages) and confirm flags/labels are localized correctly.

Overall

• The change looks like the right direction: prefer WP locale and a single source-of-truth for locale context. Please add the server-side wiring and tests, and commit source changes (not only build output) before release.

Suggested changelog entry

- FIX: Phone Field frontend translations now follow WordPress locale (improved frontend locale detection and i18n loading for phone field)

[github-actions]

🤖 AI PR Review

Risk level: medium

Review

Summary

• This PR improves the Phone Field frontend locale handling so intl-tel-input translations follow the WordPress locale/context. It adds locale normalization and resolution, injects a small locale context object via wp_localize_script, and updates a few frontend/source files (and regenerates built assets). There are also small editor/Accessibility fixes (unique ids for BaseControl).

What I reviewed (not exhaustive):

• PHP: modules/blocks-v2/phone-field/block-asset.php (wp_localize_script additions)
• JS (source): modules/blocks-v2/phone-field/assets/src/frontend/field/i18n-loader.js (normalizeLocale, resolveIntlLocale, getPageLocale, loader changes)
• JS (source): modules/blocks-v2/phone-field/assets/src/frontend/field/PhoneFieldData.js (use page locale, misc refactors, strict checks)
• JS (source): modules/blocks-v2/phone-field/assets/src/editor/block/edit.js (added id attributes to BaseControl)
• Regenerated build artifacts under assets/build/** (editor & frontend bundles, asset manifests)

Positive

• Locale resolution is more robust: code normalizes locales (e.g. en-US -> en_US) and falls back from full locale -> language -> en when no translation exists.
• Caching of loaded translations remains in place (translationCache), avoiding repeated network loads.
• The PHP-provided jfbPhoneFieldLocaleContext gives multiple locale sources to the client (pageLocale, pageLang, siteLocale, siteLang), so the frontend can pick the best candidate.
• Accessibility: adding unique ids to BaseControl improves Inspector accessibility and is a good improvement.
• Code style in source files improves readability (small refactors, clearer equality checks, removed unused error variable in catch, etc.).

Risks / Issues / Suggestions (required)

1. Backward-compatibility: determine_locale() call

   • In block-asset.php the code uses determine_locale() directly. determine_locale() was introduced in WP 5.x (it exists in modern WP), but to be safe across older environments use a fallback:

     $page_locale = function_exists( 'determine_locale' ) ? determine_locale() : get_locale();

   • Please add the check to avoid potential fatal errors on very old WP versions if the plugin supports them.

2. Data attribute boolean coercion (possible BC change)

   • In PhoneFieldData.js the logic changed from loose equality (1 == separateDialCode) to strict check separateDialCode === '1'. This is more correct for DOM dataset strings but could change behavior if other parts of the code (or third-party integrations/snippets) wrote data-separate-dial-code="true" or the build pipeline provided boolean true instead of string '1'. Recommend making the check robust to both common forms, e.g.:

     separateDialCode: separateDialCode === '1' || separateDialCode === 'true' || separateDialCode === true

   • Please confirm how the data attribute is emitted server-side and make the check accept that form.

3. wp_localize_script safety / escaping

   • wp_localize_script is used to expose locale strings. These values are locale identifiers (safe) but as a general hardening suggestion prefer to ensure values are strings and/or pass through esc_js() if you build the inline script manually. wp_localize_script is OK for this use-case.

4. Tests

   • There are no tests added around the new locale-detection/resolution behavior. This is a medium-risk change (affects UI language selection). Add unit / integration tests where possible (or at least manual QA steps) to validate the following cases:
     • document.documentElement.lang set to 'en-US' | 'en_US' | 'en' -> resolves to en
     • WordPress locale values like 'ru_RU' -> resolves to ru
     • custom window.jfbPhoneFieldLocaleContext overrides/existing values are used when present
     • behavior when no locale translations exist (falls back to English)

5. Build artifacts

   • The PR includes regenerated build files (assets/build). Ensure those were generated using the repository's standard build pipeline and that sourcemaps / hashes are correct. It's important to keep build files in the repo in the exact format used by CI.

6. Optional: broader locale candidates

   • The new getPageLocale collects several candidates (pageLocale, pageLang, documentElement.lang, siteLocale, siteLang). This is good. Consider adding a small comment in PHP next to wp_localize_script explaining why both determine_locale() and get_locale() are passed (to avoid future regressions).

7. Error logging in loader

   • The original loader logged an error when dynamic import failed; new code intentionally swallows the error (catch {}). That's OK but might make debugging harder if translations fail to load. Consider logging at debug level or at least for dev environments.

Security

• No direct security issues spotted: only locale strings are passed to the frontend via wp_localize_script. No new write/DB operations or nonce/capability changes.
• Continue to treat any fetched external resources (ipinfo.io) as untrusted: the code already catches errors and uses a sessionStorage cache.

Performance

• No regressions. Translation loading remains conditional (only non-English locales load a chunk). Caching of loaded translations is present. The ipinfo request is only performed when auto-detection is used and is cached in sessionStorage.

Files to adjust before merge (recommended)

• modules/blocks-v2/phone-field/block-asset.php: change determine_locale() usage to a function_exists fallback. Example:

  $page_locale = function_exists( 'determine_locale' ) ? determine_locale() : get_locale();
  wp_localize_script( $handle, 'jfbPhoneFieldLocaleContext', array(
    'pageLocale' => $page_locale,
    'pageLang'   => get_bloginfo( 'language' ),
    'siteLocale' => get_locale(),
    'siteLang'   => str_replace( '_', '-', get_locale() ),
  ) );

• modules/blocks-v2/phone-field/assets/src/frontend/field/PhoneFieldData.js (and mirrored built file): make the separateDialCode detection accept common alternatives ("1", "true", boolean true) to reduce backward compatibility risk.

• Add tests or QA checklist covering locale resolution and defaulting behavior.

Conclusion

• PR is a useful improvement (frontend translate phone field to WP locale). The changes are mostly good and well-implemented. Please apply the minor compatibility fix (determine_locale fallback) and make the separateDialCode parsing a bit more permissive to avoid regressions with third-party or legacy code. Add tests or QA steps for locale resolution.

Suggested changelog entry

- FIX: Phone Field frontend translations now follow WordPress locale (improved locale detection and i18n loading)