next-international V2

[QuiiBz]

next-international V1 has been released 6 months ago, and continuously improved to add more features and fix bugs.

There are however some recurring issues that can't be fixed without large breaking changes. Here's an overview of the main issues that I and the community noticed:

Chaining the middleware

#94, #187, #326, #341, #354

Translating not-found.tsx / error.tsx

#268, #288, #357

Testing

#178, #323, #348

Misc

#343

Documentation

The documentation can sometimes be hard to navigate around and find what we're looking for, especially around the available configuration options.

What about now?

I'll progressively update this issue to add solutions and possible improvements.

The focus points for the V2 are:

• Less boilerplate
• Sensible defaults, but greatly customizable
• Small, straightforward documentation
• Improve typechecking performance

How can I help?

Thank you so much for wanting to help us on this release! The first step will be to define exactly the things we need to tackle: we'll create issues for each of these task, and they'll all be under the 2.0 milestone.

Development will start soon in a separate branch. In the meantime, please share your experience, positive or negative, and things that you would like to see improved/added/fixed.

[fi5u]

Hi, thanks for this.

I'm in the process of moving my project over from next-localization to next-international. The only feature that I've noticed that I'm missing is the ability to return an object (or array) of translations. This useful for example when different languages have different requirements – it's something I've used extensively in next-localization.

I would imaging this feature being turned on from an option on useI18n / useScopedI18n.

By the way, I liked the simplicity of the documentation – it was very quick to get set up with it.

[gustaveWPM]

Hello, nice to know!
I was just having trouble here: #369 (comment)

I'm looking forward to hear about this V2. :)

[addlistener]

One thing I think we can do is better naming

I choose next-international because of its typescript native approach so a lot of features

• string literals
• splitting to multiple files
• guaranteeing all the types are the same
• overriding specific locales in the locale file

are already there as pure typescript code. No need to mess with configurations

If we have a better naming people can easily distinguish us from other libs. Check out the mess here (https://www.reddit.com/r/nextjs/comments/1c7xc6e/whats_your_i18n_lib_choice_with_nextjs_and_why/) Maybe sth like next-typescript-international?

[aurorascharff]

With nextjs 15 the headers() will need to be awaited! Error with next15:

Route "/[locale]/hjem" used headers().get('X-Next-Locale'). headers() should be awaited before using its value.

Maybe this can be added to the current version of next-international?

[addlistener]

Lazy loading of part of the locale strings. I guess it could be hacked in _app.tsx ? but a native support would be awesome.