तिथियों और संख्याओं को स्थानीयकरण की आवश्यकता क्यों है

यदि आप वैश्विक स्तर पर शिप करते हैं, तो वही स्ट्रिंग विभिन्न उपयोगकर्ताओं के लिए अलग-अलग अर्थ रख सकती है: 12/01/2025, 1.234, 1,234, 12:00, 00:00। ये छोटे अंतर केवल सौंदर्यात्मक नहीं हैं—वे विश्वास, समझ और यहां तक कि कानूनी अनुपालन को प्रभावित करते हैं। यह गाइड बताता है कि तारीखों और संख्याओं का स्थानीयकरण क्यों आवश्यक है, वास्तव में स्थानीयता के अनुसार क्या बदलता है, और इसे आपके उत्पाद में सही तरीके से कैसे लागू किया जाए।

स्थानीयता के अनुसार क्या बदलता है

• तारीखें: क्रम (MDY बनाम DMY बनाम YMD), विभाजक, महीने/दिन के नाम; कुछ बाजार गैर-ग्रेगोरियन कैलेंडर का उपयोग करते हैं।
• समय: 12-घंटे बनाम 24-घंटे की घड़ी, AM/PM मार्कर, समय क्षेत्र, दिन के उजाले की बचत के नियम, सप्ताह के दिन की शुरुआत (रविवार बनाम सोमवार)।
• संख्याएँ: दशमलव विभाजक (. बनाम ,), समूह शैली (1,234 बनाम 1.234 बनाम 1 234), भारतीय समूह (1,23,456), गैर-ब्रेकिंग स्पेस, माइनस/प्लस शैली (हाइफ़न बनाम वास्तविक माइनस −)।
• मुद्रा: प्रतीक बनाम ISO कोड, प्रतीक का स्थान (उपसर्ग/प्रत्यय), संकीर्ण बनाम चौड़ा अंतराल, दशमलव सटीकता (0, 2, या 3+), लेखांकन नकारात्मक (जैसे, (1 234,56 €))।
• प्रतिशत और इकाइयाँ: अंतराल और संकेत स्थान (50% बनाम 50 %), इकाइयों के लिए स्थानीय नाम, मीट्रिक बनाम इंपीरियल।

व्यापार प्रभाव

• विश्वास और रूपांतरण: कीमतें, शुल्क, और तारीखें जो “गलत दिखती हैं” खरीदारी को कम करती हैं और ग्राहक छोड़ने की दर को बढ़ाती हैं।
• परिचालन जोखिम: गलत पढ़ी गई तारीखें बुकिंग या समय सीमा को बदल सकती हैं; पार्सिंग त्रुटियाँ चालान, निर्यात, और विश्लेषण को तोड़ सकती हैं।
• अनुपालन: गलत प्रारूपों वाले वित्तीय दस्तावेज चालान, कर, या रिपोर्टिंग नियमों का उल्लंघन कर सकते हैं।
• समर्थन भार: उपयोगकर्ता समय, मुद्राओं, और संख्या इनपुट को स्पष्ट करने के लिए टिकट खोलते हैं जो अपेक्षाओं से मेल नहीं खाते।

वास्तविक दुनिया की घटना

एक यूरोपीय यात्रा बुकिंग प्लेटफॉर्म ने प्रस्थान तिथियों को 01/03/2024 के रूप में बिना स्थानीयता संदर्भ के प्रदर्शित किया। अमेरिकी ग्राहकों ने इसे “3 जनवरी” के रूप में समझा जबकि यूके और यूरोपीय ग्राहकों ने इसे “1 मार्च” के रूप में पढ़ा।

प्रभाव:

• 12% अंतरराष्ट्रीय बुकिंग गलत तारीखों के लिए की गईं
• ग्राहक सेवा को एक सप्ताह में 3,400+ स्पष्टीकरण टिकट प्राप्त हुए
• $2.3M रिफंड और पुनः बुकिंग शुल्क में
• 8% प्रभावित ग्राहक प्रतिस्पर्धियों के पास चले गए

