Polylang MCP for post languages, translation sets and strings

Which pages still have no German version? Reading Polylang coverage first

Before any Polylang MCP write, the useful first question is what is missing. polylang-list-content filters by post type, language, status and search, pages through up to a hundred items at a time, and returns each item's language with a summary of its translation set. Listing published pages in the default language and reading which sets lack a de entry gives a gap list without opening each page. polylang-get-content-language then shows the complete set for one page when you need to see exactly which ids are linked.

polylang-list-languages returns three codes per language, and they are used for different things. The slug, such as de, is what every write ability expects. The locale, such as de_DE, is the WordPress locale that translation files are loaded for. The W3C code is the hyphenated form browsers and hreflang attributes use, which makes it the value to compare against when checking the rendered head. The same list shows which language is the default and which are written right to left.

Right-to-left languages are worth a look before translators start. The language list says which are written right to left, and the theme has to support that direction for Arabic or Hebrew pages to read properly; check one translated page in a browser before filling a whole set.

Adding a translated page to an existing Polylang set, in order

The module does not write translated text, so a new translation is a short chain across two modules. The order matters, because a link call refuses posts that do not carry their language yet.

• polylang-get-content-language on the original page: note its language and every id already in its set.
• create-post from the core content abilities, as a draft, with the German title and content you or a translator supplied.
• polylang-get-content-language on the new draft: if it carries no language or the wrong one, polylang-set-content-language with confirm sets de.
• polylang-link-content-translations with the full map, every existing language and id plus de and the new id, again with confirm. A map that leaves out a language unlinks it.
• polylang-get-content-language once more on both pages, then publish the draft with update-post and check the language switcher and hreflang tags in a browser.

Correcting a bad string translation without losing the old one

String translations are the part owners edit most and the part with no ledger undo, so GoBuildWP changes the rules for overwrites. polylang-set-string-translation fills an empty translation freely, but replacing or clearing an existing, different translation is refused unless the call carries confirm=true. Each result returns previous, the value that was there before, and writing that value back the same way is the undo. Ask the agent to keep the previous values from a session in its reply before you close it.

For more than a handful of fixes, the bulk ability's dry run is the review step. It classifies every item as a create, update, clear or no-op against what is stored now, so a batch meant to fill gaps that turns out to contain updates is caught before anything is saved. A real run then saves each language once and reports success or failure item by item.

Polylang permissions, profiles and what stays in Polylang's screens

polylang-check-setup reports whether the connected user can edit posts and manage options, whether string translation is available on this install, and whether string registration is complete on the current request. On MCP requests registration_complete is false by design, because Polylang records pll_register_string() calls only on its own admin side; translated strings always appear, never-translated ones may not. Under the Read Only safety profile the inspection abilities run; string writes need Production Safe, and assigning a language or linking a set needs confirm on top.

Term translations, Polylang's language settings, URL modifications and the language switcher stay in Polylang's own screens, and Polylang Pro features are not exposed. The Polylang reference lists the parameters, and the Weglot page explains how a proxy-based translator differs.

• "Read only: which published pages have no Spanish translation yet?"
• "Show me every untranslated string in the theme group for fr, then dry-run filling them from this list."
• "Link page 210 as the Italian translation of page 18 without dropping the French and German pages already linked."

Polylang sites are no longer reported as WPML

Polylang includes a compatibility layer that answers some of WPML's functions, and before GoBuildWP Free 1.18.0 that was enough for the environment summary an agent reads first to call a Polylang site multilingual with WPML. The agent then reached for WPML tools that could not work. Polylang is now detected before WPML, so the summary names the right plugin and the Polylang abilities in Pro are the ones it uses.

Polylang keeps languages and translation links in two private taxonomies. A general taxonomy write aimed at either of them is refused, and the refusal now points to the Polylang abilities that change languages and links safely, instead of only saying no.