pluralRules configuration not applied when using lazy loading with defineI18nConfig

[jozefvodicka]

Environment

Nuxt project info:

Operating system	Linux 6.17.8-orbstack-00308-g8f9c941121b1
CPU	unknown (8 cores)
Node.js version	v24.12.0
nuxt/cli version	3.31.3
Package manager	yarn@4.10.3
Nuxt version	4.2.2
Nitro version	2.12.9
Builder	vite@7.3.0
Config	-
Modules	-

Reproduction

Steps to Reproduce

1. Configure Nuxt i18n with lazy loading:
   // nuxt.config.ts
   export default defineNuxtConfig({
   i18n: {
   vueI18n: './i18n/i18n.config.ts',
   defaultLocale: 'en',
   strategy: 'no_prefix',
   langDir: 'locales/',
   locales: [
   {
   code: 'cs',
   file: 'cs.ts',
   },
   // ... other locales
   ],
   },
   })

2. Define custom pluralRules in i18n.config.ts:
   // i18n.config.ts
   import { pluralRules } from '@shared/locales'

export default defineI18nConfig(() => ({
legacy: false,
pluralRules, // This should be applied but isn't
}))

3. Check runtime i18n instance:
   // In browser console
   const i18n = useNuxtApp().$i18n
   console.log(i18n.pluralRules) // Returns: {} (empty object)## Environment

• @nuxtjs/i18n version: 10.x (tested with current version)
• Nuxt version: 4.x
• Vue I18n version: 11.x (peer dependency)
• Lazy loading: enabled (langDir and file options)

Additional Context

• The pluralRules functions are correctly defined and exported
• The issue occurs specifically with lazy loading - when lazy loading is disabled, the pluralization might work correctly
• Workaround implemented: Created a custom composable that manually handles pluralization by accessing raw translation messages and selecting the correct form
• The bug affects languages with complex pluralization rules like Czech, Slovak, Polish, etc.

Impact

This prevents proper internationalization for applications that need custom pluralization rules, particularly affecting Slavic languages that have more than the standard 2-3 plural forms.

Describe the bug

Bug Report: pluralRules configuration not applied when using lazy loading with defineI18nConfig

Description

When using @nuxtjs/i18n with lazy loading and defineI18nConfig, custom pluralRules functions defined in the configuration are not being applied to the runtime Vue I18n instance. This causes the application to fall back to default pluralization rules instead of using the custom pluralization logic.

Expected Behavior

Custom pluralRules defined in i18n.config.ts should be applied to the Vue I18n instance, allowing proper pluralization for languages with complex plural forms (like Czech and Slovak with their 4 plural forms: zero, singular, few, many).

Actual Behavior

The runtime Vue I18n instance shows pluralRules: {} (empty object), and default pluralization rules are used instead of the custom ones.

Additional context

No response

Logs

[splitwarechef]

From what it seems, with the latest version of this package, the i18n.config.ts file is not even being loaded. I've setup other configs like

fallbackWarn: false

It doesn't work

[esszed]

I've run into the same issue. Works correctly on 9.5.6.

[rodion-m]

Adding cross-locale data that may help triage — pluralRules are not universally ignored under lazy mode in current @nuxtjs/i18n versions. The bug surface seems narrower than the title suggests.

Cannot reproduce on Russian (3-form) with @nuxtjs/i18n@10.2.3

Stack: Nuxt 4.2.2, @nuxtjs/i18n@10.2.3, vue-i18n@11.4.2, lazy is on (it is the default since v10.1.0 — the option was removed).

i18n.config.ts (in i18n/ directory):

export default defineI18nConfig(() => ({
  legacy: false,
  pluralRules: {
    ru: (n) => {
      if (n === 0) return 0
      const lt = n % 100, ld = n % 10, teen = lt >= 11 && lt <= 19
      if (!teen && ld === 1) return 1
      if (!teen && ld >= 2 && ld <= 4) return 2
      return 3
    }
  }
}))

Locale string: "нет артефактов | {n} артефакт | {n} артефакта | {n} артефактов" (4 forms).