मूल कारण: ईमेल पुष्टियों में हार्ड-कोडेड DD/MM/YYYY फॉर्मेट जबकि वेबसाइट ने अमेरिकी उपयोगकर्ताओं के लिए MM/DD/YYYY का उपयोग किया। इस समस्या को ठीक करने में केवल 3 घंटे की इंजीनियरिंग समय की आवश्यकता थी—अस्पष्टता की लागत रोकथाम की तुलना में 800 गुना अधिक थी।

सीख: संदर्भ के बिना तिथियाँ किसी भी वैश्विक उत्पाद के लिए एक समय बम हैं।

सामान्य गलतियाँ

• हार्ड‑कोडेड फॉर्मेट: MM/DD/YYYY या 1,234.56 को UI, ईमेल, PDF, या CSV निर्यात में शामिल करना।
• स्थानीयकृत स्ट्रिंग्स को स्टोर करना: “Dec 1, 2025” को ISO समय के बजाय सहेजना पार्सिंग बग्स और टाइमज़ोन ड्रिफ्ट का कारण बनता है।
• सरल पार्सिंग: सर्वर लोकेल डिफॉल्ट्स का उपयोग करना; विभाजक या 12/24‑घंटे की घड़ियों को मान लेना।
• स्ट्रिंग संयोजन: “राशि + मुद्रा” को "$" + 1234.56 की तरह बनाना बजाय लोकेल‑सजग फॉर्मेटिंग के।
• टाइमज़ोन अस्पष्टता: समय-संवेदनशील कार्यों के लिए स्थानीय समय को बिना स्पष्ट ज़ोन के दिखाना।
• ब्राउज़र असंगति: Safari, Firefox, और Chrome तारीखों/संख्याओं को अलग-अलग फॉर्मेट कर सकते हैं; हमेशा सभी लक्षित ब्राउज़रों पर परीक्षण करें।
• सर्वर-साइड रेंडरिंग अंतराल: Node.js बिना पूर्ण ICU डेटा (node --with-intl=full-icu) के अधूरी या गलत फॉर्मेटिंग उत्पन्न करता है।
• प्रदर्शन जाल: लूप्स या रेंडर चक्रों में नए Intl.* उदाहरण बनाना बजाय फॉर्मेटर्स को कैश करने के।

सर्वोत्तम प्रथाएँ

• कैनोनिकल मानों को संग्रहीत करें: तारीख/समय को UTC में ISO‑8601 के रूप में; पैसे को छोटे यूनिट्स (सेंट्स) या उच्च-सटीक दशमलव के रूप में।
• उपयोगकर्ता के स्थानीय भाषा के अनुसार प्रस्तुत करें: प्रदर्शन के लिए स्थानीय भाषा-सक्षम API (जैसे, Intl.DateTimeFormat, Intl.NumberFormat) का उपयोग करें।
• स्थानीय भाषा के अनुसार सत्यापन और पार्स करें: जहां उपयुक्त हो वहां स्थानीय भाषा इनपुट स्वीकार करें; उपयोगकर्ताओं को मार्गदर्शन करने के लिए प्लेसहोल्डर/उदाहरण दिखाएं।
• समय के साथ स्पष्ट रहें: समय क्षेत्र संक्षेप या ऑफसेट दिखाएं; जहां परिणाम समय पर निर्भर करते हैं वहां उपयोगकर्ता चयन की अनुमति दें।
• मुद्रा स्पष्टता: जहां अस्पष्टता होती है वहां ISO कोड को प्राथमिकता दें; स्थानीय भाषा के अनुसार प्रतीक प्लेसमेंट और स्पेसिंग का सम्मान करें।
• स्वरूपण को केंद्रीकृत करें: सभी सतहों (UI, ईमेल, PDF, निर्यात) के लिए एक उपयोगिता परत ताकि स्थिरता सुनिश्चित हो सके।
• फॉर्मेटर्स को कैश करें: Intl.* कंस्ट्रक्टर कॉल महंगे होते हैं; एक बार बनाएं और प्रत्येक स्थानीय भाषा के लिए उदाहरणों को पुनः उपयोग करें।

