Configuring the notice language in WordPress

Choose the source of language truth

A single-language store can use a fixed notice language or the WordPress site language. Record the choice. Automatic selection should have a documented order and an English technical fallback rather than silently guessing from a browser header.

WordPress exposes Site Language under General Settings, but checkout and translated content may use a multilingual plugin’s current language. Test the storefront context rather than reading only the administrator locale.

Map locales to supplied files

Normalise regional variants deliberately: for example, a language code with a country suffix may map to the same supplied EU-language file. Reject unsupported values in settings and show the resolved file in diagnostics without exposing server paths.

Verify every route

Visit each product, cart, checkout, order-confirmation, email and durable-record route in every configured storefront language. Verify pre-purchase and post-purchase surfaces separately.

Capture the resolved language and source layer—fixed, WPML, Polylang, WordPress or fallback—in the administrator diagnostic. Do not collect shopper identities to do this.

Repeat the check with the administrator interface in a different language from the storefront. Configuration labels may follow the user locale, but the public notice must follow the documented storefront resolution path.

Use a release checklist for every storefront language

The Commission distributes a fixed language-specific artwork set. Store language, checkout language and the appropriate notice are related operational choices, but they are not interchangeable. Record the intended audience and source file, then ask the responsible reviewer to approve the mapping. A WordPress locale is a technical input, not a legal conclusion about which language a seller must use.

The Notice27 2.0 synthetic demo demonstrates English, Dutch, German and French through the plugin’s storefront-language inputs. It does not present those controlled routes as proof of compatibility with every WPML or Polylang configuration; merchants should exercise their installed multilingual stack independently.

Test regional locale variants explicitly. A value such as fr_BE may map to a supplied French asset, but that mapping should be documented rather than inferred differently on each request. Record the normalized input and resolved file in diagnostics, then confirm the same result on an uncached and a cache-warmed visit.

Separate administrator language from storefront language during review. A Dutch administrator can manage an English storefront, and a multilingual checkout can differ from the dashboard locale. The settings screen should explain the resolution source without treating the logged-in user’s interface language as the shopper-facing answer.

Add a failure row for every configured language. If an expected file is missing, unreadable or mapped incorrectly, stop that release, retain the previous known-good asset and show a non-sensitive administrator warning. Do not invent a translation, alter the artwork or let an exception block the customer’s checkout request.

Document every language switch across guest and registered journeys, including cached responses and regional locale variants.

• Confirm the selected Commission-supplied file and its language code.
• Test product, cart and checkout after switching the storefront language.
• Vary cache keys by storefront language and inspect a warm-cache visit.
• Keep English fallback visible to administrators instead of silently treating it as correct.