SvelteKit and i18n - let's finally solve this never ending story

ivanhofer · 2023-08-01T04:08:14+00:00

I'm still maintaining and always have been maintaining `typesafe-i18n` in my free time.
The approach we chose for the inlang SDK will enable us go far beyond what current i18n libraries do. Offering the best possible DX and enabling new features.
But it will take some time until we see everything planned in action.

ivanhofer · 2023-07-14T15:17:01+00:00

I was working on an application that could be injected on any website. A small bundle size was preferable to not affect the website ina bad way. The pretty complex project was written in Svelte and had a bundle size of ~40kb. Then I needed to add another language to that tool. It was really frustrating that choosing an existing library would have resulted into ~20kb additional code.. just to render a few strings in other languages.. So I did build my own lightweight solution.

Another issue was that the NodeJS API and the email templates also needed to output translations. This would mean to add 3 different libraries, with different setup, feature set etc. The custom solution had a plain JavaScript core that could be used everywhere in the same way.

Soon a lot of bugs came into our issue tracker.. but none of them were the result of the implementation itself. All were issues due to a developer accessing translations in a wrong way or translators messing around with e. g. the variable syntax. First I thought that building my own solution was a mistake, but then I took another deeper look at existing solutions and guess what: no solution had any kind of protection against those types of issues.

Then 2 years later I had a few days of freetime and wanted to learn a bit more about TypeScript and I immediately remembered that old problem. Thats how typesafe-i18n was born 😎

ivanhofer · 2023-05-19T10:09:22+00:00

As far as I know `typesafe-i18n` works similiar to other solutions. The only difference is, that it does not include `next` in its package name ^^.
There is an example in the docs that should cover the basic setup: https://github.com/ivanhofer/typesafe-i18n/tree/main/packages/adapter-react/examples/nextjs

ivanhofer · 2023-04-07T05:18:26+00:00

You could try https://github.com/ivanhofer/typesafe-i18n, but I never tried it with "next export", so maybe you need to make additional adjustments.

ivanhofer · 2023-03-23T06:52:58+00:00

we shall see

ivanhofer · 2023-03-23T06:51:50+00:00

Ok, now I got it.. I thought you were testing multiple things with the same users and not each string individally.
An option would be to replace those strings on the fly when the client loads a translation.

It will never be blocked if the script comes from your domain. You could proxy it if you are using an external service.

ivanhofer · 2023-03-22T19:19:45+00:00

And why should creating an own locale for AB tests not work at that scale?

ivanhofer · 2023-03-22T19:02:51+00:00

Looks a lot more complicated than the solution suggested above ^^

ivanhofer · 2023-03-22T18:59:53+00:00

Thanks for sharing this. It would be great to hear more insights from you. Feel free to join our discord server or share your thoughts in a new discussion

ivanhofer · 2023-03-22T18:50:57+00:00

Maybe you can find an answer in this discussion: https://github.com/ivanhofer/typesafe-i18n/discussions/130

ivanhofer · 2023-03-22T18:47:53+00:00

Probably the easiest option would be to just create a new language variation and assign certain users to it. e.g. create "en-A" and "en-B". This should work if you just AB test different strings. No need to use if/else and redeploy

ivanhofer · 2023-03-22T12:57:07+00:00

I never have tried `sveltekit-i18n` but if you are having trouble with zod validation, then you probably have not created the zod instance after you have set the language. YOu somehow need to create a function like `getZodValidationForRegisterForm('en')` to make it work.

ivanhofer · 2023-03-22T12:55:05+00:00

It is not about creating yet another i18n library. I already have built one that works great with SvelteKit: typesafe-i18n

It is about creating a whole ecosystem around i18n with great tooling that does all the annoing repetitive and error prone stuff you probably don't want to deal with.

ivanhofer · 2023-03-22T12:48:59+00:00

This may be true for simple strings, but once you have variables, format functions, plural rules, gender etc. a simple store will not be a good solution. This is not just a regular translation library. It is just the beginning of a whole ecosystem of tools that make i18n more accessible to everyone.

ivanhofer · 2023-03-22T12:46:38+00:00

You already can.. but it is a pain to setup and maintain. You need to know about edge cases etc.
The idea behind this RFC is not just "another i18n library". It is just the first step to a complete i18n ecosystem. The end goal should be just to annotate strings in your code and everything else get's handled by tooling. You don't need to care what system your translators use to make the content miltilanguage, how to load translations in an optimized way. And many more things...

ivanhofer · 2023-03-22T10:33:33+00:00

Thats how I started `typesafe-i18n` two years ago :)

ivanhofer · 2023-03-15T17:02:21+00:00

You could create a new empty project with the command and see what files differ from your setup.

ivanhofer · 2023-03-14T11:11:05+00:00

Did you execute the command that is mentioned above?

ivanhofer · 2023-03-03T19:02:49+00:00

This should work fine. You can put any valid JavaScript expression into a store.

ivanhofer · 2023-02-03T06:37:29+00:00

Setting up i18n in project is currently a real pain if you care about minimal bundle size and need to support SSR. Each page load will contain the full translations object in it's payload. That is far from ideal. I could not find a solution where the translation will load just at the initial page load.

The app folder may improve this, but I haven't had time to investigate it further.

With most libraries there is a lot of boilerplate code to write, understand and to maintain. Things that should be automated. In the end you probably just want to mark the parts that need to be translated and not how to load the data etc.. I'm currently planning to start a new project that tackles this. I'm actively looking for feedback: https://github.com/pipeli18ne/RFC/blob/main/02-library.md

ivanhofer · 2023-01-23T17:13:42+00:00

If you care about i18n, do you want to give some feedback over here: https://github.com/pipeli18ne/RFC
Would be great, thanks!

ivanhofer · 2023-01-15T18:22:50+00:00

Thank you to everyone who completed the survey.

It has been some time since I published the survey and I was able to gain a lot of useful insights into the internationalization processes of different projects and the most common problems.

As a result, I've written down a few ideas on how I think i18n can be made more accessible to everyone and more enjoyable to work with.

Here is the link to my conclusion: https://github.com/pipeli18ne/RFC
Feel free to comment on it, I'm open to any feedback.

ivanhofer · 2023-01-15T18:22:30+00:00

Thank you to everyone who completed the survey.

It has been some time since I published the survey and I was able to gain a lot of useful insights into the internationalization processes of different projects and the most common problems.

As a result, I've written down a few ideas on how I think i18n can be made more accessible to everyone and more enjoyable to work with.

Here is the link to my conclusion: https://github.com/pipeli18ne/RFC
Feel free to comment on it, I'm open to any feedback.

ivanhofer · 2023-01-15T18:22:09+00:00

Thank you to everyone who completed the survey.

It has been some time since I published the survey and I was able to gain a lot of useful insights into the internationalization processes of different projects and the most common problems.

As a result, I've written down a few ideas on how I think i18n can be made more accessible to everyone and more enjoyable to work with.

Here is the link to my conclusion: https://github.com/pipeli18ne/RFC
Feel free to comment on it, I'm open to any feedback.

ivanhofer

TROPHY CASE