-
Notifications
You must be signed in to change notification settings - Fork 0
Add localization for next.js #123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughInternationalization (i18n) support is introduced to the Next.js application. This includes configuration updates, new locale files for Russian and English, dependency additions for i18n libraries, and code changes to integrate translation hooks and server-side translation loading in relevant components and pages. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Browser
participant NextJS_App
participant next-i18next
participant Locale_Files
User->>Browser: Requests page (with locale)
Browser->>NextJS_App: Sends request (locale info)
NextJS_App->>next-i18next: Calls serverSideTranslations(locale)
next-i18next->>Locale_Files: Loads translation JSON for locale
Locale_Files-->>next-i18next: Returns translations
next-i18next-->>NextJS_App: Provides translation props
NextJS_App-->>Browser: Renders page with translations
Browser-->>User: Displays 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. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
❌ Deploy Preview for dtp-stat failed. Why did it fail? →
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (2)
public/locales/en/common.json (1)
1-7: Check key parity and punctuation against the Russian source
Before merging, make sure the English file contains exactly the same keys (and any required interpolation placeholders) aspublic/locales/ru/common.json; otherwise run-time lookups will fall back to Russian or break. Also verify the trailing colon in"forPeriod"matches the Russian variant so UI punctuation stays consistent.src/pages/iframes/map.tsx (1)
35-41: Type thegetServerSidePropssignature to avoid drift
Using a hand-rolled{ locale: string }parameter ignores the rest ofGetServerSidePropsContext, which can lead to unsound code if you ever access other properties. Prefer the official type:-import { serverSideTranslations } from "next-i18next/serverSideTranslations"; +import { serverSideTranslations } from "next-i18next/serverSideTranslations"; +import type { GetServerSideProps } from "next"; -export async function getServerSideProps({ locale }: { locale: string }) { +export const getServerSideProps: GetServerSideProps = async ({ locale }) => { return { props: { ...(await serverSideTranslations(locale ?? "ru", ["common"])), }, }; -} +};
📜 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 (4)
package.json (1)
40-50: Check peer-compatibility of newly added i18n packages with Next 12 / React 17
next-i18next@15is published for recent Next versions (≥12 is fine) but its peer map expects React ≥17.0.2 AND requiresi18next@>=21. The pinned versions here satisfy that, but please confirm in lockfile/CI that no peer warnings are produced and bundle size impact is acceptable.public/locales/ru/common.json (1)
1-7: LGTM – keys are present and match the EN file
No issues spotted with the Russian translation stub.src/pages/_app.tsx (1)
5-6: Type-safety: export ofappWithTranslation(App)loses the customerrprop
appWithTranslationreturnsNextPage<AppProps>and doesn’t include{ err: Error }. If you rely on theerrprop elsewhere, add an explicit type to preserve it:-const App: React.VoidFunctionComponent<AppProps & { err: Error }> = ({ +const App: React.FC<AppProps & { err: Error }> = ({ … }); -export default appWithTranslation(App); +export default appWithTranslation(App) as unknown as React.FC< + AppProps & { err: Error } +>;At a minimum run
tscto ensure no implicit-any errors surface.Also applies to: 28-28
src/components/inherited-map/components/filter-panel/filter-panel-normal.js (1)
69-70: LGTM – localisation hook correctly replaces hard-coded strings
The component now pullsfiltersandhidefrom the “common” namespace; import path and namespace are correct.Also applies to: 88-89, 105-106
| module.exports = { | ||
| i18n: { | ||
| defaultLocale: "ru", | ||
| locales: ["ru", "en"], | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Include fallbackLng (and optionally disable locale detection) for safer runtime behaviour
If a user requests an unsupported locale the app will currently throw. Add an explicit fallback to avoid 500s and keep SSR predictable:
module.exports = {
i18n: {
defaultLocale: "ru",
locales: ["ru", "en"],
+ fallbackLng: "ru",
+ // localeDetection: false, // uncomment if you rely on Django cookie instead
},
};📝 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.
| module.exports = { | |
| i18n: { | |
| defaultLocale: "ru", | |
| locales: ["ru", "en"], | |
| }, | |
| }; | |
| module.exports = { | |
| i18n: { | |
| defaultLocale: "ru", | |
| locales: ["ru", "en"], | |
| fallbackLng: "ru", | |
| // localeDetection: false, // uncomment if you rely on Django cookie instead | |
| }, | |
| }; |
🤖 Prompt for AI Agents
In next-i18next.config.js at lines 1 to 6, the configuration lacks a fallbackLng
setting, which can cause runtime errors if an unsupported locale is requested.
Add a fallbackLng property inside the i18n object, setting it to "ru" to ensure
the app falls back to Russian when an unsupported locale is used. Optionally,
add localeDetection: false to disable automatic locale detection for more
predictable SSR behavior.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
🧩 Analysis chain
localeCookie is not a recognised Next.js i18n option
Next.js (≤ 13.5) supports locales, defaultLocale, domains, and localeDetection; there is no localeCookie field. Unknown keys are silently ignored, so the custom cookie settings here will have no effect and may mislead future maintainers.
If cookie control is required, handle it at application level (e.g. setCookie on locale switch) or confirm that your Next.js version introduces localeCookie.
i18n: {
defaultLocale: "ru",
locales: ["ru", "en"],
localeDetection: false,
- localeCookie: { … }
},🏁 Script executed:
#!/bin/bash
# Locate Next.js version in package.json
echo "Searching for Next.js dependency versions in package.json..."
grep -R -C2 '"next"\s*:' -n package.json || echo "No Next.js entry found in package.json."Length of output: 327
Remove unsupported localeCookie option from i18n
The localeCookie field isn’t recognized by Next.js 12.1.0 (or any Next.js release up through v13); Next.js only supports locales, defaultLocale, domains and localeDetection under i18n. Unknown properties are silently ignored, so this block has no effect and may mislead future maintainers. If you need to control the locale cookie, do so in application code (e.g. call setCookie when handling a locale switch).
Please remove the following lines in next.config.mjs:
i18n: {
defaultLocale: "ru",
locales: ["ru", "en"],
localeDetection: false,
- 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
- },
},📝 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 configuration includes an
unsupported localeCookie option that Next.js does not recognize and silently
ignores. Remove the entire localeCookie block from the i18n configuration to
avoid confusion and ensure only supported options remain. Manage locale cookies
separately in application code if needed.
| "@fortawesome/free-solid-svg-icons": "^6.0.0", | ||
| "@fortawesome/react-fontawesome": "^0.1.17", | ||
| "@prisma/client": "^3.9.2", | ||
| "@prisma/client": "latest", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid "latest" – pin Prisma packages to a fixed semver range
Using the string "latest" for both @prisma/client and prisma makes every install potentially pull a different version, which breaks reproducibility and can introduce breaking changes without notice (Prisma frequently ships breaking feature flags). Replace it with an explicit semver (e.g. "^5.7.0" or whatever version you have validated in CI).
- "@prisma/client": "latest",
+ "@prisma/client": "^5.7.0",
…
- "prisma": "latest",
+ "prisma": "^5.7.0",Also applies to: 84-84
🤖 Prompt for AI Agents
In package.json at line 35 and also line 84, replace the version string "latest"
for both "@prisma/client" and "prisma" dependencies with a fixed semver range
like "^5.7.0" or the specific version you have tested in CI to ensure consistent
and reproducible installs without unexpected breaking changes.
| import { NextPage } from "next"; | ||
| import dynamic from "next/dynamic"; | ||
| import Script from "next/script"; | ||
| import { useTranslation } from "next-i18next"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Remove unused t variable (will trip ESLint)
const { t } = useTranslation("common"); is never referenced, so the build will fail with no-unused-vars.
Either delete the import and the destructuring altogether or keep only the hook call:
-import { useTranslation } from "next-i18next";
-...
- const { t } = useTranslation("common");
+// Translation resources are still loaded through getServerSideProps;
+// the hook call isn't required here.Also applies to: 18-18
🤖 Prompt for AI Agents
In src/pages/iframes/map.tsx at lines 4 and 18, the variable `t` destructured
from `useTranslation("common")` is not used, causing ESLint no-unused-vars
errors. Remove the destructuring of `t` from the hook call or remove the entire
import if not needed. If the hook call is required for side effects, keep only
the hook call without destructuring `t`.
|
@triklozoid рекомендации от кролика актуальны? |
df71dc6 to
d8776bf
Compare
Описание общей логики: 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