move metaframework APIs into paraglide js

[samuelstroschein]

Context

I find it hard to give recommendations/support on paraglide for different metaframeowkrs because they have different APIs.

Proposal

Move metaframework-related APIs like routing strategy into paraglide-js for a consistent way/knowledge transfer between metaframework.

• Paraglide JS - defines the APIs for plain JS, frameworks, meta frameworks
• Paraglide {next|svelte|x} - implements the APIs I find it hard giving recommendations/support

Additional information

Came up in https://discord.com/channels/897438559458430986/1271469453149732995/1271491605077037097

[NilsJacobsen]

Curious what @loris.sigrist thinks about it

[LorisSigrist]

I try to keep the meta-framework APIs similar by reusing concepts that work in one in as many as I can. The RoutingStrategy interface is really promising & portable for example.

However, basically everything needs to interact with framework code in some way. Even RoutingStrategy relies on being able to access the Framework's Request object.

IMO most of the framework code would be quite difficult to centralize, however, we can certainly align the concepts more. Paraglide-SvelteKit should have a RoutingStrategy interface as well

[samuelstroschein]

@LorisSigrist However, basically everything needs to interact with framework code in some way.

Implementation would be up to the adapters. For knowledge transfer, the only important part is the API. Agree/disagree?

[LorisSigrist]

I can try to come up with a unified API that works in all our adapters, however, I'm not sure it'll end up being simpler, as the adapters will likely end up with way more primitives to implement.

TBH I would need to try before I can give a confident assessment here

[samuelstroschein]

Makes sense. Let's delay the discussion und push out importer/exporter + variants

[samuelstroschein]

For future discussions:

**Moving the vite plugin to paraglide js also seems to make sense. **

• In https://github.com/orgs/opral/discussions/3056 I had to explain that you can use "paraglide vite" to use paraglide js with vite. That is confusing. Easier would be "import the vite plugin from paraglide js"
• I saw multiple users using both paraglide-vite, and paraglide-sveltekit in the dependencies. Prob because they were confused.

Maybe an "adapter" architecture was/is better for communication and ease of use

With the spin that everyone installs paraglide-js and an adapter "hooks" into the compiler instead of providing their own compiler.

paraglide-js compile --adapter @inlang/paraglide-js-sveltekit-adapter

import defineConfig from "vite"
import { vitePlugin as paraglide } from "@inlang/paraglide-js"
import svelteKitAdapter from "@inlang/paraglide-js-sveltekit-adapter"

export default defineConfig({
  plugins: [
    paraglide({ adapter: svelteKitAdapter })
  ]
})

• simplified docs because we just need paraglide js docs with an adapter section
• no confusion on what to install
• unified api across frameworks (that compile different things based on the hooks of the adapter)

[samuelstroschein]

(No action required, just adding context)

Another reason for "going back to adapters" is branding. Users are referring to Paraglide JS as Paraglide JS. I found myself being confused too when I give recommendations, wondering if I should say "use Paraglide Svelte|React|Next|SvelteKit|Astro|X". Saying just "use Paraglide JS (with your frameworks adapter)" would be much simpler.

*Screenshot is taken from *https://www.reddit.com/r/nextjs/comments/1etryqn/i18n_with_app_router/

[samuelstroschein]

Independent upgrading of paragide js and the metaframework implementation is another reason to go back to adapters.

Releasing paraglide 2.0 with variant supports needs to update all metaframework versions. It would be (much!) easier if Paraglide JS can be upgraded independently of the adapters.

[samuelstroschein]

Done #201 (comment)