Migrate from `next-intl` to `i18next` by SkandarS0 · Pull Request #405 · FindMalek/dukkani

SkandarS0 · 2026-04-16T21:28:25Z

🌐 Migrate from `next-intl` to `i18next`

This PR replaces next-intl with i18next (via next-i18next) as the i18n backbone across all apps and packages. Below is a comprehensive breakdown of every aspect of the new setup.

📁 How Translations Are Added

Translations live inside packages/i18n and are organised by app and locale:

packages/i18n/src/
├── apps/
│   ├── dashboard/locales/{ar,en,fr}/pages.json
│   ├── storefront/locales/{ar,en,fr}/pages.json
│   └── web/locales/{ar,en,fr}/home.json
└── shared/locales/{ar,en,fr}/ui.json

Each JSON file maps to a namespace (e.g. pages, home, ui). To add a new translation:

Add the key/value to the relevant JSON file in every locale folder (or run the extract command and fill in the gaps).
Re-run type generation for the affected app (see below).

French (fr) is the source of truth for type generation — always keep it complete.

🔠 How Type Generation Works

Each app/scope has three auto-managed files produced by i18next-cli:

File	Purpose
`resources.ts`	Typed interface mirroring the JSON structure — do not edit manually
`types.d.ts`	Augments the `i18next` module so the `t()` function is fully type-safe
`i18next.config.ts`	Config for `i18next-cli`: locales, extraction globs, type output paths

App-level types.d.ts files merge the app's own resources with the shared resources:

// dashboard/types.d.ts (auto-generated, editable)
import UiResources from "../../shared/resources.ts";
import Resources from "./resources.ts";

declare module "i18next" {
  interface CustomTypeOptions {
    enableSelector: false;
    defaultNS: "pages";
    resources: Resources & UiResources; // app namespaces + shared
    strictKeyChecks: true;
  }
}

The shared module itself has defaultNS: false because it carries no default namespace — it's always consumed through namespace-explicit calls.

Run type generation per scope or all at once:

pnpm turbo i18n:types                          # all apps + shared
pnpm --filter `@dukkani/i18n` dashboard:types    # dashboard only
pnpm --filter `@dukkani/i18n` web:types          # web only
pnpm --filter `@dukkani/i18n` storefront:types   # storefront only
pnpm --filter `@dukkani/i18n` shared:types       # shared ui only

⚡ Caching via Turborepo

Each type generation task is wired with precise inputs so Turborepo only reruns it when the relevant files actually change:

"i18n:types": {
  "dependsOn": [
    "@dukkani/i18n#dashboard:types",
    "@dukkani/i18n#web:types",
    "@dukkani/i18n#storefront:types",
    "@dukkani/i18n#shared:types"
  ]
},
"@dukkani/i18n#shared:types": {
  "inputs": ["src/shared/locales/fr/*.json"]
},
"@dukkani/i18n#dashboard:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/dashboard/**"]
},
"@dukkani/i18n#web:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/web/**"]
},
"@dukkani/i18n#storefront:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/storefront/**"]
}

