If you asked me which WPML AI addon to install, I would ask one question before naming a plugin: what work will you be doing after the first translation?
A small blog trying its first second language, an agency repairing shared Elementor headers, and a team checking hundreds of structured product pages do not have the same problem. A table that gives each plugin a score out of ten hides that difference. I would rather show you where I would start, what I would test, and what would make me change my mind.
I installed the free AutoMLP and LATW packages in our permanent WordPress lab and inspected Lumo alongside them. This guide turns that work into a buying decision. The detailed code-level results live in the two companion reviews; here the focus is choosing a workflow you can actually maintain.
Read this as a vendor's engineering review
I am Mahdi Jabinpour, the maker of Lumo. The inspected versions were Lumo 3.20.28, AutoMLP Free 2.0.0 and LATW Free 3.1.2. Installation, interface checks and local component tests were completed. A live Gemini request was blocked by network-location restrictions. I therefore make no measured claim about translation fluency, API savings or end-to-end throughput. Competitor Pro editions and cloud services were not tested.
Start with the layer that is causing the work
Conceptual architecture. Human review is a separate responsibility, not an automatic plugin feature.
There are three responsibilities to keep separate. WPML manages the site's languages and translation relationships. The addon prepares content, runs its workflow and handles responses. The AI provider supplies the generated wording. Human review checks whether the result is acceptable.
This distinction prevents expensive wrong turns. If a widget's text never entered the payload, selecting a larger model will not recover it. If the model returned the right text but the shared header still shows the source language, translating the whole page again may target the wrong content. If the wording is inaccurate, a successful job status does not make it correct.
I investigate in this order: source ownership → extraction → response → saved target → rendered page. Only then do I decide whether the problem is a setting, a content integration, the provider, or the addon itself.
My shortlist for three different projects
Conceptual decision aid. Lumo is a conditional recommendation for template repair, not a measured universal winner.
Project 1: a small editorial site adding its first language
My starting shortlist would be AutoMLP Free and LATW Free. Both offered an OpenAI/Gemini route in the inspected interfaces. There is no reason to buy another addon solely because a feature comparison has more rows.
AutoMLP's guided setup makes the provider requirement explicit. Its long-field gateway also gave useful local results: ordinary text was split, complete pieces reassembled, and an incomplete body was omitted rather than partially reconstructed. LATW's free interface exposed translation output/editor choices and a markup-processing option. Those are different things to investigate during a pilot, not a reason to declare a universal winner.
I would select one first, run a representative page through it and inspect the target. If it meets the site's needs, keep the working setup. Do not migrate merely to follow a comparison article's favorite product.
Project 2: an agency maintaining shared Elementor content
Here my first choice would be Lumo, because the inspected interface gives me an explicit template panel and targeted content tools. In the lab, the Elementor template scan found the heading and button in our synthetic section. A local helper test changed prepared text while preserving its padding, color and link URL.
That does not establish compatibility with every Elementor widget. An invented custom caption was outside the fallback extractor's field list. The next step on a real agency project is therefore to scan the actual header and custom widgets, not assume our small section represents the whole site.
The Lumo AI Translation Addon for WPML is the paid option I would evaluate for this recurring repair work. AutoMLP lists dedicated Elementor template translation in Pro, so comparing that paid edition would be a separate exercise. I did not establish an equivalent dedicated LATW panel in this test.
Project 3: a site where HTML and review controls matter most
I would put LATW on the shortlist and test its Send Only Text workflow on the site's real content. The helper rebuilt a prepared link fixture and rejected missing, repeated and unknown markers in local tests. It also retained readable attributes such as alt text in the model-facing representation.
There is a boundary: a missing whole field was skipped by the helper, rather than producing the same marker error. That means field completeness deserves its own check. It does not prove a failure in the complete production workflow, and it does not make another product automatically safer.
If editable prompts, glossary controls, more providers or changed-fields-only updates are essential, inspect the relevant paid edition. Several LATW capabilities are presented as Pro. A useful free pilot and a full paid-product evaluation are different decisions.
A comparison table with evidence instead of scores
| Requirement | Lumo 3.20.28 | AutoMLP Free 2.0.0 | LATW Free 3.1.2 |
|---|---|---|---|
| License for the inspected edition | Paid | Free | Free |
| WPML remains necessary | ✓ | ✓ | ✓ |
| OpenAI / Gemini workflow | ✓ Controls inspected | ✓ Setup inspected | ✓ Setup inspected; model list limited |
| Main reason I would shortlist it | Targeted editorial and template repair | Free pilot and long-field handling | Free pilot and explicit markup processing |
| Concrete local evidence | Template scan; prepared text applied without changing fixture styles/link | Plain text, JSON and Unicode round trips; missing body chunk omitted | Marker validation; readable attributes; missing-field behavior |
| Global/content-type instruction controls | ✓ Inspected | Equivalent free controls not established | Editable prompt/glossary presented as Pro |
| Dedicated Elementor template workflow | ✓ Source scan tested | Pro listed in shipped edition table | Equivalent panel not established |
| Chrome local AI | Not in inspected providers | Pro in setup | Not in inspected engines |
| Live quality or speed winner | Not established | Not established | Not established |
A check indicates the stated observation, not a reliability score. Different component tests are not interchangeable benchmarks. For the exact fixtures and interpretation, read Lumo versus AutoMLP and Lumo versus LATW.
The cost I would calculate before buying
I would not compare these products using only the license price or a headline token-saving claim. A translation workflow costs more than its first API request: you may have retries, manual fixes, updates and ongoing review.
Cost per approved page =
(allocated license cost + provider cost + retry cost + review cost)
/ pages accepted after review
This is a planning formula, not a measured result from the lab. If you use it, keep the denominator honest. Ten generated drafts and ten approved pages are different outcomes. Likewise, a provider batch mode is not automatically the same as a WordPress background queue; those affect different parts of the process.
I have not frozen promotional prices into this guide. Check the current AutoMLP offering, LATW plans and Lumo product terms for the edition and site count you need. Provider usage and WPML licensing remain separate considerations.
Run a pilot that can change your mind
Proposed pilot and record-keeping plan, not completed end-to-end test results.
The following is the acceptance plan I would use next. It is not a claim that all these end-to-end cases have already passed in our lab.
1. Choose content that can expose the wrong choice
Take a short post, a long page, a shared template and a content item using your most important custom field or widget. Include a product code, a number, an inline link, a button and an image description. Use synthetic or approved content when sending it to an external service.
Do not select only easy paragraphs. A pilot that avoids the content you are worried about cannot answer the purchasing question.
2. Keep the inputs comparable
Record the plugin edition, provider, model, language pair and instructions. If a free edition cannot use the same model, say so in the notes. Otherwise you risk blaming an addon for a model difference or crediting it for a better prompt.
Use one translation owner per test job. Keep a recoverable copy of the source and target before trying a different workflow.
3. Review meaning and structure separately
A reader competent in the target language should check meaning, tone and terminology. Separately check links, numbers, field coverage and layout. Do not combine those into a vague percentage of how “human” the result feels.
If a job succeeds but the page fails either review, it is not accepted yet. Keep the smallest example that reproduces the problem; it will be much more useful to support than “translation is broken.”
4. Test the second run
Correct one target sentence manually, change one source sentence and observe the next update. Find out what is preserved, replaced or sent again. Repeat this on the content type that matters most to you.
The update path can decide the purchase. A tool that is convenient on day one may create too much review work on every later revision. I would not claim an update feature from one screenshot; I would verify it on the chosen edition and editor workflow.
5. Record the cost of getting to approval
Keep provider charges, retries and human review time in separate columns. Expand the queue only after the small sample passes. Our guide to translating 1,000 pages covers planning the larger rollout; it is the next step after an accepted pilot, not a replacement for one.
What would make me reject my initial choice?
I would reconsider Lumo if the required custom content did not extract correctly and the integration work outweighed its repair tools. I would reconsider a free addon if the essential workflow belonged to Pro or repeatedly required manual work that a different tool could remove. I would reconsider all three if the source content or review process was the real bottleneck.
That is why I do not recommend enabling three translators on the same live jobs and seeing what happens. A controlled staging comparison produces evidence you can use; overlapping jobs can produce confusion about who changed the target.
My recommendation
For ongoing shared-template and editorial repair, I would choose Lumo from the controls I inspected. For a free first pilot, I would try AutoMLP or LATW according to whether long-field handling or markup processing is the more important question. For a feature advertised only in Pro, I would evaluate that exact paid edition before making a promise to a client.
The useful winner is the workflow that gets your representative pages approved and keeps later edits manageable. This review gives you a shortlist and evidence for specific components. It does not give you a fabricated league table of language quality.
Review record
The local environment used WordPress 7.1.4, WPML 4.7.4, String Translation 3.3.3, Elementor 4.2.0 and PHP 8.1.10. Sources included the official AutoMLP repository, LATW repository, their downloaded source and the Lumo source. The diagrams in this guide explain architecture and proposed decisions; they are not screenshots or completed benchmark results. The companion reviews contain the graphically annotated interface captures and detailed local test cases.
Originally published on LumoWP.
Top comments (0)