Disable translations keys nesting

[413n]

Is your feature request related to a problem? Please describe.

I wanted to migrate from lingui.js and currently I really like using flat messages (instead of creating translations keys, I just use the whole translation text). e.g. Instead of t('card.title') i would have t('Welcome to my website. This is a subtitle') (written in the default language) so that I don't have to spend time on making translations keys. I tried but it gave me an error because the '.' is used for nesting.

Describe the solution you'd like

Would it be possible to have a flag to disable this behavior? I'm really loving using next-intl so it would be amazing to have also this small feature. Unfortunately it's the last thing that's "blocking" me to migrate all over to next-intl.

Describe alternatives you've considered

I haven't any other solution than using translation keys but I would really like to continue with "explicit" translations.

[413n]

I looked a bit into the code and I have seen that making a change of "disabling nesting" is too much of refactoring, but i may have found a solution that could cover any case. Introducing a "nested char" or "nested divider" or whatever we can call it, that replaces the checks, splitting and everything of '.' with that config param (with default '.') so that for my use case I could just pass a param (to the provider and/or any createTranslations) like nestedChar="-----" and it would never split the key and I would be able to have a flat structure.

@amannn If you think this is something you would like to support I could also create a PR to help you with most of the work.

It's sad because I'm loving next-intl and its simplicity but I would also really like to have a flat structure 🥲

[amannn]

Hmm, the . separator is currently not supported in message keys also due to the TypeScript integration, where the separator can unfortunately not be customized.

This was also discussed in https://github.com/amannn/next-intl/issues/105 before.

[413n]

@amannn I see the problem. In my case I don't even need the namespace so I think I will fork the repo and remove the nesting logic completely. Unfortunately I will lose the lib updates but it is what it is I guess. Thanks for the reply.

[amannn]

Hmm, I see! You can btw also use https://www.npmjs.com/package/patch-package to avoid a fork and allow for easier updates.

I’ll keep an eye on this topic in case more people run into this!

[413n]

Thanks for the suggestion! I would certainly use that.

I will keep an eye for changes on this topic but for the moment I will close this. And thanks for the awesome package you are maintaining!

[damienmutt]

I ran into the same problem... I'm working on an extremely dynamic app where strings are used multiple times on different components so keeping strings-as-keys approach solves string search and avoid duplicities. next-translate lib has an option to disable key nesting but does not support app router + SSG so we're looking for another lib and next-intl is amazing at SSG but lacks of key nesting customization.

[sasweb]

+1

[fabpico]

Nested keys makes it hard to find which translations are being used. I expect translation keys being 1:1 copyable and findable in the code (ex. session.notLoggedIn). Alternative is to use underline (ex. session_notLoggedIn).