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 supported product, cart and checkout route in every configured storefront language. Neither stable Notice27 1.2 nor the current private candidate provides production order-received or transactional-email placement. Those post-purchase surfaces are not Notice27 language-test routes.

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 evidence store demonstrates English, Dutch, German and French through the stable plugin’s real manual-language setting. It does not present that test as WPML or Polylang compatibility. Those detection paths are implemented and statically tested, while a real paid-package multilingual matrix remains outstanding.

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.

• 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.