Replies: 8 comments 8 replies
-
In my case, all of my locales translation is from database, so i don't think an opinionated file system based locales folder is good enough to cover some "more than basic" use cases. |
Beta Was this translation helpful? Give feedback.
-
@revskill10 you are right. Maybe will be better to define the languages and default language in But with this, you will be able to use: export async function getStaticProps({ i18n }) {
const { language } = i18n
const translations = await fetchTranslationsFromDB(language)
// ...
} with the following advantages:
|
Beta Was this translation helpful? Give feedback.
-
I'd love to see some sort of i18n support baked into next.js 🙌 Would this proposal support i18n of routes without an explicit locale prefix? eg: IMHO this is key for SEO and so far the only way to achieve it with next.js is using custom servers, which takes away from you many of the benefits of next.js |
Beta Was this translation helpful? Give feedback.
-
@javiercr I wrote a minimal configuration, but this can be extended to something like: export const config = {
i18n: {
locales: ['about'],
name: { es: 'acerca' }
}
} It would be a great idea if Next.js manage these i18n navigation internally with |
Beta Was this translation helpful? Give feedback.
-
We spend 3 month searching a good i18n option and didn't find a good one for next.js. All the options requires a feature sacrifice. Your idea of use rewrite looks nice. I think you can unify all the routing system in a config file, simplifiying it. And less attached with the idea of a future next.js 18n official lib. //next.config.js
{
...
routes: {
home: {
paths: ['/en','/es']
source: '/home/index.jsx',
},
product: {
paths: ['/en/products/:id','/es/productos/:id']
source: '/product/[id].jsx',
}
}
} With this concept you can use a lib like https://github.com/lukeed/rosetta or plain json files and generate your translated paths before the next.js app starts. |
Beta Was this translation helpful? Give feedback.
-
Hi all, just wanted to mention that we have successfully leveraged rewrites in You can find the source code here. |
Beta Was this translation helpful? Give feedback.
-
Check out the new i18n RFC and give us your feedback! 🚀 |
Beta Was this translation helpful? Give feedback.
-
Hi guys. I have just published a package for i18n next.js project SSG export, which called With Here is an example, if you have the pages defined like this:
This is the demo for this package: https://codesandbox.io/s/i18next-ssg-ozrpwx |
Beta Was this translation helpful? Give feedback.
-
Feature request
Is your feature request related to a problem? Please describe.
Currently, integrating i18n libraries with Next.js and working with Automatic Page Optimization (either SSG, or totally static) is quite cumbersome.
It would be great to have something simple and portable, compatible with
next export
.Using Dynamic routes requires a
/[lang]
folder to have each page as/en/example
. You have to write agetStaticPaths
andgetStaticProps
on each subpage to download the corresponding JSONs. Also, you need a language/locales context provider on the top of the page. And it gets even more complex with nested Dynamic routes and fallbacks. This alternative works in some projects but can be hellish in others.Using rewrites looks like a good alternative to simplify Dynamic routes. However, you can't do
next export
, becausenext export
does not have any special behavior for rewrites.Describe the solution you'd like
I understand that Next.js may give you the freedom to choose which i18n library to use. With that in mind, I propose to keep using any i18n library, but forcing them to work with Automatic Page Optimization by default. And simplifying the process.
/locales folder
Just as
/pages
folder is useful to directly define pages, it would be great to have a folder/locales
. Then you could define each supported language with their JSONs.With this structure, we should know what languages are supported in the app without any extra configuration. The default language could be renamed with some extra special character, like Dynamic routes do. Example of defining
en
as default language:Perhaps, it should allow some config on
next.config.js
for advanced things.Usage in pages
This would facilitate the use of many i18n libraries (or even without libraries) by forcing it to work with Automatic Static Optimization.
You could render the page content using the language on front;
/en
instead of/
, taking care of dynamic routes. For example, for/pages/[slug].js
the language is ignored in the slug:/en/some-slug
.During the navigation using
<Link />
orRouter.push
would be great to keep the current language on the front, unless you specify another one.Then each i18n library could manage the
locales
with their API, extending theuseI18n
hook to do the translations.Describe alternatives you've considered
I've considered
next export
to take account of rewrites. It would still not be a 100% friendly solution, but it would make it quite easy. I suppose there must be a reason behind it not being implemented.Additional context
A little more than 6 months ago I published next-translate trying to make i18n + Next.js easier after seeing its complexity, although I think that the solution I implemented is a bit "hacky". It would be nice if Next.js managed this just like it does with pages.
I hope this will help us find a simple and efficient solution.
Beta Was this translation helpful? Give feedback.
All reactions