कब स्थानीय भाषा में अनुवाद नहीं करना है

हर चीज़ को स्थानीय भाषा में अनुवाद नहीं करना चाहिए। यहां ऐसे परिदृश्य हैं जहां स्थिर, मशीन-पठनीय प्रारूप बेहतर होते हैं:

• मशीन-पठनीय निर्यात: डेटा पाइपलाइन या एनालिटिक्स टूल द्वारा उपभोग किए जाने वाले CSV फाइलों को एक स्थिर प्रारूप (जैसे, ISO-8601 तारीखें, दशमलव विभाजक के रूप में पीरियड) का उपयोग करना चाहिए। इस प्रारूप को निर्यात हेडर या README फाइलों में स्पष्ट रूप से दस्तावेज करें।
• API प्रतिक्रियाएं: REST/GraphQL API को तारीखें ISO-8601 स्ट्रिंग्स के रूप में और संख्याएं मानक JSON प्रारूप में लौटानी चाहिए। क्लाइंट्स को उनके उपयोगकर्ता की प्राथमिकताओं के आधार पर स्थानीय भाषा में अनुवाद करने दें।
• आंतरिक लॉग और मेट्रिक्स: लॉग, मॉनिटरिंग डैशबोर्ड, और डेटाबेस क्वेरी पार्सिंग, एकत्रीकरण, और अलर्टिंग के लिए स्थिर प्रारूपों से लाभान्वित होते हैं। ISO-8601 और मानक संख्यात्मक प्रारूपों का उपयोग करें।
• कैनोनिकल पहचानकर्ता: लेन-देन आईडी, ऑर्डर नंबर, या संदर्भ जो उपयोगकर्ताओं को स्थानीय भाषाओं में संवाद करने की आवश्यकता हो सकती है, उन्हें स्थानीय भाषा-विशिष्ट स्वरूपण से बचना चाहिए।

अनुमान का नियम: मनुष्यों के लिए सामग्री पढ़ने के लिए स्थानीय भाषा में अनुवाद करें; डेटा प्रोसेसिंग के लिए मशीनों के लिए मानक प्रारूपों का उपयोग करें।

कार्यान्वयन योजना

1. ऑडिट सतहें: UI, ईमेल, PDFs, CSV/Excel निर्यात, विश्लेषिकी, लॉग में इन्वेंटरी तिथियाँ, समय, संख्या, मुद्रा।
2. स्थानीयता परिभाषित करें: समर्थित स्थानीयताओं की सूची बनाएं और डिफ़ॉल्ट फॉलबैक निर्दिष्ट करें; प्रत्येक स्थानीयता के लिए 12/24‑घंटे की नीति निर्दिष्ट करें।
3. उपयोगिताएँ बनाएं: Intl.* APIs (या एक लाइब्रेरी) को साझा हेल्पर्स और परीक्षणों के साथ रैप करें; फॉर्मेटर कैशिंग लागू करें।
4. इनपुट रणनीति: स्थानीयता प्रारूपों को स्वीकार और मान्य करने के लिए फॉर्म अपडेट करें; कच्चे इनपुट के साथ-साथ कैनोनिकल मानों को स्टोर करें।
5. सामग्री नियम: छोटे/लंबे तिथियों, सापेक्ष तिथियों, मुद्रा प्रदर्शन, और प्रतिशत प्रारूपण के लिए शैली का दस्तावेजीकरण करें।
6. रोलआउट: सबसे अधिक ट्रैफ़िक और सबसे अधिक जोखिम वाली सतहों को पहले परिवर्तित करें; यदि आवश्यक हो तो एक फीचर फ्लैग के पीछे शिप करें।

