2027 年 WordPress 多語言外掛指南：工作流程、成本與控制

Originally published on LumoWP.

Choosing a multilingual plugin is easy when the demo contains one paragraph and a language switcher. The difficult part comes later: a translated product goes out of stock, an Elementor template changes, a subscription renews, or an editor rewrites a sentence that already has five translations.

That is where this comparison starts. The best WordPress multilingual plugin for your site is the one whose workflow still makes sense after the first translation.

About this 2027 guide
Researched on October 31, 2026 for people planning a 2027 website. Features and prices below describe the documentation available on that date, not unreleased 2027 versions. This is a documented workflow comparison, not a five-plugin performance benchmark. LumoWP sells a WPML AI translation add-on; that relationship is disclosed where it appears.

The shortlist: which plugin fits which job?

There is no useful universal winner. Start with the part of your website that would be hardest to translate and maintain—not the easiest page in the demo.

These are recommendations by use case, not measured rankings. A simple two-language brochure site and a store with subscriptions, custom product fields and regional pricing should not receive the same recommendation.

First understand what the plugin actually translates

Think of a multilingual website as four connected systems: content storage, translation production, public URLs, and ongoing maintenance. A plugin may make the second part easy while asking you to do more work in the fourth.

With a content-based workflow, an editor works with related language versions. With a rendered-string workflow, the translation layer works with text that appears on the page. With a multisite workflow, each language has its own site. A hosted service adds another question: what happens to the public translated experience if the subscription stops?

None of these models is automatically faster, more professional or better for Google. They create different operational responsibilities. Your checkout, search results, logged-in dashboard and reusable templates are more informative test cases than a static About page.

Conceptual illustration, not a software screenshot.

WPML: a strong candidate for structured content and complex stores

WPML is worth shortlisting when translation is an ongoing editorial process rather than a one-time conversion. Its Multilingual CMS and Agency plans include the advanced translation workflow and integrations needed for more involved sites. The cheaper Blog plan is a different scope, not simply the same product with fewer site licenses. Check the current WPML plan comparison before choosing it for a builder-heavy site.

For Elementor, start with the official integration instructions. Translate reusable templates as well as pages. A translated page can still display a source-language header if the header comes from a separate template. Custom widgets can also need field registration; a page-builder compatibility badge does not tell you whether every third-party widget in your project exposes its fields correctly.

My decision rule: shortlist WPML when you need a coordinated translation workflow across posts, products, taxonomies and templates. Before committing, include your most unusual widget and your most complicated product in the pilot.

For an existing site, do not buy another translation tool just because an update is missing. Our WPML and Elementor troubleshooting guide explains how to separate a missing field, a template issue and an outdated translation before translating again.

What to check before paying for automatic translation

The plugin license and translation usage are different cost items. WPML's current automatic translation pricing documentation describes AI-word billing and different handling of edits depending on the workflow. Do not copy a calculation from an older article about credits and assume it still applies to your selected engine and account.

Ask a practical question: if your team updates fifty product descriptions every week, what gets sent again, what is reused, and where can you inspect the charge? Calculate that before enabling a large automatic job.

Conceptual illustration, not a software screenshot.

Polylang: attractive when editors want direct control

Polylang is a sensible starting point for a site with a manageable number of languages and editors who can maintain the translated content. Its free version covers core multilingual content, while Pro adds workflow features such as duplication and expanded slug handling. WooCommerce has its own paid integration. The official feature matrix makes these boundaries clearer than a generic “free versus paid” label.

An easy setup mistake is leaving existing content without a language assignment. Follow the setup wizard guidance and check existing posts, pages and navigation after assigning the default language.

My decision rule: choose Polylang for editorial control, not because somebody promises that fewer features must mean better performance. Compare the complete stack you actually need, including the WooCommerce add-on where relevant.

The Elementor and automatic-translation detail that matters

