From 1b08c92cf80e7de3b32752a8cab1bdf5ea79cc61 Mon Sep 17 00:00:00 2001 From: Azis Alvriyanto Date: Fri, 27 Dec 2024 13:01:33 +0700 Subject: [PATCH] fix(id): improve and correct translation for better readability --- content/v1.0.0/index.id.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/content/v1.0.0/index.id.md b/content/v1.0.0/index.id.md index 5c2913a3..88596551 100644 --- a/content/v1.0.0/index.id.md +++ b/content/v1.0.0/index.id.md @@ -9,8 +9,8 @@ aliases: ["/id/"] Conventional Commits adalah perjanjian sederhana tentang cara menulis pesan komit. Ini menjelaskan sekumpulan aturan sederhana untuk membuat riwayat komit yang jelas; -yang memudahkan untuk membuat alat automatis di atasnya. -Perjanjian ini cocok dengan [SemVer](http://semver.org/lang/id/), +yang memudahkan untuk membuat alat otomatis di atasnya. +Perjanjian ini sesuai dengan [SemVer](http://semver.org/lang/id/), dengan menjelaskan suatu fitur (features), perbaikan (fixes), perubahan yang merusak (breaking changes) yang dimuat dalam pesan komit. Pesan komit harus tersusun sebagai berikut: @@ -27,19 +27,19 @@ Pesan komit harus tersusun sebagai berikut: ---
-Komit berisi elemen struktural sebagai berikut, untuk menyampaikan maksud kepada konsumen perpustakaan anda: +Komit ini memiliki elemen-elemen struktural berikut untuk menjelaskan maksud kepada pengguna pustaka: -1. **fix:** komit _tipe_ `fix` untuk perbaikan celah (bug) dalam kode anda (ini berkolerasi dengan [`PATCH`](http://semver.org/#summary) di Semantic Versioning). -1. **feat:** komit _tipe_ `feat` memperkenalkan suatu fitur (feature) baru dalam kode anda (ini berkolerasi dengan [`MINOR`](http://semver.org/#summary) di Semantic Versioning). -1. **BREAKING CHANGE:** komit yang berisi footer `BREAKING CHANGE:`, atau tambahkan `!` setelah type/scope, memperkenalkan perusakan perubahan API (ini berkolerasi dengan [`MAJOR`](http://semver.org/#summary) di Semantic Versioning). BREAKING CHANGE dapat menjadi bagian dari komit _type_ apapun. -1. _types_ daripada `fix:` dan `feat:` diperbolehkan, sebagai contoh [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) direkomendasikan `build:`, `chore:`, - `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainya. +1. **fix:** komit _tipe_ `fix` untuk perbaikan celah (bug) dalam kode Anda (ini berkaitan dengan [`PATCH`](http://semver.org/#summary) di Semantic Versioning). +1. **feat:** komit _tipe_ `feat` memperkenalkan suatu fitur (feature) baru dalam kode Anda (ini berkaitan dengan [`MINOR`](http://semver.org/#summary) di Semantic Versioning). +1. **BREAKING CHANGE:** komit yang berisi footer `BREAKING CHANGE:`, atau tambahkan `!` setelah type/scope, memperkenalkan perubahan yang merusak API (ini berkaitan dengan [`MAJOR`](http://semver.org/#summary) di Semantic Versioning). BREAKING CHANGE dapat diterapkan pada semua _tipe_ komit. +1. _types_ selain `fix:` dan `feat:` diperbolehkan, sebagai contoh [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) disarankan `build:`, `chore:`, + `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainnya. 1. _footers_ daripada `BREAKING CHANGE: ` dapat disediakan dan mengikuti konvensi yang mirip dengan [format git trailer](https://git-scm.com/docs/git-interpret-trailers). Tipe tambahan tidak di amanatkan oleh spesifikasi conventional commits, dan tidak ada efek implisit dalam Semantic Versioning (kecuali mereka termasuk BREAKING CHANGE). -
< br/> -Cakupan dapat disediakan ke tipe komit. untuk memberikan informasi kontekstual tambahan dan terkandung dalam kurung, misalnya, `feat(parser): add ability to parse arrays`. +

+Cakupan (scope) dapat disediakan ke tipe komit untuk memberikan informasi kontekstual tambahan dan terkandung dalam kurung, misalnya, `feat(parser): add ability to parse arrays`. ## Contoh @@ -116,9 +116,9 @@ awalan, memecah perubahan HARUS (MUST) ditunjukkan oleh `!` Segera sebelum `:`. ## Mengapa menggunakan Conventional Konvensional -* Secara automatis menghasilkan CHANGELOGs. -* Secara automatis menentukan versi semantic (Berdasarkan tipe komit yang dilakukan). -* Mengkomunikasikan sifat perubahan kepada rekan setim, publik, dan pemangku kepentingan lainnya. +* Secara otomatis menghasilkan CHANGELOGs. +* Secara otomatis menentukan versi semantic (Berdasarkan tipe komit yang dilakukan). +* Mengomunikasikan sifat perubahan kepada rekan setim, publik, dan pemangku kepentingan lainnya. * Memicu proses pembuatan dan publikasi. * Mempermudah orang untuk berkontribusi pada proyek Anda, dengan memungkinkan mereka untuk menjelajah riwayat komit yang lebih terstruktur. @@ -128,7 +128,7 @@ awalan, memecah perubahan HARUS (MUST) ditunjukkan oleh `!` Segera sebelum `:`. Kami menyarankan Anda melanjutkan seolah-olah Anda sudah merilis produk. Biasanya *seseorang*, bahkan jika itu sesama pengembang perangkat lunak Anda, menggunakan perangkat lunak Anda. Mereka ingin tahu apa yang diperbaiki, apa yang rusak, dll. -### Apakah tipe dalam komit judul huruf besar atau kecil? +### Apakah tipe dalam komit menggunakan judul huruf besar atau kecil? Casing apa pun dapat digunakan, tetapi yang terbaik adalah konsisten. @@ -161,7 +161,7 @@ Sebelum menggabungkan atau merilis kesalahan, sebaiknya gunakan `git rebase -i` #### Saat Anda menggunakan jenis *bukan* spesifikasi, mis. `feet` bukannya `feat` -Dalam skenario terburuk, ini bukan akhir dunia jika komit mendarat yang tidak memenuhi spesifikasi conventional commit. Ini berarti komit akan dilewatkan oleh alat yang didasarkan pada spesifikasi. +Dalam skenario terburuk, hal ini bukanlah masalah besar jika terdapat komit yang tidak memenuhi spesifikasi conventional commit. Ini berarti komit akan dilewatkan oleh alat yang didasarkan pada spesifikasi. ### Apakah semua kontributor saya perlu menggunakan spesifikasi commit konvensional?