-
|
Hi guys, |
Beta Was this translation helpful? Give feedback.
Replies: 33 comments 101 replies
-
|
For now a common solution is https://github.com/isaachinman/next-i18next. UPD (2021-10): |
Beta Was this translation helpful? Give feedback.
-
|
@isaachinman @ferlopezm94 Are you sure next-i18next still supports |
Beta Was this translation helpful? Give feedback.
-
|
@mvanaltvorst from what i've researched so far it seems like vercel doesn't plan on adding support for |
Beta Was this translation helpful? Give feedback.
-
|
No, |
Beta Was this translation helpful? Give feedback.
-
|
@kachkaev Mind updating the comment to reflect the current state of things? |
Beta Was this translation helpful? Give feedback.
-
|
Good point @isaachinman! Done. |
Beta Was this translation helpful? Give feedback.
-
|
@kachkaev thanks but I meant for serverless. I updated the title. |
Beta Was this translation helpful? Give feedback.
-
|
next-i18next now supports serverless apps via |
Beta Was this translation helpful? Give feedback.
-
|
Still struggling to find a clean and simple solution for this. I'm currently using next-i18next, but that requires a HOC with Then there is https://github.com/fwojciec/simple-i18n-example which uses dynamic routing and no custom server, but again requires a HOC that uses Another example is https://github.com/vinissimus/next-translate which allows for static rendering by using a separate folder Now that the nextjs team recommends static pages as a default, it would really be helpful to get their opinion, or even better, an example on how i18n should be implemented properly, as this really is a common requirement. |
Beta Was this translation helpful? Give feedback.
-
|
next-i18next now supports serverless apps via |
Beta Was this translation helpful? Give feedback.
-
|
It might be worth it to use https://github.com/fwojciec/simple-i18n-example as a base, but simply remove the browser language detection in I made a quick example for this: https://codesandbox.io/s/serverless-i18n-s0t6h For demonstration purpouses this now simply defaults to "en" at first, and there are several options to deal with this, for example:
One minor restriction of this approach is, that the language path is not freely configurable but sits on the beginning like: domain.com/language/page1 domain.com/language/page2, as else you would need to replicate this structure for each path. Also, I don't know yet how well this will scale if you have several languages and everything is included per page. |
Beta Was this translation helpful? Give feedback.
-
|
I'm working on an alternative which takes the approach of building a Next.js application per locale, and relies on webpack aliasing features to distribute the localized strings to each app. I made an example which deploys to ZEIT now: https://github.com/Janpot/nymus/tree/master/examples/next.js. The key elements are:
Disclaimer: I don't have it anywhere in production yet. This approach and code should only serve as inspiration. The |
Beta Was this translation helpful? Give feedback.
-
|
@Janpot Interesting, thank you for sharing this. I'm wondering, what was the main blocker or reason that made it more feasible for you to actually build separate applications per locale despite the added complexity? |
Beta Was this translation helpful? Give feedback.
-
|
@janus-reith For me, the main unresolved question/problem here is:
One approach could be to separate these out in one namespace per page and to make sure you only ship that namespace when you transfer messages. This should be relatively straightforward to build right now I guess with Another approach could be to make sure that messages are just normal ES6 modules with named exports and use them like any other code, then have the build system tree-shake away whatever is not used. And if you generate highly optimized components like
The fact that for this approach you'd need to be able alias a module per locale. Which in practice means, a different alias per basepath. I don't think there is any other way to do it currently with Next.js. It's easy to add custom webpack configuration for the whole application, but not if you want to do it more fine-grained. And if run as serverless, it should have no overhead at all whether it's 1 or 10 applications. |
Beta Was this translation helpful? Give feedback.
-
|
I created a new example, which uses static props to generate locale subpaths during build, supports namespaces and only bundles necessary strings for each page: https://codesandbox.io/s/nextjs-i18n-staticprops-92ebn Instead of API routes I just import them in the staticProps step and treeshaking works fine here so only the necessary ones are included. One thing missing is to add rewrites using the pattern described in #9081, so a path like "/de/someSubdir/test" would also work without a defined locale as "/someSubdir/test". Some note for testing Static Props seems to behave different during development than I expected. When I first tried to disable browser scripts to see the initial rendering I got a blank page and thought things didn't work out. But running a production build ( |
Beta Was this translation helpful? Give feedback.
-
|
👍 So that would basically be the first approach I mentioned in my previous comment. So some of the drawbacks I tried to solve with the other approach I describe are:
All these are fine tradeoffs of course, and your solution is good IMO. I just don't really think this is less complex. |
Beta Was this translation helpful? Give feedback.
-
|
@Janpot Right, let me rephrase that, what I had in mind was complex as in, is it possible to package it into one simple repo for beginners to check out and get started with, without the need for any existing infrastructure in place, just like most of the other nextjs example projects. |
Beta Was this translation helpful? Give feedback.
-
The folder I shared is independent of the rest of that repo. It works on its own, just like an example from the Next.js examples folder would. |
Beta Was this translation helpful? Give feedback.
-
|
Oh ok, sorry if I made false assumptions about your approach, will try it out. |
Beta Was this translation helpful? Give feedback.
-
|
I am currently using https://github.com/vinissimus/next-translate . It adds a build step, but beside that everything works fine and on serverless |
Beta Was this translation helpful? Give feedback.
-
|
BTW in the meantime I revised my approach to also optionally be able work with getInitialProps as I have some dynamic and some static pages. Furthermore I now have proper Server Side Language detection in place, without needing getInitalProps or a custom server by using an API route which detects the language header of the request. Next I use the new experimental rewrites, so all routes without a language in their path are redirected to the api endpoint, which detects the language, gets all the remaining path segments in the query and redirects it to the localized route. No unnecessary clientside redirect, no added build step and full static page support. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the query parameters: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanation, I had missing the trailing slash indeed, I get it now. I changed it to the following, to handle any depth link (see UnlyEd/next-right-now@799c72a): redirects() {
return [
{
// Redirect link with trailing slash to non-trailing slash (any depth), avoids 404 - See https://github.com/zeit/next.js/discussions/10651#discussioncomment-8270
source: '/:path*/',
destination: '/:path*',
permanent: process.env.APP_STAGE === 'production', // Do not use permanent redirect locally to avoid browser caching when working on it
},
];
},With your version, going to Your reasoning behind query parameters forwarding is good, it's a necessity and will be necessary for any non-trivial app. It may be related to my own implementation and not yours. I can't reproduce the behaviour on your sandbox. It's weird that it behaves differently locally and online. When you go to https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-awe87sbix.now.sh/terms, does it change to https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-awe87sbix.now.sh/fr/terms?lang=terms for you too? I wonder if it's not a "browser cache" related issue. |
Beta Was this translation helpful? Give feedback.
-
|
@janus-reith FYI your regex matches any "string that begins with" instead of matching for the exact word. See UnlyEd/next-right-now#42 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
@Vadorequest Yes I'm aware of that and I'm already searching for a solution as seen in the linked path-to-regexp issue mentioned inside the one you linked ( which I opened there) |
Beta Was this translation helpful? Give feedback.
-
|
@janus-reith Also, another thing to take into consideration: Basically, if an asset in The fix would be to ignore the Edit: Fixed by UnlyEd/next-right-now@fad1e2d |
Beta Was this translation helpful? Give feedback.
-
|
We've built a Next.js boilerplate with built-in i18n at https://github.com/UnlyEd/next-right-now, it uses i18next and react-i18next, also, it uses Locize provider for fetching translations, but that can be changed. In any way, it's a working implementation used in production that can also be used as a learning resource! |
Beta Was this translation helpful? Give feedback.
-
|
@Vadorequest Your boilerplate is using |
Beta Was this translation helpful? Give feedback.
-
|
@janus-reith It's just a matter of implementation. We built it when SSG with Next wasn't even a thing, so we used a SSR approach with universal language detection. It could be changed to client-side language detection fairly easily, and remove usage of Edit: I get what you mean, now that I'm a bit more acquitted with SSG. Working on UnlyEd/next-right-now#42 |
Beta Was this translation helpful? Give feedback.
-
|
With Next.js 9.3 you can use getStaticProps/getStaticPaths to easily generate localized versions of pages -- no external packages needed. Use dynamic routes to include the language code as part of the url (i.e. something like import React from "react";
import { NextPage, GetStaticProps } from "next";
import Home from "../../components/Home";
import { LanguageProvider } from "../../context/LanguageContext";
interface Props {
locale: Locale;
}
const HomePage: NextPage<Props> = ({ locale }) => {
return (
<LanguageProvider lang={locale}>
<Home />
</LanguageProvider>
);
};
export const getStaticProps: GetStaticProps = async ctx => {
return {
props: {
locale: ctx.params?.lang || "en"
}
};
};
export async function getStaticPaths() {
return {
paths: [{ params: { lang: "en" } }, { params: { lang: "pl" } }],
fallback: false
};
}
export default HomePage;For example implementation of If you need a more sophisticated approach with all the bells and whistles of a full-size localization library something like |
Beta Was this translation helpful? Give feedback.
-
|
@fwojciec This is what I did in the codesandbox demo I posted earlier. I took inspiration from your approach and made a static variant of it. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, forgot about your post earlier -- it's a good example. |
Beta Was this translation helpful? Give feedback.
-
Would it still work and be generated statically if I had the const HomePage: NextPage<Props> = ({ locale }) => {
const { setLanguage } = useContext(LanguageContext);
setLanguage(locale);
return (
<Home />
);
}; |
Beta Was this translation helpful? Give feedback.
-
|
@moaaz-bhnas Yes it would work fine. That's similar to how we do it with NRN https://github.com/UnlyEd/next-right-now |
Beta Was this translation helpful? Give feedback.
-
|
Ok. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
I just seen the same problem but when trying to achieve i18n work with SSG. Broke my head a little bit and came with a solution that wanted to share: This lib preloads Hope you find it useful as I do! |
Beta Was this translation helpful? Give feedback.
-
|
What's wrong with just having a [locale] directory and getting the locale from router.query? I'm new with this whole next.js thing and I want to understand what the downsides of this approach are. I see a lot of complex solution that make me wonder if I just have the wrong idea 😅 |
Beta Was this translation helpful? Give feedback.
-
|
@RWOverdijk That's basically what I did with UnlyEd/next-right-now#42 |
Beta Was this translation helpful? Give feedback.
-
|
Is there any official solution? |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion, it would be good if there was an official alternative solution to This would facilitate the use of many i18n libraries (or if you even want to do it without libraries) by forcing it to work with Automatic Static Optimization. Proposal/locales next.config.js export default {
i18n: {
languages: ['en', 'es', 'fr', 'it', 'de'],
defaultLanguage: 'en'
}
}/pages/index.js import useI18n from 'next/i18n'
export default function Home() {
const { language, locales } = useI18n()
const { common, home } = locales
// ...
}
export function getStaticProps({ i18n }) {
const { language, locales } = i18n
// ...
}
export const config = {
i18n: {
locales: ['home']
}
}So you can render the page content using the language on front And during the navigation using Then each i18n library could manage the |
Beta Was this translation helpful? Give feedback.
-
|
I strongly agree with the point cited by the @aralroca, above ... The only point I still miss about nextjs is a way to deal with multiple languages in a simple way, as everything else is. If there was a way to use multiple built-in or facilitated languages it would be wonderful. I didn't want to have a "build step", or a serverless function, or a custom server for this. Having locales and hooking i18n or nextTranslate useTranslation would be awesome. |
Beta Was this translation helpful? Give feedback.
-
|
@wilsonneto-dev If you want to use i18n with SSR (as your comment makes me suppose to), check out this implementation:
Doesn't rely on a custom server, no build step for this page (SSR, on-demand per request). I use a rewrite rule but that's not required (which detects the browser locale and redirects to e.g: /en), you could also detect the locale right from the getServerSideProps. |
Beta Was this translation helpful? Give feedback.
-
|
@Vadorequest I'm cheking the links, thanks so much!! |
Beta Was this translation helpful? Give feedback.
-
That's what i thought, which is why i mentioned "Not sure, so don't take my word for it". It's great to hear that you have plans for built in i18n |
Beta Was this translation helpful? Give feedback.
-
|
Okay so I have been looking into this from a pure SSR perspective (no SSG possible in my app anyways). I wanted to solve this without routes. My solution is not the best and I don't like it. It is not very performant I believe. But it works (for now, until nextjs supports it out of the box or someone finds a better solution) and it doesn't take a lot of code . Needed dependencies:
Note the lack of i18n.js import i18n from 'i18next'
import LanguageDetector from 'i18next-browser-languagedetector'
import { initReactI18next } from 'react-i18next'
const options = (lng = undefined) => ({
lng,
resources: {
en: { ...enNamespaces },
de: { ...deNamespaces }
},
// ...
})
let i18next
if (process.browser) {
i18next = i18n.use(LanguageDetector).use(initReactI18next).init(options())
} else {
i18next = (lng) => i18n.use(initReactI18next).init(options(lng)).catch(console.error)
}
export default i18nextNote the following:
_app.js import { universalLanguageDetect } from '@unly/universal-language-detector'
import i18next from './i18n'
const determineLanguage = (req) =>
universalLanguageDetect({
supportedLanguages: SUPPORTED_LANGUAGES,
fallbackLanguage: FALLBACK_LANGUAGE,
acceptLanguageHeader: req.headers['accept-language'],
errorHandler: console.error
})
MyApp.getInitialProps = async (props) => {
const language = determineLanguage(props.ctx.req)
await i18next(language)
return NextApp.getInitialProps(props)
}Note the following:
You can use namespaces, hoc, hook (basically all react-i18next features) with this approach. Again, this can be a band-aid until something better comes along. |
Beta Was this translation helpful? Give feedback.
-
|
Disclaimer: I'm the author of You could optimise your client side bundle, and have only one source of truth by using That's what I did with my i18nLocize implementation at https://github.com/UnlyEd/next-right-now/blob/v1-ssr-mst-aptd-gcms-lcz-sty/src/utils/i18nextLocize.ts#L327 Basically, I used See |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, your project surely was an inspiration for my minimal example! |
Beta Was this translation helpful? Give feedback.
-
|
@DevAtHeart Do you have some repo with this approach? |
Beta Was this translation helpful? Give feedback.
-
|
I had a tiny i18next binding library at https://github.com/jokester/i18next-react . It works with next.js without needing a custom server (but no effortless SSG). It has a nextjs example at examples/nextjs-serverless. In SSR part, the example used The code is actually quite simple, one may be able to do the same with Anyway hope it can be of some use for other people. |
Beta Was this translation helpful? Give feedback.
-
|
I just wrote a proposal to simplify i18n. Feedbacks are welcome! |
Beta Was this translation helpful? Give feedback.
-
|
I used lingui js in my next application and made a redirect to the default language if no language is First you need to install lingui js and configure it. Install dependencies yarn add --dev @lingui/cli@next @lingui/loader@next @lingui/macro@next @babel/core babel-core@bridge
yarn add @lingui/react@nextAdd lingui commands to package.json {
"scripts": {
"start": "lingui compile && next start",
"build": "lingui compile && next build",
"extract": "lingui extract --clean",
"compile": "lingui compile"
}
}Setup lingui via rc file {
"locales": ["de", "en"],
"sourceLocale": "de",
"format": "po",
"catalogs": [
{
"path": "src/locales/{locale}/messages",
"include": [
"<rootDir>/src",
],
"exclude": [
"*/node_modules/*",
"*/.next/*"
]
}
]
}Setup lingui in _app.tsx _app.tsx import { de, en } from "make-plural/plurals";
import { I18nProvider } from "@lingui/react";
import { setupI18n } from "@lingui/core";
export default function MyApp(
props: { lang: string; catalog: any } & AppProps
) {
const { Component, lang, pageProps, catalog } = props;
const i18n = React.useMemo(() => {
const i = setupI18n({
locale: lang,
localeData: {
de: { plurals: de },
en: { plurals: en },
},
messages: {
[lang]: props.catalog.messages,
},
});
i.activate(lang);
return i;
}, [catalog]);
return (
<I18nProvider i18n={i18n}>
<Component {...pageProps} />
</I18nProvider>
);
}
MyApp.getInitialProps = async (rootCtx) => {
let { lang = "de" } = rootCtx.ctx.query;
if (!lang.match(/^(de|en)$/i)) lang = "de";
// @ts-ignore
const catalog = await import(`@lingui/loader!../locales/${lang}/messages.po`);
const appProps = await App.getInitialProps(rootCtx);
return {
...appProps,
catalog,
lang,
};
};Redirect to default language if no language given: pages/index.tsx import { useEffect } from "react";
import Router from "next/router";
const defaultLanguage = "de"; // TODO: Maybe do browser detection
export default function Index() {
useEffect(() => {
Router.replace(`/${defaultLanguage}`);
}, []);
return null;
}Leverage next.js dynamic routing Add all pages under the .
├── [lang]
│ ├── page-a.tsx
│ ├── page-b.tsx
│ └── index.tsx
├── _app.tsx
├── _document.tsx
└── index.tsxAll lingui functions including macros work out of the box. I used lingui v3 here so I can leverage hooks. There are no custom routes or server needed and deployment on vercel works as well. Only the active language is imported when using ssr to reduce the bundle size. Hope that helps someone! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @michelalbers, can you show a fully functional example?? Because I have some doubts based on your example but looks awesome! Thx!! |
Beta Was this translation helpful? Give feedback.
-
|
Will do! Just give me some time :) |
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.
-
|
@isaachinman Does the beta work with SSR/SSG? |
Beta Was this translation helpful? Give feedback.
-
|
@carlreid It's SSR, yeah, as we still have a dependency on a server(less) runtime to do things like evaluate cookies and potentially 301, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @isaachinman, Thanks for providing a solution. I've been struggling with an implementation of localization in Next.js myself. Due a lot of options being available, I want to stay as close to the original repo as possible. I've tried running your example (with npm run dev), but am getting some errors:
I guess this is a dependency issue, but I can't seem to solve it. Could you have a quick look at it? *edit for styling mistakes |
Beta Was this translation helpful? Give feedback.
-
|
@pimvh If you believe you've found a genuine bug, please open an issue in the |
Beta Was this translation helpful? Give feedback.
-
|
I just added a serverless example with react-i18next. The code is available for review at #14978 The only dependencies needed apart from the default |
Beta Was this translation helpful? Give feedback.
-
|
Hi @cseas ! Is there any example that also includes logic for locale-based subpaths feature? |
Beta Was this translation helpful? Give feedback.
-
|
@Progressandro I made this example because I didn't want to use locale-based subpaths. But I think the rosetta based i18n example uses subpaths so that might be a useful reference. |
Beta Was this translation helpful? Give feedback.
-
|
Did anyone come up with a slim solution that does not require external plugins for this topic? I'd like to use:
My concerns are:
|
Beta Was this translation helpful? Give feedback.
-
I already thought about it 😸 |
Beta Was this translation helpful? Give feedback.
-
|
I released it under https://github.com/StarpTech/next-localization |
Beta Was this translation helpful? Give feedback.
-
Looks nice and clean, I will have a detailed look. From I think this could be improved, or is webpack/next somehow able to detect unused imports and drop them? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, this is just an example. You can lazy load the language on the client-side or in server hooks at build time. |
Beta Was this translation helpful? Give feedback.
-
|
@StarpTech thanks for the amazing library! Do you happen to have an example of multiple namespaces? I didnt really get how to do that with different providers. Should I create an [name].json file for every provider. So provider for page1.json and page2.json for example. |
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.
-
|
Next.js Internationalized Routing (i18n) has been released in Next.js 10 one month ago. Check out the Next.js 10 blog post and the official i18n documentation to learn more. |
Beta Was this translation helpful? Give feedback.
-
|
Hi! Did you manage to make it work only using the i18n capability of next.js? I've tried it and it works well for every locale except for the default one. It returns 404 for all the subpages unless I add the default locale suffix (which would mess with the SEO of the page). Any help would be appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @lfades, what would you recommend for internationalisation for statically generated websites? |
Beta Was this translation helpful? Give feedback.
-
|
@mvanaltvorst Next.js i18n works for that case. |
Beta Was this translation helpful? Give feedback.
-
|
We are transferring our website https://dewesoft.com to Next.js where we have the same need of setting up translated static and dynamic routes. It's important for the SEO to have translated URLs. And of course we would like to keep the existing URL structure! Static routesDynanic routesthis can translate into:
Is this possible to setup? |
Beta Was this translation helpful? Give feedback.
-
|
You can add a redirect, or a 404. All this information is available in the docs. |
Beta Was this translation helpful? Give feedback.
-
|
@isaachinman sure I understand that and was reading that as well. But is this how Next.js will handle URL translation situations? That basically mean with dynamic blog or product routes you need to maintain hundreds of rewrites and redirects. |
Beta Was this translation helpful? Give feedback.
-
|
There is a general lack of guidance regarding this particular feature. I've been using Next.js for several years and this question regularly pops. Indeed, the docs don't explicitly cover this use case, and it's usually up to the author to find a "creative" solution. Next.js doesn't cover i18n greatly, there is very basic support and it's also fairly recent. (about a year?) I wouldn't know exactly how to build such feature if I had to implement it today. Dealing with static paths looks like a lot of manual config (path by path), and dealing with dynamic urls seems even more complicated. |
Beta Was this translation helpful? Give feedback.
-
|
@PrimozRome Yes, you are right for those generated URLs you should write another rewrites config too. Like: It looks a little bit dirty but if you separate your language files, it will be good |
Beta Was this translation helpful? Give feedback.
-
|
@mehmetpekcan I don't want to go rewrites way. Manging 9 languages with static/dynamic routes and rewrites seems something very sensible to human errors and painful to maintain... It is just not a good solution for larger sides. I see it working for a site with couple of routes, but if you have many of them and 9 languages it won't work on a long run. I found this package https://github.com/hozana/next-translate-routes which seems to solve this problem, but I need to test it. I will get back with comments when I have more information on it. |
Beta Was this translation helpful? Give feedback.
-
|
My preferred way to translate pages (marketing site context) while having different localized slugs is to use a CMS (I recommend Sanity.io) and Next.js with optional catch all routes + This approach will allow you to change content faster, and have everything translated including slugs while delivering a great user experience to your users since all pages will be built upfront of users' requests. |
Beta Was this translation helpful? Give feedback.
-
|
@jferrettiboke can you tell more about this implementation or would you be willing do discuss this privately? We do use content CMS (DatoCMS) where we define slugs per language. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@PrimozRome I have created an i18n dynamic routing example, and sent a PR to Next.js just in case others are interested to see how it works. Let me know whatever! |
Beta Was this translation helpful? Give feedback.
-
|
This CMS-slug-driven pattern is also one I have implemented across several large orgs. Simply fetch all pages by locale inside It should be noted that if you have hundreds or thousands of pages, a cache layer will help immensely with build times. |
Beta Was this translation helpful? Give feedback.
-
|
We just released a solution that supports serverless (and localized) URLs out of the box - looking for more community feedback! https://github.com/Avansai/next-multilingual |
Beta Was this translation helpful? Give feedback.
-
@isaachinman not sure why you think it's an anti-pattern? if you want to do dynamic locale detection and SSR, you need to do this and this is the only way you can use the
I think one of our core features is the localized URLs but also the modular string management which I haven't found in any React-based library before.
@PrimozRome it took us +8 months to get what we believe is the best solution (so far) to localized routes. If you use configuration to do this, the challenge will be when you do the translation. This is why our solution has the same files for both strings and routes which is localization-friendly.
We haven't tested dynamic routes yet, but it is one of the features we want to support (and document) in the near future. I am not sure if I understand the example you provided but please open an issue if you would like us to look at a specific example. Normally if your localized URL segment is from a blog, the blog should be responsible for the localization process. |
Beta Was this translation helpful? Give feedback.
-
Because you are delaying the rendering of a page, which presumably could be done at build time, just to be able to negotiate an accept lang header. This is not using the NextJs framework in the way it is intended to be used. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't call using |
Beta Was this translation helpful? Give feedback.
-
|
Using SSR only to perform header negotiation is an antipattern, unless you need to render different content on the same route. Latency added from SSR is entirely unknown and will vary wildly based on any given project. Latency added from a standalone lambda checking headers is stable and will not change if your source code changes. |
Beta Was this translation helpful? Give feedback.
-
Well, this is exactly what is going on here. Content will be served in the language most suited for the user, without using a redirect.
I am coming from a PHP background nothing is statically generated and nobody worries about this - in fact, performance can match Next.js' if you know what you are doing. I literally just ran 2 Lighthouse tests and the First Contentful paint was 0.9s on a static page and 0.5 on the homepage 🤷 Also if you want to worry about SSR latency, you could do the same for the network, the shared infrastructure your app is being hosted on, etc.
Not too sure I understand what you mean here - there are many ways to host Next.js to make it performant. On our end, our solution works out of the box on both Vercel and Netlify. Lighthouse scores seem pretty good, so I would definitely not call what we put in place an "anti-pattern" but if you have ideas on how to make our solution even better let us know :) |
Beta Was this translation helpful? Give feedback.
and others
Next.js Internationalized Routing (i18n) has been released in Next.js 10 one month ago. Check out the Next.js 10 blog post and the official i18n documentation to learn more.