How translated URLs are generated and resolved

POM Translate builds localized routes from three separate parts: the site’s base path, a locale prefix when required, and language-specific path segments for the resolved WordPress object. URLs are not translated as ordinary sentences.

Every configured locale has a unique prefix

The standard prefix begins with the locale’s two-letter language code:

en_GB → en
fr_FR → fr

When several configured locales share that code, POM Translate uses a more specific locale-based prefix so the routes remain unambiguous. Prefixes are normalized and kept unique.

Additional languages always use a prefix. The base language uses one only when Use a subdirectory for the default language is enabled.

A localized path can contain several translated segments

Depending on the route, POM Translate can rebuild:

• post or page hierarchy segments;
• a custom post type base;
• an archive base;
• taxonomy bases;
• parent and child term slugs;
• the final post or term slug;
• supported suffix segments such as pagination.

For a hierarchical page, translating only the child slug may be insufficient. Its target path can also depend on the localized parent path.

Source slugs seed new target locales

When an eligible post is saved, POM Translate records its source slug. For each configured additional locale without a stored slug, the plugin initializes a unique target entry from that source slug.

That seed makes the route resolvable before an editor provides a final localized slug. It is not proof that the URL has been translated or approved.

Use Translations → Translate URLs to review and save locale-specific slugs.

Uniqueness is enforced per routing context

POM Translate checks localized slug conflicts and can append a suffix when initializing or saving a value that would otherwise be ambiguous. A route must still be tested in its complete context because WordPress bases, parent paths, redirects, and another routing plugin can affect the final result.

Do not assume that two identical final words conflict if they belong to different valid bases. Conversely, two different displayed labels can still map to the same path.

Incoming and outgoing routes use the same maps

For an outgoing link, POM Translate starts with the canonical source path, resolves the related post, term, or archive, replaces supported segments for the target locale, and adds the required prefix.

For an incoming localized request, it performs the reverse work:

1. identify the locale prefix;
2. remove it from the route used for resolution;
3. map localized bases and slugs back to canonical query variables;
4. let WordPress resolve the canonical object;
5. render that object in the selected locale.

This round trip is why a target URL can display translated content without a target-language post record.

Custom URLs have a separate dictionary

Links found in supported content may point to internal paths that are not standard post or term permalinks. POM Translate records eligible custom URL occurrences and lets editors map them per locale.

The content translator should not rewrite these destinations as prose. URL mappings have their own normalization, validation, and cache invalidation.

Query strings and fragments are not prose

Localized route generation works on the path while preserving supported suffixes, query values, and fragments where appropriate. Do not translate parameter names, security tokens, anchors, or tracking data in a content field.

Special WordPress and WooCommerce endpoints have dedicated routing behavior because a segment may represent an endpoint key or value rather than a post slug.

Verify the route round trip

For one nested page:

1. record the source permalink and WordPress post ID;
2. save target slugs for the parent and child;
3. open the generated target URL while signed out;
4. confirm it renders the same canonical post ID;
5. inspect its canonical and alternate-language links;
6. switch back to the source language and confirm the source path is restored;
7. follow an internal link to the page from another translated post;
8. confirm the outgoing link uses the same target route;
9. test a conflicting slug on staging and verify the saved route remains unique.

After changing a public slug, update redirects, sitemaps, page caches, and CDN copies deliberately. A valid new route does not retire external references to the old one.