आगामी Intlayer रिलीज़ के बारे में सूचनाएं प्राप्त करें

    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 फ़ाइल प्री-रेंडर करता है।