No generated translations
The abilities move ids and languages. Translated prose comes from a person, WPML's translation editor, or an agent using the ordinary content abilities — then it gets linked.
MCP for WPML
Multilingual work an agent can do without breaking the switcher.
WPPilot Pro gives an AI client WPML's own vocabulary — languages, translatable types, translation groups — through WPML's published hooks, with every language write confirmed before it runs.
The problem this solves first
Content created without WPML in mind has no language at all.
Not the default language. None. WPML keeps language and translation-group membership in its own table, and nothing in WordPress core writes to it — so a page created by any tool unaware of WPML sits outside every translation group and never reaches the language switcher.
setup healthlanguage discoverytranslatable post types and taxonomiescontent discovery by languagecontent language and translation grouplanguage assignmenttranslation-group linkingcross-language id resolution
Written against the published API
Through WPML's hooks, never around them.
The language a post is in, and the group its translations share, live in WPML'sicl_translationstable. Writing that table directly is the obvious shortcut and the wrong one: it skips the cache invalidation and translation-job bookkeeping WPML hangs off its own actions, and produces a site where the database says one thing and the admin shows another.
Every read and write here goes through the documented hooks instead. That also means one WPML inconsistency is absorbed rather than passed on to you: the language-details hooks spell an element type one way and the id-resolution hook spells it another, and passing the wrong form fails quietly and returns nothing at all.
Translation workflow
Find the gaps, then close them in order.
Every content row carries the complete set of translations its group holds, so the languages missing from that map are exactly the ones still to do. That answer costs one call, not one call per item per language.
- Confirm the post type is switched on for translation in WPML
- List content in the source language and read each row's translation map
- Create or edit the translated content with the ordinary content abilities
- Assign the translated post its language
- Link it into the source post's translation group, with confirmation
- Re-read the group and check the language switcher on the front end
Honest boundaries
What this module does not do.
A multilingual site has more moving parts than one plugin's language table, and claiming otherwise is how a translation project goes wrong quietly.
No string translation
WPML publishes no hook that writes a translation for a registered string, so theme and plugin strings stay in WPML's own String Translation screen.
No WPML configuration
Adding a language, switching a post type to translatable, or changing translation mode are admin decisions with site-wide effects. They are reported, never changed.
Questions
WPML MCP, without vague promises.
What is WPML MCP?
It is a controlled way for an MCP client to read and change WPML's language model on a WordPress site: which languages exist, which post is in which language, which posts form one translation group, and what a given post's counterpart is in another language. WPPilot Pro registers the module only when WPML is active and meets the supported version floor.
Does it translate my content?
No, and that distinction matters. These abilities move ids and languages around; they never write prose. Create or edit the translated content itself the way you normally would — by hand, with WPML's own translation editor, or with an agent using the ordinary content abilities — then link it.
Can it translate theme and plugin strings?
No. WPML publishes hooks that register and read strings, and none that write a translation for one, so there is no string-translation write here rather than a fragile one. The setup ability reports whether the String Translation add-on is active so you know where to go.
Why does my AI-created page not appear in the language switcher?
Because it has no language at all. WPML stores language in its own table and nothing in WordPress core writes to it, so a page created by any tool that does not know about WPML sits outside every translation group. The abilities report that state plainly, and assigning a language is the fix.
How is this different from the Polylang or Weglot modules?
They are different products with different storage and different APIs, so each has its own module. Polylang and WPML both model translation groups in WordPress; Weglot is a cloud translation service whose module manages configuration rather than content. A site runs one of them, and WPPilot loads only the matching module.
Are language changes reversible?
Assigning a language and linking a translation group are recorded writes that require explicit confirmation, and both are described before they run. They are also consequential: changing the language of a post that other translations point at is how a translation set gets split, which is why the abilities show you the current group first.
Your site · your policy · your AI client
Give the multilingual site a controlled AI connection.
Install the free MCP foundation first, then add the Pro WPML module and validate the language and linking workflow on staging.