Add basic i18n support

[jesperengstrom]

Description

Tickets involved

LXL-4362

Summary of changes

A modest proposal on how we could approach the i18n issue. Svelte has no official solution, and after looking at a number of libs, many seem too large, hacky or abandoned.

I then found this example that felt like a good approach and decided to try it out. It's basically a function that loads the needed translations and returns a translator function from the layout. It supports nested translation files and basic string interpolation (hello {name} how are you) and can easily be extended to support our exact needs (unknown to me at this point...)

Some notes:

• Translation files are .js at the moment. This allows us to typecheck the en using the sv one for example, keeping them fully synced. But we could just as well use json files.
• No cookie solution atm. Locales strictly follows the lang param (or lack of). If introduced, we'll have to discuss what should have precedence if both exist.
• Found no way to globally change the url base path (/en/ etc) at runtime, which is needed for correct links to be rendered. Current solution exposes a base variable that needs to be prepended to all links, which is a bit tedious...

[olovy]

LGTM!

I've come to prefer the gettext style of using the actual message as key. But I have no strong preference.

As you say this could easily be extended with plural forms etc. Agree on the link rewriting being tedious.

A nice starting point.

[johanbissemattsson]

I agree with it being a good starting point! I can do a more formal review this Wednesday (but I am also fine with merging it).

A quick idea regarding the issue with repetitive base url paths: could a <base> element in the root +layout.svelte be used to specify the base url path for all relative URLs on the site?

I have no real preference regarding actual message style but it can be good to further discuss it and how we can achieve pluralization.

[jesperengstrom]

A quick idea regarding the issue with repetitive base url paths: could a <base> element in the root +layout.svelte be used to specify the base url path for all relative URLs on the site?

Yay, that worked! I tried that before, but missed that you then can't use root-relative paths (/search)

[jesperengstrom]

Merging this now, continued discussion has been mostly about the base thing - i.e what's least annoying/error prone; <base> element disallowing root-relative (/) links, a {base} variable or a getLink function. Guess we'll just try it out and see.

[samuelstroschein]

@jesperengstrom

Why did Paraglide JS seem "too large"? We need to improve our communication :) cc @LorisSigrist

• You linked our monorepo https://github.com/opral/monorepo. The source code for paraglie JS is here though https://github.com/opral/monorepo/tree/main/inlang/source-code/paraglide/paraglide-js/src. A regular NPM package which is compact.
• Runtime and architecture wise Paraglide JS is the smallest i18n you can possibly adopt.

[jesperengstrom]

Hi @samuelstroschein, sorry for the sloppy comment (edited now). What I meant was that in our particular case and right now any lib probably has more functionality than we need. Paraglide seems great btw and something we'll probably consider again at some point :)