any updates? Faced with same problem when adding next-translate plugin to next.config

next-translate plugin overrides nextConfig

const nextTranslate = require('next-translate');
const nextConfig = {};

if (process.env.NODE_ENV !== 'development') {
    nextConfig.assetPrefix = '/appName';
    nextConfig.rewrites = async () => {
        return [
            { source: '/appName/_next/:path*', destination: '/_next/:path*' },
            { source: '/appName/static/:path*', destination: '/static/:path*' },
        ];
    };
}

module.exports = nextTranslate({ ...nextConfig });

This looks like a different error. We are supporting Next.js configuration and rewrites should work, but remember that adding the locales these rewrites should be adapted to the locales. You should add locales: false on you rewrites, otherwise is looking /en/_next/:path*. This is documented in the Next.js core documentation of rewrites: https://nextjs.org/docs/api-reference/next.config.js/rewrites#rewrites-with-i18n-support

Add next-translate as example

Documentation / Examples

• [x] Make sure the linting passes by running pnpm build && pnpm lint
• [x] The "examples guidelines" are followed from our contributing doc

Update i18n-routing.md

Add next-translate as example

@trungls1706 can you verify if is already solved in next-translate 2.0.0-canary.2? In order to use 2.0.0-canary.2, you need to install this devDependency: yarn add next-translate-plugin@2.0.0-canary.6 -D, because we moved our Webpack plugin to a package after improving it.

docs: https://github.com/aralroca/next-translate/blob/1382b03874bcacacabdd85fe4edfd44af431010c/docs/migration-guide-2.0.0.md

but isn't next.js moving to swc and trying to deprecate webpack in the long term? Would this path mean that we can not benefit of the advancements on the swc front?

We are enhancing the current plugin, instead of regex now we are parsing the files correctly. Currently, Turbopack is in alpha stage and has room for improvement, and it is likely that it will support Webpack plugins. If not, we are going to migrate in the future when Turbopack support it.

As a workaround, until the new functionality is implemented, if someone wishes to use the require method but have all chunks separated, they can utilize the webpack property provided below to resolve the issue. This sets up a webpack configuration that splits the chunks based on the namespace and locale, so that all chunks are separated and can be easily identified.

const namespaces = ['common', 'dynamic', 'home', 'more-examples', 'error'];
const locales = ['en', 'ca', 'es'];

module.exports = nextTranslate({
  webpack: (config) => {
    namespaces.forEach((namespace) => {
      locales.forEach((locale) => {
        config.optimization.splitChunks = {
          ...config.optimization.splitChunks,
          cacheGroups: {
            ...(config.optimization.splitChunks.cacheGroups || {}),
            [`${namespace}_${locale}`]: {
              test: new RegExp(`src/locales/${locale}/${namespace}.*$`),
              name: `${namespace}_${locale}`,
              chunks: 'all',
              enforce: true,
            },
          }
        }
      })
    })

    return config
  },
})

I'll keep that in mind, it's a good idea, thank you @lukevella . Maybe we can extend its use to:

string | () => string | () => Promise

@lukevella thanks for the comment, I like the idea of keeping things simple, and I had thought about it, although I don't like having two configurations for something similar. 🤔

I've seen many cases of people changing the structure of namespaces, either because they support many types of English (UK, US) but many translations are shared and it doesn't make sense to have them duplicated, or namespaces in other formats that are not json, etc... All of these cases should also benefit from having the namespace chunks separated, and that's why I propose the change above.

This issue was introduced because the SWC does not support dynamic import here now and by replacing it with require, it puts all the namespaces in the same chunk, making each page load all the translations instead of just the ones necessary for the page.

With this change, everything is solved; if you want to change the folder, the structure, load it from external resources with a fetch, etc.

@lukevella thanks for the comment, I like the idea of keeping things simple, and I had thought about it, although I don't like having two configurations for something similar. 🤔

I've seen many cases of people changing the structure of namespaces, either because they support many types of English (UK, US) but many translations are shared and it doesn't make sense to have them duplicated, or namespaces in other formats that are not json, etc... All of these cases should also benefit from having the namespace chunks separated, and that's why I propose the change above.

