A translated sentence can sound right and still break a page. The link may disappear. An image description may remain untranslated. A button may keep its shape but point somewhere unexpected. Those are the details I wanted to investigate when I installed LATW alongside our Lumo WPML addon in the tutorial lab.
The most interesting control was not the provider dropdown. It was Send Only Text. I followed that setting into LATW's markup helper and tried both valid and deliberately damaged responses. That gave me a more useful comparison than another list of AI model names.
Review disclosure
I am Mahdi Jabinpour from LumoWP, the maker of Lumo. This review covers LATW Free 3.1.2 and Lumo 3.20.28. Interface checks, source review and local component tests were completed. The example responses below were prepared for testing, not generated by AI. Gemini rejected our lab network location, so I cannot honestly rank live translation quality, cost or speed. LATW Pro and LATW Cloud were not activated.
Two different questions before choosing a plugin
Can the addon preserve structure? That asks about links, tags, fields and the way a response becomes saved content. Can I guide and correct the wording? That asks about terminology, tone and editorial controls. A good answer to one does not settle the other.
LATW's inspected free package provides a concrete markup-processing layer. Lumo's interface gives me separate instructions for different content types and dedicated repair tools. I would choose between them by the work the site needs, not pretend that an instruction box is equivalent to an HTML validator.
For a team mainly interested in a free WPML translation pilot, LATW deserves a real trial. For repeated terminology and editorial repair work, Lumo is the option I would choose from the inspected controls. Both still need review of the finished page.
Install LATW and locate the setting that matters
Use the official LATW AI Translation for WPML listing, not the separate LATW multilingual product. In WordPress, open Plugins → Add New Plugin, search for that exact name, and check the package before activating it on staging. WPML must already manage the site's languages.
In the installed UI, AI Translator → Settings → General contained provider and processing choices. The Translation tab contained output-status and editor choices. Advanced contained Send Only Text, enabled in the captured configuration.
Annotated redesign of the LATW Free 3.1.2 lab capture. The lower flow is conceptual. Interface: LATW.
The control does not remove HTML from your published page. It changes the representation sent to the model, then the helper puts the structural markup back. That difference matters: editing the input representation and stripping a website's HTML are very different operations.
The official LATW WPML documentation is worth keeping open during configuration. Do not assume a setting described for Pro or Cloud is part of the free local workflow.
Follow one link through the source
I used this small fixture in LATWAITR_Markup, defined in includes/class-latwaitr-markup.php:
<p class="intro">Read <a href="https://example.com/docs">the guide</a>.</p>
encode_fields() produced this representation for the body:
Read <g1>the guide</g1>.
The surrounding paragraph and the original link details no longer had to appear in the model's text response. The internal marker identified the link position. When I supplied the unchanged encoded text to decode_fields(), it reconstructed the original HTML exactly.
I then supplied a prepared German test sentence, preserving the markers:
Lesen Sie <g1>die Anleitung</g1>.
The output contained the German words inside the original paragraph and retained https://example.com/docs as the link target. This is a controlled reconstruction test, not a sample proving how well Gemini, Claude or another model translates.
That separation is useful when debugging. If a test response reconstructs correctly but a live model response fails, you can examine the returned markers instead of immediately changing the website's layout or retranslating everything.
What failed, and what did not raise the same error
The original check removed the link markers. For this review I extended it to repeated markers, an unknown marker number and a completely missing body field. These cases are easy to confuse, but the helper does not handle them identically.
Illustrated component-test results from prepared responses. These were not live AI outputs or a complete save-workflow test.
| Prepared response or fixture | Observed helper result | What I take from it |
|---|---|---|
| Original valid markers | Original HTML rebuilt | Identity round trip passed |
| German test text with valid markers | German text inside the original link and paragraph | Structure can be reconstructed independently of wording |
| Link markers removed | latwaitr_markup_mismatch | Missing markers were rejected |
| Same link markers repeated | latwaitr_markup_mismatch | Duplicate markers were rejected |
| Unknown marker number | latwaitr_markup_mismatch | Unknown markers were rejected |
| Body field absent from the response array | Body omitted; markup-only spacer restored | Field completeness is a separate concern |
| Markup-only spacer | Source spacer restored | Non-text structure did not require a translated response |
The last two rows are especially important. In the inspected decode_fields() code, a missing non-markup field is skipped. That is not the same test as a present field with a broken marker. A caller still needs to handle incomplete responses appropriately.
I am not describing a demonstrated production data-loss bug. I did not run the whole save workflow with that fault. I am describing the boundary of a specific helper so a developer does not mistake one successful validation layer for proof that every required field exists.
The source also counts expected marker occurrences and rejects unknown identities or the wrong marker kind. That is meaningful validation. It does not read the translated sentence and decide whether its meaning is correct, nor does this small fixture certify every possible HTML document.
What the response checker does with a markup error
I followed the helper into class-latwaitr-response-checker.php. For the inspected translation-service job path, a markup error is logged, the model answer is retained, and processing goes through retry_or_fail() rather than immediately passing that error to the completed-job handler. This is useful context for diagnosing a failed job instead of repeatedly translating the whole site.
That observation comes from the caller's code. I did not simulate the complete database-backed retry cycle. In particular, the missing-field case should not be confused with a marker error simply because both look incomplete to a reader.
“Text only” includes some attributes
There was another detail I would have missed from the setting's name alone. LATW's TEXT_ATTRIBUTES list includes alt, title, aria-label and placeholder. These can contain words a visitor reads or assistive technology announces.
I tested an image inside a paragraph, with a source URL, a class and alt="Blue chair". Its encoded representation retained the alt text on a marker:
See <x1 alt="Blue chair"/> now.
An unchanged round trip restored the full original fixture. That gives a concrete reason to review more than visible paragraphs after a translation. Check image descriptions and accessible labels as well. “The page looks translated” can miss text that does not appear as a normal sentence on the screen.
Do not convert this result into a promise of automatic accessibility compliance. It only establishes what this fixture and the inspected attribute list did.
Where Lumo fits: editorial instructions are a different layer
Annotated redesign of configured Lumo settings. Instructions are guidance, not proof that a model obeyed them or that HTML passed validation.
In Lumo WP → Lumo AI Translator → Settings, I inspected Global Instructions and separate content-type instructions. The lab example asks for product names to stay unchanged and gives title-specific guidance. Those controls are useful when a site's wording needs to follow an editorial policy rather than a generic prompt.
The distinction I care about is straightforward: a prompt is a request to a model; a structural check is code evaluating a response. Neither replaces the other. I would still inspect links and fields after asking a model to preserve them, and I would still review terminology after a markup validator accepts a response.
The Lumo AI Translation Addon for WPML also exposes targeted repair panels. That is why I favor it for recurring editorial maintenance. Our brand-name and terminology guide shows how to make those instructions specific. It is guidance, not an assertion that a term can never change.
| Decision point | LATW Free 3.1.2 | Lumo 3.20.28 |
|---|---|---|
| OpenAI / Gemini key setup | ✓ Limited model choices in the inspected edition | ✓ Provider/model controls inspected |
| HTML-placeholder checks | ✓ Local cases above | Equivalent helper result not established here |
| Editable prompt / glossary UI | Pro in the inspected screen | ✓ Global and content-type instructions; not a guaranteed term lock |
| Translation status/editor choices | ✓ Visible in the Translation tab | Verify the chosen WPML/Lumo workflow; not tested here |
| Gemini provider batch mode | ✓ Mode visible | A background queue is not proof of provider Batch API support |
| Dedicated Elementor template panel | Equivalent panel not established | ✓ Source scan tested in the companion review |
| Changed-fields-only workflow | Pro according to LATW documentation | Equivalent feature not established here |
I have left untested features as untested. Turning those cells into red crosses would make the table cleaner and the comparison less honest.
A practical acceptance check for your first page
Pick a staging page containing an inline link, an image with alt text, a button, a number and a term that must remain unchanged. Keep a copy of the source and the target before running anything.
- Use a provider and model available in the edition you installed. Record the choice.
- Where the workflow offers draft output, use it during the pilot and confirm which editor owns subsequent changes.
- Review the actual target page, then inspect link destinations and image/accessibility text separately.
- If a markup mismatch occurs, keep the error and a sanitized copy of the response. Test the smallest failing field before changing a global setting.
- Compare required fields with returned fields. A response can be structurally valid for one field and incomplete as a whole.
- Make one source edit and check the next update. Do not assume that manual corrections survive every retranslation path.
If you turn Send Only Text off to investigate a particular problem, understand the tradeoff: the model receives the original HTML representation instead. The switch changes the input strategy; it is not a universal repair button.
My choice, with a clear boundary
For a free workflow whose markup handling I want to inspect, I would pilot LATW. Its local checks caught the deliberately damaged markers, and the readable-attribute handling is a useful implementation detail.
For ongoing terminology and content-specific editorial work, I would choose Lumo, provided the real site passes its own structural checks. I would not describe that choice as a measured language-quality win. The right purchase is the one that solves the project's recurring work and leaves a manageable review process.
Test notes and sources
The lab used WordPress 7.1.4, WPML 4.7.4, String Translation 3.3.3, Elementor 4.2.0 and PHP 8.1.10. The extended helper tests used WordPress SHORTINIT; no provider request, saved translation or persistent plugin activation change occurred. Sources include the official LATW repository, reviewed source ZIP (3.1.2) and WPML documentation category. Images distinguish annotated lab interfaces from illustrated test results. For queue and long-field behavior rather than HTML markers, see the AutoMLP comparison.
Originally published on LumoWP.
Top comments (0)