Website translation

Three of the integration modes translate a website directly, without touching your i18n code. They differ in where the translation happens and how much of your stack you need to change:

• JS snippet — you add one script tag; translation happens in the visitor’s browser. Works on any site where you can edit the HTML.
• Edge proxy — you point your domain at the proxy; visitors receive pages already translated, cached and served from the CDN edge. No changes to your site at all.
• WordPress plugin — the page is translated on your server before it is sent, with real language attributes and hreflang tags for SEO.

All three feed the same project: strings discovered on your site flow back into the editor, where your team translates and reviews them, and the results go live automatically.

JS snippet

The snippet is a single script tag placed before </head> on your pages. It carries your publishable key and your language list, and it can render a language switcher for your visitors.

The hub’s Integration tab generates the exact tag for your project — the options you pick there (switcher style, auto-detect, and so on) are reflected live in the snippet you copy. A minimal tag looks like this:

<script
  src="https://cdn.lionrapid.com/lionrapid.auto.min.js"
  data-api-key="pk_your_key"
  data-base-url="https://app.lionrapid.com"
  data-default-locale="en"
  data-languages="en,es,de"
  async
></script>

Snippet options

Option	What it does
Auto-detect language	Match the visitor’s browser language on their first visit
Namespace	Scope translations when your site has multiple sections
Visual editor	Let translators edit content directly on your site
Language switcher	Show a switcher; pick a style — floating, buttons, or flags
Switcher position	Any of the four page corners
Show flags / show names	What each language entry displays
Brand color	Accent color for the active language
Custom CSS	Override the default switcher styles entirely

How the snippet works

1. Scan the page. The script finds the translatable text blocks in your HTML.
2. Check the cache. Each block is looked up in the browser’s local cache, so repeat visits are instant.
3. Apply translations. Cached translations are swapped in place.
4. Sync what’s missing. New or unrecognized strings are reported back to the project so you can translate them in the editor.

Edge proxy

The edge proxy translates your site with no code changes: requests to your domain pass through a translation layer, and visitors receive translated pages cached and served from the CDN edge. Your origin server is untouched.

Set it up

In the Integration tab (proxy mode), the first-time setup asks for two things:

• Site URL — the public address your site lives at, for example https://example.com.
• Origin host — the host the proxy should fetch your original pages from.

Languages are synced automatically from your project: the source language becomes the default, and every target language is enabled for visitors.

Automatic platform detection

When you enter your origin, the platform is detected automatically — WordPress, WooCommerce, Shopify, Webflow, Next.js, Drupal, Magento, Squarespace, Wix, and more. The banner shows what was recognized and how confident the detection is, and offers to apply recommended defaults for that platform: exclude paths, auth paths, and auth cookies that fit how the platform structures its URLs. You can edit or remove any of them afterward, or dismiss the banner and configure the rules manually.

Per-domain settings

Each edge proxy configuration belongs to one domain. The settings:

• Site URL & origin — the addresses above, the origin protocol, and an Active toggle to switch the whole configuration on or off.
• Languages — read-only in the proxy settings; synced from the project. Add or remove target languages on the project itself.
• Language switcher — the same switcher as the snippet: style (floating, buttons, flags), position, flags and names, brand color, custom CSS, with a live preview.
• Visual editor — let translators edit content directly on the live site.
• Advanced — translation snippet — auto-inject the script on served pages for client-side translation and the switcher.
• Advanced — path rules — exclude paths are passed through untranslated (admin areas, APIs, static assets); pages matching auth paths or carrying auth cookies are never served from the cache, so signed-in visitors always get fresh, private responses.
• Advanced — cache settings — the minimum text length worth translating, how long translated HTML stays cached, and how long the edge keeps your configuration before re-fetching it.

Cache purge

When translations change, the cache is purged automatically so fresh translations go live without you doing anything. You can also trigger a purge yourself from the settings: scope Translations clears translated content, scope All clears everything. A pending purge is shown with its scope and start time until the edge confirms it.

Danger zone

Deleting a proxy configuration permanently removes all settings for that domain. This cannot be undone — you would need to set the domain up again from scratch.

WordPress plugin

The WordPress plugin translates pages on the server, before they are sent: the first byte the visitor receives is already in their language. There is no flash of untranslated content and no JavaScript round-trip on first paint. Because the HTML itself is translated, search engines see it too:

• the page’s lang attribute reflects the actual language served,
• hreflang alternate links are added for every language,
• each language lives at its own URL path, such as /es/ for Spanish.

Install and connect

1. In your WordPress dashboard go to Plugins → Add New and install LionRapid.
2. Activate the plugin, then open Settings → LionRapid.
3. Paste the two values shown in the hub’s Integration tab — your API key and the server URL — and save.

That’s it. Everything else — languages, namespace, switcher, path rules, server-side rendering — is managed in the hub and pushed to your site automatically. When you save a setting, the plugin is notified immediately; if that notification doesn’t get through, the plugin catches up on its own schedule within about five minutes.

WordPress-specific settings

• Default namespace — the namespace your site’s strings are grouped under.
• Server-side translate initial page render — recommended, and how the plugin is meant to run. Turned off, pages are translated by JavaScript after they load instead.

The remaining sections — site URL, synced languages, language switcher, visual editor, path rules, cache settings, cache purge, and the danger zone — work the same way as for the edge proxy above.

Content stays in sync

Strings discovered on your live site flow back into the project, so new posts and edited pages show up in the editor ready to translate. Once translated, they are served automatically — no re-installation or manual export.

For using translations inside themes and page builders, see the WordPress plugin developer chapter.