This issue was introduced because the SWC does not support dynamic import here now and by replacing it with require, it puts all the namespaces in the same chunk, making each page load all the translations instead of just the ones necessary for the page.

With this change, everything is solved; if you want to change the folder, the structure, load it from external resources with a fetch, etc.

Hello everyone 😊

We are considering making an important change to our library's configuration, where the loadLocaleFrom method currently returns a promise, but in the future it could also return a string. With this change, we would be able to use our own Webpack plugin to calculate all available languages and namespaces and place them in separate chunks, thereby improving the performance of the application. This plugin is already implemented in our library and has other functionalities in addition to this. Nevertheless, we will retain the option of returning a promise, to allow users to make fetch or implement their own loading logic.

However, before proceeding with this change, we would like to hear your opinion. How do you think this modification would affect your use of the library? Are there any specific use cases in which this modification could cause problems? Any other suggestions or comments on the matter?

We appreciate your time and welcome any feedback you may provide. ❤️

Bumps cookiejar from 2.1.3 to 2.1.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

https://github.com/all-contributors please add @marcesengel for code

Move plugin to next-translate-plugin package (#975)

• Move webpack plugin to package

• Add migration guide + add some improvements

• Fix tsc package.json script

• Update docs

@StLyn4 as a major contributor to version 2, I would appreciate it if you could give me some feedback on this change 😊

About this PR:

In version 2 of the next-translate library, we have made a significant change to the way the Webpack plugin is implemented. This change improves the library by solving many of the issues reported by users and makes it more powerful. However, it also means that two of the library's rules have been broken - it is now slightly larger and has a dependency on a specific version of the TypeScript parser.

To address this, we have split the library into two separate packages. The main package, next-translate, is used as before and handles all of the translation functionality. The new package, next-translate-plugin, is used specifically for the Webpack plugin and should only be used in the next.config.js file.

It's worth noting that by splitting the library into two packages and only using the next-translate-plugin in the next.config.js file, we are able to ensure that the extra kilobytes added by the TypeScript parser are only loaded during the build process and not included in the final bundle that is served to the client. This helps to keep the size of the final bundle as small as possible and improves the performance of your application. Additionally, by listing the next-translate-plugin will be installed as devDependency to reduce the extra kilobytes in the pipeline.

To migrate your project to use version 2, you will need to make the following changes:

• Install the next-translate-plugin package as a devDependency using yarn add -D next-translate-plugin or npm install --save-dev next-translate-plugin
• In your next.config.js file, replace require('next-translate') with require('next-translate-plugin')

Example of next.config.js:

const nextTranslate = require('next-translate-plugin')

module.exports = nextTranslate()

Thanks @StLyn4 . I changed to tsc again.

Fix tsc package.json script

Update docs

@StLyn4 as a major contributor to version 2, I would appreciate it if you could give me some feedback on this change 😊

In version 2 of the next-translate library, we have made a significant change to the way the Webpack plugin is implemented. This change improves the library by solving many of the issues reported by users and makes it more powerful. However, it also means that two of the library's rules have been broken - it is now slightly larger and has a dependency on a specific version of the TypeScript parser.

To address this, we have split the library into two separate packages. The main package, next-translate, is used as before and handles all of the translation functionality. The new package, next-translate-plugin, is used specifically for the Webpack plugin and should only be used in the next.config.js file.

It's worth noting that by splitting the library into two packages and only using the next-translate-plugin in the next.config.js file, we are able to ensure that the extra kilobytes added by the TypeScript parser are only loaded during the build process and not included in the final bundle that is served to the client. This helps to keep the size of the final bundle as small as possible and improves the performance of your application. Additionally, by listing the next-translate-plugin will be installed as devDependency to reduce the extra kilobytes in the pipeline.

To migrate your project to use version 2, you will need to make the following changes:

• Install the next-translate-plugin package as a devDependency using yarn add -D next-translate-plugin or npm install --save-dev next-translate-plugin
• In your next.config.js file, replace require('next-translate') with require('next-translate-plugin')

Example of next.config.js:

const nextTranslate = require('next-translate-plugin')

module.exports = nextTranslate()

Add migration guide + add some improvements