Isomorphic functions for client framework components

[Barnabas]

Hi, first of all thank you for the high quality translation library, Alexandre. I see a point of pride is "built for Astro and nothing else." Nevertheless, I'd like to ask about or propose an isomorphic versions of this library's translation functions. By "isomorphic" I mean something that works both in the Astro server context and the browser context, meaning framework components like Vue, React, Solid, etc.

Right now astro-i18n is server only and doesn't work in framework components in the browser. You can't do import { t } from 'astro-i18n' in a Vue component, for example. I wrestled with a different translation library (vue-i18n) that happens to use the same JSON files but it had the opposite problem, failing to render on the server. AFAICT astro-i18n is closer to implementing browser compatibility than vue-i18n is to fixing SSR. It would be better to have a single awesome translation library that works with many frameworks. I cobbled together some code that used a dynamic import on the server and fetch on the client. Without access to the current locale during SSR, Astro just loaded English and then Vue complained about a hydration mismatch for all other languages.

Ultimately, I want to put JSON translation files in the /public directory and use a t() function that works in static and dynamic Astro components and also client-side framework components. What if the astro-i18n configuration could specify either a file location or a URL to load at runtime, or maybe a load callback function? Is this already possible somehow? If not, would you consider this feature worthwhile?

[Alexandre-Fernandez]

So you basically want to make this work for single page apps ? I don't see how that would work with astro.

I did think of making a common i18n logic package that astro-i18n or other frameworks could implement.
But these kind of libraries already exist so I didn't see the point of doing that.

I'm currently in early development of version 2.0 so maybe I can think about client-side but for now I don't really see the point.
When you say client-side compatible, you're still mentioning fetching, from what I understand you want the server to store the translations and the client to get only what's needed is that right ?

[Barnabas]

Thanks for the reply. Astro already has great support for client-side frameworks even though many have their own server frameworks such as Vue (Nuxt), React (Next.js), and Svelte (SvelteKit). Astro's islands tech on Vite is world-class. One could use any of those frameworks with Astro to create a static site with zero browser JavaScript. Only when we use a client directive will Astro hydrate the component for client-side interactivity.

The point of all this is to suggest that astro-i18n should be equally at home on the browser as it is in the server. What would that look like? When Astro renders the component during the build, the component will ask astro-i18n for translations which have been loaded from the local file system (as it does now). But if a framework component is executing in a browser environment such as after hydration, astro-i18n could somehow (dynamic imports? fetch?) grab the JSON and behave the same way. A developer should be able to switch between any of the client directives and translations should still work. Imagine a client component where the user chooses a value and it dynamically translates a message using a formatter.

I did look at the other library you mentioned and it's too bad that it can't use JSON files directly, unless I missed something. There are professional translators on my project updating RESX and JSON files, so strongly typed translations solves a problem we never had. I thought astro-i18n was very well made and has potential to be great, and that is why I reached out. It just seemed like such a shame that it is not yet usable in one of the most interesting and unique Astro scenarios: framework-independent transparently hydrated islands.

[Alexandre-Fernandez]

So you want astro-i18n to work even with client:only directives ? Fair enough, I also agree that it should support it, I'll try to make it happen in v2.0.

[Alexandre-Fernandez]

I just finished adding this feature to the version 2.0 (unreleased at the moment).

Translations are now divided into groups: common translations, page-specific translations, grouped translations.
The corresponding translations to the current page will be serialized into the html (with the rest of the state) and will be accessible even with the client:only directive. Even custom formatters get serialized and will work as long as they do not use things outside the function scope.

As for routing, all the route segment translations get serialized into the HTML, because of this hidden endpoints should not be added to the astro-i18n (I might add some kind of server-only route segment translations feature later on).