feat: Add Marathi Language

config.yaml

@@ -40,7 +40,7 @@ languages:
       - v1.0.0-beta.2
       - v1.0.0-beta.1
       - v1.0.0-beta
-
+  
   it:
     weight: 2
     languageName: "Italian"
@@ -428,6 +428,22 @@ languages:
       url: '#spesifikatsiya'
     - label: Github
       url: 'https://github.com/conventional-commits/conventionalcommits.org'
+    versions:
+      current: v1.0.0
+      list:
+      - v1.0.0
+
+  ma:
+    weight: 24
+    languageName: "Marathi"
+    title: परंपरागत वचने
+    description: संदेश पाठवण्यासाठी मानवी आणि मशीन वाचनीय अर्थ जोडण्यासाठी एक तपशील
+    - label: द्रुत सारांश
+      url: '#summary'
+    - label: संपूर्ण तपशील
+      url: '#specification'
+    - label: Contribute
+      url: 'https://github.com/conventional-commits/conventionalcommits.org'
     versions:
       current: v1.0.0
       list:

content/v1.0.0/index.ma.md

@@ -0,0 +1,93 @@
+परंपरागत कमिट्स १.०.०
+सारांश
+परंपरागत कमिट्स विशिष्टता कमिट संदेशांवर एक हलका परंपरा आहे. यामुळे स्पष्ट कमिट इतिहास तयार करण्यासाठी सोप्या नियमांचा सेट मिळतो; ज्यामुळे त्यावर स्वयंचलित साधने लिहिणे सोपे होते. हा परंपरा SemVer सह समन्वय साधतो, कमिट संदेशांमध्ये केलेले वैशिष्ट्ये, दुरुस्त्या, आणि ब्रेकिंग बदलांचे वर्णन करतो.
+
+कमिट संदेश संरचना पुढीलप्रमाणे असावी:
+
+arduino
+Copy code
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+<br /> कमिटमध्ये खालील संरचनात्मक घटक असतात, आपल्या ग्रंथालयाच्या वापरकर्त्यांना इरादा संवाद साधण्यासाठी:
+fix: fix प्रकाराचा एक कमिट आपल्या कोडबेसमधील एक बग पॅच करतो (याचा संबंध PATCH सह SemVer मध्ये आहे).
+feat: feat प्रकाराचा एक कमिट आपल्या कोडबेसमध्ये एक नवीन वैशिष्ट्य आणतो (याचा संबंध MINOR सह SemVer मध्ये आहे).
+BREAKING CHANGE: एक कमिट ज्यामध्ये एक फुटर BREAKING CHANGE: आहे, किंवा प्रकार/स्कोपच्या मागे ! जोडले आहे, एक ब्रेकिंग API बदल सादर करतो (याचा संबंध MAJOR सह SemVer मध्ये आहे). ब्रेकिंग चेंज कोणत्याही प्रकाराच्या कमिटचा भाग होऊ शकतो.
+fix: आणि feat: याशिवाय इतर प्रकारांची परवानगी आहे, उदाहरणार्थ @commitlint/config-conventional (जो Angular परंपरा वर आधारित आहे) build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, आणि इतर.
+BREAKING CHANGE: <description> च्या स्वरूपात एक फुटर दिला जाऊ शकतो, आणि तो git ट्रेलर फॉरमॅट सारख्या परंपरेचे अनुसरण करतो.
+परंपरागत कमिट्स विशिष्टता अनिवार्य केलेल्या प्रकारांचा समावेश करत नाही, आणि SemVer मध्ये कोणताही अप्रत्यक्ष परिणाम नाही (त्यानंतर ब्रेकिंग चेंज समाविष्ट असल्यास).
+
+<br /><br /> एक स्कोप कमिटच्या प्रकारास जोडला जाऊ शकतो, अतिरिक्त संदर्भात्मक माहिती प्रदान करण्यासाठी आणि तो वर्तुळात असावा, उदाहरणार्थ, feat(parser): add ability to parse arrays.
+
+उदाहरणे
+कमिट संदेशासह वर्णन आणि ब्रेकिंग चेंज फुटर
+vbnet
+Copy code
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+ब्रेकिंग चेंजला लक्ष वेधण्यासाठी ! सह कमिट संदेश
+vbnet
+Copy code
+feat!: send an email to the customer when a product is shipped
+स्कोप आणि ब्रेकिंग चेंजला लक्ष वेधण्यासाठी ! सह कमिट संदेश
+vbnet
+Copy code
+feat(api)!: send an email to the customer when a product is shipped
+! आणि BREAKING CHANGE फुटर दोन्ही असलेला कमिट संदेश
+rust
+Copy code
+chore!: drop support for Node 6
+
+BREAKING CHANGE: use JavaScript features not available in Node 6.
+शरीराशिवाय कमिट संदेश
+makefile
+Copy code
+docs: correct spelling of CHANGELOG
+स्कोपसह कमिट संदेश
+scss
+Copy code
+feat(lang): add Polish language
+मल्टी-पॅराग्राफ शरीर आणि एकाधिक फुटर्स असलेला कमिट संदेश
+vbnet
+Copy code
+fix: prevent racing of requests
+
+Introduce a request id and a reference to latest request. Dismiss
+incoming responses other than from latest request.
+
+Remove timeouts which were used to mitigate the racing issue but are
+obsolete now.
+
+Reviewed-by: Z
+Refs: #123
+विशिष्टता
+या दस्तऐवजात “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, आणि “OPTIONAL” या कीवर्डचे अर्थ RFC 2119 नुसार समजले जातात.
+
+कमिट्सला एक प्रकाराने पूर्वनिर्धारित असावे, ज्यात एक संज्ञा, feat, fix, इत्यादी समाविष्ट असते, जे पर्यायी स्कोप, पर्यायी !, आणि अनिवार्य टर्मिनल कॉलन आणि स्पेसने पाठवले जाते.
+feat प्रकाराचा उपयोग आपले अनुप्रयोग किंवा ग्रंथालयात नवीन वैशिष्ट्य जोडताना करावा लागतो.
+fix प्रकाराचा उपयोग आपले अनुप्रयोगासाठी बग फिक्स दर्शवित असताना करावा लागतो.
+एक स्कोप प्रकारानंतर दिला जाऊ शकतो. एक स्कोप एक संज्ञा असावी जी कोडबेसच्या एका विभागाचे वर्णन करते व तो वर्तुळात असावा, उदाहरणार्थ, fix(parser):
+एक वर्णन अनिवार्यपणे कॉलन आणि स्पेसच्या नंतर येते. वर्णन म्हणजे कोड बदलांचा संक्षिप्त सारांश, उदाहरणार्थ, fix: array parsing issue when multiple spaces were contained in string.
+एक लांब कमिट शरीर पर्यायी असू शकते, ज्यामध्ये कोड बदलांची अतिरिक्त संदर्भात्मक माहिती दिली जाऊ शकते. शरीर वर्णनानंतर एक रिक्त रांगेत सुरू होते.
+एक कमिट शरीर फ्री-फॉर्म आहे आणि त्यामध्ये कोणत्याही संख्येच्या न्यूलाइन विभक्त केलेल्या पॅराग्राफ्स असू शकतात.
+एक किंवा अधिक फुटर्स शरीरानंतर एक रिक्त रांगेत दिले जाऊ शकतात. प्रत्येक फुटर एक शब्द टोकनने बनलेला असावा, जो :<space> किंवा <space># विभाजकासह जोडलेला असावा, ज्याचा प्रेरणा git ट्रेलर परंपरा पासून आहे.
+फुटरचे टोकन व्हाइटस्पेस कॅरेक्टरच्या ठिकाणी - वापरून बनवले जावे, उदाहरणार्थ, Acked-by (यामुळे फुटर विभागाला बहु-पॅराग्राफ शरीरापासून वेगळे करण्यास मदत होते). BREAKING CHANGE या टोकनसाठी एक अपवाद आहे, जो देखील वापरला जाऊ शकतो.
+फुटरची मूल्ये स्पेस आणि न्यूलाइन समाविष्ट करू शकतात, आणि पार्सिंग पुढील वैध फुटर टोकन/विभाजक जोडणीच्या जोडीच्या शेजारी संपेल.
+ब्रेकिंग बदलांचा निर्देश कमिटच्या प्रकार/स्कोपच्या पूर्वनिर्धारणामध्ये, किंवा फुटरमध्ये दाखविला जावा.
+जर फुटर म्हणून समाविष्ट केले असेल, तर ब्रेकिंग बदल एक uppercase मजकूर असावा जो BREAKING CHANGE, नंतर कॉलन, स्पेस, आणि वर्णनाने असावा, उदाहरणार्थ, BREAKING CHANGE: environment variables now take precedence over config files.
+जर प्रकार/स्कोपच्या पूर्वनिर्धारणामध्ये समाविष्ट केले असेल, तर ब्रेकिंग बदलांना ! ने दाखवले जावे जेव्हा : असतो. जर ! वापरले असेल, तर BREAKING CHANGE: फुटर विभागात वगळले जाऊ शकते, आणि कमिट वर्णन ब्रेकिंग बदलांचे वर्णन करण्यासाठी वापरले जाऊ शकते.
+feat आणि fix याशिवाय अन्य प्रकारांचा वापर आपल्या कमिट संदेशांमध्ये केला जाऊ शकतो, उदाहरणार्थ, docs: update ref docs.
+परंपरागत कमिट्सच्या घटकांवरून साधने द्वारे संवेदनशील असल्याचे समजले जाऊ नये, BREAKING CHANGE सह सर्वात महत्त्वाचे अपवाद.
+BREAKING-CHANGE FOOTER चा उपयोग करताना BREAKING CHANGE च्या समकक्ष असावा.
+परंपरागत कमिट्सचा वापर का करावा
+आपोआप CHANGELOGs तयार करणे.
+(कमिट प्रकारांच्या आधारे) आपोआप एक सेमँटिक आवृत्ती बंप ठरवणे.
+बदलांची निसर्ग सहकारी, सार्वजनिक, आणि इतर भागधारकांशी संवाद साधणे.
+बांधकाम आणि प्रकाशन प्रक्रियांचा ट्रिगर करणे.
+आपल्या प्रकल्पाच्या API चा एक अधिक सुस्पष्ट इतर मार्गाने संवाद साधणे.
+ठराविक रूपरेषा म्हणून नवीन वैशिष्ट्ये, दुरुस्त्या आणि नवी कार्ये समजून घेणे.
+वापरकर्त्यांसाठी कमी टोकण वापरून चांगले संवाद साधणे
+कमिट संदेशांच्या अधिक स्पष्ट संवादासाठी, आपल्या विकास कार्यप्रवाहाचे योग्य मूल्यांकन करणे आवश्यक आहे. एक प्रणाली स्थापन करा आणि सर्व सदस्य आपल्या परंपरागत कमिट्सवर तत्त्वांमध्ये सहकार्य करतील. हे केवळ एक साधन तयार करण्यास मदत करेल, तर ब्रेकिंग बदलांना सहानुभूती देईल आणि आपल्या समुदायात संवाद साधणारी पद्धत जतन करेल.