WordPress Translation MCP that keeps translations linked.

Where the translated words live: on your site or in a cloud project

The three translation plugins with modules in this category split along one line, and it shapes everything an agent can do. With WPML and Polylang, each translation is an ordinary post in your database, tied to its siblings by a group record. An agent can write a German page with create-post or update-post like any other content, then give it a language and link it to the original. With Weglot, the translated text lives in Weglot's cloud and is served over your pages; the WordPress side holds configuration, translated slugs and a cached copy of the cloud settings.

So the first question for a multilingual AI agent on WordPress is not which plugin is better but which half of the job you want it doing. On WPML or Polylang it can produce and file translations. On Weglot it manages languages, exclusions, translated URLs and the switcher, while translation text is edited on the Weglot dashboard.

Choosing between WPML, Polylang and Weglot for agent-maintained sites

Each choice gives something up, and none of the modules reconfigures its plugin in depth: WPML's languages, translatable types and translation mode are reported, never set, and Polylang Pro's machine translation and WPML's Translation Management jobs are not exposed. Within those limits:

• Pick WPML when you need string translation for theme options and custom fields as well as posts. Its String Translation add-on is what the string abilities read and write, and without it they refuse with a clear error rather than guessing.
• Pick Polylang for a lighter footprint where content is the main job. Its strings are keyed by the exact original sentence, so a theme that rewords a label silently loses that translation; ask the agent to list untranslated strings after any theme update.
• Pick Weglot when nobody on the team will manage translated posts, and translation quality is handled by Weglot's engine and dashboard editing. Expect configuration changes to need a publish step before visitors see them.

Translation writes are confirmed because they cannot be rolled back

Unlike most content work, almost nothing in this category comes back from the change ledger. Assigning a language and linking a translation set rewrite a group shared by several posts, so both are confirmed writes with no undo on WPML and Polylang. String writes return the previous value so a person can put it back by hand. On Weglot, changing the original language can affect the whole translation project; review the provider's warning and publish/readback results. Recognized secret values are redacted from displayed/exported records, but usable settings before-images can retain them in protected storage. Keep keys out of prompts and exports.

Two habits keep this safe. Read the full translation map for a post before linking, because a link call treats the map it is given as the whole set and drops members you left out. And never let a language change and a link happen in the same unreviewed step: assign, check, then link.

A translation workflow an agent can run on WPML or Polylang

Term translations are not handled by either module, so category and tag names in other languages stay a manual task in the plugin's screens.

• Read the configured languages with wpml-list-languages or polylang-list-languages, and use the exact codes they return (WPML expects de, not de_DE).
• Find what is missing with wpml-list-content or polylang-list-content; languages absent from an item's map are the untranslated ones.
• Write the translation as a draft post through create-post, with the same post type as the original.
• Give the draft its language with wpml-set-content-language or polylang-set-content-language. Linking fails on a post that has no language yet.
• Link the set with wpml-link-content-translations or polylang-link-content-translations, passing every existing member.
• Publish after a person has read the translation, then check the switcher and rendered tags on both language versions.

Multilingual stores and other edges

On a WooCommerce store running WPML, products are translated through the same content abilities as any post type. WooCommerce Multilingual's handling of prices, attributes and variations per language is not wrapped, so currency and variation work stays in its own screens. Weglot translated slugs are stored on this site and never reach the Weglot project, which means another install or a refresh from the cloud can discard them; keep a note of any you add.

Weglot reads also say where their answer came from. When the configuration source is a local fallback, Weglot could not be reached and every cloud-managed field is unknown rather than empty, so an agent should report that and stop instead of concluding a language or exclusion is missing. weglot-get-status and weglot-get-translation-cache-state are the reads to start with.

Each module keeps to its own plugin. Identifiers from one are never passed to another, so a site migrating from Polylang to WPML is a migration a person plans, not a prompt. The WPML MCP guide goes deeper on that plugin alone.

Translating TranslatePress strings, one language at a time (Pro)

TranslatePress has no row in the module table above; what follows is a Pro addition and a Free change record for the abilities TranslatePress ships itself. TranslatePress's own abilities can add and remove languages, but they cannot read or write a single translation, so an agent could add Spanish and then not write a word of it. GoBuildWP Pro 1.12.0 fills that gap. It lists the strings TranslatePress has collected from the site for a language, with the status of each, and saves up to 100 translations at a time through the same call TranslatePress's own editor makes.

Saved translations use TranslatePress's reviewed status, so TranslatePress's automatic translation leaves them alone afterwards. Undo writes each string's previous translation and status back and reads them again to confirm.

From GoBuildWP Free 1.18.0, TranslatePress's own abilities for adding, removing and updating languages, choosing the default language and switching on automatic translation are recorded with a snapshot of the settings they change, so they can be undone. Setting the TranslatePress licence key is recorded as irreversible: a licence key is a secret and is never copied into the change log.