---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: Next.js में i18n के साथ स्थैतिक बनाम गतिशील रेंडरिंग
description: Next.js में i18n के साथ स्थैतिक बनाम गतिशील रेंडरिंग का उपयोग कैसे करें, सीखें।
keywords:
  - स्थैतिक
  - गतिशील
  - रेंडरिंग
  - i18n
  - next.js
  - next-intl
  - intlayer
  - फ्रेमवर्क
  - मिडलवेयर
  - कॉन्फ़िगरेशन
slugs:
  - frequent-questions
  - static-rendering
---

# Next.js में i18n के साथ स्थैतिक बनाम गतिशील रेंडरिंग

## **next-intl** के साथ समस्या

- **क्या होता है?**
  जब आप `useTranslations`, `getTranslations`, या कोई भी next-intl हेल्पर _सर्वर कंपोनेंट के अंदर_ i18n-रूटेड ऐप (`/en/…`, `/fr/…`) में उपयोग करते हैं, तो Next.js पूरे रूट को **गतिशील** के रूप में चिह्नित कर देता है। ([Next Intl][1])

- **क्यों?**
  next-intl वर्तमान लोकल को केवल अनुरोध-हेडर (`x-next-intl-locale`) से `headers()` के माध्यम से देखता है। क्योंकि `headers()` एक **गतिशील API** है, कोई भी कंपोनेंट जो इसे छूता है, स्थैतिक अनुकूलन खो देता है। ([Next Intl][1], [Next.js][2])

- **आधिकारिक समाधान (बॉयलरप्लेट)**
  1. हर समर्थित लोकल के साथ `generateStaticParams` निर्यात करें।
  2. `useTranslations` कॉल करने से _पहले_ **हर** लेआउट/पेज में `setRequestLocale(locale)` कॉल करें। ([Next Intl][1])
     इससे हेडर निर्भरता हट जाती है, लेकिन अब आपके पास अतिरिक्त कोड बनाए रखने के लिए होता है और उत्पादन में एक अस्थिर API होती है।

## कैसे **intlayer** इस समस्या से बचता है

**डिज़ाइन विकल्प**

1. **केवल रूट-पैरामीटर** – लोकल `[locale]` URL सेगमेंट से आता है जिसे Next.js पहले से ही हर पेज को पास करता है।
2. **कंपाइल-टाइम बंडल्स** – अनुवाद सामान्य ES मॉड्यूल के रूप में आयात किए जाते हैं, इसलिए वे ट्री-शेक किए जाते हैं और बिल्ड-टाइम पर एम्बेड किए जाते हैं।
3. **कोई गतिशील API नहीं** – `useT()` React संदर्भ से पढ़ता है, न कि `headers()` या `cookies()` से।
4. **कोई अतिरिक्त कॉन्फ़िगरेशन नहीं** – एक बार जब आपके पेज `app/[locale]/` के अंतर्गत होते हैं, तो Next.js स्वचालित रूप से प्रत्येक लोकल के लिए एक HTML फ़ाइल प्री-रेंडर करता है।
