The first thing I wanted to know about AutoMLP was not how many languages it advertised. I wanted to know what would happen to a long WordPress page if one piece of its translation did not come back.
That is a practical buying question. A short demo can look convincing while telling you little about incomplete responses, page-builder data or the work needed after the first translation. I installed AutoMLP Free in our tutorial lab and followed that question into its setup screen and PHP gateway. Then I compared those findings with the controls in Lumo, our own WPML addon.
Who wrote this, and what was tested
I am Mahdi Jabinpour, the maker of Lumo. This is a vendor-authored review of AutoMLP Free 2.0.0 and Lumo 3.20.28, not an independent endorsement. I checked the interfaces and source and ran local component tests. No live translation completed: Gemini rejected the lab network location. Translation fluency, API bills and end-to-end speed are therefore not ranked. AutoMLP Pro was not installed.
Is AutoMLP Free enough for your project?
For an ordinary WPML content pilot using OpenAI or Gemini, I would try AutoMLP Free before assuming a paid addon is necessary. The inspected package contains chunk handling and recovery logic worth taking seriously.
I would choose Lumo when the recurring task is more specific: correcting selected titles, applying different instructions to different content types, or finding and translating a shared Elementor template. Those are workflow reasons to pay. They are not evidence that a given AI model writes better prose through Lumo.
This review focuses on free-edition boundaries and long-content handling. If your main concern is HTML preservation, the Lumo–LATW review follows that different question.
Install the right package and check the edition first
The official repository listing is AutoMLP – AI Translation for WPML, by Cool Plugins. Its folder remains wpml-translation-check. That older slug is useful when checking the ZIP or locating its source; it does not mean you downloaded a different plugin.
On a backed-up staging site with WPML configured, open Plugins → Add New Plugin, search for AutoMLP, check the author, and install the repository package. In our lab, the setup entry appeared under WPML → AutoMLP Setup. I clicked Get Started and reached the provider configuration.
Annotated redesign of the real AutoMLP Free 2.0.0 lab capture. Continue was disabled because no provider key was configured. Official artwork and interface: Cool Plugins.
The screen offered OpenAI and Google/Gemini key fields. Continue was disabled while the keys were empty. Chrome Built-in AI was presented with an Upgrade to Pro link. I did not treat that local-AI option as a free feature or attempt to unlock Pro.
A free plugin license does not include WPML licensing, provider credit or every feature shown in vendor artwork. The official AutoMLP sales page is the place to verify the current paid offering.
| Task or requirement | AutoMLP Free 2.0.0 | Lumo 3.20.28 |
|---|---|---|
| OpenAI / Gemini key workflow | ✓ Present in setup | ✓ Provider controls present |
| Bulk translation | ✓ Listed in the package's edition table | ✓ Bulk Tools and WPML workflow |
| Split and reassemble long ordinary text | ✓ Local test passed | Chunking code and controls inspected; same fixture not benchmarked |
| Chrome local AI | Pro in the inspected setup | Not offered in the inspected provider screen |
| Dedicated Elementor template translation | Pro in the shipped edition table | ✓ Dedicated panel; source scan tested |
| Custom post types | Pro in the shipped edition table | Depends on WPML content configuration |
| Separate instructions for titles and other content | Equivalent controls not established in the free setup | ✓ Controls inspected |
The edition source is admin/automlp-ai-dashboard/views/free-vs-pro.php. A check means a feature is present or a named local test passed. It is not a blanket compatibility certificate.
My long-text test: completeness before convenience
I traced AutoMLP's AI_Gateway in includes/providers/class-ai-gateway.php. Its translation_units() method associates each piece with a field name and an index. reassemble_units() uses those identities when rebuilding a field.
For the original test, I supplied a title and a body made by repeating “Keep the webhook URL unchanged.” The gateway produced three units in total. Feeding the unchanged pieces back into the reassembler reproduced the original fields exactly.
Next I removed the first body chunk from the prepared response. The complete title was still returned, but the incomplete body was omitted. That is the behavior I wanted from this layer: do not hand the next stage half of a page as though it were complete.
It is a positive result for AutoMLP, with a narrow meaning. I called the component with controlled input. I did not observe a real provider timeout followed by a completed WPML job, or prove how every downstream save path handles an omitted field.
I also followed the caller before trusting the result
The gateway is only one layer, so I checked its caller in includes/queue/class-dispatcher.php. Before invoking the translation writer, that path rejects an empty reconstructed response and checks whether fewer fields were rebuilt than were required. The source also preserves partial progress when a provider call returns an error.
That strengthens the design explanation: the complete field is reconstructed first, and a second check sits before the writer. It is source evidence, not a live crash-and-resume test. I would still verify recovery with the actual hosting and provider before launching a large queue.
The useful surprise: JSON is not split like prose
I extended the test because page-builder content is not always a plain paragraph. With the same repeated sentence as the only body field, I checked plain text, a JSON wrapper and multilingual text. These are actual local results, not estimated provider token counts.
Illustration of recorded component-test counts. Document contents are symbolic; the exact fixtures and character counts are explained in the table. No AI request was made.
| Fixture | Characters measured with mb_strlen | Units returned | Unchanged pieces rebuilt exactly? |
|---|---|---|---|
| Repeated plain body | 7,680 | 2 | Yes |
| Same body inside a JSON object | 7,691 | 1 | Yes |
| Repeated Persian, German and French text | 8,400 | 3 | Yes |
The reason is in split_text_into_chunks(): the method returns an atomic structure as one piece. is_atomic_text() recognizes bracketed JSON-like text and serialized-data patterns. Ordinary content goes through boundary-aware splitting. The inspected default chunk setting is 4,000 characters, with a filter that can change it.
This explains why “my field exceeds the chunk size” does not automatically mean the plugin has ignored its setting. Keeping a structure intact can be deliberate. It also means a chunk limit is not a promise that every outbound unit fits the same size. I would pay particular attention to large structured fields and the provider's constraints during a real pilot.
Here is the shape of the local check, simplified from my harness. It calls internal methods and belongs in a test process, not a live theme's functions.php:
$units = $gateway->translation_units($fields);
$parts = [];
foreach ($units as $unit) {
$parts[$unit['field']][$unit['index']] = $unit['text'];
}
$rebuilt = $gateway->reassemble_units($fields, $units, $parts);
// Compare with the original before testing a missing piece.
This does not measure semantic consistency between chunks. A page can reassemble perfectly and still use two translations for one product term. That requires language review and appropriate instructions, not just a successful string comparison.
Where Lumo changes my decision: the next repair
Suppose a translated page looks fine but its shared header remains in the source language. Re-running the page body may be the wrong operation. I want to identify the content that owns the header first.
Annotated lab interface with a conceptual header/body diagram. The scan was real; no translation was submitted.
In Lumo WP → Lumo AI Translator → Bulk Tools → Elementor Templates, I selected our synthetic Harbor Desk section and ran Scan Source Template. The scan found its heading and button. The locally published section appeared in the picker; its draft version had not appeared.
That is the concrete reason Lumo becomes useful to me here: an explicit template-selection and inspection step. In a separate helper test, applying prepared strings changed the title and button while preserving the fixture's padding, color and button URL. Those strings were written for the test; they were not AI output.
I also tested an invented third-party custom_caption field. Lumo's fallback list did not extract it. WPML integrations can register additional fields, so this is not a verdict on every third-party widget. It is a reason to include your actual widgets in the pilot rather than trust a broad compatibility label.
The Lumo AI Translation Addon for WPML brings these repair panels and content-specific instructions together. If you do not need them, they are not a reason by themselves to replace a working free workflow. For a stale header, our Elementor translation troubleshooting guide explains how to find the correct source before retranslating.
A pilot I would approve before a bulk run
Choose one short article, one long page and one real shared template. Record the source language, target language and provider/model. Give each fixture a link, a product name and a number that are easy to check afterwards.
- Confirm that the edition supports the content type. A page-builder page and a saved template are not interchangeable requirements.
- Complete one live translation on staging and inspect the rendered target. The local tests here do not replace this step.
- Change one source sentence, then observe what a second run overwrites. Keep a backup of any human correction.
- If a job stalls, record the error and the smallest unfinished unit. Do not repeatedly launch the entire site as a troubleshooting method.
- Count review and repair time as well as API charges. A cheap first response is not necessarily a cheap approved page.
My verdict
AutoMLP Free earns a place on the shortlist. Its chunk reassembly passed the local checks, and the structured-field exception is a thoughtful implementation detail. I would start there for an ordinary API-based WPML pilot with a limited addon budget.
I would choose Lumo for ongoing editorial repair and shared-template work, where the inspected controls address tasks I actually need. For Chrome local AI, I would investigate AutoMLP Pro instead; that is not a capability I established in Lumo.
Neither decision depends on a claim that one logo makes the same AI model more human. The deciding question is whether the workflow handles your content and makes the next correction manageable.
Evidence and limits
Tests used WordPress 7.1.4, WPML 4.7.4, String Translation 3.3.3, Elementor 4.2.0 and PHP 8.1.10 in our permanent lab. Extended component calls used WordPress SHORTINIT and made no API calls or saved translations. Sources: the official AutoMLP package and changelog, its reviewed source ZIP (2.0.0), and the local Lumo package. Tutorial panels are graphically annotated lab captures; the chunk graphic illustrates recorded local results. No Pro test, language-quality ranking or large-scale throughput result is implied.
Originally published on LumoWP.
Top comments (0)