How to Translate a Svelte or SvelteKit App

Quick answer — Svelte ships no official internationalisation library, so teams pick a community one or build a store-based pattern. SvelteKit's server rendering and route parameters handle the harder half — making translated pages crawlable.

No official library, which is the Svelte way

The framework stays small and the ecosystem fills gaps. For i18n that means several community options with different trade-offs, or a straightforward store-based approach of your own.

A writable store holding the current locale, a derived store resolving keys against a message object, and a helper in templates gets a small app a long way without a dependency.

Reactivity does the hard work

Because a derived store recomputes when the locale changes, switching language updates the whole interface with no reload and no manual re-render.

That is genuinely simpler than the equivalent in most frameworks, and it is the reason a hand-rolled solution is defensible here in a way it would not be elsewhere.

SvelteKit routing gives you the URLs

A [lang] route parameter produces /fr/pricing — a distinct, crawlable URL per language, which is the requirement everything in multilingual SEO rests on.

Load the right messages in the load function so they arrive with the server render rather than after hydration. That is the difference between a crawler seeing French and seeing a shell.

What to get right in the load function

Fetch messages server-side, return them as page data, and let the component read them synchronously. Fetching them in onMount means the first paint is untranslated and the crawler never sees the translation at all.

Metadata per language

Title, description and Open Graph tags set in the page's head, generated from the same locale the body uses. A translated page with English metadata competes as an English page.

hreflang needs to reciprocate across every language version, emitted from one place rather than written per route.

Static adapter and prerendering

Prerendering a multilingual SvelteKit site multiplies routes by languages. Manageable, and worth deciding deliberately which languages are prerendered rather than accepting whatever the default produces.

Beyond the interface

Content from a CMS is a separate pipeline from interface strings, and website translation covers the rendered output where the two combine. translation memory keeps recurring cost proportional to what actually changed.

Setup notes are on the Svelte integration page.

Stores and server-side rendering

A module-level store is shared across requests on the server. Setting the locale in a shared store means one user's language can leak into another user's response under concurrent load. Keep the locale in page data rather than a module-level store, or scope the store per request. This is the single most important correctness detail in a hand-rolled SvelteKit i18n setup.

Progressive enhancement

Forms and actions that work without JavaScript need their responses localized server-side too, since there is no client to do it.

Choosing a library versus rolling your own

A hand-rolled store works well for a small app with a few hundred strings. Past that, the things a library gives you — plural rules, interpolation, message formatting, extraction tooling — are exactly the things that are tedious and error-prone to write yourself. The switching point is usually plural handling. The moment a string depends on a count, a library earns its place.

Where to start

Render one page in the target language and view source. If the translated text is in the HTML, search engines can read it. If it only appears after hydration, it is a client-side render and needs the server side solved first.

FAQ

Does Svelte have an official i18n library? No. Teams use a community library or build a store-based pattern: a writable store for the locale, a derived store resolving keys, and a template helper. Reactivity makes the hand-rolled version defensible here.

How do I get language URLs in SvelteKit? With a [lang] route parameter, which produces paths like /fr/pricing. That gives each language a distinct crawlable URL, which everything else in multilingual SEO depends on.

Where should messages be loaded? In the load function, so they arrive with the server render. Fetching them in onMount means the first paint is untranslated and a crawler never sees the translated text at all.

Does prerendering work with multiple languages? Yes, though it multiplies routes by languages. Decide deliberately which languages are prerendered rather than accepting whatever the default configuration produces.