What Happens to Your Translated Pages if LgTranslate Goes Down?

When our dashboard and API are down, your visitors should keep getting the translations you already published. That is the central design rule of LgTranslate, and it is a design, not a track record: it has been built and tested offline, but not proven by long production traffic. This guide explains what the design is, what each kind of failure looks like to a visitor, and where the promise stops.

Two planes that share only static files

LgTranslate has two parts:

• The control plane is the dashboard, the API, the translation engines and the publisher. It is where you edit, translate and publish. It can go down.
• The delivery plane is a set of small static files: one per language, plus a manifest that lists them. Copies sit on your own site and on content delivery networks (CDNs). It is built to stay up.

The rule that connects them: nothing a visitor's browser does to show a translated page calls the control plane. Our threat model states the same principle: the control plane may be down, and visitors must still get translated pages.

How a translated page reaches a visitor

1. A small script, the loader, runs in the visitor's browser.
2. It fetches the manifest and checks its digital signature against a public key that you configured.
3. It fetches the language file and checks the file's checksum against the one in the signed manifest.
4. It replaces the text on the page and saves a copy in the browser.

If any step fails, the page stays in your original language. The loader never shows unchecked text, and a missing translation is never an error page. Each request has a time limit (2.5 seconds per place by default), so a slow place cannot freeze the page.

What visitors see when something fails

The last row matters for security as well as reliability. Because every language file is pinned by a checksum inside a signed manifest, a CDN or storage account is treated as untrusted transport, and an older signed manifest cannot roll the page back to an earlier version.

Why the files live in several places

A single location is a single point of failure. The design publishes to your own site (on WordPress, the plugin keeps a local copy and serves it first), then to two independent CDN or storage providers. Files are written first and the manifest last, and the publisher verifies the result. Two independent providers are what makes the promise work, and at the start of any deployment you might have fewer than that: with only the application's own host, translations depend on that host for first-time visitors, and the dashboard says so and recommends adding a second place. Adding one later is a configuration change and does not require republishing.

The limits we state openly

A promise is only useful if you know where it stops:

• Publishing needs our servers. Showing translations you already published does not. While we are down, new text on your site stays in the original language.
• First-time visitors need one working place. If your site and both CDNs are unreachable, they see the original language.
• The loader itself has to come from somewhere. On WordPress it comes inside the plugin, from your own site. With a plain script tag it comes from a CDN; if that CDN is down the script cannot run. You can reduce that dependency by hosting a numbered copy of the loader yourself.
• Browsers that cannot check the signature stay on the original language on purpose. This is safer than unchecked text. Exact browser support is something we mark as verify.
• If your own website is down, nothing on it can be seen or translated. The promise concerns our servers, not yours.
• Search engines. Translations applied in the browser are mostly not seen by crawlers. Real language addresses (WordPress, Shopify, framework kits) are what search needs; see client-side vs server-side translation and SEO.

How to test it yourself

You do not have to trust us. Open your site in a private window, block the host that serves the translation files in your browser's developer tools, and reload. You should see your original language, not an error. Then reload with the files allowed. Our guide to testing translation failure walks through the checks, including a returning-visitor test.

Keep your own copy

Independence is more than uptime. You can hold the published files on your own systems: the WordPress plugin does it for you, the command-line tool can download and verify the published bundle, the framework kits write translated pages into your own build, and an export gives you the text in standard formats such as XLIFF, PO, CSV and TMX. See avoiding translation vendor lock-in.

Next step

If a translation outage is a risk you want to remove, run the failure test on whatever you use today, then try the same test on a LgTranslate site. Create an account, publish one language, and block the file host as described above. The resilience use case summarises what the product does and does not promise.

Key takeaways

• Published translations are static, signed files held in several places; the visitor's browser never calls our dashboard.
• During an outage you can still serve what you published, but you cannot edit or publish new text.
• The promise has stated limits: first-time visitors, the loader file and your own host.
• This is a design backed by offline tests, not a proven production record.

Sources

• LgTranslate threat model and architecture notes in the project repository (docs/security/THREAT_MODEL.md, docs/architecture/ARCHITECTURE.md) – control plane and delivery plane, trust model
• Localized versions of your pages – Google Search Central – crawlers and language versions (checked 2026-11-06)
• Managing multi-regional and multilingual sites – Google Search Central – Google recommends different URLs for each language version (checked 2026-11-06)
• Block Search indexing with noindex – Google Search Central – how Google treats pages it should not index (checked 2026-11-06)