परीक्षण रणनीति

मैनुअल QA के अलावा, प्रतिगमन को रोकने के लिए स्वचालित परीक्षण लागू करें:

• स्नैपशॉट परीक्षण: प्रत्येक समर्थित स्थानीयता के लिए प्रारूपित आउटपुट को फ्रीज़ करें। परिवर्तन समीक्षा को ट्रिगर करते हैं ताकि यह सुनिश्चित हो सके कि वे इरादतन हैं।
• राउंड-ट्रिप परीक्षण: सत्यापित करें कि format → parse → format स्थिर परिणाम उत्पन्न करता है। सटीकता हानि या अस्पष्ट प्रारूपों को पकड़ता है।
• किनारे के मामले: नकारात्मक संख्या, शून्य, बहुत बड़ी संख्या (अरब/खरब), DST संक्रमण, लीप वर्ष, और सीमा तिथियों (जनवरी 1, दिसंबर 31) का परीक्षण करें।
• क्रॉस-ब्राउज़र मान्यता: Chrome, Firefox, Safari, और Edge पर स्वचालित परीक्षण करें ताकि रेंडरिंग अंतर को पकड़ सकें।
• स्थानीयता फॉलबैक: जब असमर्थित स्थानीयताओं का अनुरोध किया जाता है तो सुचारू गिरावट की पुष्टि करें।
• प्रदर्शन बेंचमार्क: फॉर्मेटर निर्माण लागत को मापें; सुनिश्चित करें कि उत्पादन में कैशिंग काम कर रही है।

प्रदर्शन सुझाव

Intl.* APIs शक्तिशाली हैं लेकिन यदि गलत तरीके से उपयोग किए जाते हैं तो धीमे हो सकते हैं। इन दिशानिर्देशों का पालन करें:

// ❌ खराब: हर कॉल पर नया फॉर्मेटर बनाता है
function formatPrice(amount, locale) {
  return new Intl.NumberFormat(locale, { 
    style: 'currency', 
    currency: 'USD' 
  }).format(amount);
}

// ✅ अच्छा: स्थानीय भाषा के अनुसार फॉर्मेटर्स को कैश करें const formatters = new Map(); function getFormatter(locale) { if (!formatters.has(locale)) { formatters.set(locale, new Intl.NumberFormat(locale, { style: ‘currency’, currency: ‘USD’ })); } return formatters.get(locale); }

function formatPrice(amount, locale) { return getFormatter(locale).format(amount); }

- **फॉर्मेटर इंस्टेंस को कैश करें**: `Intl.*` निर्माण महंगा है (~1–5ms); मौजूदा इंस्टेंस के साथ फॉर्मेटिंग तेज है (~0.01ms)।
- **लूप्स से बचें**: कभी भी `map()`, `forEach()`, या रेंडर लूप्स के अंदर फॉर्मेटर्स न बनाएं।
- **स्थानीय भाषा डेटा को लेज़ी-लोड करें**: वेब ऐप्स के लिए, केवल आवश्यक स्थानीय भाषाओं को लोड करने के लिए कोड-स्प्लिटिंग पर विचार करें, जिससे बंडल आकार कम हो।
- **सर्वर-साइड**: प्रत्येक अनुरोध/प्रतिक्रिया चक्र के लिए एकल फॉर्मेटर का उपयोग करें; बड़े डेटा सेट में प्रति आइटम निर्माण से बचें।

## QA चेकलिस्ट

