support i18n

[tevel]

it seems like svelte does not support i18n...

I mean possibility to add language files and easily translate string in templates as well as in javascript code. e.t.c: this.$t('home.wellcome') will be translated to 'Welcome guest' from file /lang/en-US.json.

Is support of i18n planned?

[Conduitry]

Have you looked at Svelte's built-in Store? It seems like that could be used pretty well to grab strings from json files and to make them available to all components.

[tevel]

yes, I did, this can be a solution.

but I'm using not just Svelte but also Sapper and I seems to be tricky to implement it correctly both for server and client side.
It would be great to get full well-done solution sometime...

[tevel]

I tried to create my own store:

class MyStore extends Store ...

added to client:

init(
    document.querySelector('#sapper'),
    routes,
    {
        store: data => {
            return new MyStore(data);
        }
    });

but I got:

client.js:11 Uncaught TypeError: my_store__WEBPACK_IMPORTED_MODULE_2_.MyStore is not a constructor at Object.store (client.js:11)

it can't instantiate my class
B.T.W for the standart store it works...

[tevel]

I'm sorry, I forgot to add
export { MyStore };

[tevel]

finally solution with Store works fine

but in this case Store is not POJO anymore

it causes problem with transferring state from server to client in Sapper
as described here: sveltejs/sapper#230

[stalkerg]

I have special function _ in store for this case, and it works very fine.

[laurentpayot]

Did you try https://github.com/kaisermann/svelte-i18n ?

[andymans]

@Rich-Harris had an extensive thread on this some months back, incl on his Twitter feed, I remember correctly. Not sure what the outcome was; but rolling your own is very easy and svelte provides all the programming concepts you'd need in order to do so without adding much to your bundle-size.

[korywka]

@Conduitry what type of help is wanted?

[ecstrema]

here's another translation lib that works with sveltekit: https://www.npmjs.com/package/s20n. (sorry for the self promotion, but that's what issues are for I guess...)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jaeming]

This doesn't seem like something that needs to be built into Svelte itself. There are now several third party solutions available.

i18next is a popular i18n library that works with many frameworks. They list Svelte as one of the supported frameworks among many others, with store-based wrapper available here: https://github.com/NishuGoel/svelte-i18next

I tried it out recently as was able to get it working fairly easily in conjunction with this plugin. using this tool I was able to bundle the language message json files as separate js chunks in my public folder and then lazy load them as necessary.

[Spenhouet]

Sad to hear that this is not planned. I really hoped Svelte would provide a out-of-the-box solution, making i18n a native feature, not needing any janky third-party plug-in. I thought "I was able to make it work" wouldn't be the "good enough" bar.

[Rich-Harris]

Unless you have a specific feature request in mind, it's outside the scope of what belongs in a rendering framework — it's an application-level concern

[Spenhouet]

Fair. I have/had a bit of a more general perspective on what Svelte is and isn't, but when you say it's just a rendering framework and such does not include native i18n support, then that's how it is. Internationalization is (imo) a core function for every web page, but in my experience it's an afterthought in most of web development and web frameworks. Internationalization requires a deep integration and due to the limitations of building on-top of a framework, most third party libraries do a poor job. I don't have a golden solution nor am I an expert on that topic. I just found my self being unhappy with all existing solutions and my wishful thinking was "if the Svelte team integrated a native solution it's going to be awesome". Anyway, thanks for the great framework!

[paoloricciuti]

Fair. I have/had a bit of a more general perspective on what Svelte is and isn't, but when you say it's just a rendering framework and such does not include native i18n support, then that's how it is. Internationalization is (imo) a core function for every web page, but in my experience it's an afterthought in most of web development and web frameworks. Internationalization requires a deep integration and due to the limitations of building on-top of a framework, most third party libraries do a poor job. I don't have a golden solution nor am I an expert on that topic. I just found my self being unhappy with all existing solutions and my wishful thinking was "if the Svelte team integrated a native solution it's going to be awesome". Anyway, thanks for the great framework!

Take a look at inlang paraglide...they have a very thoughtful framework for i18n and they are basically working on that alone. The domain knowledge that they have can make a better i18n framework than any svelte could build on the side of the rendering framework.

[Rich-Harris]

Internationalization requires a deep integration and due to the limitations of building on-top of a framework

I agree — but 'framework' in this case means 'application framework' rather than 'component framework'. In other words if we were to develop a more deeply integrated solution (ideally building on top of the work that's already been done by the community), it would be in SvelteKit rather than Svelte.

Svelte is about defining the isolated building blocks of your app in such a way that they can be assembled into a larger whole, and i18n — which asks questions like 'how do I determine locale for a given user, based on request headers or cookies or localStorage or what-have-you?' and 'where do my translations live, and how can non-programmers edit them?' and 'how do I interact with my build tooling so that the right translation files are delivered at the right time without waste or duplication?' and many others — sits far outside that.

[laurentpayot]

For those interested, I ended up having a separate build for each of my supported languages (translations imported via symlinked modules). Nowadays hosting services (Vercel, Netlify, Firebase…) allow redirects to the right directory depending on the detected browser language.

[Spenhouet]

it would be in SvelteKit rather than Svelte

I'm not using one without the other, so I never thought about the difference between both. I wasn't referring to either, but rather "Svelte" as a whole.
But I take it that you also wouldn't be interested in solution integrated in SvelteKit?

For those interested, I ended up having a separate build for each of my supported languages (translations imported via symlinked modules).

Thanks for providing a prime example of why a proper native solution is needed.

[Rich-Harris]

But I take it that you also wouldn't be interested in solution integrated in SvelteKit?

On the contrary. But there are only so many hours in the day, so we have to prioritise

[samuelstroschein]

@laurentpayot For those interested, I ended up having a separate build for each of my supported languages (translations imported via symlinked modules)

Is your repo public? I'd like to take a look.

For context, I am working on Paraglide JS. Solving per-language message splitting (opral/inlang-paraglide-js#88) is the last part missing for hyper-efficient tree shaking. I always thought that the way to achieve per language tree-shaking is to build per language and swap out the imports.

[laurentpayot]

@samuel not public but I use Vite as a build system, with the vite.config file below:

// ...
const LANG = process.env.VITE_LANG ?? "en"
// ...
export default defineConfig({
    // ...
    root: "./src",
    publicDir: "../public",
    build: {
        // ...
        outDir: `../dist`,
        emptyOutDir: false,
        rollupOptions: {
            output: {
                entryFileNames: `assets/index-${LANG}-[hash].js`
            }
        }
    },
    // ...
})

then my build script for en and fr locales is the following (symlinking index.html makes it work):

{
"build:js": "vite build",
"build": "rm -rf dist && mkdir -p dist/localized/en && mkdir -p dist/localized/fr && VITE_LANG=fr pnpm build:js && cp dist/index.html dist/localized/fr && ln -s ../../index.html ./dist/localized/en/index.html && VITE_LANG=en pnpm build:js"
}

As you can see it’s a bit tricky…

I always thought that the way to achieve per language tree-shaking is to build per language and swap out the imports.

I agree. (Even if you can get an i18n library in 20 LOC 😉 )

[samuelstroschein]

@laurentpayot Do you think your solution is generalizable to all sorts of SvelteKit projects?

For example, symlinking seems to be an entry point for platform-specific bugs, e.g., windows, UNIX behave differently.