# Translating WordPress with AI: fast, affordable, and without the WPML frustration – our complete workflow > URL: https://4eck-media.de/en/blog/translating-wordpress-with-ai-fast-cheap-and-without-the-wpml-frustration-our-complete-workflow/ > Language: en > Description: WordPress powers around 41 percent of all websites worldwide. And yet, in 2026, on the number one CMS there is still no way to translate a website that doesn't either take weeks, … --- WordPress powers around 41 percent of all websites worldwide. And yet, in 2026, on the number one CMS there is still no way to translate a website that doesn’t either take weeks, swallow a small fortune – or quietly lose translations along the way. We know this because we have lived through all three variants. An article with more than 10,000 words, translated in the WPML editor, box checked, saved – and on the live site: German. Not everywhere, that would have been easy to spot. Only in 1,247 of 1,725 fields. This article is the record of how we solved the problem for ourselves. You’ll learn why translations in WordPress fail so often and which WPML bugs cost us the most nerves. You’ll see our solution in detail: a retrofit of about 300 lines of code that Claude Code wrote in ten minutes, and a translation workflow that translates, checks, and imports a 10,000-word article in 3 to 5 minutes – verifiably complete. And at the end you’ll get the two prompts you can use to rebuild the whole thing yourself: one for your developer or Claude Code, and one for the translation work itself. One thing up front, so expectations are right: this is not an “AI does everything” article. In our setup, AI handles the routine – reliably, verifiably, and at a fraction of the previous cost. The responsibility rests with a process that has controls built in. What that looks like is what you’ll read now. ![WordPress content is automatically translated into multiple languages and checked with AI](https://4eck-media.de/wp-content/uploads/2026/07/wordpress-wpml-claude-cover-safe-layout-source.avif) ## Why multilingualism is no longer a nice-to-have The short answer: because your next inquiry no longer necessarily comes from the neighboring town, but from Zurich, Vienna – or Tokyo. Anyone who runs their website in German only turns language into a sales barrier. And that’s in a market that abolished exactly this barrier long ago. ### What does the EU single market have to do with it? The single market has largely leveled tariffs, borders, and bureaucracy between member states. An agency in Görlitz can work for a client in Lisbon, a shop in Graz can ship to Helsinki – legally and logistically, that’s everyday business. The last real border that remains is language. Anyone who offers a website in only one language raises again the border the market has just torn down. The economic pressure is correspondingly real: your competitors are no longer the three providers in your area, but everyone who speaks the customer’s language. ### How do we know the market really is global? From our own inbox. We now receive inquiries from Switzerland, Austria, Japan, Canada, and the USA. The reason is remarkable: AI assistants recommend us when someone asks for the “best WordPress agency” or looks for help with SEO, marketing, and AI integration. We’ve described in detail how to get into these recommendations in our [GEO article](https://4eck-media.de/en/blog/the-4eck-geo-framework-for-ai-visibility-ai-recommendations/) – here only the consequence matters: the customer researches in their language, their AI assistant answers in their language, and if your website doesn’t exist there, you don’t exist for that customer. That changes the math. In the past, an English version was “nice for international visitors.” Today it decides whether you appear in answer engines at all. And no one can predict any more in which language the next inquiry will arrive – for us, most recently, it was Japanese. We drew the consequence from that and set up ten languages in WPML. Not because we want to open offices in ten markets, but because we can no longer decide where the next customer will do their research. ### Why are price and speed a strategic question? Because multilingualism is not a one-time project but a permanent state. Every new blog article, every case study, every service page has to be brought along – otherwise the foreign-language version decays into a ruin of outdated content. And this is where the declaration of intent parts ways with practice: if a translation round takes weeks or costs four figures per language, at some point it just doesn’t happen. Not out of ill will, but because in day-to-day business there’s always something more urgent waiting. That’s exactly why we treat translation cost and translation speed not as an operational detail but as a strategic lever: they determine whether multilingualism is actually lived or gathers dust on the “someday” list. How we got both under control is shown in the chapters that follow. Why the market is no longer local - The EU single market has removed almost all borders – language is the last one, and it’s on your website - Our inquiries now come from Switzerland, Austria, Japan, Canada, and the USA - AI assistants recommend us for queries like “best WordPress agency” as well as for SEO, marketing, and AI integration - Anyone who offers only one language is simply absent from foreign-language AI answers - The price and speed of translations decide whether multilingualism is maintained over the long term ### Frequently asked questions about multilingualism Is multilingualism worth it for small businesses too? Especially then. Large providers can afford translation agencies; small ones lose international inquiries without a fight. When translations become fast and cheap, the only rational argument against them disappears – and the addressable market grows without you running a single ad. Which language should you start with? With the one that inquiries already come from or that your target customers research in. English is usually the first step, because AI assistants also use it as a bridge language. After that, your market decides, not your gut feeling. Isn't the automatic translator in the visitor's browser enough? No. Browser translation only kicks in once the visitor is already on your site. The decisive moment comes before that: in search and in the AI recommendation, which happens in the user’s language. There, only what actually lies translated on your domain counts. ## How translations work in WordPress – and where they fail If you want to understand why website translations are so laborious and expensive, you only need a single insight: WordPress does not store an article as one text. It stores it as hundreds of small fields – and every single one of them has to go through the translation. ### Why is an article not “one text”? What looks like a continuous article in the browser sits in the database in pieces: the headline is a field, every paragraph is a field, every single list item, every image caption, every subheading. Add to that the invisible parts that no visitor reads but every search engine does: SEO title, meta description, the URL slug. A concrete example from our own blog: our largest article, the GEO framework, consists of 1,599 blocks and breaks down into 1,725 translation segments. Over 10,000 words, spread across more than 1,700 form fields. That’s an extreme case, admittedly – but it shows the order of magnitude a single ambitious specialist article plays in. Translation plugins mirror exactly this structure. WPML is the market leader, Polylang and TranslatePress are the best-known alternatives – the basic principle is the same everywhere: the plugin creates a copy of the field structure for each language and runs every field through the translation individually. That’s not a design flaw but a necessity, so that layout, links, and formatting survive the translation. But it explains why “just quickly translate the page” is no small request. There are essentially three ways to fill these fields – and each one hurts in its own way. ### Path 1: Manually in the translation editor The translation editor shows the German field on the left, the empty target field on the right. You translate, click next, translate, click next. For a contact page with twenty fields, that’s doable. For a 10,000-word article with more than 1,700 fields, it’s days of assembly-line work – per language, mind you. And it’s the most exhausting kind of work: monotonous enough to produce mistakes, but too demanding to hand off to the untrained. Anyone who loses concentration after field 900 doesn’t notice it – the result does. We set up ten languages in WPML; anyone who honestly follows that math to its conclusion quickly puts the calculator away again. ![WPML translation editor with the long field list of a large article, many fields per post](https://4eck-media.de/wp-content/uploads/2026/07/Bild-2-wpml.avif) ### Path 2: The translation agency The classic path: export the text, hand it to an agency, feed the result back in. Often good in quality – but the billing follows a merciless formula: price per word × volume × number of languages. For a website like ours, with 116 blog articles, 53 case studies, and 199 competency pages, this multiplication turns into an amount that no marketing budget hands over voluntarily. Add to that the return trip: someone has to sort the delivered texts back into the hundreds of fields – which gets you part of Path 1 thrown in for free. ### Path 3: Automatic translation with WPML credits WPML comes with built-in automation: at the push of a button, DeepL, Google, or Microsoft translate the content, billed via credits. That’s the most convenient path – and it has two catches. First, the billing: per word and per language. Bringing one article into one language is cheap; bringing 116 articles into several languages no longer is. Anyone who publishes regularly pays regularly too. Second, and this weighs more heavily: the automation translates without project context. It doesn’t know your brand, your product names, your terminology – it only ever sees the single segment currently in front of it. So it cheerfully translates brand names along with the rest, and technical terms jump back and forth between pages: on one page it’s called this, on the next something else, and the reader wonders whether those are two different things. The result is rarely wrong, but reliably mediocre. For a business-card page, that may be enough. For a blog that’s supposed to prove competence – and that wants to be used as a source by AI assistants – “reliably mediocre” is the wrong quality target. Let’s be clear: expensive, slow, or mediocre – take your pick. This is exactly where our workflow comes in. But first we have to talk about something more unpleasant: about the places where WPML isn’t just laborious but simply broken. Three paths – expensive, slow, or mediocre - A WordPress article is not text but hundreds of fields: our largest breaks down into 1,725 segments at over 10,000 words - Path 1, manual in the editor: over 1,700 fields per language – days of assembly-line work - Path 2, translation agency: price per word × volume × languages – unaffordable at 116 articles - Path 3, WPML credits: convenient, but billed per word and language – and without project context, brands get translated along with everything else - All three paths scale poorly: expensive, slow, or mediocre ### Frequently asked questions about WordPress translations Why can't I just copy the whole article and paste it in translated? Because the structure gets lost in the process: blocks, formatting, internal links, and SEO metadata are attached to the individual fields. Translation plugins break the content into segments for exactly this reason – only that way does the page remain technically identical to the original after translation. Is WPML the right choice, or better Polylang or TranslatePress? For websites with complex content (ACF fields, Gutenberg blocks, SEO metadata), WPML is the most deeply integrated and therefore the market leader. Polylang and TranslatePress are leaner alternatives for simpler setups. Anyone already deep into WPML should know: a migration is usually more expensive than repairing the problems. Isn't automatic WPML translation enough to start with? For individual pages: yes, certainly. The problem begins with volume and ambition – many articles times several languages gets expensive, and without a glossary and context, consistency suffers. Fine for a business-card website, too little for a specialist blog. How many segments does a normal page have? That varies enormously. A short service page gets by with a few dozen fields; our largest blog article comes to 1,725 segments. It’s exactly this range that makes blanket statements about translation effort so unreliable – count segments, not pages. ## The WPML bugs we learned the hard way Up front, so no wrong impression arises: we love WordPress. It powers around 41 percent of all websites and holds just under 60 percent of the CMS market – we build our business on it. That’s exactly why we’re annoyed. What follows is not a hater’s takedown but the record of users who deploy WPML in production and, in doing so, found things you won’t read in any product description. ### The silent data loss: max_input_vars The worst bug is the one that throws no error message. Our GEO framework article has 1,599 blocks, which become over 1,700 form fields in the translation editor. But PHP has a default limit on how many form fields a server accepts per request: max_input_vars, 1,000 out of the box. Everything above that is silently discarded on save. No error, no warning – the editor reports success, the excess fields are simply gone. The result for us: 1,247 of 1,725 segments were stuck. Cleanly translated in the editor, the “Translation is complete” box checked – but the translations never reached the live site. You work for days, the system confirms the work, and the visitor to the translated page still reads German. The insidious part: the error looks like an operator mistake. Did someone forget to save? Caught the wrong language? Anyone who doesn’t know what to look for searches within themselves for weeks – while the cause is a server constant that most editors have never heard of. ### Green checkmarks on empty fields Even more perfidious: we found translations where the “Translation is complete” box was checked – on empty fields. The status says done, the field says nothing. For a translation system, that’s the worst-case scenario, because the status is the only thing planning and sign-off rely on. Our conclusion has been in every work instruction since: you must not believe the status checkmarks. Control happens on the exported content, never on the dashboard. ![WPML editor: several empty target fields with the "Translation is complete" box checked at 1 percent progress](https://4eck-media.de/wp-content/uploads/2026/07/bild-03-wpml-complete-leer.avif) ### The Translation Memory forgets The Translation Memory is actually WPML’s strongest feature: whatever has been translated once is pre-filled the next time. For our large article, it delivered a solid 462 of 1,725 segments ready to go – nearly a quarter of the work as a gift, which we’ll gladly take. But it has a weakness: when an article changes and WPML re-segments the content, segments that were actually already translated get lost in the process. You then pay for the same translation a second time – or, worse, you overlook that it’s missing, because “everything was actually already translated once.” You don’t build planning on a memory that forgets when you turn the page. ### And then the cache comes on top of it all Suppose you’ve found all of this and imported the corrections. Then, between you and the visitor, there’s still the page cache: in one case the correction was long since in the system, but visitors saw the old, faulty version for another 24 hours. For quality control, that means: even a look at the live site proves nothing as long as you don’t know when the cache was last cleared. Troubleshooting thus becomes a layer model – editor, database, cache, and each layer can tell a different truth. ### The small stuff that costs hours Two finds from the “only costs nerves” category: the export always delivers XML – no matter which file extension you request. Anyone who built their tooling on a different format gets to rebuild. And the REST API doesn’t see hidden languages: as long as a language isn’t published yet, you simply can’t query it via the interface – precisely in the phase when you most urgently want to check automatically. ### Why we still don’t switch You could now shout: away with WPML! We see it differently, for two reasons. First, WPML is deeply integrated into our website – ACF, Gutenberg, SEO metadata. A migration would be more expensive than the repair. Second, and this is the more important point: under the hood, everything is there. XLIFF export and import, Translation Memory, internal APIs – the machine works. Only the browser form layer is broken, which is exactly the layer people work with. And let’s be clear: these are not operator errors. We searched long enough in the other direction to say that with some certainty. These are systemic problems of a tool with over a million installations. When a form silently discards data on large articles and a status checkmark sits on empty fields, it hits everyone who publishes seriously in multiple languages – most just don’t notice, because nobody proofreads the Polish version of their own blog field by field. The good news: precisely because the underlying functions are intact, you can bypass the broken form layer instead of repairing it. How, is shown in the next chapter. The WPML traps that cost us nerves - max_input_vars (default: 1,000 fields) silently truncates the editor form on large articles – 1,599 blocks, over 1,700 fields, no error message - Result for us: 1,247 of 1,725 segments translated and marked “complete,” but never arrived on the live site - We also found the “Translation is complete” box checked on completely empty fields – the status is not to be trusted - Translation Memory loses already-translated segments on re-segmentation; the cache showed visitors the old version for 24 hours - Small stuff: export always delivers XML, the REST API doesn’t see hidden languages - Bottom line: systemic problems, not operator errors – but the underpinnings (XLIFF, TM, internal APIs) work ### Frequently asked questions about WPML problems How do I recognize that the max_input_vars bug affects me? By the contradiction between status and live site: the editor reports “complete,” but on the translated page German text still stands or fields stay empty. Mainly affected are long articles with many blocks. Export the translation and search the target for empty segments and source language – you must not believe the checkmark alone. Is it enough to raise max_input_vars on the server? It defuses this one bug, yes – provided your host lets you change the value at all. The other problems remain: false complete statuses, segment losses in the Translation Memory, cache delays. That’s why we decided to bypass the form entirely and import via XLIFF – one operation, no field limit. Should we migrate away from WPML because of these bugs? In most cases: no. With deep integration into ACF, Gutenberg, and SEO metadata, a migration is more expensive than the repair, and WPML’s core functions are intact. What’s broken is the form layer in the browser – and that can be bypassed instead of replacing the whole system. How do we make sure translations are really live? With control on the content instead of the status: after the import, export the translation again and check whether everything arrived; on the live site, spot-check for source language; and after corrections, keep an eye on the cache. For us, this control export is a fixed part of every translation cycle. ## Repair instead of switch: our decision We stayed with WPML – and instead built a path around the broken form. This decision was made not out of nostalgia but after a sober calculation: WPML is deeply embedded in our project. ACF fields, Gutenberg blocks, SEO metadata – everything runs through WPML, across ten languages. A migration to a different translation plugin would have meant rebuilding this wiring across 116 blog articles, 53 case studies, and 199 competency pages. That would have been more expensive than the repair. Considerably more expensive. On top of that came an observation that changed everything. When we looked under the hood, nothing was broken. WPML has XLIFF export and import. WPML has a Translation Memory that remembers every passage ever translated. WPML has internal APIs that handle all of it cleanly. The engine room works. Only the user floor is broken: the browser form of the translation editor, which on large articles sends more fields than the server accepts – and silently discards the excess ones. So a plugin switch would have thrown out the working engine room along with it, just to get rid of a defective surface. And on top of that the Translation Memory: every already-paid, already-signed-off translation from ten languages. Nobody gives up that capital voluntarily. Anyone who tears down the whole house because of one defective floor has a budget problem. The rational answer is: we take the stairs. Concretely, that means running the cycle of exporting, translating, and importing entirely past the form – directly through the functions WPML already brings along. No fork, no replacement, no parallel operation of two plugins. Just a detour around the one spot that doesn’t hold. And this is exactly where AI comes in. Not as a magic button labeled “translate” that you press and hope – such buttons had just given us empty fields with green checkmarks. But as a worker you can hand two very concrete assignments. First: the retrofit itself – writing the code that opens the detour. Second: the translation – the actual grind, segment by segment, with checks before and after. Both are tasks with clear rules and a measurable result. Exactly the kind of work AI reliably delivers on today – and where a human as reviewer still has the last word. What this retrofit looks like, how long it really took, and why it turns a broken editor into a continuous translation workflow – those are the next two chapters. ## The retrofit: a mini plugin with four routes that Claude Code wrote in ten minutes The whole repair is a single mu-plugin: around 300 to 400 lines of PHP that open four HTTP routes to functions WPML has long possessed. The plugin translates nothing, creates nothing, deletes nothing. It’s a door – nothing more. The code was written by Claude Code following a technical specification; our developer reviewed and deployed it. The generation itself was a ten-minute task. ![Architecture of the geo-helper mini plugin: AI environment, REST routes, WPML functions, and database](https://4eck-media.de/wp-content/uploads/2026/07/bild-04-plugin-architektur.avif) ### What exactly does the plugin do? It provides five endpoints, four of which carry the actual work: - **/status** – what’s translated, what’s not. The answer you’d otherwise have to laboriously click together in the WPML backend, as a single query. - **/requeue** – put a piece of content back into the translation queue. WPML then builds the job and pre-fills from the Translation Memory everything that was ever translated. - **/export** – export the complete content as an XLIFF file, segments in pairs: German source, target-language field. - **/import** – play the finished XLIFF file back in, as a single operation. In addition there’s **/ping** for diagnostics: does the installation respond at all before you start a run? What’s decisive is what the plugin does *not* do. It invents no new translation logic, no editor of its own, no parallel data model. Each route is a pure wrapper around a WPML-internal function – the same mechanisms that WPML’s official XLIFF workflow uses too. We didn’t remodel anything, we just gave four existing capabilities an address you can reach without a browser. ### How did it come about? Told transparently, because this part interests many project managers: at the start there wasn’t code but a technical specification – which routes, which parameters, which behavior in the error case, what is explicitly forbidden. We worked out this specification with Claude Code and then handed it back as an assignment: write the mu-plugin exactly according to this document. ![Technical specification of the five REST routes of the geo-helper plugin](https://4eck-media.de/wp-content/uploads/2026/07/bild-05-spezifikation-routen.avif) The code generation took about ten minutes. And here we stay honest, because the ten-minute figure alone would paint a skewed picture: the review by our developer, setting up the IP allowlist, and the deployment cost an evening. A human read every line before it was allowed onto the live environment. That’s not distrust of the AI but simply the division of labor we would apply to any code on a client environment – regardless of who wrote it. The math still clearly works out: an evening of effort for a tool that has carried every translation cycle since. ### Is that secure? The question came up internally first, and it’s justified: four open HTTP routes on a production website sound at first like an attack surface. Our answer consists of three levels. First: an IP allowlist instead of tokens. Only the fixed outbound IP addresses of the AI environment may address the routes at all; every other request bounces off. This also means there are no tokens in the code that could expire, leak, or be committed by accident. Second: the plugin can’t delete anything. This capability simply doesn’t exist in the code – the worst case imaginable is a failed import, not lost content. Third: it creates no content. No new posts, no pages, no users. It moves translation data exclusively through channels that WPML itself defines. ### Why is this the game changer? Because it changes *who* can run the cycle. Previously, “export → translate → import” hung on the browser: log in, click, wait – and on saving large articles, run straight into the max_input_vars trap we dissected in the previous chapters. An AI agent can’t rescue a browser form that the server truncates server-side. With the four routes, the same cycle runs without a browser. And that means: an AI agent can take it over completely. It queries the status, puts the article back into the queue, fetches the XLIFF file, translates, checks, plays it back, and reconciles – and doesn’t fail at a form that was never built for 1,700 fields. A tool that a human has to operate and that fails on large content becomes an interface that a machine can operate reliably. The next section shows this process step by step on the largest article of our website. The helper plugin in five points - One mu-plugin, approx. 300-400 lines of PHP – pure wrappers around existing WPML functions - 4 work routes (/status, /requeue, /export, /import) plus /ping for diagnostics - Code generation by Claude Code: ~10 minutes; review, IP allowlist, and deployment by the developer: one evening - Security: IP allowlist instead of tokens, no deletion possible, creates no content - Effect: the cycle “export → translate → import” runs without a browser – an AI agent can take it over completely ### Frequently asked questions about the retrofit Does the mini plugin replace WPML? No. It extends WPML with four externally reachable routes to functions WPML already brings along: XLIFF export, XLIFF import, queue, status query. Translation still happens in WPML’s data structures – including the Translation Memory. Does the plugin translate itself? No, not a single line. It exports content as XLIFF and plays finished XLIFF files back in. The translation happens outside – for us through AI agents, but there could just as well be a human translation agency at the other end. Why an IP allowlist and not API tokens? Because the AI environment has fixed outbound IP addresses, and with them we reduce the attack surface to a minimum without managing secrets in the code. No token means: nothing that can expire, leak, or accidentally end up in a repository. Can such a plugin damage the website? The damage potential is deliberately kept small: the plugin can’t delete content and can’t create any; it only moves translation data through WPML’s own mechanisms. Add to that the control export after every import, which checks whether what should have arrived really did. ## How a translation runs today: the workflow step by step The result up front, on the toughest example on our website: our largest article – the GEO framework, 1,725 translation segments, over 10,000 words – was translated with this workflow in 3 to 5 minutes. 1,215 segments freshly translated, automatically checked, imported, and confirmed by a control export. The same article on which 1,247 segments were previously stuck in the broken editor. Here is the process, step by step. ![WPML translation queue with many items in multiple languages, all in the status needs translation](https://4eck-media.de/wp-content/uploads/2026/07/bild-10-wpml-queue.avif) ### Step 1: requeue – WPML sets the table The agent calls the /requeue route, WPML builds the translation job and pre-fills from the Translation Memory everything that was ever translated. For our article, the TM delivered 462 of 1,725 segments ready to go – a good quarter of the work was done before anyone had translated a word. This is the moment when every previously saved translation pays off, including those from the WPML era before the retrofit. ### Step 2: Export – the whole article as one file Via /export, the complete article comes out as a single XLIFF file: all segments in pairs, German source next to the target-language field. One file, one state, one point of truth – instead of 1,700 form fields, of which the server accepts only the first 1,000. ### Briefly explained: What is an XLIFF file? XLIFF stands for “XML Localization Interchange File Format” – an industry standard established for years for translations. You can think of it as a standardized container: an XLIFF file contains the text cleanly broken into segments, and each segment has a source field (the original) and a target field (the translation). Formatting, tags, and order are preserved in the process. The charm of it: almost every serious translation tool speaks XLIFF – WPML too exports and imports in this format. Instead of squeezing text through narrow form fields, you pass around a single, checkable file. That’s exactly what we use: WPML issues the article as XLIFF, the AI fills the target fields, and WPML reads the finished file back in – without anything getting lost along the way. ### Step 3: Sorting – not everything belongs in translation A script divides the segments into three stacks: **translate**, **don’t touch** (brand names, URLs, ACF settings – everything that has to stay identical in every language) and **already done** (the 462 TM hits). This step seems inconspicuous but prevents the two classic errors of machine translation: that someone “translates” a URL or that a technical settings field ends up in beautiful target-language prose. ### Step 4: Parallel AI agents – 14 batches, one glossary The remaining segments go in 14 batches of about 85 segments to parallel AI agents. So that fourteen translators don’t choose fourteen words for the same technical term, they all work with a shared terminology glossary that was built beforehand from the existing translations. Consistency here arises not from hope but from a shared word list. The parallelism is the reason a 10,000-word article doesn’t become a week-long task: 14 workers, at the same time, with identical rules. ![Pipeline log: 14 batches, checks, and import confirmation of the AI translation](https://4eck-media.de/wp-content/uploads/2026/07/bild-06-pipeline-log.avif) ### Step 5: Checks before the import – the machine controls the machine Before anything flows back into WordPress, every translated file runs through automatic checks: Is the XML valid? Are all HTML tags complete? Do lists have as many items as in the original? Are links untouched? And: are there still leftover German words in the target text? For the last check there’s a whitelist of proper names – a “Deutsche Gesellschaft für …” is called that in every language and must not fail as a translation error. If a batch fails, it’s corrected before it may proceed. Nothing reaches the import unchecked. ### Step 6: Import – one operation, past the form The checked XLIFF file goes back via /import – as a single operation, directly through WPML’s internal functions. No browser form, no max_input_vars limit, no silent discarding of fields. Exactly the spot where the old path broke simply doesn’t exist in this path. ### Step 7: Control export – trust is good, reconciliation is mandatory Finally, we export the same article once more and reconcile: does every target field really contain what was imported? We trained ourselves into this paranoia with the empty fields with the “Translation is complete” checkmark. Since then we no longer believe a status checkmark – but we do believe an export reconciliation. [Screenshot placeholder: article page before/after – empty translation with “complete” checkmark vs. fully translated live page] ### What does that mean in numbers? 1,215 segments freshly translated, checked, and imported – in 3 to 5 minutes. For comparison, the old calculation for the same article: a week of translator work, plus another week to dig out what the editor lost on save. And the workflow scales: for English we managed 638 segments across 50 case studies, one blog article, and 4 pages in a day; French stands at 53 case studies fully complete with 401 translated and corrected segments. Today EN, FR, and PL are 100% complete – blog, case studies, pages. Spanish is running autonomously right now, following a written work instruction. The human in the chain hasn’t disappeared. They’ve just moved from typing to signing off. The workflow using the example of our largest article - 1,725 segments, over 10,000 words – the largest article on the website - Translation Memory delivered 462 segments ready to go - 14 parallel AI agents, batches of ~85 segments, shared terminology glossary - 5 automatic checks before the import: XML, HTML tags, list items, links, leftover German words - Result: 1,215 segments translated, checked, and imported in 3 to 5 minutes - Old path: a week to translate plus a week to find what wasn’t saved ### Frequently asked questions about the workflow Why is the article exported as a single XLIFF file? Because one file is a consistent state: source and target lie in pairs next to each other, nothing is truncated by the server, and the import later runs back as one operation. That’s exactly what the browser form can’t manage on large articles – there the process broke off. How do you make sure 14 parallel agents translate uniformly? Through a shared terminology glossary that’s built from the existing translations before the run. Every batch works with the same word list; technical terms and recurring phrasings thereby stay consistent across all batches. What happens if a translation doesn't pass the automatic checks? Then it doesn’t reach the import. The checks run before the import: XML validity, complete HTML tags, the same number of list items, untouched links, no leftover German words. Only a clean file goes back via /import. How do you know that after the import everything really arrived? Through the control export: after the import, the article is exported again and reconciled against the imported version. We no longer trust the status checkmark alone – empty fields with “Translation is complete” were, after all, the starting point of this whole story. ### The real lever for speed: parallel instead of sequential That a week-long task becomes a few minutes isn’t due to faster typing. It’s due to parallelism. Instead of working through field by field and language after language, Claude breaks the work into independent batches, translates them simultaneously, and merges everything at the end – including the checks. ![Schema of the parallel orchestration: Claude divides the work into batches, runs them simultaneously, and merges them; time comparison weeks versus minutes](https://4eck-media.de/wp-content/uploads/2026/07/bild-09-parallel-orchestrierung.avif) The nice thing about it: Claude often does this on its own. It recognizes that the individual batches don’t need to know anything about each other and starts them in parallel without you having to ask specially. But not always. With a vaguely phrased instruction, the model sometimes dutifully works through in order – the result is right, it just takes longer. That’s why we write the speed directly into the prompt. One sentence is enough, and you simply append it to the work instruction: ``` Process the batches in parallel, not one after the other: start several translation agents at the same time and merge the results at the end. Process the batches in parallel, not one after another: run several translation agents at the same time and merge the results at the end. ``` The effect is exactly the one from the graphic: weeks become minutes. And in a business where time is the only raw material you can’t buy, in the end it’s often not the better product that decides but the faster one. Whoever implements an idea immediately is there before the competition even starts. ## How we know that really EVERYTHING is translated Short answer: we don’t believe a single checkmark. Instead, we check every language in three stages – first the overall status, then every individual segment, then the content itself. Only when all three stages are clean does a language count as done for us. And it’s exactly this skepticism that let us find errors that had gone unnoticed by anyone in the German original for years. If you’ve read this far, you know the reason for our distrust: 1,247 segments with the “Translation is complete” checkmark set – and behind them empty fields. Anyone who has experienced that once builds a control system. Ours has three stages. ### Stage 1: Where do we stand at all? The status matrix. Per language and content type – blog articles, case studies, pages – we see at a glance: complete, outdated, or untranslated. That’s the one-minute overview you want as a project manager every morning. Not twenty clicks through the WPML backend, but a table that answers the question: where is something still missing? The matrix, however, only says what WPML *believes*. That’s why there’s Stage 2. ![Status matrix before/after: translation gaps at the start of the project and fully green languages EN, FR, PL](https://4eck-media.de/wp-content/uploads/2026/07/bild-08-status-matrix.avif) ### Stage 2: Are the checkmarks right? The segment scan. We export every single translation job and search by machine for two things: empty target fields and German text where none should be. You must not believe the status checkmarks – it was with exactly this scan that we found the articles where “complete” sat on empty fields. The status was well-kept, the live site half German. That sounds like a lot of work, but it’s a script: export, reconcile, findings list. Proper names like “Deutsche Gesellschaft für …” are on a whitelist so they don’t slip through as errors. ### Stage 3: Is it also good Polish? Any script finds an empty field. But a Germanism? An undeclined proper name? For that we have AI agents read the translation as native-speaking proofreaders against the German original – sentence by sentence, meaning against meaning. The result for Polish surprised even us. All 53 case studies stood at “complete.” The proofreading nevertheless found around 70 findings: Germanisms, undeclined proper names – and in one case the description of the wrong client. A copy-paste error that was even in the German original. Online for years, noticed by no human, found by the AI during the systematic comparison. We imported all 132 corrections in one evening. For us, that’s the real point of this chapter: the AI doesn’t just translate – it’s the auditor that doesn’t get tired at the 1,500th segment. A human proofreader reads 53 case study pages and tires at some point; that’s not criticism, that’s biology. The agent reads segment 1,500 with the same attention as segment 1. The three-stage quality control - Stage 1 – status matrix: language × content type, overall picture in one minute - Stage 2 – segment scan: export every job, search for empty fields and leftover German words; checkmarks don’t count - Stage 3 – native-speaker AI proofreading against the original: meaning errors, calques, declensions - Practical proof: 53 Polish case studies “complete” – yet ~70 findings, including the wrong client in a description - All 132 corrections imported in one evening ### Frequently asked questions about quality control Isn't the status display in WPML enough? No. The status only says that a translation job was completed – not that the content arrived on the live site. We had 1,247 segments with a checkmark and empty fields. That’s why we always check again at the segment level. Who controls the control – can the AI find its own errors? The proofreading checks against the German original, not against its own translation, and runs as a separate step with a separate role. Add to that automatic checks before every import: valid XML, complete HTML tags, untouched links. In the end, a human still takes spot-check sign-off with us. How long does such a check run take? The status matrix is one minute. The segment scan and proofreading run automated – for Polish we imported all 132 corrections from the proofreading in a single evening. Does the proofreading really find things that humans overlook? Yes, demonstrably: the copy-paste error with the wrong client was even in the German original – and had never been noticed there by anyone. The systematic comparison sentence by sentence doesn’t tire, and that’s precisely where its advantage lies. ## Who translates and who checks: the division of labor between the models The insider tip from our workflow isn’t a piece of software but a staffing decision: we use two different AI models – one translates, the other checks. This division of roles is the reason the math works out in the end. The split looks like this: Claude Opus 4.8 is the executing model. It’s fast and, for mass work, considerably cheaper – ideal for the actual translation work, the parallel batches of around 85 segments, working through the queue. Claude Fable 5 is analytically stronger but more expensive – and is therefore only needed selectively: it plans the process, checks spot samples, and signs off on the result. If that sounds familiar, it’s because you probably organize your team that way: the junior translates, the senior reviews. Nobody has the most expensive head in the house translate 1,700 segments of body text – they should set the structure and take a look at the end. That’s exactly what we do with the models. Except both work at night and don’t get sick. ### Fast, cheap, good – pick two? The old project-management triangle says: of fast, cheap, and good you only ever get two. The division of roles is our answer to that – it delivers all three. Fast, because the executing model works in parallel in batches. Cheap, because the expensive model is only paid for the moments when analysis is really needed: planning, spot check, sign-off. And good, because it’s not the same model waving through its own work, but a second, stronger instance that checks. What matters is the order: first the senior model plans the assignment – what gets translated, what stays untouched (brands, URLs, ACF settings), which terminology glossary applies. We build the glossary from the existing translations so that all parallel agents use the same terms – otherwise the same technical term is called something different in batch 3 than in batch 11. Then the junior model works through the mass. At the end the senior comes back and checks by spot sample whether the result matches the specification. No segment goes into the import that hasn’t run through this chain. With the 1,725-segment article, it looked concretely like this: 14 parallel agents, each with a batch of around 85 segments and the same glossary. The mass ran on the cheap model – the planning before and the sign-off after on the strong one. Result in 3 to 5 minutes, without the expensive instance translating even a single body-text segment itself. For you as a project manager, that means: with AI projects, don’t think in terms of the question “Which model is the best?” but “Which role needs which model?”. Using the best model everywhere makes as much sense as giving every task in the team to the most expensive person. Who translates, who checks - Claude Opus 4.8 translates: fast, cheaper for mass work, parallel batches of ~85 segments - Claude Fable 5 plans, checks spot samples, signs off: analytically stronger, only needed selectively - Principle: junior translates, senior reviews – both work at night and don’t get sick - Result: fast AND cheap AND good – the division of roles overrides the old “pick two” ## What that means in numbers The bottom line first: 116 blog articles, 53 case studies, 19 pages – English, French, and Polish stand at 100 percent complete. Spanish is running right now, and autonomously at that: following a written work instruction, without anyone sitting alongside. The time frame for it: hours instead of weeks. Two examples that make the difference tangible. For English we translated, checked, and imported 638 segments in a single day – 50 case studies, one blog article, four pages. And the biggest chunk of the whole website, the GEO framework article with 1,725 segments and over 10,000 words, was done in 3 to 5 minutes: the Translation Memory delivered 462 segments ready to go, the remaining 1,215 were translated, checked, and imported by 14 parallel AI agents. The same article on which the translation editor had previously failed with 1,247 stuck segments. Add to that French: 53 case studies complete, 401 segments translated or corrected. And for Polish, all 132 corrections from the proofreading went live in one evening. With the costs, the logic is simple: we pay a Claude subscription – no billing per word and per language. WPML’s automatic translation via credits (DeepL, Google, Microsoft) exists, but is billed exactly that way: per word, per language. At 116 articles times several languages, that adds up considerably. On top of that: the subscription covers not just the translation but also the proofreading, the check scripts, and the control export – work steps that don’t even appear in a per-word calculation. Add to that an effect we hadn’t planned for: inquiries now come from Switzerland, Austria, Japan, Canada, and the USA. AI assistants recommend us for queries like “best WordPress agency” as well as for SEO, marketing, and AI integration. The market has become global – and a website that speaks only German is invisible in this market. ### What AI can’t do here So no wrong impression arises: we’re not claiming AI can do everything. Legal texts and brand slogans need a human at the end of the chain – with the one, liability is attached, with the other, nuance, and neither is delegated to a language model. In our workflow too, a person takes the final spot-check sign-off. But that’s not an argument against the approach, rather its limit. Where weeks of routine work can be automated – export, translate, check, import 1,725 segments -, it’s the only rational decision to do so. The responsibility here rests with the process and its checks: status matrix, segment scan, proofreading, automatic checks before every import. Not with faith in the model. The project in numbers - 116 blog articles, 53 case studies, 19 pages – EN, FR, and PL 100% complete - Spanish is running autonomously following a written work instruction - 638 EN segments in one day; the 1,725-segment article in 3 to 5 minutes - Cost: one Claude subscription instead of billing per word and language - Limit: legal texts and brand slogans need a human at the end ## What you need to rebuild this The good news up front: the shopping list is short. You don’t need a new translation platform, no migration, and no special budget – just four things, three of which you probably already have. **First: WordPress with WPML.** Any version with XLIFF support will do. The whole workflow uses functions already in WPML – XLIFF export and import, Translation Memory, the internal APIs. Nothing is replaced, only made accessible. **Second: a developer for half a day.** The mu-plugin – around 300 to 400 lines of PHP, pure wrappers around WPML-internal functions – is generated by the AI in about ten minutes. The human does what you don’t delegate: code review, deployment, IP allowlist. For us that was an evening. For security: only the fixed outbound IPs of the AI environment get through, no tokens in the code, and the plugin can’t delete anything – it exports, imports, and reports status, nothing more. **Third: a Claude subscription** with access to Claude Code and Cowork. That’s the engine of the whole thing – and the reason no per-word bill arises. **Fourth: a person for the final sign-off.** Native-speaker spot checks at the end of the chain. The AI proofreads systematically, but the last approval stays with a human. That doesn’t have to be a full-time translator – it’s about spot checks, not a complete read-through; the complete part has already been done by the machine beforehand. ### When is our path not worth it? That too belongs in an honest checklist. A 5-page website you’ll translate faster by hand – building the workflow only pays off once the volume beats the manual approach. And legal content, with us, only goes ahead with professional review as a matter of principle; we deliberately don’t automate that. For everything in between – blogs, case studies, competency pages in multiple languages – the following applies: the tools are ready. XLIFF export, Translation Memory, the internal APIs – all of that is already in WPML; the four routes of the plugin (/status, /requeue, /export, /import) merely make it reachable from outside. What’s missing is usually not technology but the decision to plug it together. What you need to rebuild it - WordPress + WPML, any version with XLIFF support - A developer for half a day: plugin review, deployment, IP allowlist - Claude subscription with Code + Cowork - A person for native-speaker spot-check sign-off - Not worthwhile for: 5-page websites (by hand is faster) and legal content without professional review ## To take away: Prompt 1 – the retrofit (for Claude Code or your developer) We now make good on the promise from the introduction. The following prompt is the compressed version of the specification our helper plugin was created from. Copy it into Claude Code – the result is a plugin draft that your developer reviews and deploys. That’s exactly how ours came about: ten minutes of generation, one evening of review and deployment. Two things you additionally have to do by hand, without which nothing works: First: enable your website domain for the AI environment. Important – this doesn’t happen in the Claude app but in the account settings on the claude.ai website, under Capabilities → Allow network egress → Additional allowed domains. There you enter your domain (for us 4eck-media.de). The reason: Claude works in a sealed-off environment that isn’t allowed onto the open internet on its own. If this entry is missing, the environment blocks every request to your server – requeue, Export, and Import fail before they even start. A one-time step, without which the whole workflow won’t run. ![Settings on claude.ai: your own website domain entered under Capabilities, Allow network egress, Additional allowed domains](https://4eck-media.de/wp-content/uploads/2026/07/bild-11-claude-domain-allowlist.avif) Second: if you also use Claude in the browser (for example for checks in the WordPress admin), add your website to the list of allowed sites in the Claude browser extension. ``` Task: Build a WordPress mu-plugin ("translation-helper", single PHP file, ~300–400 lines) that exposes existing WPML translation operations over HTTP, so an external AI agent can run a full translation cycle without using the wp-admin browser forms. Routes (REST namespace translation-helper/v1): 1. GET /ping → { ok, wpml_version, plugin_version } - health check, no params. 2. GET /status → params: lang (required), type (post type, e.g. post/page/custom), per_page, page. Returns items with: post_id, title, target_lang, translation_status (not_translated | in_progress | needs_update | complete), job_id, needs_requeue. 3. POST /requeue → JSON body { post_id, target_lang }. Re-queues the post for translation using WPML's Translation Management API (equivalent to sending it to translation in the dashboard). WPML must prefill targets from Translation Memory. Returns new job_id. 4. GET /export → param job_id. Streams the job as XLIFF 1.2 (XML). 5. POST /import → multipart: job_id + file (the translated XLIFF). Applies the translation using WPML's own import routines. Returns { ok, segments_total, segments_applied, status }. Hard requirements: - Wrap EXISTING WPML functions only (Translation Management API, XLIFF export/import). Do not reimplement translation logic. Confirm exact function names against the installed WPML version before finalizing. - Auth: IP allowlist from a constant in the plugin file. Behind Cloudflare/proxies check CF-Connecting-IP (or X-Forwarded-For), not REMOTE_ADDR. Reject everything else with 403. - The plugin must not be able to delete content, create posts, or modify anything except applying translation jobs via /import. - Rate limiting: one concurrent write (requeue/import); return { code: "busy" } or { code: "rate_limit" } so the client can back off and retry. - Log every write operation (timestamp, IP, route, post_id/job_id) to a rotating file. Deliverables: the plugin file + a short README with the curl calls for all five routes. ``` Prompt 1: the retrofit in brief - One mu-plugin, ~300-400 lines, five routes: ping, status, requeue, export, import - Only wrappers around existing WPML functions – translates nothing itself, deletes nothing - Access via IP allowlist, every write operation is logged - Generation: ~10 minutes. Review and deployment by a human: one evening - After that, the complete translation cycle runs without a browser form ## To take away: Prompt 2 – the work instruction for the translation (Claude Cowork) The second prompt is the work instruction for the actual translation. It assumes that the plugin from Prompt 1 is running. We use it in Claude Cowork; there the AI can process files, run scripts, and work autonomously for hours. Adapt the language, domain, and the “do not translate” list to your project. ``` Task: Translate the website content of [YOUR-DOMAIN] from [SOURCE-LANG] to [TARGET-LANG] using the translation-helper plugin (REST namespace translation-helper/v1). Work autonomously, sequentially, and keep a verifiable journal. Cycle per post: 1. POST /requeue { post_id, target_lang } → new job_id. WPML prefills targets from Translation Memory - do not re-translate those segments. 2. GET /export?job_id=... → save the XLIFF (keep it as "before" artifact). 3. Classify every trans-unit: (a) TRANSLATE if target is empty or identical to a source that is real [SOURCE-LANG] text; (b) KEEP AS IS if it is a brand name, person, city, URL, or a short technical setting value; (c) TM-DONE if target differs from source - never overwrite these, but reuse them as your terminology reference. 4. Translate with strict rules: reproduce the HTML structure of the source byte-for-byte (same tags, attributes, entities, number of
  • ); translate only human text; SEO title ≤ 60 chars, meta description ≤ 160; [add your language conventions here]. Do not translate: [YOUR BRAND LIST], people, places, technical terms (SEO, PageSpeed…). 5. Validate before import: XML parses; tag list of every changed target equals its source; list item counts match; no leftover [SOURCE-LANG] function words (keep a whitelist for proper names). 6. POST /import (multipart) → expect segments_applied == segments_total, status complete. 7. GET /export again → verify your translations are actually in the re-export ("after" artifact). A status flag alone is NOT proof. 8. Journal line per post: post_id, job_id, segments total/prefilled/translated/kept, import result, verified yes/no. Constraints: all write requests strictly sequential; on "busy"/"rate_limit" back off 30→60→120s; batches of 5–10 posts; never touch posts outside the given list; never change source content; skip WordPress sample pages. Order of work: pilot on ONE small post first and show me the result. Then: references → pages → blog posts → [other post types]. Report after every batch. ``` And the tip that made the biggest difference to our costs: separate the roles. The mass translation, with us, runs on Claude Opus 4.8 – fast and cheap. The planning, spot checks, and sign-off are done by Claude Fable 5 – analytically stronger, but only needed selectively. Junior translates, senior reviews. That way you get quality, speed, and a reasonable price at the same time. ### Frequently asked questions about WordPress translation with AI Does this replace a professional translator? No – and we say so deliberately clearly. For legal texts and brand slogans, a human belongs at the end of the chain, and even the best AI changes nothing about that. What the AI replaces is the mass work: having 116 blog articles, 53 case studies, and 199 competency pages translated by hand was never a realistic option for us. With a clean check process – automatic checks before the import plus native-speaker proofreading against the original – AI is the only rational decision for this mass content. What does translating a WordPress website with AI cost? Honestly: considerably less than the alternatives, but the exact figure depends on your setup. The decisive difference lies in the billing model – automatic translation via WPML credits (DeepL, Google, Microsoft) is billed per word and per language, which gets very expensive at 116 articles times several languages. Our workflow, by contrast, runs on an AI subscription that doesn’t tick per word. Add to that the one-time setup: around 300-400 lines of PHP, deployed by the developer in one evening. Does this also work with Polylang or TranslatePress? In principle yes, because the core idea is plugin-independent: pull content out of the system via export, translate and check it externally, then play it back via import – past the browser form. It was exactly this form that was our bottleneck (max_input_vars silently cut 1,247 off at 1,725 segments). The concrete routes of our geo-helper plugin, however, are wrappers around WPML-internal functions; for Polylang or TranslatePress, a developer would have to rebuild the connection to their interfaces. The pattern stays the same, the implementation doesn’t. What about SEO and hreflang? WPML sets the hreflang markup itself as soon as a translation is considered complete – you don’t have to worry about that separately. Yoast titles and meta descriptions run along as perfectly normal segments through the XLIFF export and are translated in the same cycle. The only important thing is that the AI agents respect the length limits for title and description, otherwise Google truncates. That can be written as a rule into the work instruction and checked automatically. Is it safe to give an AI access to the website? Yes, because the AI gets no general access at all. The mu-plugin only opens four tightly limited routes for translation operations – status, requeue, export, import – and invents nothing new but wraps existing WPML functions. An IP allowlist lets only the fixed outbound IPs of the AI environment through; tokens aren’t in the code. And by design, the plugin can’t delete content and can’t create any new content: the worst conceivable case is a bad translation that gets stuck in the review. What happens with a WPML update? As a rule: nothing, because the plugin uses WPML’s official internal functions instead of its own database tricks. These same functions also drive the regular XLIFF export and the Translation Memory – they are the stable foundation; what was broken with us was only the browser form layer. Nevertheless, after every major update we recommend a pilot cycle: send one article through requeue, export, import, and control export and reconcile the result. Costs minutes and takes the fright out of the update. How many languages are realistic? Our honest number: 10 languages are set up in WPML, 4 of them complete – EN, FR, and PL at 100 percent, Spanish running autonomously right now following a written work instruction. The bottleneck here is no longer the translation itself; 638 English segments in a day or 1,215 segments in 3 to 5 minutes show how fast that goes. The bottleneck is the review: who checks the results, who decides on terminology questions? So plan languages according to your review capacity, not according to technical feasibility. How long does the setup take? Shorter than most expect: with us, the developer needed half a day, and the first article ran through the complete cycle that same day. The specification for the mu-plugin is finished and copyable – Claude Code generated the code in around 10 minutes; review, deployment, and IP allowlist were handled by our developer in one evening. After that the workflow is immediately productive: requeue, export, translate, check, import, control export. ## Glossary: the terms from this article **ATE (Advanced Translation Editor)** – WPML’s browser-based translation editor, in which translations are edited segment by segment and marked “complete.” On very large articles, its form hits server-side limits – with us, 1,247 of 1,725 segments were silently lost this way. **Egress allowlist** – A security list of fixed outbound IP addresses from which the AI environment goes onto the internet. Only these IPs may call the routes of the translation plugin; all other requests are rejected. **hreflang** – An HTML attribute that tells search engines which language and which region a page version is intended for. WPML sets hreflang automatically for finished translations, so that Google serves the right language version to the right users. **max_input_vars** – A PHP setting that limits how many form fields a server accepts per request (default: 1000). If a translation form exceeds this limit – our largest article had over 1,700 fields – the rest is truncated without an error message. **mu-plugin** – A “must-use plugin” in WordPress: it sits in its own directory, is always active, and can’t be deactivated via the admin backend. Our geo-helper is such a mu-plugin with around 300 to 400 lines of PHP. **Segment** – The smallest translation unit in WPML, typically a paragraph, a heading, or a single field. Our largest article consists of 1,725 segments at over 10,000 words; our AI agents work through them in batches of around 85 segments. **Translation Memory** – WPML’s translation store: once-translated segments are remembered and automatically pre-filled on new jobs. For our largest article, it delivered 462 of 1,725 segments ready to go. **XLIFF** – An XML-based interchange format for translations that stores source and target text in pairs per segment. Via XLIFF export and import, whole articles travel past the form as a single file – the import is one single operation without a max_input_vars limit. ## A note from us Everything presented in this article is based on our own observations and conclusions from our own practice. It is not a universal guide, nor legal or technical advice. Whatever you implement yourself, you do at your own risk. ## Conclusion: The number one CMS deserves better translations For a decade and a half, the old project rule applied to WordPress translations: fast, cheap, good – pick two. Our conclusion after this project: the rule was a property of the tool, not of the task. Since the cycle runs past the broken form and an AI takes over the routine, we translate in hours instead of weeks, pay a subscription instead of per-word rates – and, thanks to three-stage control, know for the first time, verifiably, that really everything is translated. Do you want this for your own website? Copy this article – the whole text – and give it to your Claude Code. There are enough details in it for it to derive the rebuild from it; the two prompts above are the starting point. And if you’d rather have it done for you: that’s exactly what we’re here for. We build multilingual WordPress websites that get found – by humans and by AI systems. More on that on our page [Have a multilingual website built](https://4eck-media.de/en/competencies/build-a-multilingual-website-more-reach-more-customers/) – or [get in touch with us](https://4eck-media.de/en/contact/).