Test React hydration when outsourced work adds localization

Reconstruct the first half-second

Hydration localization defects are often timing defects. List what the server knows when it writes HTML: URL locale, cookie, account setting, request timezone, message revision, and feature flags. Then list what the browser discovers later, such as local storage or an operating-system preference. When those sets disagree, the product needs an intentional transition. Suppressing a warning only hides the evidence. Use a synthetic order near midnight UTC so the same instant can display as a different day as well as a different language.

Save the raw HTML before JavaScript runs. Hydrate it under a controlled browser locale and timezone, then capture console output, the resulting DOM, focus, accessible names, and first visible paint. Repeat with the optimized build. Development diagnostics and Strict Mode can change timing, while production may quietly replace a mismatched subtree. The test should say which text may update after hydration and which response content must remain stable until navigation or an explicit preference change.

Choose translations that stress structure

A translated greeting proves little. Build cases for zero, one, two, and a larger plural count; a currency with no minor unit; a right-to-left message containing an identifier; a long label inside a compact control; and a missing key whose fallback has different markup. Check that labels still reference their controls and that line wrapping does not hide actions. These fixtures make localization part of component behavior instead of a string substitution performed after the component is considered finished.

Formatter calls must receive named inputs during the hydration pass. Reading the current clock, default timezone, or browser locale from inside rendering makes the first client result depend on a machine the server never saw. If client-local time is a product requirement, render a stable value first and document the later correction. Test the change with focus inside the affected region so React cannot discard an interactive node without the review noticing.

Slow message loading exposes mixed-language pages

Delay one message bundle while the page streams. Observe the shell, fallback, and resolved region. Navigate to another locale before the slow response finishes. A late English region inserted into a Filipino page is a race even if a refresh fixes it. Record catalog identifiers and requested locale with the test revision, but do not log account claims or translated private content. The error boundary should preserve the locale and offer a deliberate retry rather than falling back to whatever catalog happens to be cached.

Repeat with an invalid stored preference and a missing translation. Decide whether the application uses a parent locale, a source language, or an explicit unavailable state. That hierarchy needs one owner and one implementation. Components should not invent different fallbacks. If a failed catalog load replaces a form, check whether typed data and focus survive. A language fallback that discards work is not a harmless display issue.

Deliver a locale matrix, not a screenshot album

Pair each server locale and timezone with browser preference, expected HTML, permitted client update, warning result, final text, direction, focus, and accessible name. Attach only the saved HTML and screenshots that explain decisive differences. Include supported browser and React versions. Run a missing-key control so the reviewer knows the test would detect a broken catalog. A matrix makes it possible to add a locale later without copying an undocumented sequence of manual clicks.

End with the policy question that code cannot answer: does a stored browser preference override the response immediately, after hydration, on the next navigation, or only after confirmation? The programmer can show the visible and technical consequences. The product owner chooses precedence and the supported locale set. Put that answer in the ticket and in a focused regression test so future screens do not create their own hierarchy.

Use differential runs to locate the first unstable value

When a mismatch appears, change one input at a time. Hold the URL, cookie, catalog revision, timestamp, and feature flags constant while switching only the browser locale. Then restore the locale and switch only the timezone. Repeat for currency and numbering systems if the product supports them. Save the server text and the first client render for the smallest node that differs. This prevents a team from blaming translation copy when the real cause is a clock read, random identifier, invalid nesting, or an environment-specific formatter. Test an instant on both sides of daylight-saving transitions and a plural count whose category differs by language. For bidirectional content, include an account code and telephone number so punctuation and isolation errors are visible. Verify the document language and direction at the correct container, not merely on a menu. If localized rich text can include links, confirm the translator-controlled structure cannot detach a label from its destination or create unsafe markup. These cases describe observable output and remain useful even if the message library changes.

Recovery deserves its own run. Corrupt one cached catalog response, serve an older catalog with newer application code, and make the requested locale unavailable during a client navigation. Determine whether the screen keeps its last coherent language, shows a bounded error, or moves to an approved fallback. It must not assemble a sentence from two catalog revisions or strand focus inside a subtree React replaces. Reload after the failure and confirm cache invalidation actually fetches a usable catalog. Inspect monitoring for locale, catalog version, route, and error category without recording private rendered copy. Add a production browser test that compares stable semantic values rather than fragile serialized HTML, plus a server test for the exact initial strings. The release note should name supported locale and timezone pairs, fallback ownership, and any screen deliberately excluded. Localization bugs are easy to dismiss as cosmetic; the acceptance evidence should instead show whether the first response is truthful, the hydrated controls retain identity, and a failed catalog leaves the person with a comprehensible next action.

Buyer questions

Questions about planning the role