IssueRaiser

i18n brainstorming

We've somewhat glossed over the problem of internationalisation up till now. Frankly this is something SvelteKit isn't currently very good at. I'm starting to think about how to internationalise/localise https://svelte.dev, to see which parts can be solved in userland and which can't. (For anyone unfamiliar: 'Internationalisation' or i18n refers to the process of making an app language agnostic; 'localisation' or l10n refers to the process of creating individual translations.) This isn't an area I have a lot of experience in, so if anyone wants to chime in — particularly non-native English speakers and people who have dealt with these problems! — please do. Where we're currently at: the best we can really do is put everything inside `src/routes/[lang]` and use the `lang` param in `preload` to load localisations (an exercise left to the reader, albeit a fairly straightforward one). This works, but leaves a few problems unsolved. I think we can do a lot better. I'm prepared to suggest that SvelteKit *should* be a little opinionated here rather than abdicating responsibility to things like `i18next`, since we can make guarantees that a general-purpose framework can't, and can potentially do interesting compile-time things that are out of reach for other projects. But I'm under no illusions about how complex i18n can be (I recently discovered that a file modified two days ago will be labeled 'avant-hier' on MacOS if your language is set to French; most languages don't even ha

Posted by Rich-Harris on Feb 23, 2019, 5:56 AM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments

github (SaaS)

i18n brainstorming

Rich-HarrisFeb 23, 2019, 5:56 AM

We've somewhat glossed over the problem of internationalisation up till now. Frankly this is something SvelteKit isn't currently very good at. I'm starting to think about how to internationalise/localise https://svelte.dev, to see which parts can be solved in userland and which can't. (For anyone unfamiliar: 'Internationalisation' or i18n refers to the process of making an app language agnostic; 'localisation' or l10n refers to the process of creating individual translations.) This isn't an area I have a lot of experience in, so if anyone wants to chime in — particularly non-native English speakers and people who have dealt with these problems! — please do. Where we're currently at: the best we can really do is put everything inside `src/routes/[lang]` and use the `lang` param in `preload` to load localisations (an exercise left to the reader, albeit a fairly straightforward one). This works, but leaves a few problems unsolved. I think we can do a lot better. I'm prepared to suggest that SvelteKit *should* be a little opinionated here rather than abdicating responsibility to things like `i18next`, since we can make guarantees that a general-purpose framework can't, and can potentially do interesting compile-time things that are out of reach for other projects. But I'm under no illusions about how complex i18n can be (I recently discovered that a file modified two days ago will be labeled 'avant-hier' on MacOS if your language is set to French; most languages don't even ha

Comments (0)

No comments yet. Start the discussion.

Comment on this issue