Namespace support using js module imports

[minht11]

I know I know namespace support has been discussed a lot. I understand your reasoning about not wanting to support it because of namespace.key access is not valid JS identifier, complexity and so on, but dealing with large amount of translations is really huge hit to DX.

Currently it is possible to use plugin-inlang-json or plugin-inlang-i18next but then you lose on treeshaking benefits and vite/cli integrations of plugin-inlang-messageFormat.

So my proposal in addressing your concerns is to use JS module system, instead of merging namespaces into one object. For example let's say you have 3 namespaces common app and site. It would looks something like this:

import { m } from '$paraglide/messages'
import { m as mApp } from '$paraglide/messages/app'
import { m as siteApp } from '$paraglide/messages/site'

Now namespaces are all separate and treeshaking does not suffer. If you wanted to merge them for some sort of upload functionality you can use non valid js identifier like site@welcome to know in which namespace it belongs.

If user wants they can use path alias/auto imports to make it DX better but that is up to them.

I imagine implementing this in current plugin paraglide vite plugin would not be too hard, since you would just read more files and emit them, leaving heavy lifting to JS module imports.

[samuelstroschein]

Hmmm, admittedly cool proposal. Question: Is this still relevant after supporting "nesting" via opral/inlang-paraglide-js#285?

[samuelstroschein]

Btw i am 100% sure that we want to support compiling namespaces in Paraglide JS. Yet, alone for incremental adoption of Paraglide JS (use existing i18next translations and compile them with paraglide JS).

[minht11]

I am not that much familiar with i18next, but aren't nested keys and namespaces bit of separate features? One is multiple files other one same file with nested objects.

In my case I wouldn't want nesting support (I read your documentation on that 😄), tho because of reasons you mentioned option to opt in into that sort of behavior would be good.

As for namespaces if you wanted to access them from the same object while being treeshable, with some barrel file trickery it could be done

// messages.js
export * as app from './app.js'
export * as site from './site.js'

export const commonGreeting = () => {}

export const title = () => {}

so using it is exactly the same as nested object

import * as m from '$paraglie/messages'

m.commonGreeting()

m.app.home()

Rollup is able to optimize this into separate direct imports, as long as you only access namespaced imports statically and do not do reasigment or so on. See Rollup playground example.

[minht11]

I guess the same optimisation could be done for nested objects as well.

[samuelstroschein]

Insightful discussion. Namespaces in most i18n libraries are referenced via the key. For i18next, it's something:key.value where something is the namespace, see https://www.i18next.com/principles/namespaces. Same in next-intl where the dot notation is used Namespace.key.

Hence, supporting namespaces could all fall under opral/inlang-paraglide-js#285. Example usage could look like:

import * as m from "paraglide"


m['something:key.value']

Your idea with re-exports is also cool. I did some testing a while ago which yielded that some bundlers have problems tree-shaking re-exports. Hence, I refrained from going down that path. If rollup & co implemented tree-shaking for re-exports, might be worthwhile to explore though.

Btw, how messages are saved on disk is not a concern of Paraglide JS. Paraglide JS merely opens an inlang project and compiles it. Plugins for the inlang project define how messages are saved on disk. You could write a plugin that splits translations into separate files. That said, we learned the hard way that a bunch of files is the wrong direction. Long term, an inlang project will be a binary (sqlite) file (that can be "unpacked" and stored in git)

I'd say let's implement opral/inlang-paraglide-js#285 first and then see if further support for namespacing is required.