How POM Translate selects the active language

The active language is request context. POM Translate determines it before localized content, URLs, menus, SEO metadata, or supported dynamic responses are rendered.

The source locale comes from WordPress

The main language follows Settings → General → Site Language. Additional locales are configured under Settings → POM Translate → Languages setup.

Changing the WordPress site language is therefore a source-language decision, not merely an administration-interface preference. Review existing translations and routes before changing it on a populated multilingual site.

The public route is authoritative

For a normal frontend request, POM Translate first inspects the URL:

1. A recognized locale prefix selects that locale and stores it as the visitor’s preference.
2. A route without a recognized prefix starts in the base locale.
3. If the base locale is configured to use a prefix, an unprefixed eligible route redirects to its prefixed equivalent.

A visitor opening /fr/menu/ should therefore remain in French even if a saved preference or browser header suggests another configured language.

Only configured locales are accepted. Unknown prefixes do not create a new active locale.

URL selection and browser redirection are different

POM Translate can detect a language from the current route without forcing every first-time visitor to a browser-matched route.

The Browser language detection setting controls an optional redirect for eligible unprefixed routes. When it is enabled, POM Translate checks a valid saved preference first, then the browser’s Accept-Language preferences, then the configured browser fallback. Unsupported results fall back to the base locale.

Keep browser detection disabled while validating deterministic source and target URLs. When enabled, test first visits, existing preferences, bots, root-like routes, and excluded requests separately.

Browser detection should not override an explicit locale prefix.

Administration remains in the base content context

Normal WordPress administration requests use the base locale for POM Translate’s content context. This prevents a visitor cookie or public route from making the source editor behave as though it were editing translated content.

Editors still choose a target locale explicitly inside Translations.

Dynamic requests need an allowed language signal

AJAX and REST calls do not always include the visible page path in the same form as the browser document. POM Translate handles supported requests through dedicated context logic:

• eligible frontend AJAX requests can set a normalized target locale;
• allowlisted REST routes can use their request context to select a locale;
• WooCommerce AJAX and Store API requests have additional locale handling;
• unsupported, administration, cron, command-line, sitemap, and other excluded contexts remain outside normal frontend localization.

An integration should pass one of the plugin’s supported language signals rather than relying on whichever cookie happens to be present.

Email context can outlive the browser request

WooCommerce email rendering may happen later or outside the original checkout page. POM Translate records and restores the order’s locale through the WooCommerce integration so subjects, headings, body values, item data, and account links can use the intended language.

The current administrator’s browser language must not determine a customer email’s locale.

Context must be restored

Temporary locale overrides for supported AJAX, Store API, preview, or email work are scoped to that operation and restored afterwards. This prevents one translated operation from leaking its language into unrelated work during the same process.

Verify precedence deliberately

Use one source route and one configured target route:

1. disable browser-language detection;
2. open the source route in a private window and confirm the base language;
3. open the prefixed target route and confirm the target language;
4. switch language through a selector and confirm the destination URL carries the choice;
5. reload both explicit routes and verify each remains stable;
6. enable browser detection on staging;
7. start a new private session with a matching browser preference;
8. confirm only the eligible first visit follows the configured redirect behavior;
9. reopen an explicit source or target route and confirm the URL remains authoritative.

If content, selector state, canonical URL, and the document language disagree, diagnose the active-language context before editing translations.