Translate storefront text, starting with French - #1524

Translated errors go stale when the language changes. The cart error (and storageWarning at lines 492/506) is stored as an already-translated string. If messages switches from frFR to enUS, the existing error/warning stays in French until the next mutation or storage write. Consider storing the cause or message key and calling describeError/formatMessage at render time.

Agreed, fixed in 7c627f1. The cart now keeps the failure's cause and a storage-unavailable flag, and translates both on render with describeError and formatMessage. Switching messages from frFR to enUS updates an error already on screen. A new extensibility test covers this: it switches an English cart error to French by rerendering. The catalog, product page and connection errors were already described on render, so this was the last stored string.

Malformed message input can crash rendering. If a plural object has no other form (e.g. {"one": "{count} produit"} with count 3), or a value is not a string/object (e.g. "sale": 1), text ends up non-string and text.replace throws. The README invites loading messages from JSON, and an invalid locale already falls back safely; falling back to enUS[key] here would be consistent.

Fixed in 7c627f1. formatMessage now checks the message's shape, so a malformed one falls back to enUS[key] instead of throwing. A plural with no matching form uses other. If other is missing too, or the value isn't a string or plural object, it uses the English message. Covered by a new test with {"one": "{count} produit"} at count 3, and "sale": 1.

fallbackCurrency is never passed. The changeset says this no longer assumes USD, but no caller passes the store currency and the default is still 'USD', so an empty/untotaled EUR cart still reports USD. Either pass the configured currency through from callers or make the parameter required.

Good catch, reverted in 7c627f1. Nothing in the server package calls getCartSummaryTotals, and the package's index doesn't export it, so the parameter did nothing there. The server package is now unchanged and dropped from the changeset. I kept the parameter in the storefront: getCartSummaryTotals is public there, so a host can pass config.currencyCode, and the default stays 'USD' for compatibility. The storefront's own cart uses the store currency through cart-state.ts (cart currency ?? config.currencyCode). The changeset now says the fallback is optional, not that USD is gone.

Inherited properties can match error codes. messages.errorCodes[error.code] has no own-property check, so a server code like constructor or toString returns a function (truthy), which then flows into cart error state and the error event. Suggest Object.hasOwn(messages.errorCodes, error.code) or a null-prototype object.

Fixed in 7c627f1. describeError now uses the entry only if Object.hasOwn(messages.errorCodes, code) and the value is a non-empty string. A test covers code 'constructor': it gets the server text in English and requestFailed in French.

Behavior change for title={null}. The previous default parameter only applied to undefined; title ?? text('relatedTitle') also replaces null, so sites passing title={null} to suppress the heading will now get "You may also like". Consider title === undefined ? text('relatedTitle') : title.

Fixed in 7c627f1. RelatedProducts uses the default only when title === undefined, so title={null} hides the heading text again, as it did before. I made the same change to CatalogHeader's title and description, which had the same ?? regression, and added a test for null there.

formatRange with equal min/max returns an approximate value. Intl.NumberFormat#formatRange(2000, 2000) yields ~$20.00 in en-US. ProductCardPrice guards against this, but the exported useMoneyRange/moneyRange don't; returning format.format(min) when min === max would fix it for custom parts too.

Fixed in 7c627f1. moneyRange (and so useMoneyRange) returns format.format(min) when min === max, before calling formatRange, so custom parts get an exact price. Covered for en-US/USD and fr-FR/EUR.

Memo invalidates on every render with the README pattern. resolvedMessages is keyed on messages identity, but the README example messages={{ ...frFR, checkout: 'Commander' }} creates a new object each render, which cascades to every useMessage callback and the sample-cart/product-card memos. Consider a shallow key comparison, or document that messages should be stable (e.g. hoisted or memoized).

Fixed in 7c627f1 rather than documented, since the README pattern is the natural way to write it. The provider compares messages by its top-level keys and values, and only rebuilds the resolved messages when one changes. So messages={{ ...frFR, checkout: 'Commander' }} keeps useMessage and the dependent memos stable across renders. A test checks that useMessage returns the same function across rerenders with an inline object, and that the text updates when a value changes. The test fails without the fix. errorCodes is compared by identity, so an inline errorCodes object still rebuilds. I think that's fine, and hoisting it fixes it.

