Configure browser language detection

Browser language detection can redirect an eligible unprefixed first visit to a configured locale. It is a routing convenience, not a translation service: it neither creates translated content nor changes an explicit language URL.

Configure stable language routes and selectors before enabling it.

Enable detection

Open:

Settings → POM Translate → Languages setup → Base setup

Then:

1. confirm the Main language;
2. review the order of Additional languages;
3. enable Browser language detection;
4. choose Fallback language for redirects;
5. save Base setup;
6. test in a private browser session.

The feature has no useful destination unless the intended locale is already in the configured language list.

Understand request precedence

POM Translate resolves an unprefixed eligible request in this order:

1. a valid language preference previously selected by the visitor;
2. the best configured match from the browser’s Accept-Language header;
3. Fallback language for redirects;
4. the main language if the configured fallback is no longer valid.

A recognized prefix bypasses this choice and selects its own locale. Visiting /fr/…, for example, remains a French request even if the browser prefers Spanish.

A visitor preference is stored when the visitor follows a valid localized route. It can remain effective for up to one year, so changing browser preferences alone may not reproduce a first visit.

How browser languages are matched

An exact locale match wins first. If the site offers en_GB and the browser requests that locale, POM Translate selects it.

If there is no exact match, POM Translate normalizes regional notation and then considers the general two-letter language. When several configured regional variants share that language, the first one in the effective language order wins. The main locale is first; additional locales follow their order in the repeater.

Browser quality weights are respected. This means a higher-priority configured language can win even when another language appears earlier in the raw header.

Use Order languages to control ambiguous general-language matches.

Requests that are not redirected

Automatic detection is intentionally limited. It does not redirect:

• requests that already contain a recognized language prefix;
• non-GET and non-HEAD requests;
• WordPress admin, login, AJAX, cron, REST, XML-RPC, or comment endpoints;
• feed requests;
• paths that look like files because they contain a dot;
• recognized bots and crawlers.

These exclusions prevent language negotiation from interfering with state-changing requests, APIs, assets, administrative traffic, and search-engine crawling.

When detection does choose another locale, POM Translate issues a temporary redirect to the localized equivalent of the requested path. Query parameters are preserved by the localized URL builder where supported.

Test without an old preference

Use a private window or clear the site’s language preference before each first-visit test.

Run this matrix:

Also test the same content after selecting a different language manually. The saved visitor choice should take precedence over the browser header on later eligible unprefixed visits.

Avoid redirect loops and surprises

Before launch:

• verify each configured prefix is unique;
• confirm source and target routes resolve the same canonical object;
• make sure external redirect rules do not send localized paths back to unprefixed ones;
• exclude page-cache entries from being shared across different redirect outcomes;
• test behind the actual CDN or reverse proxy;
• keep selectors available so visitors can override automatic detection.

If detection causes unexpected navigation, disable Browser language detection while keeping explicit language URLs active. This isolates negotiation from translation and routing.

Read Configure the browser redirect fallback before choosing the no-match destination.