One post, many languages

A translated post in POM Translate is one WordPress post with locale-specific values. The source editor continues to own the canonical post. POM Translate supplies a translated title, excerpt, body, selected metadata, and localized slug when another language is active.

What remains shared

The following properties belong to the same WordPress object in every language:

• post ID and post type;
• author and publication status;
• publication and modification dates;
• featured image and media relationships;
• taxonomy assignments;
• parent and child relationships;
• comments and other integrations tied to the post ID.

Changing one of these shared properties changes the canonical object. POM Translate does not create or synchronize a second language-specific post.

What can vary by locale

For an enabled post type, the site can choose whether to translate its title, content, excerpt, and supported metadata. The localized slug is managed separately from the prose. A target locale may therefore have a translated title and body while keeping the source value for an untranslated excerpt.

The public result is assembled value by value. A missing translation does not make the whole post unavailable: POM Translate uses the corresponding source value. This supports gradual translation, but it also means a public target page can contain mixed languages until editorial review is complete.

Follow one post through the workflow

Consider a published source post with ID 245:

1. An editor saves the post in the normal WordPress editor.
2. POM Translate checks that the post type and fields are enabled.
3. The source title, excerpt, body segments, supported attributes, shortcode values, and allowed metadata are discovered.
4. Editors add target text under Translations → Translate contents.
5. Editors manage the target slug under Translations → Translate URLs.
6. A visitor opens the target-language route.
7. WordPress resolves post 245; POM Translate renders its stored values for the active locale.

The post ID does not change between steps 1 and 7. The language affects presentation and routing, not the canonical object identity.

Source editing remains authoritative

Edit the source title or body in the WordPress post editor, not in a target translation field. When the post is saved, POM Translate inspects it again and updates the extracted source values and skeleton.

If a source unit changes, an old translation for that exact location is not silently treated as current. The translation workflow needs another review. When the same normalized source text already has a valid stored translation elsewhere, POM Translate can reuse that exact match; it does not infer that merely similar sentences mean the same thing.

Publication decisions still belong to editors

The WordPress publication status is shared. Publishing the source post makes the object publicly queryable; POM Translate does not maintain a second target-language draft status for a duplicate post.

Before promoting a target route, review its completion in the translation interface and test it while signed out. Source fallback is a rendering safeguard, not an editorial approval signal.

When this model matters most

The one-object model is useful when:

• external systems refer to content by WordPress ID;
• inventory, pricing, taxonomy assignments, or featured media should stay shared;
• editors want one source record with a centralized translation workspace;
• queries should return canonical objects instead of language copies.

It is a different model from a system that creates one post per language. Read Why POM Translate does not duplicate posts before importing content from such a system or designing an integration that expects language-specific post IDs.