- तिथियाँ `en-US`, `en-GB`, `de-DE`, `fr-FR`, `hi-IN`, `ja-JP`, `ar-EG` में अस्पष्ट नहीं हैं।
- समय सही 12/24‑घंटे की परंपरा का उपयोग करता है; AM/PM मार्कर अपेक्षित स्थान पर दिखाई देते हैं; समय-गंभीर प्रवाह के लिए टाइमज़ोन दिखाए जाते हैं।
- संख्याएँ सही दशमलव और समूह विभाजक का उपयोग करती हैं; जहाँ मानक है वहाँ गैर‑ब्रेकिंग स्पेस (जैसे `fr-FR`)।
- मुद्रा सही प्रतीक/कोड, स्थान और दशमलव सटीकता प्रत्येक स्थानीय भाषा के लिए दिखाती है; नकारात्मक सही ढंग से प्रदर्शित होते हैं।
- इनपुट उपयोगकर्ता स्थानीय भाषा डेटा को स्वीकार और पार्स करते हैं (या स्पष्ट रूप से समर्थित प्रारूप लागू करते हैं); सत्यापन संदेश स्थानीय भाषा के प्रति जागरूक होते हैं।
- निर्यात (CSV/PDF) स्थानीय भाषा अपेक्षाओं से मेल खाते हैं या मशीन उपभोग के लिए निश्चित प्रारूपों को स्पष्ट रूप से दस्तावेज़ करते हैं।
- क्रॉस-ब्राउज़र: तिथियाँ, समय और संख्याएँ Chrome, Firefox, Safari, और Edge पर लगातार रेंडर होती हैं।
- प्रदर्शन: लूप्स में फॉर्मेटर निर्माण नहीं; रेंडर्स के बीच कैश किए गए इंस्टेंस का पुन: उपयोग।

## कोड उदाहरण

### JavaScript

