"official" i18n solution/guide for VPS

[samuelstroschein]

Hi there,

I am exploring possibilities to invest substantial resources in VPS by providing an "official" i18n library/guide.

We are users of VPS and build i18n/localization infrastructure (github/inlang). Providing VPS with an i18n solution would help us localizing our own product but also provide VPS with:

• relieve @brillout, or users of VPS, from months of work to build an i18n solution with support for SPA, SSR, message splitting, etc
• avoid/minimze i18n related issues like Vite-plugin-ssr build mode #660, Memory leak #653, Module is a CommonJS module, which may not support all module.exports as named exports. #635
• increase the user experience of VPS because the inlang ecosystem will work out of the box (editor, ide extension, cli, and more)

The task would be a large undertaking but may be worth it if users of VPS are interested, and we can design the i18n to be framework agnostic (like TanStack libraries). We need conviction to invest resources into this proposal though.

---

EDIT: Discussion is ongoing at opral/monorepo#395

[brillout]

Sounds good and this actually potentially matches the vision VPS is pursuing, which is to deeply integrate with third-party tools, such as Inlang.

A working example is https://github.com/brillout/vite-plugin-ssr/tree/main/examples/stem-react. The neat thing here is that the whole renderer logic is provided by Stem React which makes VPS a lot more like Next.js. Now this idea can be extended to all kinds of tools: admin panel, CMS, (error) tracking, emailing, full-text search, etc. (Although many will need to integrate not only with VPS but also with other tools – it will take time to fully unfold the vision.) Eventually, the user will be able to start with a full-fledged stack without having to write a single line of glue code. Ideally these Stem integrations are ejectable so that the user doesn't lose flexibility.

Creating Stem packages is pretty easy: you create a normal VPS app and then move some **/*.page.js files from pages/ (or renderer/) to node_modules/my-stem-package/.

One thing we can do is to start creating a normal VPS app that uses Inlang for i18n. Once we are happy with the result we create a new stem-inlang package and start moving files from pages/ to node_modules/stem-inlang/. (Depending on what we want to achieve, we may need to extend the capabilities of Stem packages. Let's see.)

[samuelstroschein]

The stem approach sounds good!

Before we move ahead, we are exploring interest from other metaframework authors to evaluate whether the effort of building an i18n library for metaframeworks is worth the effort.