Separate locale file for each module or multiple locale files

[3adel-bassiony]

Is your feature request related to a problem? Please describe. When using next-international in a big project with support for multiple languages it's hard to add all locales in one file, so I think it will be better if we have an option to divide the locale file into multiple locale files, so each feature or module can have a separate locale file.

Describe the solution you'd like Divide the locale files into multiple ts files so we can use a different locale file for each module

[QuiiBz]

Indeed, that's currently one of the limitation of next-international.

so we can use a different locale file for each module

Could you describe what "module" means in this context? Are you referring to a JavaScript module?

[irfancoder]

Could you describe what "module" means in this context? Are you referring to a JavaScript module?

I think he is referring to namespaces, like in i18next. In my previous work, we group the translations by route, and load the namespaces as necessary. I agree with OP this is a very much a needed feature +1

[3adel-bassiony]

@irfancoder Yes that's correct, I mean something like Namespaces in i18next @QuiiBz In this case I can divide the locale file into multiple files and work on them easily

[QuiiBz]

Thanks for the details! This feature certainly translates to APIs breaking change/new APIs to support this behaviour. I'll take a look at how other libraries have designed this feature, so feel free to also share your thoughts!

[olafurns7]

@QuiiBz just to give you a term of scope, in our use case we have ~7000 translation strings, in 14 locales :)

[chungweileong94]

This is kinda related to this issue/question #180.

Wrote a simple repo myself to test out this library, and this is what I found:

• Bundle size is not an issue on server component, but it might be an issue while loading huge locale files? 🤷
• Bundle size will be an issue on client component, all the locale files for the selected language will be loaded.

[aabmets]

@3adel-bassiony @QuiiBz Do you mean something like this? This works.

[QuiiBz]

@aabmets not really, because we want to only load the necessary locale file when needed. If you split your locales per page, you only want to load the locales for this page.

[aabmets]

@QuiiBz is it possible to define all localizations in one place (like the translations folder i have) and then implement this feature, that next-i11l would be able to only import a subset of these localization files with const t = await getI18n(['ns1', 'ns2'])?

[QuiiBz]

Not right now, but that's the goal of this issue, yes - but the API would probably be different, and in order to keep loading only the necessary file, you wouldn't have any index.ts which returns every locale file.

[Meierschlumpf]

Not sure about the performance, but maybe something like this would already be enough:

I've got full typesafety for the defined namespace. But of course I'm also creating a new instance of I18nClient whenever I call the useI18n method

[Meierschlumpf]

Nevermind it's more complicated :joy:

[gustaveWPM]

The more I think about it, the more I think we should be able to write the object of a locale file with both inlined translations and lazy-loaded fragments (which would be loaded just-in-time).

Unfortunately, I'm afraid this would cause problems on the client side...