Release 11.1 introduces i18n limits that blocks us from upgrading.

[gtothesquare]

What version of Next.js are you using?

10.2.3 -> 11.1

What version of Node.js are you using?

14.x, 16.x

What browser are you using?

Chrome, Firefox

What operating system are you using?

macOS

How are you deploying your application?

next build and we then deploy it in our own infra. (Docker and kubernetes)

Describe the Bug

Currently we are using version 10 of next js. After the summer we planned to upgrade to 11. Then with the release of 11.1 we decided to jump directly to latest. We have a site that has 177 locales and it has been working fine (even on version 11.0). However, 11.1 introduced hard limit to 100 without explanation or warning or a workaround.

Here is the commit of the documentation https://github.com/vercel/next.js/pull/27542/files
And docs in prod
https://nextjs.org/docs/advanced-features/i18n-routing#limits-for-the-i18n-config

Expected Behavior

We can upgrade without issues given that it worked before.

To Reproduce

Create a next.config.js file with 100 more than i18n locales and then run next build.

[orneryd]

This is a blocker for us as well and will force us to find a suitable alternative.

We would also like to be able to define /change the locales at runtime instead of needing to be configured up-front. (for multi-tenancy purposes)

[irmakcosarsahna]

Same problem

[ijjk]

Hi, is unique content being generated for all 177 locales or are there so many locales being configured to ensure they are routed correctly?

Would ensuring the routing maps en-GB -> en help reduce the number of locales that need to be configured for your set-up?

Note: for each locale configured an additional version of each page is generated (unless using getStaticPaths and only the provided locale paths are generated)

[gtothesquare]

Hi, thanks for the response.

Yes is unique content. We have like 80+ languages where the site is translated to. However, each country has its own content in official local language and in English.. So, even if we have 30+ sites in English the content varies for each.

Not sure if I understand your note, however what are you saying is that for each local a "copy" of the site is generated in the respective locale. Maybe is easier to see the use case: here is the index of all the sites generated https://www.volvocars.com/intl/legal

One question is why the 100 limit ? Will be interesting to understand the reasoning behind it.

[ijjk]

I see thanks for the details, the reason we put this limit in place was from potential performance impacts from having boundless locales configured. We also want to make sure users aren't accidentally creating extra locales by auto-generating them so having a limit in place is good.

The performance impacts mentioned comes into play for a few places one is during build-time which is from generating a version of each page in so many locales which may not be a problem for smaller sites but in larger ones can slow things down a noticeable amount e.g. 20 pages with 175 locales needs to generate 3500 versions (potentially requiring data be fetched each time in getStaticProps), another place is with increasing the size of NEXT_DATA which is inlined in the initial HTML for every request this isn't too impactful as locales are very short but is a point to consider as this can potentially increase HTML size by 1 - 2KB, and another place is with rewrites, redirects, and headers in next.config.js as each route added in these is currently prefixed with every locale unless using locale: false which adds complexity to checking against these routes for every request.

We are looking into optimizing these items along with a few others to ensure the best performance. This limit is definitely flexible and we used the fact that Google translate has 108 languages as prior art for deciding on the initial limit. I converted this hard error for hitting the limit into a warning and also added documentation for the caveats of statically generating pages with i18n enabled here.

[JohnDeved]

Hi, is unique content being generated for all 177 locales or are there so many locales being configured to ensure they are routed correctly?

Would ensuring the routing maps en-GB -> en help reduce the number of locales that need to be configured for your set-up?

Note: for each locale configured an additional version of each page is generated (unless using getStaticPaths and only the provided locale paths are generated)

for my case that would help, content would not be different across different countries.
how could the routing be archived?
@ijjk

[gtothesquare]

@ijjk ahhh I see. Much appreciated. Thanks for the quick fix.

[JohnDeved]

@ijjk trying to do this as a workarround, sadly causes issues with links on the site, these will still redirect to "/en"

  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/:lang(\\w{2})-:country(\\w{2})/:path*',
          destination: '/:lang/:path*',
        },      
      ],
    }
  }

[ijjk]

@JohnDeved there isn't currently a workaround using rewrites to achieve the mentioned behavior it will need to be added in next-server itself, I re-opened #28410 to track this there

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.