@intlayer/docs 9.4.1 → 9.4.3

package/blog/hi/date_time_number_formatting_locales.md

@@ -0,0 +1,216 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Intl के साथ लोकेल के अनुसार दिनांक और संख्याओं को फॉर्मेट करना"
+description: आपको शायद किसी फॉर्मेटिंग लाइब्रेरी की आवश्यकता नहीं है। जानें कि Intl लोकेल के अनुसार दिनांक, संख्या, मुद्रा और सूचियों को कैसे संभालता है, कैशिंग की लागत, और टाइमज़ोन बग जो केवल उत्पादन में सामने आता है।
+keywords:
+  - लोकेल द्वारा दिनांक प्रारूपित करें
+  - Intl.DateTimeFormat
+  - Intl.NumberFormat
+  - toLocaleDateString
+  - लोकेल मुद्रा प्रारूप
+  - सापेक्ष समय प्रारूप
+slugs:
+  - blog
+  - date-time-number-formatting-locales
+author: aymericzip
+---
+
+# Intl के साथ लोकेल के अनुसार दिनांक और संख्याओं को फॉर्मेट करना
+
+स्ट्रिंग्स का अनुवाद करना अंतर्राष्ट्रीयकरण (i18n) का केवल दृश्यमान हिस्सा है। दूसरा हिस्सा जो लगातार बग रिपोर्ट उत्पन्न करता है, वह है फ़ॉर्मेटिंग: एक जर्मन उपयोगकर्ता `1.234,56` के बजाय `1,234.56` देखता है, एक जापानी उपयोगकर्ता `08/02/2026` को देखता है और इसे अगस्त समझता है, या एक तारीख जो सर्वर और क्लाइंट पर अलग-अलग रेंडर होती है और React के हाइड्रेशन को विफल कर देती है।
+
+इनमें से किसी के लिए भी लाइब्रेरी की आवश्यकता नहीं है। `Intl` प्रत्येक आधुनिक रनटाइम में पहले से उपलब्ध है।
+
+## विषय सूची
+
+<TOC/>
+
+## अपने हाथ से लिखे दिनांक सहायक फ़ंक्शन को हटाने से शुरुआत करें
+
+लगभग हर कोडबेस में एक `formatDate` फ़ंक्शन होता है जो लोकेल के बारे में सोचने से पहले लिखा गया था। यह एक निश्चित क्रम, एक विभाजक और आमतौर पर अंग्रेज़ी महीने के नामों को हार्डकोड करता है।
+
+```ts
+// जिसे आपको हटाना चाहिए:
+const formatDate = (d: Date) =>
+  `${d.getMonth() + 1}/${d.getDate()}/${d.getFullYear()}`;
+```
+
+`Intl.DateTimeFormat` इसे पूरी तरह बदल देता है और हर लोकेल में सही परिणाम देता है:
+
+```ts
+new Intl.DateTimeFormat("de-DE", { dateStyle: "long" }).format(date);
+// "2. August 2026"
+new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(date);
+// "2026年8月2日"
+```
+
+यही बात संख्याओं पर भी लागू होती है। `toFixed(2)` हर जगह `1234.56` उत्पन्न करता है, जो अधिकांश यूरोप में गलत है।
+
+## `Intl` क्या कवर करता है
+
+| API                       | इसके लिए उपयोग करें                                     |
+| :------------------------ | :------------------------------------------------------ |
+| `Intl.DateTimeFormat`     | दिनांक और समय, `dateStyle` / `timeStyle` प्रीसेट के साथ |
+| `Intl.NumberFormat`       | दशमलव, मुद्रा, प्रतिशत, इकाइयाँ, संक्षिप्त संकेतन       |
+| `Intl.RelativeTimeFormat` | "3 दिन पहले", "2 घंटे में"                              |
+| `Intl.ListFormat`         | "क, ख और ग" की सूची फॉर्मेटिंग                          |
+| `Intl.PluralRules`        | यह तय करना कि कोई संख्या किस बहुवचन श्रेणी में आती है   |
+| `Intl.Collator`           | भाषा के अनुसार स्ट्रिंग्स को सही ढंग से क्रमबद्ध करना   |
+
+`Intl.Collator` वह है जिसे लोग अक्सर भूल जाते हैं। स्ट्रिंग्स पर सादा `array.sort()` यूनिकोड कोड पॉइंट क्रम का उपयोग करता है, जिससे उच्चारण वाले अक्षर `z` के बाद चले जाते हैं। यदि आप उपयोगकर्ताओं को दिखने वाली सूचियों को सॉर्ट करते हैं, तो हमेशा एक collator का उपयोग करें।
+
+```ts
+["zebra", "édouard", "apple"].sort(new Intl.Collator("hi").compare);
+// ["apple", "édouard", "zebra"]
+```
+
+## हाथ से बनाए गए विकल्पों की तुलना में प्रीसेट को प्राथमिकता दें
+
+`dateStyle` और `timeStyle` लोकेल को क्रम और विभाजक तय करने की अनुमति देते हैं। `year`, `month` और `day` को अलग-अलग निर्दिष्ट करना आपको ऐसा नियंत्रण देता है जो आमतौर पर नहीं होना चाहिए, क्योंकि सही क्रम लोकेल के अनुसार भिन्न होता है और आप अपनी मान्यताओं के साथ CLDR डेटा को अधिलेखित कर रहे होते हैं।
+
+```ts
+// लोकेल संरचना तय करता है:
+new Intl.DateTimeFormat(locale, { dateStyle: "medium" }).format(d);
+
+// जब आप संरचना तय करते हैं, तो यह अन्य क्षेत्रों में गलत हो जाता है:
+new Intl.DateTimeFormat(locale, {
+  year: "numeric",
+  month: "2-digit",
+  day: "2-digit",
+}).format(d);
+```
+
+स्पष्ट घटकों का उपयोग केवल तभी करें जब डिज़ाइन को वास्तव में एक निश्चित चौड़ाई की आवश्यकता हो, उदाहरण के लिए एक संकीर्ण तालिका कॉलम।
+
+## फ़ॉर्मेटर बनाना महंगा है
+
+यह प्रदर्शन विवरण है जो मायने रखता है। `Intl.NumberFormat` का निर्माण लोकेल डेटा लोड करता है, और यह बाद के `.format()` कॉल से कहीं अधिक महंगा है। एक हजार पंक्तियों पर लूप के अंदर ऐसा करने से ध्यान देने योग्य धीमापन आता है।
+
+```ts
+// प्रत्येक पंक्ति पर फ़ॉर्मेटर का पुनर्निर्माण (धीमा):
+rows.map((r) => new Intl.NumberFormat(locale).format(r.total));
+
+// एक बार बनाएं, पुन: उपयोग करें (तेज़):
+const nf = new Intl.NumberFormat(locale);
+rows.map((r) => nf.format(r.total));
+```
+
+`toLocaleDateString()` और `toLocaleString()` के अंदर भी यही समस्या छिपी है: प्रत्येक कॉल एक नया फ़ॉर्मेटर बनाता है। वे एक मान के लिए ठीक हैं और सूची के लिए गलत हैं।
+
+लोकेल और विकल्पों के संयोजन द्वारा कैश करें:
+
+```ts
+const cache = new Map<string, Intl.NumberFormat>();
+
+const getNumberFormat = (
+  locale: string,
+  options: Intl.NumberFormatOptions = {}
+) => {
+  const key = `${locale}:${JSON.stringify(options)}`;
+  let formatter = cache.get(key);
+  if (!formatter) {
+    formatter = new Intl.NumberFormat(locale, options);
+    cache.set(key, formatter);
+  }
+  return formatter;
+};
+```
+
+## टाइमज़ोन बग जो केवल उत्पादन में दिखाई देता है
+
+यह समस्या कई डेवलपर घंटे बर्बाद करती है। सर्वर SSR के दौरान एक तारीख प्रस्तुत करता है, ब्राउज़र इसे हाइड्रेट करता है, और React एक हाइड्रेशन बेमेल फेंकता है क्योंकि दोनों ने अलग-अलग पाठ उत्पन्न किया है।
+
+कारण यह है कि `Intl.DateTimeFormat` परिवेशी समय क्षेत्र का उपयोग करता है जब आप किसी एक का नाम नहीं देते हैं। आपका उत्पादन सर्वर UTC में चलता है। आपका लैपटॉप नहीं। इसलिए यह बग स्थानीय स्तर पर अदृश्य है और केवल उत्पादन में ही सामने आता है।
+
+```ts
+// UTC में सर्वर और UTC+5:30 में ब्राउज़र असहमत हैं। हाइड्रेशन बेमेल:
+new Intl.DateTimeFormat(locale, { dateStyle: "short" }).format(d);
+
+// दोनों पूरी तरह सहमत हैं:
+new Intl.DateTimeFormat(locale, { dateStyle: "short", timeZone: "UTC" }).format(
+  d
+);
+```
+
+तीन व्यावहारिक दृष्टिकोण:
+
+- सर्वर पर **टाइमज़ोन को पिन करें** और इसे स्पष्ट रूप से पास करें। सटीक और नियतात्मक, लेकिन हर कोई UTC देखता है।
+- **केवल क्लाइंट पर रेंडर करें**, सर्वर पास के लिए एक स्थिर प्लेसहोल्डर के साथ। उपयोगकर्ता के लिए सटीक, लेकिन हल्का फ़्लैश होता है।
+- **उपयोगकर्ता के टाइमज़ोन को संग्रहीत करें** और इसे दोनों पक्षों पर पास करें। सबसे अच्छा परिणाम, अधिक काम।
+
+आप जो भी चुनें, सर्वर और क्लाइंट दोनों पर प्रस्तुत की गई किसी भी तारीख के लिए हमेशा `timeZone` स्पष्ट रूप से पास करें। बिना टाइमज़ोन की तारीख दो मानों वाली तारीख होती है।
+
+## मुद्रा को मुद्रा की आवश्यकता है, लोकेल की नहीं
+
+लोकेल और मुद्रा स्वतंत्र हैं। `fr-FR` का अर्थ यूरो नहीं है: एक फ्रांसीसी उपयोगकर्ता USD इनवॉइस देख सकता है।
+
+```ts
+new Intl.NumberFormat("fr-FR", { style: "currency", currency: "USD" }).format(
+  1234.5
+);
+// "1 234,50 $US"
+```
+
+लोकेल विभाजक, अंक समूहीकरण और प्रतीक प्लेसमेंट को नियंत्रित करता है। मुद्रा आपके डेटा से आती है। एक से दूसरे का अनुमान लगाना एक बग है जो लेखांकन तक पहुँचता है।
+
+`currencyDisplay` पर भी ध्यान दें। ऐसे इंटरफ़ेस में जहाँ कई डॉलर मुद्राएँ सह-अस्तित्व में हैं, `"code"` अमेरिकी, कनाडाई और ऑस्ट्रेलियाई डॉलर के बीच अस्पष्टता को दूर करता है।
+
+## सापेक्ष समय पूर्ण समय से बेहतर पढ़ा जाता है
+
+किसी भी हालिया घटना के लिए, "2 घंटे पहले" एक सटीक टाइमस्टैम्प से बेहतर होता है, और `Intl.RelativeTimeFormat` इसे ठीक से स्थानीयकृत करता है।
+
+```ts
+new Intl.RelativeTimeFormat("hi", { numeric: "auto" }).format(-1, "day");
+// "कल"
+```
+
+`numeric: "auto"` वह है जो "1 दिन पहले" के बजाय "कल" उत्पन्न करता है।
+
+## Intlayer क्या जोड़ता है
+
+Intlayer इन्हें कैश्ड हेल्पर्स में लपेटता है ताकि आपको ऊपर दिए गए मैप को मैन्युअल रूप से प्रबंधित न करना पड़े, और सक्रिय लोकेल हर कॉल साइट पर पास होने के बजाय डिफ़ॉल्ट रूप से लागू हो।
+
+```ts
+import {
+  number,
+  currency,
+  date,
+  relativeTime,
+  units,
+  compact,
+  list,
+} from "intlayer";
+
+number(1234.5); // "1,234.5"
+currency(1234.5, { currency: "EUR" }); // "€1,234.50"
+date(new Date(), "short");
+relativeTime(now, twoHoursAgo, { unit: "hour", numeric: "auto" }); // "2 घंटे पहले"
+units(5, { unit: "kilometer", unitDisplay: "long" }); // "5 किलोमीटर"
+compact(1200); // "1.2K"
+list(["सेब", "केला", "संतरा"]); // "सेब, केला और संतरा"
+```
+
+`date()` फ़ंक्शन प्रीसेट (`"short"`, `"long"`, `"dateOnly"`, `"timeOnly"`, `"full"`) भी स्वीकार करता है। React और Vue के समकक्ष हुक और कंपोज़ेबल संदर्भ से सक्रिय लोकेल को हल करते हैं।
+
+यह प्लेटफ़ॉर्म API पर एक कुशल कैशिंग परत है। वास्तविक फ़ॉर्मेटिंग व्यवहार पूरी तरह से `Intl` है। पूर्ण हस्ताक्षर [फ़ॉर्मेटर्स दस्तावेज़](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/formatters.md) में देखें।
+
+## सामान्य गलतियाँ
+
+- **बिना लोकेल के `toLocaleDateString()`.** रनटाइम के डिफ़ॉल्ट का उपयोग करता है, जो सर्वर पर कंटेनर कॉन्फ़िगरेशन पर निर्भर करता है।
+- **बिना कैश के लूप में फ़ॉर्मेट करना।** फ़ॉर्मेटर का निर्माण अधिकांश लागत लेता है। एक बार बनाएं।
+- **आइसोमॉर्फिक तिथियों पर कोई `timeZone` नहीं।** हाइड्रेशन बेमेल जो आपके स्थानीय सिस्टम पर कभी प्रकट नहीं होता।
+- **लोकेल से मुद्रा का अनुमान लगाना।** `fr-FR` हमेशा यूरो नहीं होता है।
+- **दृश्यमान स्ट्रिंग्स पर सादा `sort()`.** हमेशा `Intl.Collator` का उपयोग करें।
+- **महीने या दिन के नामों को हार्डकोड करना।** वे हर भाषा के लिए CLDR में पहले से ही उपलब्ध हैं।
+- **सापेक्ष समय के लिए `numeric: "always"` बनाए रखना।** इससे "कल" के बजाय अप्राकृतिक "1 दिन पहले" मिलता है।
+
+## आगे पढ़ें
+
+- [फ़ॉर्मेटर्स और लोकेल उपयोगिताएँ: `number`, `currency`, `date`, `relativeTime`, `list`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/formatters.md)
+- [कॉन्फ़िगरेशन संदर्भ](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/configuration.md)
+- [फ्रेमवर्क में बेंचमार्क रिपोर्ट](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/benchmark/index.md)
+- [react-intl कम्पैट एडॉप्टर](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/react-intl.md)
+- [ICU संदेश प्रारूप: बहुवचन, चयन और संख्या कंकाल](https://github.com/aymericzip/intlayer/blob/main/docs/blog/hi/icu_message_format.md)
+- [फ़ॉर्मेटर और बहुवचन कवरेज सहित अनुवादों का परीक्षण कैसे करें](https://github.com/aymericzip/intlayer/blob/main/docs/blog/hi/i18n_testing_strategies.md)
+- [अंतर्राष्ट्रीयकरण वास्तव में क्या कवर करता है](https://github.com/aymericzip/intlayer/blob/main/docs/blog/hi/what_is_internationalization.md)

package/blog/hi/detecting_missing_translations.md

@@ -0,0 +1,202 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "उपयोगकर्ताओं से पहले अनुपस्थित अनुवादों का पता कैसे लगाएं"
+description: अनुपस्थित अनुवाद चुपचाप विफल हो जाते हैं। फ़ॉलबैक उन्हें क्यों छुपाता है, चार पहचान परतें जो वास्तव में काम करती हैं, और अनुवाद न की गई कुंजी पर बिल्ड को कैसे विफल करें।
+keywords:
+  - अनुपस्थित अनुवाद खोजें
+  - अनुपस्थित अनुवाद कुंजियाँ
+  - i18n ऑडिट
+  - गैर-अनुवादित स्ट्रिंग्स
+  - अनुवाद कवरेज
+  - i18n lint
+slugs:
+  - blog
+  - detecting-missing-translations
+author: aymericzip
+---
+
+# उपयोगकर्ताओं से पहले अनुपस्थित अनुवादों का पता कैसे लगाएं
+
+एक गायब अनुवाद शायद ही कभी कोई अपवाद फेंकता है। आपके सेटअप के आधार पर यह या तो जापानी उपयोगकर्ता को अंग्रेज़ी स्ट्रिंग दिखाता है, या लाइव पेज पर `checkout.summary.total` प्रिंट करता है। दोनों शिप हो जाते हैं, दोनों कोड समीक्षा पास कर लेते हैं, और दोनों आपके बजाय ग्राहक द्वारा खोजे जाते हैं।
+
+## विषय सूची
+
+<TOC/>
+
+## यह लागू होता है चाहे आप किसी भी लाइब्रेरी का उपयोग करें
+
+यहाँ कुछ भी किसी एक स्टैक के लिए विशिष्ट नहीं है। नीचे दी गई पहचान परतें i18next, react-i18next, next-intl, react-intl, vue-i18n, next-translate या Lingui पर समान रूप से काम करती हैं, क्योंकि वे सभी कुंजियों को एक ही तरह से हल करती हैं और एक ही तरह से विफल होती हैं।
+
+टूलिंग भी पोर्टेबल है। यदि आपके संदेश आज JSON कैटलॉग में रहते हैं, तो [Sync JSON प्लगइन](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/plugins/sync-json.md) Intlayer को उन फ़ाइलों पर इंगित करता है, जिससे आपको अपनी सामग्री को स्थानांतरित किए बिना या एक भी आयात बदले बिना ऑडिट, फिल और टेस्ट कमांड मिलते हैं:
+
+```ts fileName="intlayer.config.ts"
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config = {
+  plugins: [
+    syncJSON({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.json`,
+      format: "i18next", // या next-intl / react-intl के लिए "icu"
+    }),
+  ],
+};
+
+export default config;
+```
+
+यदि आप चाहते हैं कि रनटाइम API भी समान रहे, तो [कम्पैट एडॉप्टर](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/index.md) बंडलर स्तर पर `useTranslation`, `$t` और मित्रों को एलियास करते हैं। किसी भी तरह, नीचे दिए गए आदेशों को विचार के एक कार्यान्वयन के रूप में समझें, आवश्यकता के रूप में नहीं।
+
+## वे अदृश्य क्यों हैं
+
+प्रत्येक i18n लाइब्रेरी एक ही श्रृंखला के माध्यम से एक कुंजी को हल करती है: सक्रिय लोकेल देखें, डिफ़ॉल्ट पर वापस जाएं, और यदि वह विफल रहता है, तो कुंजी को ही वापस कर दें। वह अंतिम कदम ही समस्या है। कोई त्रुटि नहीं है, उत्पादन में कोई चेतावनी नहीं है, और कोई असफल परीक्षण नहीं है, क्योंकि पाइपलाइन में कुछ भी गायब कुंजी को असामान्य नहीं मानता है।
+
+फ़ॉलबैक इसे बेहतर बनाने के बजाय बदतर बना देता है। एक पृष्ठ जो चुपचाप अंग्रेज़ी में प्रस्तुत होता है, वह एक अंग्रेज़ी बोलने वाले डेवलपर और आपके पास मौजूद प्रत्येक स्वचालित जांच के लिए ठीक दिखता है। बग केवल उस व्यक्ति को दिखाई देता है जो परिणाम नहीं पढ़ सकता है।
+
+तो सवाल यह नहीं है कि "मैं रनटाइम पर गायब अनुवादों को कैसे संभालूँ"। यह है "मैं गायब अनुवाद को मर्ज करना असंभव कैसे बनाऊं"।
+
+## चार स्थान जहाँ आप उन्हें पकड़ सकते हैं
+
+प्रत्येक परत कुछ ऐसा पकड़ती है जो अन्य नहीं पकड़ पाती हैं। आप एक से अधिक चाहते हैं।
+
+| परत              | क्या पकड़ती है                                           | क्या चूक जाती है                                      |
+| :--------------- | :------------------------------------------------------- | :---------------------------------------------------- |
+| प्रकार (Types)   | वे कुंजियाँ जो बिल्कुल मौजूद नहीं हैं                    | एक कुंजी जो मौजूद है लेकिन `ja` में अनुवादित नहीं है  |
+| लिंट (Lint)      | हार्डकोडेड स्ट्रिंग्स जो अनुवाद के लिए कभी नहीं भेजी गईं | कैटलॉग से गायब कुंजियाँ                               |
+| ऑडिट (Audit)     | प्रत्येक घोषित कुंजी में लोकेल कवरेज                     | वह पाठ जिसे कभी अनुवाद योग्य नहीं बनाया गया           |
+| रेंडरिंग परीक्षण | कुंजियाँ जो हल होती हैं लेकिन गलत रेंडर होती हैं         | वह सब कुछ जो किसी परीक्षण द्वारा कवर नहीं किया गया है |
+
+अधिकांश टीमों के पास जो अंतर है वह तीसरी पंक्ति है: वे जानते हैं कि उनकी कुंजियाँ मान्य हैं, लेकिन कुछ भी यह जाँच नहीं करता है कि सभी अठारह लोकेल में वास्तव में एक मान है।
+
+## परत 1: कुंजी को एक प्रकार बनाएं, स्ट्रिंग नहीं
+
+`t("checkout.summry.total")` एक टाइपो है जो संकलित होता है। यदि आपकी कुंजियाँ सादी स्ट्रिंग हैं, तो प्रत्येक नाम बदलना एक रनटाइम जोखिम है और प्रत्येक विलोपन एक अनाथ छोड़ देता है।
+
+टाइप की गई कुंजियाँ इसे बिल्ड त्रुटि में बदल देती हैं। `react-i18next` घोषणा विलय के माध्यम से इसका समर्थन करता है, `next-intl` आपके संदेश के आकार से अनुमान लगाता है, Lingui स्रोत पाठ से आईडी प्राप्त करता है, और Intlayer घोषणा फ़ाइलों से प्रकार उत्पन्न करता है। वे सभी काम करते हैं; जो भिन्न है वह यह है कि आपको कितना तार लगाना है।
+
+यह परत आवश्यक है और पर्याप्त नहीं है। प्रकार आपके डिफ़ॉल्ट कैटलॉग के आकार का वर्णन करते हैं। वे इस बारे में कुछ नहीं कहते हैं कि क्या कोरियाई में उस कुंजी का कोई मान है।
+
+## परत 2: उन स्ट्रिंग्स को लिंट करें जो कभी कुंजियाँ नहीं बनीं
+
+जो अनुवाद आपको नहीं मिल पाता वह अक्सर वह होता है जिसे कभी बाह्य रूप नहीं दिया गया था। किसी घटक में हार्डकोड किया गया लेबल प्रत्येक कैटलॉग-आधारित ऑडिट के लिए अदृश्य होता है, क्योंकि जहाँ तक टूलिंग का संबंध है, स्ट्रिंग मौजूद ही नहीं है।
+
+Intlayer का ESLint प्लगइन इसे `no-raw-text` के साथ कवर करता है, साथ ही रिवर्स केस के लिए `no-unused-content`: सामग्री घोषित की गई और अब किसी भी चीज़ द्वारा नहीं पढ़ी गई।
+
+```js fileName="eslint.config.mjs"
+import intlayer from "@intlayer/eslint-plugin";
+
+export default [
+  intlayer.configs.recommended,
+  {
+    rules: {
+      "@intlayer/no-raw-text": "error",
+      "@intlayer/no-unused-content": "warn",
+    },
+  },
+];
+```
+
+`no-unused-content` वह है जो कैटलॉग को हमेशा बढ़ने से रोकता है। मृत कुंजियाँ कोई शुद्धता बग नहीं हैं, लेकिन वे वही हैं जो अनुवाद विक्रेता के चालान को आवश्यकता से बड़ा बनाती हैं। [ESLint प्लगइन दस्तावेज़](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/eslint.md) में पूर्ण नियम सूची।
+
+## परत 3: ऑडिट लोकेल कवरेज
+
+यह वह परत है जो वास्तविक प्रश्न का उत्तर देती है। Intlayer इसे CLI कमांड के रूप में भेजता है:
+
+```bash packageManager="npm"
+npx intlayer content test
+```
+
+यह आपके कॉन्फ़िगर किए गए लोकेल और घोषित शब्दकोशों को पढ़ता है, फिर रिपोर्ट करता है कि कौन सी कुंजियाँ किस लोकेल में और किस फ़ाइल में गायब हैं।
+
+इसे किसी भी चीज़ में जोड़ने से पहले जानने योग्य एक विवरण: **CLI एक रिपोर्ट प्रिंट करता है लेकिन विफलता पर गैर-शून्य से बाहर नहीं निकलता है।** यदि आप इसे एक लाल बिल्ड की उम्मीद में पाइपलाइन में छोड़ देते हैं, तो आपको टेक्स्ट की एक दीवार के साथ एक हरा बिल्ड मिलेगा जिसे कोई नहीं पढ़ता है। गेटिंग के लिए, इसके बजाय प्रोग्रामेटिक API का उपयोग करें, जिसे नीचे कवर किया गया है।
+
+## परत 4: इसे परीक्षण सूट में जोर दें
+
+`listMissingTranslations()` आपको डेटा के रूप में वही ऑडिट देता है, जो आप बिल्ड गेट के लिए चाहते हैं।
+
+```ts fileName="i18n.test.ts"
+/* @vitest-environment node */
+import { listMissingTranslations } from "intlayer/cli";
+import { describe, expect, it } from "vitest";
+
+describe("translations", () => {
+  it("has no missing required locales", async () => {
+    const result = await listMissingTranslations();
+
+    if (result.missingRequiredLocales.length > 0) {
+      console.log(result.missingTranslations);
+    }
+
+    expect(result.missingRequiredLocales).toHaveLength(0);
+  });
+});
+```
+
+तीन फ़ील्ड वापस आते हैं, और भेद मायने रखता है:
+
+- `missingTranslations`: प्रति कुंजी, कौन से लोकेल गायब हैं और किस फ़ाइल से। परीक्षण विफल होने पर आप यही प्रिंट करते हैं।
+- `missingLocales`: प्रत्येक कुंजी में संघ।
+- `missingRequiredLocales`: आपके कॉन्फ़िगरेशन में `requiredLocales` तक सीमित, या यदि आपने इसे सेट नहीं किया है तो सभी लोकेल।
+
+## `requiredLocales` उपयोगी घुंडी है
+
+अठारह लोकेल शिपिंग का मतलब यह नहीं है कि तैनात करने के लिए सभी अठारह पूर्ण होने चाहिए। अधिकांश टीमों के पास एक स्तर होता है जो रिलीज़ को रोकता है और एक स्तर जो सर्वोत्तम प्रयास होता है।
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [
+      Locales.ENGLISH,
+      Locales.FRENCH,
+      Locales.JAPANESE,
+      Locales.POLISH,
+    ],
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+`requiredLocales` के बिना, प्रत्येक घोषित लोकेल की आवश्यकता होती है और आपका बिल्ड तब तक लाल रहता है जब तक कि अंतिम भाषा न आ जाए। आमतौर पर इसी तरह टीमें जांच को पूरी तरह से अक्षम कर देती हैं, जो कि इसे न रखने से भी बदतर है।
+
+## उन लोगों को खोजना जो पहले से ही उत्पादन में हैं
+
+ऊपर दी गई परतें नए अंतरालों को रोकती हैं। पहले से शिप किए गए ऐप के लिए, दो चीज़ें मदद करती हैं।
+
+**स्यूडोलॉकालाइज़ेशन।** एक ऐसा लोकेल चलाएँ जहाँ प्रत्येक स्ट्रिंग बदल दी जाती है, उदाहरण के लिए `[!!! Ĉĥéçķöũţ !!!]`। सादे अंग्रेज़ी में प्रस्तुत होने वाली कोई भी चीज़ हार्डकोड की जाती है। यह दस मिनट में वह ढूंढ लेता है जो एक कैटलॉग ऑडिट संरचनात्मक रूप से नहीं देख सकता, क्योंकि यह कैटलॉग के बजाय प्रस्तुत पृष्ठ का परीक्षण करता है।
+
+**अपनी खुद की साइट क्रॉल करें।** यदि आप स्थानीयकृत URL प्रदान करते हैं, तो प्रति लोकेल एक नमूना प्राप्त करें और अपनी डिफ़ॉल्ट-भाषा स्ट्रिंग्स के लिए HTML को ग्रैप करें। `/ja/` में "Add to cart" वाला पेज या तो एक गायब अनुवाद है या एक फ़ॉलबैक जिसके बारे में आप नहीं जानते थे।
+
+```bash
+curl -s https://example.com/ja/checkout | grep -c "Add to cart"
+```
+
+## अंतराल को भरना
+
+एक बार जब आप जान जाते हैं कि क्या गायब है, तो `intlayer fill` खाली प्रविष्टियों को भरता है, और `autoFill` विकल्प सामग्री घोषित होने पर प्रति-लोकेल फ़ाइलें उत्पन्न कर सकता है। [autoFill](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/autoFill.md) देखें।
+
+इसके बारे में स्पष्ट होना चाहिए: मशीन से भरे अनुवाद एक _दृश्यमान_ अंतर को एक _अदृश्य_ अंतर में बदल देते हैं। कुंजी का अब एक मान है, इसलिए ऑडिट हरा हो जाता है, और किसी ने शब्दों की समीक्षा नहीं की। रिलीज़ को अनब्लॉक करने के लिए इसका उपयोग करें, फिर ग्राहक द्वारा निर्णय लेने से पहले पढ़ी जाने वाली किसी भी चीज़ के लिए आउटपुट को एक मानव के माध्यम से रूट करें। यह एक पाड़ है, उत्तर नहीं।
+
+## सामान्य गलतियाँ
+
+- **फ़ॉलबैक को एक सुविधा के रूप में मानना।** यह एक रेंडरिंग रणनीति है, सुरक्षा जाल नहीं। एक मूक अंग्रेज़ी पृष्ठ एक ऐसा बग है जो किसी को रिपोर्ट नहीं करता है।
+- **CI को गेट करने के लिए CLI रिपोर्ट पर भरोसा करना।** `intlayer content test` शून्य से बाहर निकलता है। एक परीक्षण में जोर दें।
+- **प्रत्येक लोकेल की आवश्यकता।** पहली बार जब कोई रिलीज़ आधी-अधूरी भाषा द्वारा अवरुद्ध होती है, तो जांच अक्षम हो जाती है।
+- **कैटलॉग का ऑडिट करना लेकिन कभी रेंडर किए गए पेज का नहीं।** हार्डकोडेड स्ट्रिंग्स परिभाषा के अनुसार कैटलॉग ऑडिट के लिए अदृश्य हैं।
+- **परीक्षणों में केवल डिफ़ॉल्ट लोकेल की जाँच करना।** वह एकमात्र लोकेल जो गायब नहीं हो सकता।
+- **मशीन फिल को लूप बंद करने देना।** हरा ऑडिट, असमीक्षित प्रतिलिपि।
+
+## आगे पढ़ें
+
+- [अपनी सामग्री का परीक्षण: CLI ऑडिट, प्रोग्रामेटिक API और UI असर्शन](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/testing.md)
+- [ESLint प्लगइन नियम, जिनमें `no-raw-text` और `no-unused-content` शामिल हैं](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/eslint.md)
+- [autoFill: प्रति-लोकेल घोषणा फ़ाइलें उत्पन्न करना](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/autoFill.md)
+- [कॉन्फ़िगरेशन संदर्भ: `locales`, `requiredLocales`, `defaultLocale`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/configuration.md)
+- [फ्रेमवर्क में बेंचमार्क रिपोर्ट](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/benchmark/index.md)
+- [ड्रॉप-इन i18next कम्पैट एडॉप्टर](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/i18next.md)
+- [अंतर्राष्ट्रीयकरण वास्तव में क्या कवर करता है](https://github.com/aymericzip/intlayer/blob/main/docs/blog/hi/what_is_internationalization.md)
+- [प्रति-घटक बनाम केंद्रीकृत i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/hi/per-component_vs_centralized_i18n.md)