After nuxt build, inspecting the production bundle confirms the config is loaded and applied:

• A dedicated chunk is emitted containing the minified function and the merged pluralRules object:

  function r(t){if(t===0)return 0;const u=t%100,n=t%10,e=u>=11&&u<=19;return!e&&n===1?1:!e&&n>=2&&n<=4?2:3}
  const l=()=>({legacy:!1,pluralRules:{ru:r,uk:r,be:r}});
  export{l as default};

• Main entry imports it via PM = [() => import("./<chunk>.js")] and resolves it in the i18n options loader (Y2 = async e => { const t = await IM(PM); ...; return t }).
• In runtime, the message-format selection picks the function via e.pluralRules[t] for the active locale.

End-to-end check (t('artifacts', n, { named: { n } }) for n in [0,1,2,3,4,5,10,11,12,14,15,21,22,25,101,111,122]) all return the correct russian forms.

What that suggests for #3903

The reporter's case is CZ/SK (4 forms with "many"). My case is RU (3 forms but using a 4-slot message). Both rely on pluralRules being applied at runtime. It works for me, doesn't for the reporter. Possible differentiators worth checking:

1. Config file shape. I use defineI18nConfig(() => ({ ... })) (factory). If the reporter used the object form defineI18nConfig({ ... }) or returned the config object directly, the loader path may differ.
2. i18nDir vs custom langDir. I keep the file at i18n/i18n.config.ts (default restructureDir). vueI18n: './i18n.config.ts' is resolved relative to i18nDir, not to nuxt.config.ts — putting the file at the project root makes it silently skipped (see vueI18n config silently skipped in production builds; API docs don't state the path is resolved relative to i18nDir #3983).
3. Locale code shape. Mine are bare 2-letter codes (ru, uk, be). The reporter shows cs/sk — same shape, but worth verifying.

Likely root cause is vue-i18n core, not the Nuxt layer

The same symptom (custom pluralRules ignored, default Math.min(n, 2) taking over) was reported and fixed upstream:

• intlify/vue-i18n#2280 — Arabic case, identical behaviour (custom rules never invoked), closed completed 2025-10-08.
• intlify/vue-i18n#2020 / PR intlify/vue-i18n#2400 — adds Intl.PluralRules fallback and explicitly preserves user-defined pluralRules as highest priority. Merged to master 2026-02-23, breaking change targeted at v12 — not yet released as of v11.4.2 (today's stable).

If reporters here can pin their vue-i18n to the v12 pre-release once it ships and re-test, that's likely the fix.

Asks for the original reporter

Could you post:

• Exact shape of defineI18nConfig call (factory vs object).
• Result of console.log(useNuxtApp().$i18n.pluralRules) after the lazy-loaded locale resolves (in onMounted plus a nextTick), not during plugin init.
• A grep of your bundled chunks for pluralRules:{cs: (or whichever locale) — if it isn't in any chunk, the file isn't being picked up at all (likely a path-resolution issue, not a runtime one).

Happy to bisect further if there's interest from maintainers.

[github-actions]

Would you be able to provide a reproduction? 🙏

More info

Why do I need to provide a reproduction?

Reproductions make it possible for us to triage and fix issues quickly with a relatively small team. It helps us discover the source of the problem, and also can reveal assumptions you or we might be making.

What will happen?

If you've provided a reproduction, we'll remove the label and try to reproduce the issue. If we can, we'll mark it as a bug and prioritise it based on its severity and how many people we think it might affect.

If needs reproduction labeled issues don't receive any substantial activity (e.g., new comments featuring a reproduction link), we'll close them. That's not because we don't care! At any point, feel free to comment with a reproduction and we'll reopen it.

How can I create a reproduction?

We have a couple of templates for starting with a minimal reproduction:

👉 Reproduction starter (v8)
👉 Reproduction starter (v9)
👉 Reproduction starter (v10)

A public GitHub repository is also perfect. 👌

Please ensure that the reproduction is as minimal as possible. See more details in our guide.

You might also find these other articles interesting and/or helpful:

• The Importance of Reproductions
• How to Generate a Minimal, Complete, and Verifiable Example