Why POM Translate does not duplicate posts

POM Translate localizes the output of a canonical WordPress object instead of creating a linked copy for every language. This is a deliberate data model with practical consequences for queries, integrations, editorial work, and migrations.

Canonical identity comes first

WordPress and connected systems commonly use an object ID as the stable reference for:

• post metadata and featured media;
• comments and revisions;
• taxonomy relationships;
• product inventory and other commerce data;
• API references and external synchronization.

Duplicating the post would also duplicate or synchronize some of those relationships. POM Translate avoids that split: WordPress identifies the source object first, then the plugin replaces supported display values for the active locale.

Normal queries keep returning canonical objects

A query for published posts does not need to select among several language copies. It returns the canonical records allowed by WordPress. POM Translate can then localize supported properties such as the title, excerpt, body, terms, metadata, menu labels, and links in the relevant rendering context.

This distinction is important for developers and site owners:

• a target-language view is not evidence of a second post in Posts;
• the target URL should resolve back to the canonical object;
• deleting target text should not delete the source post;
• integrations should not search for a translated post ID that does not exist.

Shared fields are not translation fields

The plugin does not treat every post property as language-specific. Author, publication state, dates, featured image, taxonomy relationships, and other canonical relationships remain on the source object.

Only supported and enabled values enter the translation workflow. This prevents technical identifiers or structured data from becoming prose merely because they are attached to a post.

Deletion has a clear boundary

Deleting the canonical post removes the object that the translation records belong to, so POM Translate cleans up the related translation data. Removing one target translation or localized slug has a smaller effect: the source object remains and the public target value can fall back to its source equivalent where that surface supports fallback.

Removing an entire language is a broader publishing change. Existing localized URLs may already be indexed or linked externally, so plan redirects and content retirement before changing the language list.

Migration requires an explicit mapping

A multilingual system based on duplicate posts cannot be imported by assuming that each language post should stay independent. A migration needs to decide:

1. which record becomes the canonical source object;
2. which fields from the other records become target translations;
3. how language-specific slugs map to the canonical object;
4. how duplicate media, terms, parents, and custom fields are reconciled;
5. which old URLs redirect to the new localized routes.

POM Translate’s import workflow can match stored translation data to source values, but it does not automatically convert an unrelated network of duplicated posts into one-object relationships.

Verify the model on an existing site

Use one representative post:

1. record its WordPress ID in the source editor;
2. open its target-language public URL;
3. use the normal edit link while authorized;
4. confirm WordPress opens the same source post;
5. change only a target translation and save it;
6. confirm no new post appears and the source editor remains unchanged;
7. clear the target value and verify the documented source fallback.

If an integration depends on one record per language, adapt that integration before launch. POM Translate will not manufacture duplicate records to satisfy that assumption.