How POM Translate differs from duplicate-post translation
POM Translate does not model a language as another WordPress post. It keeps one source object and attaches locale-specific values to that object. This changes where editors work, how queries behave, and what must be checked when source content changes.
Compare the two editorial models
| Decision | POM Translate | Duplicate-post model |
|---|---|---|
| WordPress record | One canonical post or term | Usually one record per language |
| Source editing | Normal WordPress editor | Normal editor for each language record |
| Target editing | POM Translate’s translation interfaces | The duplicated record’s editor |
| Relationships | Shared from the canonical object | May need to be synchronized between records |
| Native content query | Returns the canonical object | Often needs language-specific record selection |
| Missing target value | Shows the corresponding source value | Depends on the relationship and fallback rules |
| Translated slug | Stored for the canonical object and locale | Usually belongs to the language-specific record |
| Deleting a translation | Removes target text, not the source object | May involve deleting a separate post |
This is an architectural distinction, not a claim that every multilingual workflow should use the same model. Choose it when a single source object and centralized translation editing match the site’s ownership rules.
What editors gain
The source post keeps one ID, publication state, featured image, author, taxonomy assignments, and other relationships. A change to those shared properties does not need to be repeated across language-specific copies.
POM Translate also leaves the normal WordPress content query focused on canonical objects. The translated title, excerpt, body, term, menu, meta, and URL values are applied for the active locale after WordPress has identified the object.
This is particularly useful when other systems refer to a post or product by its WordPress ID and should not choose among several language copies.
What editors must learn
Translated prose is not edited by opening another post. Use Translations → Translate contents, or the Manage translations action shown for an enabled post type. Localized slugs have their own Translate URLs workspace.
The separation is intentional:
- the WordPress editor owns the source;
- Translate contents owns extracted target text;
- Translate URLs owns locale-specific slugs and mapped URLs;
- Other translations owns registered singleton strings and supported defaults;
- Software translations owns gettext catalog work.
Changing the wrong surface can leave the source correct while a target value remains stale.
Source changes require a translation review
Saving an eligible source post makes POM Translate examine the current title, excerpt, body, supported attributes, shortcode text, and allowed meta. When source text changes, the related translation state may need editorial attention.
Do not treat an existing target page as permanently synchronized. After a meaningful source edit:
- save the canonical post;
- reopen its target locale under Translate contents;
- review changed and missing values;
- check protected formatting markers;
- verify the localized route again as a visitor.
Compatibility consequences
An integration that expects a separate post ID for every language is not using POM Translate’s model. Integrations should work with the canonical WordPress object and allow POM Translate to localize its supported output.
Likewise, importing a set of duplicated language posts does not automatically establish POM Translate translations. Plan content migration separately and validate exact source matches before importing translation data.
Read Requirements and compatibility before replacing another multilingual solution on an existing site.