Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add marathi language #610

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ languages:
- v1.0.0-beta.2
- v1.0.0-beta.1
- v1.0.0-beta

it:
weight: 2
languageName: "Italian"
Expand Down Expand Up @@ -432,7 +432,21 @@ languages:
current: v1.0.0
list:
- v1.0.0

ma:
weight: 25
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:
- v1.0.0
ar:
weight: 24
languageName: "العربية"
Expand Down
1 change: 1 addition & 0 deletions content/about/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,7 @@ The first draft of this specification has been written in collaboration with som
* [Cocogitto](https://github.com/oknozor/cocogitto): Cocogitto is a set of cli tools for the conventional commits and semver specifications.
* [Conventional Commits Linter](https://gitlab.com/DeveloperC/conventional_commits_linter): A tooling and language agnostic Git commit linter for the _Conventional Commits_ specification.
* [Uplift](https://github.com/gembaadvantage/uplift): Semantic versioning the easy way. Powered by Conventional Commits. Built for use with CI.
* [Monopub](https://github.com/thi-ng/monopub): Conventional Commits-driven release tool for monorepo releases, versioning & changelog generation
* [Monopub](https://github.com/thi-ng/monopub): Conventional Commits-driven release tool for monorepo releases, versioning & changelog generation.
* [git-cliff](https://git-cliff.org/): A highly customizable changelog generator written in Rust that can generate changelog files for any Git repository that follows the _Conventional Commits_ specification
* [cz-git](https://github.com/Zhengqbbb/cz-git): A customizable CLI tool for generating commit messages following Conventional Commits.
Expand Down
99 changes: 99 additions & 0 deletions content/v1.0.0/index.ma.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
---
draft: false
aliases: ["/ma/"]
---
# Conventional Commits 1.0.0

परंपरागत कमिट्स १.०.०
सारांश
परंपरागत कमिट्स विशिष्टता कमिट संदेशांवर एक हलका परंपरा आहे. यामुळे स्पष्ट कमिट इतिहास तयार करण्यासाठी सोप्या नियमांचा सेट मिळतो; ज्यामुळे त्यावर स्वयंचलित साधने लिहिणे सोपे होते. हा परंपरा 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 चा एक अधिक सुस्पष्ट इतर मार्गाने संवाद साधणे.
ठराविक रूपरेषा म्हणून नवीन वैशिष्ट्ये, दुरुस्त्या आणि नवी कार्ये समजून घेणे.
वापरकर्त्यांसाठी कमी टोकण वापरून चांगले संवाद साधणे
कमिट संदेशांच्या अधिक स्पष्ट संवादासाठी, आपल्या विकास कार्यप्रवाहाचे योग्य मूल्यांकन करणे आवश्यक आहे. एक प्रणाली स्थापन करा आणि सर्व सदस्य आपल्या परंपरागत कमिट्सवर तत्त्वांमध्ये सहकार्य करतील. हे केवळ एक साधन तयार करण्यास मदत करेल, तर ब्रेकिंग बदलांना सहानुभूती देईल आणि आपल्या समुदायात संवाद साधणारी पद्धत जतन करेल.