Package google.type

इंडेक्स

PostalAddress

डाक पता दिखाता हो. जैसे, डाक या पेमेंट के पते. डाक पता दिए जाने पर, डाक सेवा किसी परिसर, पीओ बॉक्स या ऐसे ही किसी दूसरे पते पर सामान डिलीवर कर सकती है. इसका इस्तेमाल भौगोलिक जगहों (सड़कों, शहरों, पहाड़ों) को मॉडल करने के लिए नहीं किया जाता है.

आम तौर पर, प्रोसेस के टाइप के आधार पर, उपयोगकर्ता के इनपुट के ज़रिए या मौजूदा डेटा को इंपोर्ट करने से एक पता बनाया जाएगा.

पता डालने / बदलाव करने के बारे में सलाह: - https://github.com/google/libaddressinput जैसे अंतरराष्ट्रीय पता के लिए तैयार विजेट का इस्तेमाल करें) - उपयोगकर्ताओं को उन देशों से बाहर फ़ील्ड में इनपुट या बदलाव करने के लिए यूज़र इंटरफ़ेस (यूआई) एलिमेंट नहीं दिए जाने चाहिए जहां उस फ़ील्ड का इस्तेमाल किया जाता है.

इस स्कीमा का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, कृपया यह देखें: https://support.google.com/business/answer/6397478

फ़ील्ड
revision

int32

PostalAddress का स्कीमा में किया गया बदलाव. इसे 0 पर सेट करना ज़रूरी है, जो सबसे नया वर्शन है.

सभी नए बदलाव, पुराने बदलावों के साथ काम करने की ज़रूरी है.
region_code

string

ज़रूरी है. पते के देश/इलाके का CLDR इलाके का कोड. इसका अनुमान कभी नहीं लगाया जाता और यह उपयोगकर्ता पर निर्भर करता है कि वैल्यू सही है या नहीं. ज़्यादा जानकारी के लिए, https://cldr.unicode.org/ और https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html पर जाएं. उदाहरण: स्विट्ज़रलैंड के लिए "CH".
language_code

string

ज़रूरी नहीं. इस पते के कॉन्टेंट का BCP-47 भाषा कोड (अगर पता हो). आम तौर पर, यह इनपुट फ़ॉर्म की यूज़र इंटरफ़ेस (यूआई) भाषा होती है. इसके अलावा, यह भाषा, पते के देश/इलाके में इस्तेमाल की जाने वाली किसी भाषा या ट्रांसलिट्रेट के बराबर बोली जाने वाली भाषा से मेल खानी चाहिए. इससे कुछ देशों के फ़ॉर्मैटिंग पर असर पड़ सकता है. हालांकि, यह डेटा के सही होने के लिए ज़रूरी नहीं है. साथ ही, पुष्टि करने या फ़ॉर्मैट न करने से जुड़ी दूसरी कार्रवाइयों पर कभी इसका असर नहीं पड़ेगा.

अगर यह वैल्यू पता नहीं है, तो इसे मिटा देना चाहिए (संभावित रूप से गलत डिफ़ॉल्ट वैल्यू तय करने के बजाय).

उदाहरण: "zh-Hant", "ja", "ja-Latn", "en".
postal_code

string

ज़रूरी नहीं. पते का पिन कोड. सभी देश पिन कोड का इस्तेमाल नहीं करते या ऐसा करने की ज़रूरत नहीं होती, लेकिन जहां उनका इस्तेमाल होता है, वहां वे पते के दूसरे हिस्सों के साथ अलग से पुष्टि कर सकते हैं (उदाहरण के लिए, अमेरिका में राज्य/पिन कोड की पुष्टि).
sorting_code

string

ज़रूरी नहीं. अलग-अलग देश के हिसाब से, क्रम से लगाने के लिए कोड. ज़्यादातर इलाकों में इसका इस्तेमाल नहीं किया जाता है. जहां इसका इस्तेमाल किया जाता है वहां वैल्यू, "CEDEX" जैसी स्ट्रिंग होती है. वैकल्पिक तौर पर, इसके बाद कोई संख्या होती है (जैसे कि "CEDEX 7"), या सिर्फ़ कोई संख्या होती है, जो "सेक्टर कोड" (जमैका), "डिलीवरी क्षेत्र इंडिकेटर" (मलावी) या "पोस्ट ऑफ़िस इंडिकेटर" (जैसे, आइवरी कोस्ट) को दिखाती है.
administrative_area

