From One Translation Ability to a Full AI Workflow

Course 6’s Multilingual Translation Workflow project did one real, useful thing: given a post ID and a target language, it called wp_ai_client_prompt() to produce a translated draft, then linked that draft back to its source with a pair of post meta keys, _translation_of and _translation_language. That lesson was also honest about where it stopped. Its own closing step said plainly that plugins like WPML and Polylang solve problems a standalone meta key doesn’t, language switchers, translated permalinks, taxonomy translation, and syncing relationships across a whole site, and that a real multilingual site should use one of those rather than treat that meta key as a substitute. This course is what comes after that admission. It builds the rest of the system.

What you'll learn in this lesson

Where Course 6's project stops, precisely

What it does well, and the four specific gaps this course exists to close.

Why plugin-linked translations matter more than a meta key at scale

What actually breaks on a real site when translations aren't registered inside WPML or Polylang.

The shape of a production multilingual workflow

Plugin integration, terminology consistency, locale-aware SEO, and a review gate, as one connected system rather than four separate tricks.

How this course's eight lessons map onto that shape

So you can jump to the lesson that matches the gap you actually have.

Prerequisites

Course 6’s translation-workflow/translate-post project, or at least a read of it, this course assumes you’ve seen the pattern of translating a post with wp_ai_client_prompt() and inserting the result as a linked draft. You’ll also want either WPML or Polylang active on a real or staging site before Lessons 2 and 3, since those lessons are plugin-specific and branch from here.

Step 1: What Course 6 actually built, and where it stopped

The Course 6 project is a single ability, translation-workflow/translate-post. It reads a source post, sends its title and body to wp_ai_client_prompt() with an instruction to translate into a named target language, inserts the result with wp_insert_post() as a draft, and stores the relationship in post meta in both directions. It’s a genuinely useful starting point, and the draft-only behavior it established (never auto-publishing a machine translation) is a pattern this course keeps and extends rather than replaces.

What it doesn’t do is anything a real i18n plugin is responsible for: it doesn’t tell WPML or Polylang that the new post is a translation, so neither plugin’s language switcher, admin language column, or translated-permalink routing knows the relationship exists. It sends the same translation prompt every time with no shared terminology, so a product name or technical term can come out differently across two separate runs. It says nothing about hreflang or about what a meta title or description should look like once translated. And it has no batch path for translating dozens of WooCommerce products at once, or a formal review gate beyond “it’s a draft.”

Step 2: The four gaps, and why they matter at real-site scale

What Course 6’s project leaves open, and what breaks without it
Gap	What actually happens without it on a real site
No real i18n plugin integration	WPML’s or Polylang’s own language switcher, admin filters, and translated permalinks never see the new post as a translation, since they read their own data structures, not a custom meta key.
No terminology consistency	The same source term gets rendered differently across separate AI calls, a brand name gets accidentally translated in one post and left alone in another.
No locale-aware SEO	Search engines have no signal connecting the language versions of a page, and a literally translated meta title can read awkwardly or miss how people actually search in that locale.
No batch path or formal review gate	Translating a 200-product catalog one post at a time isn’t a workflow, and “it’s a draft” alone doesn’t guarantee anyone bilingual actually reviewed it before it went live.

This isn't a criticism of Course 6's project, it's a scope difference

A single ability that translates one post and links it with post meta is exactly the right size for that lesson, introducing wp_insert_post() and the review-draft pattern without the added weight of a specific plugin’s API. This course exists because a real multilingual site’s actual requirements are bigger than that one lesson ever claimed to solve.

Step 3: How this course’s lessons map onto those four gaps

The path through this course

Lessons 2 and 3: real plugin integration

The same translate-then-link idea from Course 6, rebuilt around WPML's wpml_object_id filter or Polylang's pll_get_post() and pll_get_post_translations(), so the new post is a translation the plugin itself recognizes.

Lesson 4: terminology consistency

A glossary fed into every translation prompt through using_system_instruction(), so a term translates the same way every time it appears.

Lesson 5: locale-aware SEO

hreflang tags generated from your plugin's own translation relationships, plus meta titles and descriptions written for the target locale, not just translated word for word.

Lesson 6: scale

Batch translation for a WooCommerce catalog with wc_get_products(), keeping structured fields like price and SKU separate from the free-text fields an AI model actually rewrites.

Lesson 7: the review gate

A formal, draft-until-approved workflow for every translation this course produces, tying back to Course 25's human-in-the-loop pattern.

Each of Lessons 2 through 7 is a self-contained build, same as Course 6’s own project lessons were. You don’t need to build all six to get value from any one of them, read Lesson 2 if your site runs WPML, Lesson 3 if it runs Polylang, and treat 4 through 7 as add-ons you layer onto whichever plugin-specific ability you build first.

Recap

Course 6’s translation project proved the core idea, an ability that calls wp_ai_client_prompt() to translate a post and inserts the result as a linked draft, but it deliberately stopped short of real i18n plugin integration, terminology consistency, locale-aware SEO, and catalog-scale translation. This course closes those four gaps in order: WPML and Polylang integration in Lessons 2 and 3, a terminology glossary in Lesson 4, hreflang and locale-aware metadata in Lesson 5, WooCommerce batch translation in Lesson 6, and a formal human review gate in Lesson 7.

Resources & further reading

Project: Multilingual Translation Workflow, this track, Course 6
AI Content That Actually Ranks, this track, Course 25
WPML: WordPress Multilingual Plugin, wpml.org
Polylang, polylang.pro