Package google.type

इंडेक्स

तारीख

कैलेंडर की पूरी या कुछ तारीख दिखाता है, जैसे कि जन्मदिन. दिन का समय और टाइम ज़ोन या तो किसी दूसरी जगह पर बताया गया है या बहुत कम है. तारीख ग्रिगॉरियन कैलेंडर के हिसाब से है. यह इनमें से किसी एक चीज़ को दिखा सकता है:

  • साल, महीने, और दिन की वैल्यू के अलावा, पूरी तारीख.
  • महीना और दिन, जिसमें कोई साल नहीं हो. उदाहरण के लिए, सालगिरह.
  • अपने-आप में, साल की शुरुआत, जिसमें शून्य महीना और एक शून्य दिन होता है.
  • साल और महीना, जिसमें शून्य दिन हो (उदाहरण के लिए, क्रेडिट कार्ड के खत्म होने की तारीख).

मिलते-जुलते टाइप:

फ़ील्ड
year

int32

तारीख का साल. 1 से 9999 के बीच होना चाहिए या बिना साल वाली तारीख बताने के लिए 0 होना चाहिए.
month

int32

साल का महीना. बिना महीना और दिन के किसी साल के बारे में बताने के लिए, यह 1 से 12 के बीच होना चाहिए या 0 होना चाहिए.
day

int32

महीने का दिन. 1 से 31 के बीच होना चाहिए और साल और महीने के लिए मान्य होना चाहिए या खुद में किसी साल या किसी साल और महीने के बारे में बताने के लिए 0 मान्य होना चाहिए, जिसमें दिन अहम नहीं होता है.

DayOfWeek

हफ़्ते का कोई दिन दिखाता है.

Enums
DAY_OF_WEEK_UNSPECIFIED हफ़्ते का दिन नहीं बताया गया है.
MONDAY सोमवार
TUESDAY मंगलवार
WEDNESDAY बुधवार
THURSDAY गुरुवार
FRIDAY शुक्रवार
SATURDAY शनिवार
SUNDAY रविवार

LatLng

ऐसा ऑब्जेक्ट जो अक्षांश/देशांतर के जोड़े को दिखाता है. डिग्री अक्षांश और डिग्री देशांतर दिखाने के लिए इसे 'डबल्स' के जोड़े के तौर पर दिखाया जाता है. जब तक कि कोई दूसरा ऑब्जेक्ट न दिया गया हो, तब तक यह ऑब्जेक्ट WGS84 स्टैंडर्ड के मुताबिक होना चाहिए. वैल्यू, सामान्य रेंज के अंदर होनी चाहिए.

फ़ील्ड
latitude

double

डिग्री में अक्षांश. यह [-90.0, +90.0] की रेंज में होना चाहिए.
longitude

double

डिग्री में देशांतर. यह [-180.0, +180.0] की रेंज में होना चाहिए.

धन

किसी रकम को उसके मुद्रा टाइप के साथ दिखाता है.

फ़ील्ड
currency_code

string

तीन अक्षर वाला मुद्रा कोड, जिसके बारे में ISO 4217 में बताया गया है.
units

int64

रकम की पूरी इकाइयां. उदाहरण के लिए, अगर currencyCode "USD" है, तो 1 यूनिट एक डॉलर होगी.
nanos

int32

मात्रा की नैनो (10^-9) यूनिट की संख्या. वैल्यू -9,99,99,999 से 9,99,99,999 के बीच होनी चाहिए. अगर units धनात्मक है, तो nanos का मान धनात्मक या शून्य होना चाहिए. अगर units शून्य है, तो nanos पॉज़िटिव, शून्य या नेगेटिव हो सकता है. अगर units ऋणात्मक है, तो nanos को ऋणात्मक या शून्य होना चाहिए. उदाहरण के लिए, $-1.75 को units=-1 और nanos=-7,50,000,000 के तौर पर दिखाया जाता है.

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

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

TimeOfDay

दिन का कोई समय दिखाता है. तारीख और टाइम ज़ोन या तो अहम नहीं हैं या कहीं और बताए गए हैं. एपीआई लीप सेकंड की अनुमति दे सकता है. मिलते-जुलते टाइप google.type.Date और google.protobuf.Timestamp हैं.

फ़ील्ड
hours

int32

24 घंटे के फ़ॉर्मैट में दिन के घंटे. यह 0 से 23 के बीच होना चाहिए. कारोबार के बंद होने के समय जैसी स्थितियों के लिए, एपीआई "24:00:00" वैल्यू की अनुमति दे सकता है.
minutes

int32

दिन के घंटे के मिनट. संख्या 0 से 59 के बीच होनी चाहिए.
seconds

int32

समय के मिनट में. आम तौर पर, यह संख्या 0 से 59 के बीच होनी चाहिए. लीप-सेकंड की अनुमति देने पर, एपीआई वैल्यू 60 की अनुमति दे सकता है.
nanos

int32

नैनोसेकंड में सेकंड के अंश. 0 से 9,99,99,999 के बीच होना चाहिए.