Add localization for next.js #122
Conversation
✅ Deploy Preview for dtp-stat ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
WalkthroughInternationalization (i18n) support is introduced and configured for a Next.js application. The changes add i18n configuration files, update dependencies to include i18n libraries, provide English and Russian translation resources, and refactor UI components and pages to use translation hooks and server-side translation loading. The application is now set up for multilingual support. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Browser
participant NextJS_Server
participant i18n_Library
participant Translation_Files
User->>Browser: Request page (with locale)
Browser->>NextJS_Server: HTTP request (locale info)
NextJS_Server->>i18n_Library: Load translations for locale
i18n_Library->>Translation_Files: Fetch translation JSON
Translation_Files-->>i18n_Library: Return translations
i18n_Library-->>NextJS_Server: Provide translations
NextJS_Server->>Browser: Rendered page with localized strings
Browser->>User: Display localized UI
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
next-i18next.config.js (1)
1-6: Consider adding fallback & detection flags explicitly
AddingfallbackLng: "ru"andlocaleDetection: falseprevents runtime warnings and unwanted redirects when a user’s browser provides an unsupported locale.i18n: { defaultLocale: "ru", locales: ["ru", "en"], + fallbackLng: "ru", + localeDetection: false, },public/locales/ru/common.json (1)
2-6: Minor: keep key order identical across locale files
Maintaining identical ordering eases diffing and spotting missing keys. Consider sorting bothenandrufiles alphabetically.src/pages/iframes/map.tsx (2)
4-5: Remove unused i18n import / variable
useTranslationis imported andconst { t } = useTranslation("common");is declared, buttis never referenced afterwards.
This will survive build-time lint suppression but is still dead code and a tiny chunk of unnecessary client bundle.-import { useTranslation } from "next-i18next"; ... - const { t } = useTranslation("common");Also applies to: 18-18
35-41: Type thegetServerSidePropscontext correctly for future safetyThe param is declared as a plain object
{ locale: string }, but Next.js already provides a typed context:GetServerSidePropsContext.
Switching to the official type avoids accidental shape mismatches and gives IDE help.-import type { GetServerSidePropsContext } from "next"; ... -export async function getServerSideProps({ locale }: { locale: string }) { +import type { GetServerSidePropsContext } from "next"; + +export async function getServerSideProps({ locale }: GetServerSidePropsContext) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (8)
next-i18next.config.js(1 hunks)next.config.mjs(1 hunks)package.json(2 hunks)public/locales/en/common.json(1 hunks)public/locales/ru/common.json(1 hunks)src/components/inherited-map/components/filter-panel/filter-panel-normal.js(4 hunks)src/pages/_app.tsx(2 hunks)src/pages/iframes/map.tsx(3 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/pages/iframes/map.tsx (1)
src/components/inherited-map/components/filter-panel/filter-panel-normal.js (1)
useTranslation(69-69)
🔇 Additional comments (2)
public/locales/en/common.json (1)
2-6: Sync with RU locale – missing future keys will break runtime look-ups
Ensure any future keys added to one locale are added to the other to avoid fallback to the default language.src/components/inherited-map/components/filter-panel/filter-panel-normal.js (1)
2-2: i18n integration looks correctThe new
useTranslationhook is wired up properly and the static text has been replaced with keys that will be resolved at runtime.
No functional or stylistic issues spotted in these lines. Nice and minimal change.Also applies to: 69-69, 88-88, 105-105
| i18n: { | ||
| defaultLocale: "ru", | ||
| locales: ["ru", "en"], | ||
| localeDetection: false, // отключить автоопределение по Accept-Language | ||
| localeCookie: { | ||
| name: "django_language", | ||
| httpOnly: false, | ||
| sameSite: false, // Django uses None, Next.js uses false for None | ||
| path: "/", | ||
| secure: false, // same as Django DEBUG mode | ||
| }, | ||
| }, |
There was a problem hiding this comment.
i18n.localeCookie is not supported by Next config
Next.js (≤ 13.5) validates next.config.js and fails on unknown keys.
localeCookie is not part of the documented i18n schema, so this block will either be ignored or throw during next build, breaking the pipeline.
If you need custom cookie handling, move that logic to middleware.ts or your own server layer and drop the unsupported field:
i18n: {
defaultLocale: "ru",
locales: ["ru", "en"],
localeDetection: false,
- localeCookie: {
- name: "django_language",
- httpOnly: false,
- sameSite: false,
- path: "/",
- secure: false,
- },
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| i18n: { | |
| defaultLocale: "ru", | |
| locales: ["ru", "en"], | |
| localeDetection: false, // отключить автоопределение по Accept-Language | |
| localeCookie: { | |
| name: "django_language", | |
| httpOnly: false, | |
| sameSite: false, // Django uses None, Next.js uses false for None | |
| path: "/", | |
| secure: false, // same as Django DEBUG mode | |
| }, | |
| }, | |
| i18n: { | |
| defaultLocale: "ru", | |
| locales: ["ru", "en"], | |
| localeDetection: false, // отключить автоопределение по Accept-Language | |
| }, |
🤖 Prompt for AI Agents
In next.config.mjs around lines 24 to 35, the i18n.localeCookie configuration is
not supported by Next.js and will cause build failures. Remove the entire
localeCookie block from the i18n config. If custom cookie handling is required,
implement that logic separately in middleware.ts or your server code instead of
placing it in next.config.mjs.
| "@prisma/client": "latest", | ||
| "@sentry/nextjs": "^6.17.9", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Avoid un-pinned "latest" for Prisma – introduces non-deterministic builds
Using "latest" for both @prisma/client and prisma means every fresh install can silently pick up a new major version and break your compiled client or schema workflow. Pin to an explicit semver range you’ve verified.
- "@prisma/client": "latest",
+ "@prisma/client": "^5.9.0",
…
- "prisma": "latest",
+ "prisma": "^5.9.0",Also applies to: 84-85
🏁 Script executed:
#!/bin/bash
# Verify use of un-pinned “latest” for Prisma packages
echo "@prisma/client version in dependencies:"
jq -r '.dependencies["@prisma/client"] // "not found"' package.json
echo "prisma version in devDependencies:"
jq -r '.devDependencies["prisma"] // "not found"' package.json
echo "All occurrences of “latest” in package.json:"
rg -n '"latest"' -n package.jsonLength of output: 512
Avoid un-pinned “latest” for Prisma – introduce deterministic, reproducible builds
Using "latest" for both @prisma/client and prisma means any fresh install can pull in a new major release and silently break your generated client or migration workflow. Pin each to an explicit, tested semver range.
Locations to update:
- package.json – Line 35:
"@prisma/client": "latest" - package.json – Line 84:
"prisma": "latest"
Suggested diff:
- "@prisma/client": "latest",
+ "@prisma/client": "^5.9.0",
…
- "prisma": "latest",
+ "prisma": "^5.9.0",Adjust ^5.9.0 to whichever patch/minor you’ve verified in your CI before merging.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@prisma/client": "latest", | |
| "@sentry/nextjs": "^6.17.9", | |
| // … in your "dependencies" section around line 35 … | |
| "@prisma/client": "^5.9.0", | |
| "@sentry/nextjs": "^6.17.9", | |
| // … other dependencies … | |
| // … in your "devDependencies" section around line 84 … | |
| "prisma": "^5.9.0", | |
| // … other devDependencies … |
🤖 Prompt for AI Agents
In package.json at lines 35 and 84, the dependencies "@prisma/client" and
"prisma" are set to "latest", which can cause unpredictable builds. Replace
"latest" with a specific semver version range, such as "^5.9.0" or the exact
version verified in your CI, to ensure deterministic and reproducible builds.
| "i18next": "^25.3.2", | ||
| "lru-cache": "^7.4.0", | ||
| "mobx": "^6.4.0", | ||
| "mobx-devtools-mst": "^0.9.30", | ||
| "mobx-react": "^7.3.0", | ||
| "mobx-state-tree": "^5.1.3", | ||
| "next": "^12.1.0", | ||
| "next-i18next": "^15.4.2", | ||
| "react": "^17.0.2", |
There was a problem hiding this comment.
Version incompatibility: next-i18next@15 requires Next ≥ 13.4 but project is on 12.1
next-i18next v15 moved to Next.js’ App Router and relies on features that do not exist in Next 12. Either:
- Upgrade
next(and React) to a compatible version, - or downgrade
next-i18nextto ≤ 13.x.
Failing to align these will surface at build time with Module not found/appDir errors.
🤖 Prompt for AI Agents
In package.json around lines 40 to 48, the version of next-i18next (15.4.2)
requires Next.js version 13.4 or higher, but the project currently uses Next
12.1. To fix this, either upgrade the next dependency to at least 13.4 along
with a compatible React version, or downgrade next-i18next to version 13.x or
lower to maintain compatibility and avoid build errors related to missing
modules or appDir features.
| import { appWithTranslation } from "next-i18next"; | ||
| import * as React from "react"; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pass the config object to appWithTranslation to ensure SSR parity
next-i18next looks for the config via CJS require, which fails in some ESM/monorepo setups and on Netlify. Importing and passing the config makes the linkage explicit.
-import { appWithTranslation } from "next-i18next";
+import { appWithTranslation } from "next-i18next";
+import nextI18NextConfig from "../../next-i18next.config.js";
…
-export default appWithTranslation(App);
+export default appWithTranslation(App, nextI18NextConfig);Also applies to: 28-28
I’ll verify whether a next-i18next.config file exists and inspect how appWithTranslation is currently being invoked.
🏁 Script executed:
#!/bin/bash
# Locate the i18next config file
fd next-i18next.config.* --max-depth 2
# Show the top of _app.tsx to see current imports and usage
sed -n '1,80p' src/pages/_app.tsxLength of output: 906
Import and pass the Next-i18next config to appWithTranslation
To ensure the config is resolved correctly in ESM/monorepo setups (and on Netlify), explicitly import your next-i18next.config.js and pass it into appWithTranslation.
• In src/pages/_app.tsx, add:
import nextI18NextConfig from "../../next-i18next.config.js";• Replace the default export on line 28:
- export default appWithTranslation(App);
+ export default appWithTranslation(App, nextI18NextConfig);This makes the CJS→ESM linkage explicit and avoids SSR parity issues.
🤖 Prompt for AI Agents
In src/pages/_app.tsx around lines 5 to 6, import the next-i18next configuration
explicitly by adding "import nextI18NextConfig from
'../../next-i18next.config.js';" and then update the default export on line 28
to pass this config into appWithTranslation, i.e., use appWithTranslation(MyApp,
nextI18NextConfig). This ensures proper config resolution in ESM/monorepo
environments and prevents SSR parity issues.
Описание общей логики: https://github.com/dtpstat/dtp-project/wiki/%D0%9B%D0%BE%D0%BA%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Summary by CodeRabbit
New Features
Chores