next-intl बनाम react-i18next बनाम Lingui: 2026 में किसे चुनें

Next.js App Router प्रोजेक्ट के लिए next-intl चुनें। React SPA या ऐसी किसी भी चीज़ के लिए जो आगे चलकर एक framework से बड़ी हो सकती है, react-i18next चुनें। अगर ecosystem के आकार से ज़्यादा compile-time extraction और lean bundles आपके लिए महत्वपूर्ण हैं, तो Lingui चुनें। ये तीनों runtime i18n libraries हैं: ये आपके components को translations उपलब्ध कराती हैं, लेकिन इनमें से कोई भी आपके लिए keys या locale files नहीं बनाती। globalize.now AI-powered localization infrastructure है, जो आपके codebase से ये keys और catalogs तैयार करता है और तीनों libraries के साथ काम करता है।

ये तीनों libraries वास्तव में करती क्या हैं?

ये सभी एक ही runtime समस्या हल करती हैं: किसी key और locale को देखते हुए सही string लौटाना, जिसमें pluralization और formatting भी सही हो। इसमें interpolation, date और number formatting, तथा ICU-style messages के ज़रिए plural rules शामिल हैं।

इनमें से कोई भी translations तैयार नहीं करती। Runtime library पहले से मौजूद catalog का इस्तेमाल करती है। फिर भी किसी को आपके components में मौजूद हर user-visible string ढूँढकर उसे key से बदलना और हर भाषा के लिए locale file भरना पड़ता है। यह stack की अलग layer है। दोनों layers को अलग समझना इस तुलना को स्पष्ट करने का सबसे तेज़ तरीका है: आप ठीक एक runtime library चुनेंगे, और उसका मुकाबला उन tools से नहीं है जो उसके catalogs भरते हैं। हमारा developer docs इस विभाजन को और विस्तार से समझाते हैं।

next-intl का इस्तेमाल कब करना चाहिए?

जब आप Next.js के साथ App Router इस्तेमाल कर रहे हों। इन तीनों में next-intl ही वह library है जिसे App Router primitives को ध्यान में रखकर बनाया गया है: async Server Components, locale-aware navigation और routing helpers, तथा metadata APIs। सितंबर 2026 तक यह version 4 पर है और हर सप्ताह लगभग 50 लाख npm downloads हासिल करता है। इसलिए व्यवहार में नए Next.js प्रोजेक्ट के लिए यह सिर्फ़ सैद्धांतिक नहीं, बल्कि default विकल्प है।

Messages ICU MessageFormat में होते हैं, इसलिए plurals, gender और interpolation उसी standard का पालन करते हैं जिसे पूरा industry इस्तेमाल करता है। अगर ICU syntax आपके लिए नया है, तो हमने ICU MessageFormat की सरल भाषा में गाइड लिखी है। इसकी कीमत coupling है: next-intl, Next.js की library है। अगर आप Next.js छोड़ते हैं, तो अपना i18n layer भी migrate करना पड़ेगा।

react-i18next का इस्तेमाल कब करना चाहिए?

जब आप Next.js पर नहीं हैं, या जब आप अपने पीछे सबसे बड़ा ecosystem चाहते हैं। react-i18next, i18next का React binding है और हर सप्ताह लगभग 1.4 करोड़ npm downloads के साथ यह बड़े अंतर से सबसे अधिक इस्तेमाल की जाने वाली React i18n library है। i18next core को एक दशक से अधिक समय से maintain किया जा रहा है और इसके लगभग हर ज़रूरत के लिए plugins हैं: HTTP के ज़रिए catalogs लोड करने वाले backends, language detectors, caching layers और React से आगे के frameworks के bindings।

अधिकांश AI coding tools default रूप से इसी library को चुनते हैं। Cursor या Lovable से Vite + React ऐप में “translations जोड़ने” को कहें, तो लगभग हमेशा i18next setup मिलेगा। यह default उचित है: यह हर जगह काम करता है और इसका JSON catalog format ecosystem में lingua franca के सबसे करीब है। इसकी कमी यह है कि यह Server Components से पहले का है। इसलिए App Router पर इसे next-intl की तुलना में अधिक wiring चाहिए और जब तक आप अलग व्यवस्था न करें, translation का अधिकांश काम client पर होता है।

Lingui सही विकल्प कब है?

जब bundle size और source ergonomics आपकी प्राथमिकता हों। सितंबर 2026 तक major version 6 पर मौजूद Lingui compiler-first approach अपनाता है: आप macros के साथ messages inline लिखते हैं और इसका CLI build time पर उन्हें catalogs में extract करता है। Compiled catalogs runtime parsing overhead के बिना ship होते हैं, जिससे आपके bundle में i18n की लागत कम रहती है।

Lingui अपने catalog format के रूप में gettext PO files को भी standard बनाता है, जिन्हें पेशेवर अनुवादक दशकों से संभालते आए हैं। इसके weekly downloads लगभग 15 लाख हैं—react-i18next से एक order of magnitude कम—इसलिए Stack Overflow पर कम जवाब और third-party plugins भी कम मिलेंगे। यह सामान्य रूप से React के साथ काम करता है, केवल Next.js के साथ नहीं, लेकिन react-i18next की तरह यह भी App Router primitives के इर्द-गिर्द नहीं बना है, जैसा next-intl है।

एक नज़र में इनकी तुलना कैसे होती है?

AI-generated codebase के लिए आपको किसे चुनना चाहिए?

ऊपर की तरह framework के आधार पर चुनें—लेकिन यह समझें कि AI-built apps की समस्या library का चुनाव नहीं है। Cursor, Claude Code और Lovable, चाहे कोई भी i18n library इंस्टॉल हो, default रूप से hardcoded English strings बनाते हैं। Library सेट अप करने के बाद भी component edit करने वाला agent इन्हें जोड़ता रहेगा।

इसलिए सही क्रम यह है: अपने framework के लिए उपयुक्त runtime library चुनें, फिर extraction और catalog upkeep को अलग समस्या की तरह हल करें। Next.js के मामले में हमने पूरा setup Cursor से बनाए गए Next.js ऐप में i18n जोड़ना में दस्तावेज़ित किया है, और Next.js integration page बताता है कि runtime wiring से पहले globalize.now next-intl के लिए keys और locale files कैसे तैयार करता है।

क्या runtime library के साथ भी localization infrastructure की ज़रूरत रहती है?

हाँ, क्योंकि library केवल catalogs पढ़ती है—उन्हें बनाना और maintain करना ही आपका समय खाता है। globalize.now इसी layer पर काम करता है: अपना रिपॉज़िटरी कनेक्ट करें और यह codebase को एक बार convert करके hardcoded strings को keys से बदलता है और locale files बनाता है। इस one-time conversion के बाद, आपके commits से जुड़ी नई catalog entries को push jobs translate करती हैं।

Output JSON या PO होता है—next-intl और i18next setups के लिए JSON, और Lingui के native format के लिए PO—इसलिए catalogs उसी रूप में तैयार होते हैं जिसे आपकी runtime library पहले से consume करती है। अगर आपके ऐप में पहले से partial i18n setup है, तो उसे भी संभाला जाता है: globalize.now मौजूदा i18n के साथ काम करता है, उसे replace नहीं करता। Plans और usage rates pricing page पर देखें।

इन तीनों में से कोई भी गलत विकल्प नहीं है। App Router पर हैं तो next-intl, maximum ecosystem चाहते हैं तो react-i18next, और compile-time extraction व PO catalogs चाहते हैं तो Lingui। एक चुनें, strings को अपने components से बाहर रखें और बाकी काम catalog layer पर छोड़ दें।