```js
// तिथियाँ
const date = new Date('2025-01-12T00:00:00Z');

console.log(new Intl.DateTimeFormat('en-US', { dateStyle: 'short', timeZone: 'UTC' }).format(date));
// → 1/12/25

console.log(new Intl.DateTimeFormat('en-GB', { dateStyle: 'short', timeZone: 'UTC' }).format(date));
// → 12/01/2025 (दिन/माह/वर्ष)

console.log(new Intl.DateTimeFormat('ja-JP', { dateStyle: 'medium', timeZone: 'UTC' }).format(date));
// → 2025/01/12

// समय क्षेत्र के साथ समय प्रदर्शन
const time = new Date('2025-01-12T18:05:00Z');

console.log(new Intl.DateTimeFormat('en-US', { 
  dateStyle: 'short',
  timeStyle: 'short', 
  timeZone: 'America/New_York',
  timeZoneName: 'short' 
}).format(time));
// → 1/12/25, 1:05 PM EST

console.log(new Intl.DateTimeFormat('de-DE', { 
  timeStyle: 'short', 
  timeZone: 'Europe/Berlin', 
  hour12: false 
}).format(time));
// → 19:05

// संख्याएँ
const n = 1234.56;
console.log(new Intl.NumberFormat('en-US').format(n)); // → 1,234.56
console.log(new Intl.NumberFormat('de-DE').format(n)); // → 1.234,56
console.log(new Intl.NumberFormat('fr-FR').format(n)); // → 1 234,56 (NBSP समूह विभाजक के रूप में)

// भारतीय संख्या प्रणाली
console.log(new Intl.NumberFormat('hi-IN').format(1234567.89)); // → 12,34,567.89

// मुद्रा
console.log(new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(n));
// → $1,234.56

console.log(new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(n));
// → 1.234,56 €

console.log(new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }).format(1234));
// → ¥1,234 (कोई दशमलव नहीं)

// प्रतिशत और इकाइयाँ
console.log(new Intl.NumberFormat('en-US', { style: 'percent', maximumFractionDigits: 0 }).format(0.5));
// → 50%
console.log(new Intl.NumberFormat('fr-FR', { style: 'percent', maximumFractionDigits: 0 }).format(0.5));
// → 50 %

// फॉर्मेटर कैशिंग उदाहरण
class LocaleFormatter {
  constructor() {
    this.cache = new Map();
  }

  getDateFormatter(locale, options) {
    const key = `date:${locale}:${JSON.stringify(options)}`;
    if (!this.cache.has(key)) {
      this.cache.set(key, new Intl.DateTimeFormat(locale, options));
    }
    return this.cache.get(key);
  }
}

formatDate(date, locale, options = { dateStyle: 'medium' }) {
    return this.getDateFormatter(locale, options).format(date);
  }
}

const formatter = new LocaleFormatter();
console.log(formatter.formatDate(new Date(), 'en-US')); // → Jan 12, 2025
console.log(formatter.formatDate(new Date(), 'fr-FR')); // → 12 janv. 2025

Python

from babel.dates import format_date, format_time, format_datetime
from babel.numbers import format_number, format_currency, format_percent
from datetime import datetime
import pytz

# तारीखें
date = datetime(2025, 1, 12)
print(format_date(date, format='short', locale='en_US'))  # → 1/12/25
print(format_date(date, format='short', locale='en_GB'))  # → 12/01/2025
print(format_date(date, format='medium', locale='ja_JP')) # → 2025/01/12

# समय क्षेत्र के साथ समय
tz_ny = pytz.timezone('America/New_York')
tz_berlin = pytz.timezone('Europe/Berlin')
time = datetime(2025, 1, 12, 18, 5, tzinfo=pytz.UTC)

print(format_datetime(time.astimezone(tz_ny), 'short', tzinfo=tz_ny, locale='en_US'))
# → 1/12/25, 1:05 PM

print(format_time(time.astimezone(tz_berlin), format='short', tzinfo=tz_berlin, locale='de_DE'))
# → 19:05

# संख्याएं
n = 1234.56
print(format_number(n, locale='en_US'))    # → 1,234.56
print(format_number(n, locale='de_DE'))    # → 1.234,56
print(format_number(n, locale='fr_FR'))    # → 1 234,56

# भारतीय संख्या प्रणाली
print(format_number(1234567.89, locale='hi_IN'))  # → 12,34,567.89

# मुद्रा
print(format_currency(n, 'USD', locale='en_US'))  # → $1,234.56
print(format_currency(n, 'EUR', locale='de_DE'))  # → 1.234,56 €
print(format_currency(1234, 'JPY', locale='ja_JP')) # → ¥1,234

# प्रतिशत
print(format_percent(0.5, locale='en_US'))  # → 50%
print(format_percent(0.5, locale='fr_FR'))  # → 50 %

Java

import java.text.NumberFormat;
import java.time.ZonedDateTime;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;
import java.util.Currency;

// तिथियाँ
ZonedDateTime date = ZonedDateTime.of(2025, 1, 12, 0, 0, 0, 0, ZoneId.of("UTC"));

DateTimeFormatter usFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT)
    .withLocale(Locale.US);
System.out.println(usFormatter.format(date)); // → 1/12/25

DateTimeFormatter gbFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT)
    .withLocale(Locale.UK);
System.out.println(gbFormatter.format(date)); // → 12/01/2025

DateTimeFormatter jpFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM)
    .withLocale(Locale.JAPAN);
System.out.println(jpFormatter.format(date)); // → 2025/01/12

// समय
ZonedDateTime time = ZonedDateTime.of(2025, 1, 12, 18, 5, 0, 0, ZoneId.of("UTC"));
ZonedDateTime timeNY = time.withZoneSameInstant(ZoneId.of("America/New_York"));

DateTimeFormatter usTimeFormatter = DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT)
    .withLocale(Locale.US);
System.out.println(usTimeFormatter.format(timeNY)); // → 1:05 PM

// संख्याएँ
double n = 1234.56;
NumberFormat usFormat = NumberFormat.getInstance(Locale.US);
System.out.println(usFormat.format(n)); // → 1,234.56

NumberFormat deFormat = NumberFormat.getInstance(Locale.GERMANY);
System.out.println(deFormat.format(n)); // → 1.234,56

NumberFormat frFormat = NumberFormat.getInstance(Locale.FRANCE);
System.out.println(frFormat.format(n)); // → 1 234,56

// मुद्रा
NumberFormat usCurrency = NumberFormat.getCurrencyInstance(Locale.US);
usCurrency.setCurrency(Currency.getInstance("USD"));
System.out.println(usCurrency.format(n)); // → $1,234.56

NumberFormat deCurrency = NumberFormat.getCurrencyInstance(Locale.GERMANY);
deCurrency.setCurrency(Currency.getInstance("EUR"));
System.out.println(deCurrency.format(n)); // → 1.234,56 € 

NumberFormat jpCurrency = NumberFormat.getCurrencyInstance(Locale.JAPAN); jpCurrency.setCurrency(Currency.getInstance(“JPY”)); System.out.println(jpCurrency.format(1234)); // → ¥1,234

### Go

```go
package main

