Understand URL language prefixes

A language prefix is the first path segment that identifies the active locale, such as /fr/. POM Translate generates these prefixes from the configured locale list and keeps them unique.

There is no ordinary per-language prefix field in Base setup.

Standard prefixes use the language code

When one configured locale uses a two-letter language, POM Translate normally uses that code:

fr_FR → /fr/
de_DE → /de/
it_IT → /it/

Additional languages always require a prefix. The main locale requires one only when Use a subdirectory for the default language is enabled.

Regional collisions use specific prefixes

Two locales cannot both own /en/. When more than one configured locale shares the same two-letter language, POM Translate derives a more specific prefix from the full locale:

en_GB + en_US
→ /en-gb/ + /en-us/

The same rule applies to other regional language groups. Generated values are normalized, checked against prefixes already in use, and made unique.

Adding or removing a regional sibling can therefore change the generated prefix of an established locale. Treat regional-language list changes as URL migrations.

Labels and prefixes are independent

Changing Custom language label from English (UK) to English does not change /en-gb/.

The locale controls the prefix. The label controls presentation. A translated post slug controls a later segment:

/en-gb/seasonal-menu/
│       └─ localized post slug
└─ generated locale prefix

Edit the post segment under Translations → Translate URLs, not in language settings.

Prefixes select request context

For an incoming localized request, POM Translate:

1. compares the first path segment with the configured prefix map;
2. selects the matching locale;
3. stores that valid locale as the visitor preference;
4. removes the language layer from the path used for object resolution;
5. maps localized bases and slugs back to a canonical WordPress object.

An explicit recognized prefix is authoritative. Browser detection does not replace it.

Save and refresh routing

Saving Languages setup → Base setup flushes WordPress rewrite rules. Test routes immediately after:

• adding a locale;
• removing a locale;
• adding or removing a regional sibling;
• changing the main-language prefix policy.

If WordPress still uses stale rules, save Settings → Permalinks once and inspect redirect, security, page-cache, and CDN layers.

Plan prefix changes as public migrations

Before changing a prefix-producing configuration:

1. list important source and target URLs;
2. record indexed and externally linked target paths;
3. prepare permanent redirects from old paths;
4. update menus, selectors, sitemaps, canonical URLs, and alternates;
5. purge old page and CDN entries;
6. verify the new route resolves the same canonical object;
7. keep redirect chains to one hop.

Do not rely on a removed prefix continuing to select its old language. Once a locale is unavailable, that first segment is no longer recognized as its POM Translate context.

Verify every prefix

For each locale:

• the homepage route uses the expected first segment;
• two regional variants have distinct prefixes;
• source and target URLs resolve the same canonical object;
• the document language matches the prefix;
• selector links use the same generated route;
• canonical and alternate-language metadata agree;
• old paths redirect after a migration;
• page caches and CDN keys remain separated by locale path.

Read Choose the main-language URL policy for the one prefix decision exposed directly in Base setup.