How translated content is assembled for a visitor

POM Translate assembles a localized post after WordPress has identified the canonical object and the request has an active target locale. The renderer reads prepared source units and stored translations; it does not extract content, create jobs, or call POM AI during the visit.

The base locale stays native

For the source language, WordPress returns the canonical title, excerpt, content, and metadata. POM Translate does not reconstruct the source body from target translations.

The reconstruction pipeline is used when the active locale differs from the base and the post type and field are enabled.

Related data is prepared together

Before localizing a post object, POM Translate primes the source rows and target translation maps for the required subjects. It can reuse request caches and WordPress object-cache entries instead of repeating the same lookups for the title, body, metadata, terms, and menus.

This preparation is an optimization, not a different editorial model. The returned values still belong to the same canonical post.

Each field has its own rendering path

The target title and excerpt resolve their matching source rows directly. Supported metadata is loaded only for approved keys. The body uses the saved content skeleton:

1. load the current compatible skeleton;
2. collect body, attribute, and shortcode rows;
3. order rows by their saved positions;
4. choose the target translation or source fallback for each row;
5. validate and restore protected inline markup;
6. escape translated attribute values;
7. replace every expected skeleton token;
8. apply supported content formatting and shortcode processing;
9. localize supported internal links;
10. cache the completed body for subsequent eligible reads.

The renderer refuses to use a reconstructed body that still contains unresolved skeleton tokens.

Fallback happens per value

For every row, the initial value is the source text. A target value replaces it only when the stored translation is a non-empty string.

If the row uses protected markers, the target value must also pass marker validation. An invalid target falls back to the source unit before its original inline elements are restored.

This means one broken paragraph cannot safely corrupt the whole page’s HTML, but it can leave that paragraph in the source language. Editorial verification remains necessary.

Shortcodes run after reconstruction

Supported shortcode attributes and inner values occupy their own positions in the skeleton. Once the localized body has been rebuilt, POM Translate normalizes shortcode spacing where appropriate and invokes WordPress shortcode processing.

The shortcode callback therefore receives localized supported values. The shortcode’s own runtime behavior, remote data, permissions, and output remain the responsibility of the shortcode provider.

Layouts that depend on shortcode structure can bypass ordinary automatic paragraph formatting when applying it would add incorrect markup.

Internal links are localized last

After body reconstruction and shortcode handling, POM Translate inspects supported internal links. When a destination belongs to a known post, term, archive, or custom URL mapping, the path can be rebuilt for the active locale.

External URLs and unsupported destinations are not translated as prose. Link localization also preserves the distinction between a locale prefix and a translated object slug.

Cached output has a narrow scope

Completed post bodies are cached by the post, locale, rendering options, and renderer version for a limited period. Saving related source content or a target translation invalidates the relevant POM Translate runtime entry.

This cache is not the same as a static page cache. A CDN or POM Cache HTML file can still answer before WordPress and must be refreshed through its own policy.

Verify the assembled result

Use a post with a title, excerpt, two paragraphs, a translated attribute, protected inline link, and supported shortcode:

1. translate every value except the second paragraph;
2. open the target route while signed out;
3. confirm the translated fields appear;
4. confirm the second paragraph uses source fallback in the correct location;
5. inspect the inline markup and translated attribute;
6. follow the internal link and confirm it stays in the target locale;
7. reload the route and confirm the result remains identical;
8. edit one target value, save it, and verify the updated result after clearing any external page or CDN cache.

If the source content appears in full, save the canonical post again and check that its post type, fields, target locale, and skeleton are current before troubleshooting individual translation rows.