Polylang Pro offers DeepL translation using your own API connection, but its current pricing matrix explicitly says this machine-translation feature is not compatible with Elementor. That is a limitation of this specific workflow, not a claim that no Polylang-and-Elementor site can exist.

If your brief says “automatically translate all Elementor pages,” resolve that requirement before choosing a plan. For a closer comparison of the editorial models, see Polylang versus WPML.

Conceptual illustration, not a software screenshot.

TranslatePress: useful when translation starts with what visitors see

TranslatePress takes a visual approach: work with the front end and translate the text in context. This can be easier for an owner who recognizes a button on the page but does not know which plugin generated it.

The important technical detail is persistence. Its automatic translation documentation explains that generated translations are stored in the database rather than requested from the translation API on every page view. That does not mean the complete site has zero translation-related runtime cost; it means repeated API generation is not the normal delivery model.

My decision rule: shortlist it when visual editing suits your team and your important front-end states can be reproduced for translation and review. Test a validation error, a cart update and an account page—not only visible text on the initial page load.

Source edits need a maintenance plan

TranslatePress's FAQ describes the distinction between an original string and its translation. Changing the source can create a new string to translate, while the old translation remains stored. That is different from an editor thinking “I changed one paragraph in this translated post.”

Try this before rollout: translate a page, change its heading and one repeated call-to-action in the source, then inspect the translated page. Write down what needs review. This small experiment tells your editorial team more than a screenshot of the translation sidebar.

Conceptual illustration, not a software screenshot.

Weglot: a service decision as much as a plugin decision

Weglot is appealing when the team wants to manage translation through a hosted service. The trade-off is a recurring service relationship with word and language allowances.

One pricing detail deserves attention: the Weglot pricing page describes a total translated-word allowance across the project, not a fresh allowance that resets every month. If a simplified 20,000-word source corpus is translated into three languages, use roughly 60,000 translated words as an initial planning estimate, then verify the actual counted content. Navigation, dynamic text and the service's counting rules can change the result.

My decision rule: shortlist Weglot when the ongoing service model is acceptable and the team values that workflow. Compare the plan required for your whole translated corpus, not just the starting price.

Cancellation is an operational requirement

Weglot's cancellation documentation says translated content stops appearing when the relevant paid service is cancelled or paused. Treat exit planning as part of selection. Ask what you can export, what URLs you would need to preserve, and how you would replace the translated delivery layer before cancelling.

This is not the same question as whether you retain a copy of translated text. Owning an export and continuing to serve the same multilingual website are two different things.

Conceptual illustration, not a software screenshot.

MultilingualPress: when markets need separate sites

MultilingualPress uses WordPress Multisite, with each language on its own site. Its documentation presents independent content and configuration as central to the design.

That makes it interesting when your German and French operations need more independence than translated paragraphs: different teams, different catalogs or different site settings. It also means backups, network permissions, deployment and integrations must be planned for a network.

My decision rule: shortlist it when separate sites are an intentional business requirement. Do not convert a simple brochure site to Multisite merely because a comparison labels the architecture “enterprise.”

A useful question for the agency is: who owns the relationship between the sites after launch? If nobody will maintain cross-language links and shared requirements, architectural independence can turn into editorial drift.

What about GTranslate and Loco Translate?

GTranslate belongs in the discussion, but distinguish its free translation widget from its paid multilingual SEO offering. The WordPress.org listing lists indexable language URLs and related SEO features in the paid offering. A visitor being able to read a translated page does not, by itself, establish that Google can crawl a dedicated translated URL.

Loco Translate addresses a different task: translating theme and plugin localization strings. It can help with interface wording, but it is not a substitute for a full architecture of translated posts, language URLs and editorial workflows. Do not compare these products as though they solve an identical problem.

Budget comparison: price the complete workflow

The following are public entry points observed on October 31, 2026. They are not guaranteed 2027 prices. Taxes, promotions, renewal terms, usage and the required number of sites can change the final cost.

Verify these on WPML, Polylang, TranslatePress, Weglot and MultilingualPress before purchasing.

