Project: Metaframework adapter overhaul

[samuelstroschein]

Context

Metaframeworks (SvelteKit, NextJS) lead to recurring bugs and maintenance overhead.

• Redirect loop since Paraglide SK 0.9 #230

Proposal

Investigate what causes the metaframework complexities and simplify the architecture to reduce bugs and maintenance effort.

Potential solutions

• generalizable i18n routing API (discord)
• should not force a url based approach discord
• i18n routing should exclude paths entirely discord
• i18n routing should be opt-in, not opt-out to avoid bugs and increase discovery discord, Images with Sveltekit #233 (comment), discord2
• metaframeworks should be adapters that extend the compiler Project: Metaframework adapter overhaul #217 (comment)

Timeline

The project Paraglide JS 2.0 #201 comes first.

Issues

Open issues can be seen by filtering the "metaframework overhaul" label

[samuelstroschein]

@paraglide users, your input is appreciated on how we can make the metaframework stuff sipler

[samuelstroschein]

Re-route on sveltekit is making issues.

[EcksDy]

@samuelstroschein
Came from #233 , my 2 cents:

I've re-read the docs section for exclusions.

Excluded routes will:

• Not have any rel="alternate" links added to them
• Not have their Paths translated
• Not have links pointing to them translated

In my case I didnt realize my paths will be localized. For ru and he, they aren't.
Tying together asset routes, page translations, alt links and route localization on one exclude is confusing, that's for sure.
I guess that ru/he are not supported for route localization, which is good for me, considering the currently available config API I'd be a lot more frustrated if they were.

What I'm trying to achieve is:

• have alternate links
• translate pages
• images/static assets should not be translated/redirected
• routes should not be localized
• have the project build without errors

What I think should happen by default:

• route localization should be off
• page translation should be on
• alternate links should be on
• images/assets(fonts/binaries/etc) should be excluded

[samuelstroschein]

It's increasingly clear that metaframeworks should be adapters that extend the compiler.

• one doc site
• unified API (setLocale, etc)
• simplified metaframework implementations that just emit an additional file adapter-sveltekit.{js}
  -- increases discoverability of what is going on
  -- simple, adapter in a file :)
  -- people can write their own adapter files

[gerardmarquinarubio]

• one doc site

I come from #245 and while I have not much valuable to add I feel like any meta-framework rewrite to unify adapters should still have different documentation for different possible combinations of frameworks/choices. That could bloat that single doc site adding to visual clutter and possibly lead to unmantained docs due to the sheer amount of different pages that are available.

Just with NextJS you have 4 different combinations (pages/app router and localized routes vs other strategies) each with different setups and examples. Not even counting different Next versions that possibly break compatibility and may also need specific guides/instructions.

[Mardoxx]

Cookie language selection only would be fantastic (without URL rewriting). I haven't managed to get there yet with writing my own adapters (sveltekit)

[samuelstroschein]

@Mardoxx the paraglide js 2.0 beta is coming this january with elaborate docs on how to write your own adapter

[samuelstroschein]

@Mardoxx here are the docs https://inlang.com/m/gerre34r/library-inlang-paraglideJs/strategy

[samuelstroschein]

Here's what I am going to do (see the update #201 (comment)):

• Adapters will all have the same APIs. The API is defined in Paraglide JS itself
• The strategy becomes configurable e.g. domain routing, cookie stuff whatever

Goals:

• make adapters unopinionated
• increase DX by having the same API across Paraglide JS and it's adapters