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

Hi Svelte Summit! Today we will take a look at the two most commended issues in the SvelteKit repository.
Both issues deal with internationalization, or in short I18N.
SvelteKit has reached the stable 1.0 release a few months ago, but still does not provide a solution if you want to make your applications available in multiple languages.
I'm Ivan and I want to show you how a possible solution to those two issues could look like
using the Inline SDK.
Some of you might know me from Typesafe I18N, a lightweight and fully Typesafe internationalization
library that works with all frameworks, also with Svelket.
And there also exist some other solutions that you can already use to localize your
project.
I have learned a lot over the past two years
while maintaining TypeSafe I8NN.
Each project is somehow different,
and probably 90% of questions I get asked
is related to how to set it up
for a specific project and its needs.
There is a documentation, and there are also examples,
but those can't give you the answer
that matches 100% to your project.
You will need a deep knowledge of SvelteKit
and the library in order to not mess things up
if you want to change the default behavior.
A better approach is needed.
So I teamed up with Inlang to solve those problems.
And now I will show you how easy it should be to use I18N in any project.
I have cloned an empty Svelte application
and have added a file for the English and another file for the German translation.
Let's install the Inlang SDK.
As a next step, we add the inline plugin right before the SvelteKit-Deep plugin.
That's all you need to set it up.
We can now go to our plus-page.svelte file and render our first message on the home page.
To do that, we import the inline function and call it with the key we have defined in our language files.
Let's also add two buttons to switch between languages.
Open the terminal and execute npm rundev. We now see the German message appear because my browser
is set to German. I can switch language by pressing the buttons and if I reload the page
the language does not change because it gets persisted in local storage. But what if we want
to include the language information in the URL? We can open the inline-config.js file that was
automatically created previously and change the language negotiation settings to URL.
If you visit the home page, the server should read the accept language header and redirect
us to the preferred language version we have set in our browser. Let's start the server again and
we see that we got redirected to the German page. We once again can click on those two buttons to
switch language, but this time also the URL changes. If we open the source code view, we see
that server-side rendering works too. And to prove that the server is doing the redirect,
we can try to visit the home page, but we immediately see the German page because we
got redirected.
But what if you want to output a static application where no server is involved? Let's do that
by setting the pre-render option to true in the root layout file and see what happens.
We don't really see a difference in the browser, but if we visit the home page in the source
code new again, we no longer get redirected. If we visit the home page in a regular way,
JavaScript clicks in, reads the language information from the browser, and redirects
me again to the German page. So why are those two issues still open? This one is already four years
old and the work on it hasn't even started yet. You need quite some time to go over all comments.
Making a project available in multiple languages is not just replacing text A with text B.
It can take a lot of effort if you want to do it right.
Auto-detecting the user's preferred language, creating a SEO-friendly output, alternate links,
plural rules, number and date formatting. Do you offer server-side rendering? Is your application
static or serverless or does it run on a node server. You should also do some bundle optimization
at the end to offer your users the best possible experience. That's a short summary of those two
issues. Each decision you make will affect the way how you need to set up the internationalization
library. Inline automatically adapts to your project needs. Remember, we never have touched
any code to set up an IAPN library. We never saw any implementation details. How easy is that?
Apart from this Weldkit integration, Inlang provides also other tools to make internationalization as
effortless as possible. I have published this example to GitHub and now I can open up the
Inlang editor to see my messages appear. I can add Italian as a third language and let AI translate
the message for me. Commit, push, and go back to VS Code. We can pull the changes
and start the dev server again.
Now we have a third language and it renders on screen without touching a
single line of code. Inlang also provides an IDE extension.
Here we forgot to extract some hard-coded string. We can use the
extension to extract it.
Commit, push and reload the editor. The new message shows up and any non-technical
people can edit and translate it. In the background, Inlang uses your Git
repository as a source of truth and synchronizes all changes using commits.
We started with the development of the SDK just a few weeks ago. The base is already here. We try
to automate as many things as possible and add configuration options where it makes sense.
Some things may not be ideal right now. We needed to find some creative ways to deal with some
limitations SvelteKit currently has, but we already have talks with the SvelteKit team
and together we are looking for a solution to make things more simple.
We need your feedback. Try it out and let us know what you think. We are just at the beginning.
Tell us what features do you want to see. This feedback helps us prioritize our development
efforts. In a few months we want to offer the go-to solution when it comes to internationalization in
any Threadkit project. Other meta frameworks like Next.js will follow. All tools I showed you today
are open source and you can use them for free. They also work independently from each other.
If you have an existing project you can try the editor first without refactoring your whole code
base or you could use the SDK also without the other tools. I hope I could give you a quick
overview of Inline and show you how easy it should be to localize a project.
We take the burden off your shoulders and hopefully Recheris is able to make that satisfying
click on both issues.