From f777146b5d331c9ee33b0028e861df14e3992fe9 Mon Sep 17 00:00:00 2001 From: Qudratillo <80141037+softXengineer@users.noreply.github.com> Date: Mon, 22 Jan 2024 12:55:14 +0500 Subject: [PATCH] feat(lang): add uzbek translation (#558) --- config.yaml | 17 ++++ content/v1.0.0/index.uz.md | 183 +++++++++++++++++++++++++++++++++++++ 2 files changed, 200 insertions(+) create mode 100644 content/v1.0.0/index.uz.md diff --git a/config.yaml b/config.yaml index a94f65e..8231f8f 100644 --- a/config.yaml +++ b/config.yaml @@ -411,6 +411,23 @@ languages: url: '#নির্দিষ্টকরণ' - label: গিটহাব url: 'https://github.com/conventional-commits/conventionalcommits.org' + versions: + current: v1.0.0 + list: + - v1.0.0 + + uz: + weight: 23 + languageName: "Uzbek (O'zbekcha)" + title: Conventional Commits + description: Commit xabarlariga inson va mashina o'qishi mumkin bo'ladigan ma'noni qo'shish uchun spesifikatsiya + actions: + - label: Xulosa + url: '#xulosa' + - label: Spesifikatsiya + url: '#spesifikatsiya' + - label: Github + url: 'https://github.com/conventional-commits/conventionalcommits.org' versions: current: v1.0.0 list: diff --git a/content/v1.0.0/index.uz.md b/content/v1.0.0/index.uz.md new file mode 100644 index 0000000..975e849 --- /dev/null +++ b/content/v1.0.0/index.uz.md @@ -0,0 +1,183 @@ +--- +draft: false +aliases: ["/uz/"] +--- + +# Conventional Commits 1.0.0 + +## Xulosa + +Conventional Commits spetsifikatsiyasi - bu commit xabarlarni qanday yozish kerakligi haqidagi oddiy kelishuv. U tushunarli commitlar tarixini yaratish uchun oddiy qoidalar to'plamini taqdim etadi, shuningdek, commitlar tarixiga asoslangan avtomatlashtirish vositalarini ishlab chiqishni osonlashtiradi. Ushbu konventsiya [SemVer](http://semver.org) bilan bog'liq bo'lib, commit xabarlarida kiritilgan yangi xususiyatlar, tuzatishlar va o'zgarishlarni ifodalaydi. + +Commit xabari quyidagi tarzda tuzilishi kerak: + +--- + +``` +[ixtiyoriy kontekst]: + +[ixtiyoriy tana (body)] + +[ixtiyoriy so'ngi qism(lar) (footer(s))] +``` + +--- + +
+ +Commit kutubxonangiz foydalanuvchilariga mohiyatni yetkazish uchun quyidagi tarkibiy elementlarni o'z ichiga olishi kerak: + +1. **fix:** `fix` commit _turi_ - kodingizdagi xatoni tuzatadi (bu, Semantik Versiyalashtiruvdagi [`PATCH`](https://semver.org/#summary) bilan mos keladi). +2. **feat:** `feat` commit _turi_ - kodingizga yangi xususiyat qo'shadi. (bu, Semantik Versiyalashtiruvdagi [`MINOR`](https://semver.org/#summary) bilan mos keladi). +3. **BREAKING CHANGE:** `BREAKING CHANGE` nomli _footerga_ ega yoki `[ixtiyoriy kontekst]` dan so'ng undov belgisi (`!`) bilan tugallanadigan commit - amaldagi API ga nomutanosib o'zgartirish kiritadi (bu, Semantik Versiyalashtiruvdagi [`MAJOR`](https://semver.org/#summary) bilan mos keladi). `BREAKING CHANGE` har qanday _tur_ dagi commitlarning bir qismi bo'lishi mumkin. +4. Yuqorida ko'rsatilgan _tur_ lardan boshqalariga ham ruxsat beriladi, masalan [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) konventsiyasi asosida) `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` , va boshqalar. +5. `BREAKING CHANGE: ` dan boshqa muqobil footerlardan foydalanish, hamda [git trailer formatiga](https://git-scm.com/docs/git-interpret-trailers) amal qilish mumkin. + +Boshqa _turlar_ `Conventional Commits` tomonidan talab qilinmaydi va Semantik versioning ga hech qanday aniq ta'sir ko'rsatmaydi (faqatgina `BREAKING CHANGE` ni o'z ichiga olishmasa). Commit turiga, qo'shimcha `kontext` qo'shish uchun _turdan_ so'ng qavsdan foydalaning, masalan, `feat(parser): add ability to parse arrays` + +## Namunalar + +### `BREAKING CHANGE` footer ga hamda ta'rifga ega commit xabarlari + +``` +feat: allow provided config object to extend other configs + +BREAKING CHANGE: `extends` key in config file is now used for extending other config files +``` + +### `BREAKING CHANGE` ni ifodalovchi `!` belgisiga ega commit xabarlari + +``` +feat!: send an email to the customer when a product is shipped +``` + +### `BREAKING CHANGE` ni ifodalovchi `!` belgisi hamda _kontekstga_ ega commit xabarlari + +``` +feat(api)!: send an email to the customer when a product is shipped +``` + +### `BREAKING CHANGE` ni ifodalovchi `!` belgi va _footerga_ ega commit xabarlari + +``` +chore!: drop support for Node 6 + +BREAKING CHANGE: use JavaScript features not available in Node 6. +``` + +### _tana(body)_ siz commit xabarlari + +``` +docs: correct spelling of CHANGELOG +``` + +### _kontekst_ ga ega commit xabarlari + +``` +feat(lang): add polish language +``` + +### Bir nechta paragrafli _tana(body)_ va bir nechta _footer_ ga ega commit xabalari + +``` +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 +``` + +## Spesifikatsiya + +Ushbu hujjatdagi «MUST», «MUST NOT», «REQUIRED», «SHALL», «MAY» и «OPTIONAL» kalit so'zlari [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) da ko'rsatilgandek talqin qilinishi kerak. + +1. Commitlar ot so'z turkumiga oid, `feat`, `fix` va shunga o'xshash so'z bilan boshlanishi shart(MUST). Undan keyin ixtiyoriy kontekst (OPTIONAL), undov belgisi (`!`) (OPTIONAL), va undan so'ng ikki nuqta (`:`) hamda bo'sh joy (` `) joydan iborat bo'lishligi talab etiladi (REQUIRED). +2. Agar commit ilovangiz yoki kutubxonangizga yangi xususiyat qo'shsa, `feat:` _turidan_ foydalanishingiz shart (MUST). +3. Agar commit ilovangiz yoki kutubxonangizdagi muommoni bartaraf qilsa, `fix:` _turidan_ foydalanishingiz shart (MUST). +4. Turdan so'ng _kontekst_ kelishi mumkin (MAY). _Kontekst_ qavslar bilan o'ralgan, kutubxonangizdagi kodlarning bir qismini tavsiflovchi ot so'z turkumiga oid so'z bo'lishligi kerak, masalan `fix(parser)`. +5. Commit haqida tavsif darhol _tur_/_kontekst_ prefiksidan keyin ikki nuqta (`:`) va bo'sh joydan (` `)keyin bo'lishi kerak (MUST). Tavsif bu kod o'zgarishlarining qisqacha xulosasidir. Masalan, `fix: array parsing issue when multiple spaces were contained in string` +6. Qisqa tavsifdan so'ng kod o'zgarishlari haqida qo'shimcha kontekstual ma'lumotlarni taqdim etuvchi tana(body) qismi taqdim etilishi mumkin (MAY). Tana(body) qismi tavsifdan keyin bitta bo'sh qatordan so'ng boshlanishi kerak (MUST). +7. Commitning tana(body) qismi ixtiyoriy bo'lib, istalgan miqdordagi paragraflardan iborat bo'lishi mumkin. (MAY) +8. _Tana(body)_ qismidan keyin 1ta bo'sh qatordan so'ng, bir yoki bir nechta _footerlar_ bo'lishligi mumkin (MAY). Har bir _footer_ so'z belgisidan iborat bo'lishi, undan keyin `:` yoki `#` ajratuvchisi, keyin matn qiymatidan iborat bo'lishligi shart (MUST) ([git trailer format](https://git-scm.com/docs/git-interpret-trailers) asosida). +9. _Footer_ tokeni uchun (` `) bo'sh joy begilising o'rniga (`-`) dan foydalanish kerak (MUST). Masalan, `Acked-by` (bu _footer_ tokenini uning ko'p paragrafli _tana_ qismidan ajratishga yordam beradi). _BREAKING CHANGE_ bundan mustasno, undan token sifatida ham foydalanish mumkin (MAY). +10. _Footerning_ qiymati ya'ni tana qismida boʻshliqlar va yangi satrlar boʻlishi mumkin (MAY) va keyingi _footer_ token/ajratuvchi juftlik kuzatilganda avvalgi _footer_ tugatilishi kerak (MUST). +11. `BREAKING CHANGE` o'zgarishlar commit xabarining _tur/kontekst_ prefiksida yoki _footer_ token qismida ko'rsatilishi kerak (MUST). +12. Agar _footerda_ `BREAKING CHANGE` bo'lsa, u katta harflardan tashkil topgan `BREAKING CHANGE` so'zlari va undan so'ng ikki nuqta (`:`), bo'sh joy (` `) va tavsifdan iborat bo'lishi kerak (MUST). Masalan, `BREAKING CHANGE: environment variables now take precedence over config files.` +13. Agar _tur/kontekst_ prefiksida `BREAKING CHANGE` mavjud bo'lsa, u holda ikki nuqtadan (`:`) avval undov belgisi (`!`) bo'lishligi shart (MUST)! Agar undov belgisi (`!`) ishlatilgan bo'lsa, u holda _footer_ qismida emas (MAY), balki commit xabarining `tasnif` qismida `BREAKING CHANGE` haqida ma'lumot berilishi mumkin. (SHALL) +14. Commit xabarlarida `feat` va `fix`dan boshqa turlardan foydalanish mumkin (MAY). Masalan, `docs: updated ref docs` +15. "Conventional Commits" kelishuviga asosan ishlatilayotgan so'zlar, dasturchilar tomonidan `case sensitive` bo'lmasligi kerak (MUST NOT), lekin `BREAKING CHANGE` bundan mustasno, chunki bu katta harflarda yozilishi lozim (MUST). +16. `BREAKING-CHANGE`, _footerning_ tokeni sifatida ishlatilganda, `BREAKING CHANGE` bilan sinonim bo‘lishi kerak (MUST). + +## Nima uchun «Conventional Commits» dan foydalanish kerak + +- Avtomatik tarzda o'zgarishlar ro'yhati(CHANGELOG) yaratilishi. +- Semantik versiyani avtomatik ravishda aniqlash (qo'shilgan commitlarning _turlariga_ asoslanib). +- Jamoadoshlarni, ommani va boshqalarni o'zgarishlarning mohiyati haqida xabardor qilish. +- `Build` hamda `Publish` jarayonlarini ishga tushirish. +- Yaxshi tuzilgan commitlar tarixini o'rganish orqali, odamlarga sizning loyihalaringizga hissa qo'shishni osonlashtirish imkonini beradi. + +## FAQ (Tez-tez so'raladigan savollar) + +### Boshlang'ich rivojlantirish bosqichida commit xabarlari bilan qanday munosabatda bo'lish kerak? + +Biz, siz mahsulotni allaqachon ishlab chiqarilgan deb davom etishingizni tavsiya qilamiz. Odatda _kimdir_, garchi u sizning dastur ishlab chiquvchi hamkasbingiz bo'lsa ham, sizning dasturingizdan foydalanadi. Ular, tuzatilgan narsalar, nimalar qo'shilganligi va h.k haqida xabardor bo'lishni istaydilar. + +## Commit _turi_ katta yoki kichik harflarda bo'lishi kerakmi? + +Sizga eng yoqqanini tanlang va unga qat'iy rioya qiling. + +### Agar commit birdan ko'p commit turlariga mos keladigan bo'lsa nima qilish kerak? + +Iloji bo'lsa, orqaga qayting va bir nechta commitlarni yarating. `Conventional Commits`ning afzalliklaridan biri bu bizni ko'proq tashkillashtirilgan commitlar va PR (Pull Request) qilishga undash qobiliyatidir. + +### Bu tez rivojlanish va tez iteratsiyaga to'sqinlik qilmaydimi? + +Bu tez, tartibsiz harakatni oldini oladi. Bu sizga turli hissa qo'shuvchilar bilan bir nechta loyihalar bo'ylab tez uzoq muddatli harakat qilish imkonini beradi. + +### `«Conventional Commits»` dasturchilarni o'zlari bajaradigan commitlar _turlarini_ cheklashga olib kelishi mumkinmi, chunki ular tavsiya etilgan _turlarga_ ko'ra o'ylashadi? + +`Conventional Commits` bizni tuzatishlar (`fix: `) kabi muayyan turdagi commitlarni ko'proq qilishga undaydi. Bundan tashqari, `Conventional Commits`ning moslashuvchanligi sizning jamoangizga o'z _turlarini_ ishlab chiqishga va vaqt o'tishi bilan bu _turlarni_ o'zgartirishga imkon beradi. + +### Buni Semantik versiyaga qanday aloqasi bor? + +`fix` _turidagi_ commitlar `PATCH` relizlariga, `feat` - `MINOR`-ga, `BREAKING CANGE` - _turidan_ qat'iy nazar - `MAJOR`-ga tarjima qilinishi kerak. + +### Qanday qilib kengaytmalarimni(extensions) «Conventional Commits» spetsifikatsiyasiga moslashtirishim kerak, masalan. `@jameswomack/conventional-commit-spec`? + +Ushbu spetsifikatsiyaga o'z kengaytmalaringizni chiqarish uchun Semantik versiyadan foydalanishni tavsiya etamiz (va sizni ushbu kengaytmalarni yaratishga undaymiz!). + +### Agar tasodifan noto'g'ri commit _turidan_ foydalansam nima qilishim kerak? + +#### Siz spetsifikatsiyaga tegishli, lekin to'g'ri _turdan_ foydalanmaganingizda, masalan. `feat` o'rniga `fix` + +Xatoni `push` yoki `releasing` qilishdan oldin, biz commitlar tarixini tahrirlash uchun `git rebase -i` dan foydalanishni tavsiya qilamiz. `Release` so'ng, tahrirlash qaysi vositalar va jarayonlardan foydalanganingizga qarab o'zgaradi. + +#### Spetsifikatsiyada ko'rsatilmagan _turdan_ foydalanganda. Misol uchun, `feat` o'rniga `feet` + +Eng yomon holatga ko'ra, agar commit `Conventional Commits` spetsifikatsiyasiga to'g'ri kelmasa, bu qiyomat degani emas. Bu shunchaki spetsifikatsiyaga asoslangan vositalar tomonidan commit o'tkazib yuborilishini anglatadi. + +### Mening barcha kontributorlarim `Conventional Commits` spetsifikatsiyasidan foydalanishlari kerakmi? + +Yo'q! Agar siz `Git`da commitlarni birlashtirish (`squash`) usulidan foydalansangiz, loyiha maintainerlari birlashtirilgan, oddiy commit qiluvchilarning ish yukini qo'shmasdan birlashtirishi, topshiriq xabarlarini tartibga solishi mumkin. Buning uchun umumiy ish jarayoni sizning git tizimingiz avtomatik ravishda `PR` soʻrovi boʻyicha commitlarni `squash` qilish va maintainerga birlashtirish uchun tegishli git commit xabarini kiritadigan formani taqdim qilishi kerak. + +### «Conventional Commits» orqali qanday qilib bekor qilingan commitlarni uzatish mumkin? + +Kod o'zgarishlarini bekor qilish qiyin bo'lishi mumkin: + +- Bir nechta commitlarni bekor qilyabsizmi? +- Agar siz yangi xususiyat o'zgarishlarini bekor qilsangiz, keyingi versiya `PATCH` bo'lishi kerakmi? + +`Conventional Commits` bekor qilish xatti-harakatini aniqlash uchun aniq tarzda ta'riflashga urinmaydi. Buning o'rniga, biz o'zgarishlarni bekor qilish uchun o'z mantig'ini ishlab chiqishda _turlar_ va _footerlarning_ moslashuvchanligidan foydalanishni vosita mualliflariga qoldiramiz. + +Tavsiyalardan biri `revert` turi va qaytarilayotgan majburiyat xeshlariga (`SHA`) ishora qiluvchi _footerdan_ foydalanishdir. Masalan: + +``` +revert: let us never again speak of the noodle incident + +Refs: 676104e, a215868 +```