My planning formula is simple: license or subscription + translation generation + human review + maintenance + eventual migration. Human review is not a rounding error. A cheap first translation can become expensive if your editors repeatedly repair terminology or cannot see which content changed.

What user reviews reveal—and what they do not

I use public reviews and support threads to identify questions worth testing, not to calculate failure rates. People who post reviews are not a random sample, and a difficult support case does not establish that every installation has that problem.

Sources: TranslatePress user reviews, the slug-pricing review and developer reply, and the WPML Elementor support discussion. The visible support discussion does not establish a final resolution; I am not presenting one.

A 2026 community discussion on Reddit shows the disagreement clearly: some participants value WPML integration coverage, while others report performance or maintenance frustrations on larger builds. These are self-reported experiences with different stacks, not controlled comparisons. The useful takeaway is to include your custom fields, forms and representative database size in the pilot.

When you read a review, look for the plugin version, the actual requirement, the surrounding stack and the support response. “Slow” without a reproducible page, cache state and measurement is a reason to investigate, not a benchmark to copy into a buying guide.

A pilot that can reject the wrong plugin before launch

An editorial checklist illustration, not a benchmark or a plugin screenshot.

Do not begin by translating a thousand URLs. On a staging copy, choose one target language and a small representative set. The goal is to expose the expensive failure modes early.

Record the versions, theme, builder, host, cache settings and exact URLs. For timing, compare repeated measurements of the same page and separate cached delivery from uncached generation. Do not declare a plugin faster because one test hit a cache and the other did not.

For WooCommerce, language and currency are separate dimensions. A French translation does not necessarily mean euros, and a German-speaking customer may live outside Germany. Test your chosen policy explicitly; our WPML currency-by-language guide covers that distinction.

The SEO checks that matter more than the plugin badge

Google recommends separate URLs for different language versions and warns that locale-adaptive behavior can prevent complete crawling. A language switcher should provide a usable route to the translated page; do not make automatic redirection the only route. See Google's multilingual and multi-regional site guidance.

Check the actual page output: an indexable URL, the intended canonical, matching language content and valid alternate-language relationships. Google's hreflang documentation requires reciprocal references, including the page itself, for the relevant alternate sets. A checkbox in a plugin is not a substitute for inspecting the output.

Do not translate into twenty languages just because the software permits it. Start where you can support the reader or customer, review critical wording and maintain updates. Our multilingual SEO and crawl-budget guide explains the maintenance and discovery implications in more depth.

A practical stop condition
If the team cannot review checkout wording, maintain translated source updates or explain which URLs should be indexed, pause the rollout. Adding languages multiplies that unfinished work; it does not solve it.

Where Lumo's WPML AI add-on fits

Disclosure: LumoWP develops and sells this add-on. It is not a sixth replacement for the multilingual systems above. Choose the multilingual architecture first; then decide how to generate and review translations inside that workflow.

The Lumo AI Translation Addon for WPML is relevant if you already use WPML and want an AI-provider workflow with your own API credentials. Its product interface includes separate bulk tools for content types, including Elementor templates. That can address a practical maintenance need, but it does not remove the need to check field compatibility, provider charges and translation quality.

Lumo supplies the translation engine while WPML manages the languages. Select the image to see the product and requirements.

Start with a small batch and a terminology list. Review names, units, product promises, buttons and links before expanding. No provider name or add-on guarantees a translation sounds natural in every language, and no plugin guarantees search rankings.

My recommendation for a 2027 project

For a complex single-site WordPress or WooCommerce build, start by evaluating WPML against the real integration requirements. For a modest site with hands-on editors, evaluate Polylang. For a team that prefers visual translation, test TranslatePress. For managed-service convenience, calculate Weglot's full corpus cost and exit plan. For independent market sites, consider MultilingualPress with a deliberate Multisite operating plan.

The final choice should be the plugin that passes your smallest realistic pilot with the least ongoing friction. You do not need the longest feature list. You need a translated website your team can still keep accurate six months after launch.