string

ज़रूरी नहीं. सबसे बड़ा प्रशासनिक उपविभाग, जिसका इस्तेमाल किसी देश या क्षेत्र के डाक पतों के लिए किया जाता है. उदाहरण के लिए, यह कोई राज्य, प्रांत, ओब्लास्ट या प्रीफ़ेक्चर हो सकता है. खास तौर पर, स्पेन के लिए यह प्रांत है, न कि स्वायत्त समुदाय (उदाहरण के लिए, "बार्सीलोनिया" न कि "कैटलोनिया"). कई देश डाक पतों में प्रशासनिक क्षेत्र का इस्तेमाल नहीं करते हैं. उदाहरण के लिए, स्विट्ज़रलैंड में इसे खाली छोड़ा जाना चाहिए.
locality

string

ज़रूरी नहीं. आम तौर पर, पते के शहर/कस्बे के हिस्से का मतलब होता है. उदाहरण: अमेरिका का शहर, आईटी कम्यून, यूके पोस्ट टाउन. दुनिया की जिन जगहों के बारे में सही जानकारी नहीं दी गई है या जो इस स्ट्रक्चर में फ़िट नहीं हैं वहां के इलाके को खाली छोड़ें और address_lines इस्तेमाल करें.
sublocality

string

ज़रूरी नहीं. पते का मोहल्ले. उदाहरण के लिए, ये आस-पड़ोस, नगर, जिले हो सकते हैं.
address_lines[]

string

पते के निचले लेवल के बारे में बताने वाली अनस्ट्रक्चर्ड मैसेज लाइनें.

पता_लाइनों की वैल्यू में टाइप की जानकारी नहीं होती और कभी-कभी एक ही फ़ील्ड में एक से ज़्यादा वैल्यू भी हो सकती हैं (जैसे कि "Austin, TX"), इसलिए ज़रूरी है कि लाइन का क्रम साफ़ हो. पते के देश/इलाके के लिए, पता पंक्तियों का क्रम "लिफ़ाफ़ा ऑर्डर" होना चाहिए. जिन जगहों पर यह अलग-अलग हो सकता है (उदाहरण के लिए, जापान), वहां बेहतर तरीके से साफ़ तौर पर जानकारी देने के लिए address_language का इस्तेमाल किया जाता है. जैसे, बड़े से छोटे क्रम के लिए "ja" और छोटे से बड़े क्रम के लिए "ja-Latn" या "en" का इस्तेमाल किया जाता है. इस तरह, भाषा के आधार पर किसी पते की सबसे खास लाइन को चुना जा सकता है.

किसी पते का कम से कम स्ट्रक्चर किस तरह इस्तेमाल किया जा सकता है, यह दिखाने के लिएregion_code का कोड दिया जाता है. साथ ही, पते में बची हुई सारी जानकारी को address_lines में डाला जाता है. ऐसे पते को जियोकोडिंग के बिना फ़ॉर्मैट करना संभव है, लेकिन पते के किसी भी कॉम्पोनेंट के बारे में कोई सिमैंटिक तर्क (सिमैंटिक तर्क) तब तक नहीं लिया जा सकता, जब तक कि इसे पूरी तरह से हल न कर दिया जाए.

ऐसा पता बनाएं जिसमें सिर्फ़ origin_code और address_lines वाला पता हो. इसके बाद, पूरी तरह से व्यवस्थित नहीं किए गए पतों को मैनेज करने के लिए, जियोकोडिंग का सुझाव दिया जाता है (यह अनुमान लगाने के बजाय कि पते के कौनसे हिस्से इलाके या प्रशासनिक क्षेत्र होने चाहिए).
recipients[]

string

ज़रूरी नहीं. पते पर मौजूद व्यक्ति. कुछ मामलों में, इस फ़ील्ड में एक से ज़्यादा लाइन वाली जानकारी हो सकती है. उदाहरण के लिए, इसमें "केयर ऑफ़" जानकारी हो सकती है.
organization

string

ज़रूरी नहीं. पते पर मौजूद संगठन का नाम.