import (
    "fmt"
    "time"
    "golang.org/x/text/language"
    "golang.org/x/text/message"
    "golang.org/x/text/number"
)

func main() {
    // Numbers
    n := 1234.56

    pUS := message.NewPrinter(language.AmericanEnglish)
    fmt.Println(pUS.Sprintf("%.2f", n)) // → 1,234.56

    pDE := message.NewPrinter(language.German)
    fmt.Println(pDE.Sprintf("%.2f", n)) // → 1.234,56

    pFR := message.NewPrinter(language.French)
    fmt.Println(pFR.Sprintf("%.2f", n)) // → 1 234,56

    // Currency (using number package)
    fmt.Println(pUS.Sprint(number.Decimal(n, number.Scale(2))))  // → 1,234.56

    // Dates - Go's time package uses layouts instead of locale formatting
    // For full i18n date formatting, use github.com/goodsign/monday or similar
    date := time.Date(2025, 1, 12, 0, 0, 0, 0, time.UTC)
    fmt.Println(date.Format("01/02/2006")) // US: 01/12/2025
    fmt.Println(date.Format("02/01/2006")) // EU: 12/01/2025
    fmt.Println(date.Format("2006/01/02")) // ISO: 2025/01/12
}

नोट: Go की मानक लाइब्रेरी में स्थानीय समर्थन सीमित है। उत्पादन उपयोग के लिए विचार करें:

• संख्या प्रारूपण के लिए golang.org/x/text
• स्थानीयकृत दिनांक/समय प्रारूपण के लिए github.com/goodsign/monday
• मुद्रा प्रबंधन के लिए github.com/bojanz/currency

उपयोगी संसाधन

• मानक: Unicode CLDR (स्थानीय डेटा मानक), IETF BCP 47 (स्थानीय पहचानकर्ता)
• प्रलेखन: MDN Intl Reference
• लाइब्रेरी:
  • Luxon (आधुनिक दिनांक/समय लाइब्रेरी i18n के साथ)
  • date-fns स्थानीय मॉड्यूल के साथ
  • Globalize.js (CLDR पर आधारित व्यापक i18n)
  • Format.js (React-केंद्रित i18n ICU संदेश सिंटैक्स के साथ)
• परीक्षण: Intl polyfill पुराने ब्राउज़रों के लिए

समापन

तारीखों और संख्याओं को सही तरीके से प्राप्त करना एक कम प्रयास, उच्च प्रभाव वाली जीत है: उच्च विश्वास, कम त्रुटियाँ, और एक सुचारू वैश्विक अनुभव। स्वरूपण को केंद्रीकृत करें, कैनोनिकल मानों को संग्रहीत करें, स्थानीय जागरूक एपीआई का उपयोग करें जहाँ आपके उपयोगकर्ता समय, पैसा, या संख्याएँ पढ़ते या टाइप करते हैं—और मशीन-पठनीय डेटा के लिए स्थानीयकरण को छोड़ने का समय जानें। उचित कैशिंग और परीक्षण के साथ, आप एक मजबूत प्रणाली बनाएंगे जो प्रदर्शन का त्याग किए बिना स्थानीयों में विस्तार करती है।