What Is a Translation Widget? How Website Translation Works Without Rebuilding Your Site

"Just add a translation plugin" sounds simple until you actually try to scope the work. Some tools want you to duplicate every page into a second language. Others want your developer to restructure the database. A newer category, usually called a translation widget or runtime translation, skips both of those. Here is what it actually does, in plain terms.

The old way: duplicate content

Plugins like WPML work by creating a real, separate copy of every page for every language. A French version of your homepage is a distinct row in the database, with its own content, its own SEO fields, its own edit screen. This gives you full control over each language, but it means every new page, every product update, every blog post has to be translated and maintained twice, three times, or however many languages you support.

This approach makes sense for sites that need deep per-language customization, a different layout for one market, or content that genuinely differs by country rather than just being translated. It is thorough. It is also slow to set up and expensive to keep in sync.

The newer way: runtime translation

A translation widget takes a different approach. Instead of creating separate pages, it adds one small script to your site. When a visitor picks a language, the script scans the text that is already rendered on the page and replaces it, in the browser, with a translated version. Nothing changes in your database. There is no second copy of the page to keep updated.

The tradeoff is the mirror image of the plugin approach: setup takes minutes because there is nothing to duplicate, but you generally cannot make one language structurally different from another. You are translating the same page, not building a separate one.

What this means in practice

If your content is genuinely the same across markets, just in a different language, runtime translation gets you there with almost no setup. If you need a fundamentally different page per market (different pricing, different legal text, a different layout), a plugin-based approach that treats each language as its own content gives you more control.

Most small business and marketing sites fall into the first category: same offer, same pages, different language. That is the case runtime translation was built for.

Where it falls short

Runtime translation depends on the page being fully rendered before it scans the text, so content that loads very late or lives inside certain embedded widgets can be missed. It also cannot restructure a page for a market that needs a genuinely different layout, only translate what's there. And because translation happens automatically, a first pass should always be treated as a draft for anything customer-facing and important, a slogan, a product name, a headline, not a final answer. (For more on what happens when nobody checks that first pass, see our post on famous translation fails.)

How WeLocale fits in

WeLocale is a runtime translation widget: one script, translated in the browser, nothing duplicated in your CMS. It uses AI to do the first pass automatically, and every resulting string is editable in your dashboard, so a translation you are not happy with can be fixed once and stays fixed. On Pro and Scale plans it also adds hreflang tags automatically, so search engines can still tell which language version of a page to show which audience, addressing the one SEO gap that pure runtime translation has compared to a plugin-based setup.

Right now WeLocale ships as a JavaScript snippet plus a free WordPress plugin. Support for other platforms is on the roadmap, not live yet, so check what a specific integration actually supports before you plan around it.

Get started

Sign up free at welocale.net and add the snippet to see it translate your homepage. The free plan covers your first 3,000 words, enough to judge whether the runtime approach fits your site before you commit to anything.