Uncached Intl.NumberFormat. currencyFormat constructs a new formatter on every money/range call (every card price, line, subtotal, and label per render). messages.ts already caches formatters by locale; the same Map-cache keyed by ${locale}|${currency} would work here.

Fixed in 7c627f1. currencyFormat caches the formatter and its scale in a Map keyed by ${locale}|${currency}, as messages.ts does for plurals and numbers. Locales and currencies are few per page, so the cache stays small.

Nit: duplicates useMessage. Components like SampleAction call useCommerce() just for messages to pass to sampleName, next to const text = useMessage(). text('sampleProductName', { number }) does the same; sampleName could be kept internal to SampleCartProvider where there's no hook context.

Agreed, done in 7c627f1. SampleAction and ProductCardRoot now use text('sampleProductName', { number }) from useMessage, and no longer pull messages from useCommerce. sampleName is no longer exported and is only used inside SampleCartProvider, which builds the cart items and the added-item name.

Nit / maintenance: shared phrases ("Ajouter au panier", "Sous-total", "Passer la commande") are copied from @godaddy/localizations. Understood that this is deliberate, but fixes from the native-speaker review will need to be applied in both packages to avoid drift.

Agreed this is the trade-off. I kept the copy rather than adding a dependency, because @godaddy/localizations is shaped for checkout and has many more keys, and the storefront ships French as a standalone subpath with no imports. To limit drift, 7c627f1 adds a line to the storefront notes in AGENTS.md: the shared checkout phrases follow @godaddy/localizations' frFr, and wording fixes should go to both packages. A shared-phrases module could replace this later if more languages make the drift costly.

Thanks for the fix. One gap: nested overrides still change every render. shallowEqual compares only top-level values with Object.is, so an inline nested override, such as messages={{ ...frFR, errorCodes: { ...frFR.errorCodes, not_found: 'Introuvable' } }} or an inline plural like cartButtonLabel: { one: '…', other: '…' }, is a new reference each render. The check fails, and the merged messages, useMessage's text, and the memos that depend on them are rebuilt every render. The new test only covers a top-level string override. Comparing one level deeper (plain objects only) would cover errorCodes and plural messages.

Fixed in b15cc8a. The comparison now goes one level deeper for plain-object values, which covers errorCodes and plural forms. Strings and other values are still compared with Object.is. The test now uses a new plural and a new errorCodes object on every render, and fails with the old top-level comparison.

Writing stable.current during render isn't safe under concurrent rendering. If React throws away a render (an interrupted transition, or StrictMode's second render), the ref keeps that render's messages, and the next committed render can return a value that was never committed. A safer pattern is to keep the last committed value in state and update it with the "compare during render, then setState" pattern, or to compare against a ref that is updated only in an effect (useLayoutEffect). Since messages is just data, useMemo keyed on a stable serialization of the messages would also work.

Agreed, fixed in b15cc8a. The kept value is now state rather than a ref. During render, it's compared with the new messages. If they differ, the hook calls setState and returns the new messages, React's documented pattern for storing information from previous renders. A render React discards leaves nothing behind, because its update is discarded along with it. The stability test now renders inside StrictMode.

describeError can still throw on partial messages. It's exported, and Object.hasOwn(messages.errorCodes, error.code) throws a TypeError when errorCodes is missing, for example when a custom part passes messages loaded from JSON instead of the provider's merged messages. formatMessage now falls back safely, so this is the one remaining path that can crash rendering. Something like const codes = messages.errorCodes ?? enUS.errorCodes; (or guarding with messages.errorCodes &&) would close it.

Fixed in b15cc8a. describeError reads messages.errorCodes into a local and checks for undefined before Object.hasOwn, so messages without errorCodes fall through to the generic text instead of throwing. Covered by a new test.