[bug] i18next format cannot handle namespaces

[eikaramba]

Problem

the new inlang format lacks quite some features, e.g. namespaces and pluralisation etc. at least i didn't find anything like this.

because my server in my monorepo is using i18next i switched to i18next format but then compiling does not work.

vite v4.5.0 building SSR bundle for production...
❌ Encountered error in src/paraglide/messages.js
Missing semicolon. (19:44)
✓ 0 modules transformed.
✓ built in 112ms
[houdini] Missing semicolon. (19:44)
error during build:
RollupError: Missing semicolon. (19:44)
....

Expected behavior

No response

Reproduction

my inlang config

{
  "$schema": "https://inlang.com/schema/project-settings",
  "sourceLanguageTag": "en",
  "languageTags": ["en", "de"],
  "modules": [
	"https://cdn.jsdelivr.net/npm/@inlang/plugin-i18next@latest/dist/index.js"
  ],
  "plugin.inlang.i18next": {
    "pathPattern": {
		"index": "./translations/{languageTag}/index.json",
		"auth": "./translations/{languageTag}/auth.json"
	},
	"variableReferencePattern": ["{{", "}}"]
  }
}

my folder structure

the compiled messages.js file looks like this

import { languageTag } from "./runtime.js"
import * as en from "./messages/en.js"
import * as de from "./messages/de.js"


/**
 * This message has been compiled by [inlang paraglide](https://inlang.com/m/gerre34r/library-inlang-paraglideJs).
 *
 * - Don't edit the message's code. Use the [inlang ide extension](https://inlang.com/m/r7kp499g/app-inlang-ideExtension),
 *   the [web editor](https://inlang.com/m/tdozzpar/app-inlang-editor) instead, or edit the translation files manually.
 * 
 * - The params are NonNullable<unknown> because the inlang SDK does not provide information on the type of a param (yet).
 * 
 * 
 * @returns {string}
 */
export const index:again = () => {
	if (languageTag() === "de") return de.index:again()
	if (languageTag() === "en") return en.index:again()
	// if the language tag does not exist, return undefined
	// 
	// the missing translation lint rule catches errors like this in CI/CD
	// see https://inlang.com/m/4cxm3eqi/messageLintRule-inlang-missingTranslation
	// @ts-expect-error - for better DX treat a message function is always returning a string
	return undefined
}
....

Other information

No response

[eikaramba]

upon creating this ticket i saw the houdini output in the error console. this could mean that the houdini plugin actually is interfering here and not inlang. i will try to investigate this and if so, create an appropiate ticket for houdini. it is although always good to track these kind of incompatibilities in both repos.

[eikaramba]

i can confirm it was because houdini was trying to parse the paraglide output js files.

putting this into the houdini.config.js file fixed it:

const config = {
    "watchSchema": {....
....
    "exclude" : [ 
        "**/paraglide/**/*.js"<--
    ],
...

[eikaramba]

unfortunately i still have the problem that paraglide cannot handle the namespaces of i18next, see the following error on build

[felixhaeberle]

cc @samuelstroschein

[eikaramba]

btw if i switch to single file locales and only nest my json keys within that file to get some structure, i get the following error:

[samuelstroschein]

Hi @eikaramba,

Use _ to define structure e.g. auth_acceptTerms.

Paraglide JS does not need namespaces, namespaces via special syntax doesn't work in JS, and the upcoming Unicode MessageFormat 2.0 also won't allow dots (.). Multiple reasons why we are hesitant to loosen our restrictions.

pluralisation is not working yet.

That is correct. Expect support in the next weeks. If you need pluralization now, I recommend to await the 1.0 release.

[eikaramba]

not that i agree with the whole namespace topic, but your plugin does state to support namespaces --> https://inlang.com/m/3i8bor92/plugin-inlang-i18next

so the issue still persists or do you say your i18next plugin is currently not working resp. not compatible anymore?

[samuelstroschein]

so the issue still persists or do you say your i18next plugin is currently not working resp. not compatible anymore?

Neither. We will release #1585 which will resolve this issue. See my very in depth-reply here #1577 (comment)

[samuelstroschein]

I am closing this issue in favor of #1577