shared:types is always a prerequisite and always runs first.
If you only touch src/apps/dashboard/locales, only dashboard:types (+ shared:types) re-executes — storefront and web tasks stay cached.
The i18n:status tasks additionally track the consuming app's own source files as inputs (e.g. $TURBO_ROOT$/apps/dashboard/src/**), so a missing translation key used in application code will also bust the cache.
The shared:status task tracks packages/ui/src/** as input, because the shared namespace is extracted from the @dukkani/ui package source.

🪝 `useT` vs `getT`

	`useT`	`getT`
Import	`next-i18next/client`	`next-i18next/server`
Where to use	Client Components (`"use client"`)	Server Components (async)
API style	React hook — synchronous	Async function — `await`-able

// ✅ Client Component
"use client";
import { useT } from "next-i18next/client";

export function MyClientComponent() {
  const { t } = useT("pages", { keyPrefix: "dashboard.overview" });
  return <h1>{t("title")}</h1>;
}

// ✅ Server Component
import { getT } from "next-i18next/server";

export async function MyServerComponent() {
  const { t } = await getT("home", { keyPrefix: "header" });
  return <h1>{t("brandName")}</h1>;
}

🔗 More Shared Translations (e.g. a new `models.json`)

The shared namespace lives in packages/i18n/src/shared/locales/ and is flat — there is no sub-folder per package. The resourceLoader in each app's instance.ts automatically routes any unknown namespace there:

resourceLoader: async (lng, ns) => {
  if (!I18nextDashboardNamespaces.includes(ns)) {
    // Falls back to shared/locales/{lng}/{ns}.json
    return (await import(`../../shared/locales/${lng}/${ns}.json`)).default;
  }
  return (await import(`./locales/${lng}/${ns}.json`)).default;
},

The current shared namespace is ui — it includes password/image field labels, the language switcher, and all supported currency names with their regions.

To add a new shared namespace (e.g. models.json with translated entity labels shared across the dashboard and storefront):

Create packages/i18n/src/shared/locales/{ar,en,fr}/models.json
Add "models" to the ns array in the instance.ts of every app that needs it
Run pnpm --filter @dukkani/i18n shared:types to regenerate shared/resources.ts
Regenerate types for the affected apps

✨ i18next Features

Pluralization

Use the _one / _other suffix convention directly in JSON — i18next picks the right form based on count:

{
  "itemsCount_one": "{{count}} item",
  "itemsCount_other": "{{count}} items"
}

t("itemsCount", { count: 1 }) // → "1 item"
t("itemsCount", { count: 5 }) // → "5 items"

Interpolation

Embed dynamic values with {{variableName}} syntax directly in the JSON files:

{
  "viewOrder": "View order {{id}}",
  "instructions": "Send /link {{code}} to the bot if you are not redirected."
}

t("viewOrder", { id: "ORD-123" }) // → "View order ORD-123"

Context

Append _contextValue variants in JSON to select context-specific strings:

{
  "status_pending": "Waiting for confirmation",
  "status_confirmed": "Confirmed",
  "status_cancelled": "Cancelled"
}

t("status", { context: order.status }) // → "Confirmed"

Number, Date & Currency Formatting

The shared library exposes typed, locale-aware native Intl helpers:

import { formatCurrencyFn, formatDateFn, DateTimeFormattingOptions } from "@dukkani/i18n";

const formatPrice = formatCurrencyFn("fr", "TND");
formatPrice(1234.56) // → "1 234,56 TND"

const formatDate = formatDateFn("ar", DateTimeFormattingOptions.date.long);
formatDate(new Date()) // → "١ يناير ٢٠٢٥"

🧩 Dedicated Type Generation per App — Modularity

Every app owns its complete i18n stack in isolation, and the shared layer is its own independent module:

packages/i18n/src/
├── apps/
│   └── dashboard/
│       ├── i18next.config.ts   ← CLI config: locales, extract globs, type output
│       ├── instance.ts         ← Runtime config: supportedLngs, fallbackLng, resourceLoader
│       ├── resources.ts        ← Auto-generated typed interface (do not edit)
│       └── types.d.ts          ← Module augmentation (auto-generated, editable)
└── shared/
    ├── i18next.config.ts       ← CLI config for the shared ui namespace
    ├── resources.ts            ← Auto-generated shared typed interface (do not edit)
    ├── types.d.ts              ← Module augmentation with defaultNS: false
    ├── locales/{ar,en,fr}/
    │   └── ui.json
    └── lib/
        ├── currency.ts
        ├── date.ts
        └── language.ts

Benefits:

Dashboard types don't pollute storefront or web types.
Each app declares only its own namespaces + the shared ui namespace.
The shared module is generated independently and versioned separately from any single app.
Onboarding a new app means duplicating an apps/ sub-folder, updating the config, and running type generation.

🔑 `returnObjects` & `keyPrefix`

`keyPrefix`

Scopes the t function to a sub-tree of the namespace so call sites stay concise:

// Without keyPrefix — verbose
const { t } = useT("pages");
t("auth.emailSignIn.email.label") // "Email address"

// With keyPrefix — clean
const { t } = useT("pages", { keyPrefix: "auth.emailSignIn" });
t("email.label") // "Email address"

`returnObjects`

Returns the entire object or array at a translation key instead of a string:

// JSON: "benefits": ["Save hours of phone calls", "Eliminate fake orders", "Verify address accuracy"]
const benefits = t("benefits", { returnObjects: true }); // → string[]
benefits.map(b => <li>{b}</li>)

// JSON: "steps": { "createStore": { "title": "1. Create Store", "descriptionMobile": "Setup in 5 minutes." } }
const step = t("steps.createStore", { returnObjects: true });
// → { title: string, descriptionMobile: string, descriptionDesktop: string }

Both options compose naturally with each other:

const { t } = useT("home", { keyPrefix: "body.features.items" });
const feature = t("telegramAlerts", { returnObjects: true });
// → { title: string, descriptionMobile: string, descriptionDesktop: string }

…o configuration

…onProvider

…cific locale files

…attern for French translations

…y instead

…odularity with shared namespaces

…t as the primary language for the cli

SkandarS0 · 2026-04-17T07:34:20Z

@coderabbitai, the modularity of the shared locales has changes, update the description u did above

coderabbitai · 2026-04-17T07:35:59Z

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

Let me inspect the current state of the shared locales structure.

🏁 Script executed:

#!/bin/bash
echo "===SHARED LOCALES STRUCTURE==="
find . -path "*/packages/i18n/src/shared*" -not -path "*/node_modules/*" | sort

echo "===SHARED LOCALES FR (source of truth)==="
find . -path "*/packages/i18n/src/shared/locales*" -not -path "*/node_modules/*" | sort

echo "===SHARED fr JSON files==="
find . -path "*/packages/i18n/src/shared/locales/fr*" -name "*.json" -not -path "*/node_modules/*" -exec echo "FILE: {}" \; -exec cat {} \;

echo "===SHARED en JSON files==="
find . -path "*/packages/i18n/src/shared/locales/en*" -name "*.json" -not -path "*/node_modules/*" -exec echo "FILE: {}" \; -exec cat {} \;

echo "===SHARED ar JSON files==="
find . -path "*/packages/i18n/src/shared/locales/ar*" -name "*.json" -not -path "*/node_modules/*" -exec echo "FILE: {}" \; -exec cat {} \;

echo "===SHARED index.ts==="
cat packages/i18n/src/shared/index.ts

echo "===SHARED resources.ts==="
cat packages/i18n/src/shared/ui/resources.ts 2>/dev/null || cat packages/i18n/src/shared/resources.ts 2>/dev/null

echo "===SHARED types.d.ts==="
cat packages/i18n/src/shared/ui/types.d.ts 2>/dev/null || cat packages/i18n/src/shared/types.d.ts 2>/dev/null

echo "===ALL SHARED TS FILES==="
find . -path "*/packages/i18n/src/shared*" -name "*.ts" -not -path "*/node_modules/*" -exec echo "FILE: {}" \; -exec cat {} \;

echo "===DASHBOARD instance.ts (current)==="
cat packages/i18n/src/apps/dashboard/instance.ts

echo "===WEB instance.ts (current)==="
cat packages/i18n/src/apps/web/instance.ts

echo "===STOREFRONT instance.ts (current)==="
cat packages/i18n/src/apps/storefront/instance.ts

echo "===DASHBOARD types.d.ts (current)==="
cat packages/i18n/src/apps/dashboard/types.d.ts

echo "===WEB types.d.ts (current)==="
cat packages/i18n/src/apps/web/types.d.ts 2>/dev/null

echo "===TURBO.JSON (current)==="
cat turbo.json 2>/dev/null || find . -maxdepth 2 -name "turbo.json" -not -path "*/node_modules/*" -exec cat {} \;

Length of output: 19221

@SkandarS0, here's the key structural change I found: the shared/ui/ sub-folder has been flattened — resources.ts, types.d.ts, and i18next.config.ts now live directly under src/shared/ (no ui/ sub-directory). Consequently, all Turborepo tasks renamed from ui:types/ui:status → shared:types/shared:status.

Here is the fully updated description — please paste it into the PR body:

🌐 Migrate from `next-intl` to `i18next`

This PR replaces next-intl with i18next (via next-i18next) as the i18n backbone across all apps and packages. Below is a comprehensive breakdown of every aspect of the new setup.

📁 How Translations Are Added

Translations live inside packages/i18n and are organised by app and locale:

packages/i18n/src/
├── apps/
│   ├── dashboard/locales/{ar,en,fr}/pages.json
│   ├── storefront/locales/{ar,en,fr}/pages.json
│   └── web/locales/{ar,en,fr}/home.json
└── shared/locales/{ar,en,fr}/ui.json

Each JSON file maps to a namespace (e.g. pages, home, ui). To add a new translation:

Add the key/value to the relevant JSON file in every locale folder (or run the extract command and fill in the gaps).
Re-run type generation for the affected app (see below).

French (fr) is the source of truth for type generation — always keep it complete.

🔠 How Type Generation Works

Each app/scope has three auto-managed files produced by i18next-cli:

File	Purpose
`resources.ts`	Typed interface mirroring the JSON structure — do not edit manually
`types.d.ts`	Augments the `i18next` module so the `t()` function is fully type-safe
`i18next.config.ts`	Config for `i18next-cli`: locales, extraction globs, type output paths

App-level types.d.ts files merge the app's own resources with the shared resources:

// dashboard/types.d.ts (auto-generated, editable)
import UiResources from "../../shared/resources.ts";
import Resources from "./resources.ts";

declare module "i18next" {
  interface CustomTypeOptions {
    enableSelector: false;
    defaultNS: "pages";
    resources: Resources & UiResources; // app namespaces + shared
    strictKeyChecks: true;
  }
}

The shared module itself has defaultNS: false because it carries no default namespace — it's always consumed through namespace-explicit calls.

Run type generation per scope or all at once:

pnpm turbo i18n:types                          # all apps + shared
pnpm --filter `@dukkani/i18n` dashboard:types    # dashboard only
pnpm --filter `@dukkani/i18n` web:types          # web only
pnpm --filter `@dukkani/i18n` storefront:types   # storefront only
pnpm --filter `@dukkani/i18n` shared:types       # shared ui only

⚡ Caching via Turborepo

Each type generation task is wired with precise inputs so Turborepo only reruns it when the relevant files actually change:

"i18n:types": {
  "dependsOn": [
    "@dukkani/i18n#dashboard:types",
    "@dukkani/i18n#web:types",
    "@dukkani/i18n#storefront:types",
    "@dukkani/i18n#shared:types"
  ]
},
"@dukkani/i18n#shared:types": {
  "inputs": ["src/shared/locales/fr/*.json"]
},
"@dukkani/i18n#dashboard:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/dashboard/**"]
},
"@dukkani/i18n#web:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/web/**"]
},
"@dukkani/i18n#storefront:types": {
  "dependsOn": ["^@dukkani/i18n#shared:types"],
  "inputs": ["src/apps/storefront/**"]
}

shared:types is always a prerequisite and always runs first.
If you only touch src/apps/dashboard/locales, only dashboard:types (+ shared:types) re-executes — storefront and web tasks stay cached.
The i18n:status tasks additionally track the consuming app's own source files as inputs (e.g. $TURBO_ROOT$/apps/dashboard/src/**), so a missing translation key used in application code will also bust the cache.
The shared:status task tracks packages/ui/src/** as input, because the shared namespace is extracted from the @dukkani/ui package source.

🪝 `useT` vs `getT`

	`useT`	`getT`
Import	`next-i18next/client`	`next-i18next/server`
Where to use	Client Components (`"use client"`)	Server Components (async)
API style	React hook — synchronous	Async function — `await`-able

// ✅ Client Component
"use client";
import { useT } from "next-i18next/client";

export function MyClientComponent() {
  const { t } = useT("pages", { keyPrefix: "dashboard.overview" });
  return <h1>{t("title")}</h1>;
}

// ✅ Server Component
import { getT } from "next-i18next/server";

export async function MyServerComponent() {
  const { t } = await getT("home", { keyPrefix: "header" });
  return <h1>{t("brandName")}</h1>;
}

🔗 More Shared Translations (e.g. a new `models.json`)

The shared namespace lives in packages/i18n/src/shared/locales/ and is flat — there is no sub-folder per package. The resourceLoader in each app's instance.ts automatically routes any unknown namespace there:

resourceLoader: async (lng, ns) => {
  if (!I18nextDashboardNamespaces.includes(ns)) {
    // Falls back to shared/locales/{lng}/{ns}.json
    return (await import(`../../shared/locales/${lng}/${ns}.json`)).default;
  }
  return (await import(`./locales/${lng}/${ns}.json`)).default;
},

The current shared namespace is ui — it includes password/image field labels, the language switcher, and all supported currency names with their regions.

To add a new shared namespace (e.g. models.json with translated entity labels shared across the dashboard and storefront):

Create packages/i18n/src/shared/locales/{ar,en,fr}/models.json
Add "models" to the ns array in the instance.ts of every app that needs it
Run pnpm --filter @dukkani/i18n shared:types to regenerate shared/resources.ts
Regenerate types for the affected apps

✨ i18next Features

Pluralization

Use the _one / _other suffix convention directly in JSON — i18next picks the right form based on count:

{
  "itemsCount_one": "{{count}} item",
  "itemsCount_other": "{{count}} items"
}

t("itemsCount", { count: 1 }) // → "1 item"
t("itemsCount", { count: 5 }) // → "5 items"

Interpolation

Embed dynamic values with {{variableName}} syntax directly in the JSON files:

{
  "viewOrder": "View order {{id}}",
  "instructions": "Send /link {{code}} to the bot if you are not redirected."
}

t("viewOrder", { id: "ORD-123" }) // → "View order ORD-123"

Context

Append _contextValue variants in JSON to select context-specific strings:

{
  "status_pending": "Waiting for confirmation",
  "status_confirmed": "Confirmed",
  "status_cancelled": "Cancelled"
}

t("status", { context: order.status }) // → "Confirmed"

Number, Date & Currency Formatting

The shared library exposes typed, locale-aware native Intl helpers:

import { formatCurrencyFn, formatDateFn, DateTimeFormattingOptions } from "@dukkani/i18n";

const formatPrice = formatCurrencyFn("fr", "TND");
formatPrice(1234.56) // → "1 234,56 TND"

const formatDate = formatDateFn("ar", DateTimeFormattingOptions.date.long);
formatDate(new Date()) // → "١ يناير ٢٠٢٥"

🧩 Dedicated Type Generation per App — Modularity

Every app owns its complete i18n stack in isolation, and the shared layer is its own independent module:

packages/i18n/src/
├── apps/
│   └── dashboard/
│       ├── i18next.config.ts   ← CLI config: locales, extract globs, type output
│       ├── instance.ts         ← Runtime config: supportedLngs, fallbackLng, resourceLoader
│       ├── resources.ts        ← Auto-generated typed interface (do not edit)
│       └── types.d.ts          ← Module augmentation (auto-generated, editable)
└── shared/
    ├── i18next.config.ts       ← CLI config for the shared ui namespace
    ├── resources.ts            ← Auto-generated shared typed interface (do not edit)
    ├── types.d.ts              ← Module augmentation with defaultNS: false
    ├── locales/{ar,en,fr}/
    │   └── ui.json
    └── lib/
        ├── currency.ts
        ├── date.ts
        └── language.ts

Benefits:

Dashboard types don't pollute storefront or web types.
Each app declares only its own namespaces + the shared ui namespace.
The shared module is generated independently and versioned separately from any single app.
Onboarding a new app means duplicating an apps/ sub-folder, updating the config, and running type generation.

🔑 `returnObjects` & `keyPrefix`

`keyPrefix`

Scopes the t function to a sub-tree of the namespace so call sites stay concise:

// Without keyPrefix — verbose
const { t } = useT("pages");
t("auth.emailSignIn.email.label") // "Email address"

// With keyPrefix — clean
const { t } = useT("pages", { keyPrefix: "auth.emailSignIn" });
t("email.label") // "Email address"

`returnObjects`

Returns the entire object or array at a translation key instead of a string:

// JSON: "benefits": ["Save hours of phone calls", "Eliminate fake orders", "Verify address accuracy"]
const benefits = t("benefits", { returnObjects: true }); // → string[]
benefits.map(b => <li>{b}</li>)

// JSON: "steps": { "createStore": { "title": "1. Create Store", "descriptionMobile": "Setup in 5 minutes." } }
const step = t("steps.createStore", { returnObjects: true });
// → { title: string, descriptionMobile: string, descriptionDesktop: string }

Both options compose naturally with each other:

const { t } = useT("home", { keyPrefix: "body.features.items" });
const feature = t("telegramAlerts", { returnObjects: true });
// → { title: string, descriptionMobile: string, descriptionDesktop: string }

…s now supported > [Related Issue](i18next/i18next-cli#238)

This reverts commit caa5930.

SkandarS0 · 2026-04-17T09:02:15Z

For now, there were no translation changes in the keys' structures, it can take a significant amount of time to refactor them, it will be done in a different PR

SkandarS0 · 2026-04-17T09:03:51Z

@FindMalek you might want to have look at Locize for CI, or related automation.

SkandarS0 added 30 commits April 15, 2026 16:43

chore(typescript): disable verbatimModuleSyntax

caa5930

chore(deps): add i18next and next-i18next to catalog

bf6619b

feat(i18n): add i18n configuration for ui package and web app

a428fca

chore(deps): add '@swc/core' to onlyBuiltDependencies

c35a085

refactor(web/i18n): migrate to i18next

5f7b37c

chore(turborepo): add i18n types' generation and status tasks to turb…

6d7b7db

…o configuration

chore(web/deps): remove next-intl

29bba17

fix(i18n): correct export path for ui module in package.json

553b2f7

fix(features): correct icon assignment for telegramAlerts feature

c332b06

fix(direction): update prop name from 'direction' to 'dir' in Directi…

87a45e1

…onProvider

fix(turborepo): fix the paths of cache inputs

d75f7de

chore(turborepo/i18n): update input paths for web and ui types to spe…

48665d8

…cific locale files

fix(next-themes): add patched dependencies for next-themes@0.4.6

53257a3

feat(i18n/ui): implement ui translation and fix language switcher

ffa38c7

feat(i18n/web): add english translations

d1703ce

fix(ui/chart): fix typescript errors

e5e9c7c

fix(ui/tsconfig): add 'node' type as it was overriden

fe14087

feat(i18n/ui): add images field translations in English and French

10be4d4

fix(i18n/ui): update output paths for locale files and adjust input p…

41174cc

…attern for French translations

feat(i18n): add currency and date formatting utilities

05c1e8e

fix(i18n): correct currency code from 'LYB' to 'LYD'

0f80008

chore(common/deps): add @dukkani/i18n

5fd06ad

fix(storefront): replace useIsRtl with useDirection as it was removed

183b119

fix(apps/layout): change direction prop to dir

9f8eb02

refactor(store-currency): use the i18n global settings of the currenc…

fb3863b

…y instead

fix(ui/language-switcher): use useMemo for consistent behaviour

fd2facb

fix(web/footer): make the component renders server side

f8baa20

refactor(i18n): restructure the package files' structure for better m…

cc7b68f

…odularity with shared namespaces

feat(i18n): add Arabic translations for home and UI components

6b890ed

fix(i18n): make the french language as the first one to auto detect i…

de5b332

…t as the primary language for the cli

vercel Bot deployed to Preview – dukkani-storefront April 16, 2026 22:32 View deployment

vercel Bot had a problem deploying to Preview – dukkani-api April 16, 2026 22:33 Failure

SkandarS0 added 2 commits April 17, 2026 08:23

refactor(i18n): enhance modularity for the shared locales

917d1bd

fix(storefront/i18n): update low stock messages for pluralization

8dfa7f9

vercel Bot deployed to Preview – dukkani-storefront April 17, 2026 07:34 View deployment

vercel Bot had a problem deploying to Preview – dukkani-api April 17, 2026 07:36 Failure

vercel Bot had a problem deploying to Preview – dukkani-web April 17, 2026 07:37 Failure

vercel Bot had a problem deploying to Preview – dukkani-dashboard April 17, 2026 07:38 Failure

SkandarS0 added 2 commits April 17, 2026 08:43

chore(deps): update i18next

34aa3c1

fix(i18n/apps): fix types of resources

6feb742

vercel Bot deployed to Preview – dukkani-web April 17, 2026 08:10 View deployment

vercel Bot deployed to Preview – dukkani-dashboard April 17, 2026 08:10 View deployment

vercel Bot deployed to Preview – dukkani-storefront April 17, 2026 08:12 View deployment

vercel Bot had a problem deploying to Preview – dukkani-api April 17, 2026 08:13 Failure

refactor(i18n): rename formatCurrencyFn to formatPriceFn

8a47570

vercel Bot deployed to Preview – dukkani-web April 17, 2026 08:21 View deployment

vercel Bot deployed to Preview – dukkani-storefront April 17, 2026 08:21 View deployment

vercel Bot had a problem deploying to Preview – dukkani-api April 17, 2026 08:23 Failure

vercel Bot deployed to Preview – dukkani-dashboard April 17, 2026 08:25 View deployment

SkandarS0 added 3 commits April 17, 2026 09:53

chore(i18n): update i18next-cli to 1.54.0 as verbatimModuleSyntax i…

d4bb08c

…s now supported > [Related Issue](i18next/i18next-cli#238)

Revert "chore(typescript): disable verbatimModuleSyntax"

e4665c8

This reverts commit caa5930.

chore(typescript): use type imports

6279b07

vercel Bot deployed to Preview – dukkani-dashboard April 17, 2026 09:01 View deployment

vercel Bot deployed to Preview – dukkani-web April 17, 2026 09:02 View deployment

vercel Bot deployed to Preview – dukkani-api April 17, 2026 09:04 View deployment

vercel Bot deployed to Preview – dukkani-storefront April 17, 2026 09:05 View deployment

Navigation Menu

Migrate from `next-intl` to `i18next` - #405

Migrate from `next-intl` to `i18next`#405
SkandarS0 wants to merge 72 commits into
mainfrom
399-translation-keys-cannot-be-used-in-vanilla-ts-only-in-nextjs-apps-in-react-code

SkandarS0 commented Apr 16, 2026 •

edited

Loading

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

coderabbitai Bot commented Apr 17, 2026

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

SkandarS0 commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🌐 Migrate from next-intl to i18next

📁 How Translations Are Added

🔠 How Type Generation Works

⚡ Caching via Turborepo

🪝 useT vs getT

🔗 More Shared Translations (e.g. a new models.json)

✨ i18next Features

Pluralization

Interpolation

Context

Number, Date & Currency Formatting

🧩 Dedicated Type Generation per App — Modularity

🔑 returnObjects & keyPrefix

keyPrefix

returnObjects

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

coderabbitai Bot commented Apr 17, 2026

🌐 Migrate from next-intl to i18next

📁 How Translations Are Added

🔠 How Type Generation Works

⚡ Caching via Turborepo

🪝 useT vs getT

🔗 More Shared Translations (e.g. a new models.json)

✨ i18next Features

Pluralization

Interpolation

Context

Number, Date & Currency Formatting

🧩 Dedicated Type Generation per App — Modularity

🔑 returnObjects & keyPrefix

keyPrefix

returnObjects

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

SkandarS0 commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

SkandarS0 commented Apr 16, 2026 •

edited

Loading

🌐 Migrate from `next-intl` to `i18next`

🪝 `useT` vs `getT`

🔗 More Shared Translations (e.g. a new `models.json`)

🔑 `returnObjects` & `keyPrefix`

`keyPrefix`

`returnObjects`

🌐 Migrate from `next-intl` to `i18next`

🪝 `useT` vs `getT`

🔗 More Shared Translations (e.g. a new `models.json`)

🔑 `returnObjects` & `keyPrefix`

`keyPrefix`

`returnObjects`