xsteadfastx/conventionalcommits.org
1
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2024-11-15 02:45:15 +01:00
Code Issues Projects Releases Wiki Activity

feat(lang): Add Indonesian (ID) translation for version v1.0.0 (#217)

Browse Source 
* feat(lang): Add Indonesian (ID) translation for version v1.0.0

* update indonesia current version
This commit is contained in:
Aldi Nugraha 2020-01-15 14:37:36 +07:00 committed by Damiano Petrungaro
parent 14de482ebb
commit 9c2fd1295d
2 changed files with 26 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
config.yaml
View File

@ -228,8 +228,9 @@ languages:
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0-beta.4
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0

41
content/v1.0.0/index.id.md
View File

@ -7,7 +7,11 @@ aliases: ["/id/"]
## Ringkasan
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 otomatis di atasnya. Perjanjian ini cocok dengan [SemVer](http://semver.org), dengan menjelaskan suatu fitur (features), perbaikan (fixes), merusak perubahan (breaking changes) yang dimuat dalam pesan komit.
Conventional Commits adalah perjanjian sederhana tentang cara menulis pesat 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),
dengan menjelaskan suatu fitur (features), perbaikan (fixes), perubahan yang merusak (breaking changes) yang dimuat dalam pesan komit.
Pesan komit harus tersusun sebagai berikut:
@ -58,17 +62,17 @@ refactor!: drop support for Node 6
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```
### Pesan komit tanpa badan
### Pesan komit tanpa body
```
docs: correct spelling of CHANGELOG
```
### Pesan komit dengan cakupan
### Pesan komit dengan scope
```
feat(lang): add polish language
```
### Pesan komit dengan badan multi-paragraf dan beberapa footer
### Pesan komit dengan badan multi-paragraf dan multi-footer
```
fix: correct minor typos in code
@ -84,24 +88,26 @@ Refs #133
Kata kunci “HARUS”, “TIDAK BOLEH”, “DIBUTUHKAN”, “SEHARUSNYA”, “JANGAN SAMPAI”, “SEBAIKNYA”, “SEBAIKNYA TIDAK”, “DIREKOMENDASIKAN”, “BISA”, dan “OPSIONAL” di dokumen ini sesuai dengan [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Komit HARUS (MUST) diawali dengan tipe, yang terdiri dari kata benda, `feat`, `fix`, dll., diikuti dengan cakupan OPSIONAL (OPTIONAL) `!`, dan DIBUTUHKAN (REQUIRED) terminal colon dan spasi.
1. Komit HARUS (MUST) diawali dengan tipe, yang terdiri dari kata benda, `feat`, `fix`, dll., diikuti dengan scope OPSIONAL (OPTIONAL) `!`, dan DIBUTUHKAN (REQUIRED) terminal colon dan spasi.
1. Tipe `feat` HARUS (MUST) digunakan ketika komit menambahkan fitur baru ke aplikasi atau pustaka Anda.
1. Tipe `fix` HARUS (MUST) digunakan ketika komit merepresentasikan perbaikan bug untuk aplikasi Anda.
1. Cakupan BISA (MAY) disediakan setelah tipe. Cakupan HARUS (MAY) terdiri dari kata benda yang menggambarkan bagian dari kode yang dikelilingi tanda kurung, misalnya, e.g., `fix(parser):`
1. Deskripsi HARUS (MUST) segera mengikuti spasi setelah awalan tipe/cakupan. Deskripsi adalah ringkasan singkat dari perubahan kode, misalnya, _fix: array parsing issue when multiple spaces were contained in string_.
1. Badan yang lebih panjang BISA (MAY) disediakan setelah deskripsi singkat, memberikan informasi kontekstual tambahan tentang perubahan kode. Badan HARUS (MUST) memulai satu baris kosong setelah deskripsi.
1. Badan komit adalah bentuk bebas dan BISA (MAY) terdiri dari sejumlah paragraf terpisah baris baru.
1. Scope BISA (MAY) dicantumkan setelah tipe. Scope HARUS (MAY) terdiri dari kata benda yang menggambarkan bagian dari kode yang dikelilingi tanda kurung, misalnya, e.g., `fix(parser):`
1. Deskripsi HARUS (MUST) segera mengikuti spasi setelah awalan type/scope. Deskripsi adalah ringkasan singkat dari perubahan kode, misalnya, _fix: array parsing issue when multiple spaces were contained in string_.
1. Body yang lebih panjang BISA (MAY) disediakan setelah deskripsi singkat, memberikan informasi kontekstual tambahan tentang perubahan kode. Body HARUS (MUST) memulai satu baris kosong setelah deskripsi.
1. Body komit adalah bentuk bebas dan BISA (MAY) terdiri dari sejumlah paragraf terpisah baris baru.
1. Satu atau lebih footer BISA (MAY) disediakan satu baris kosong setelah badan. Setiap footer HARUS (MUST) terdiri dari token kata, diikuti oleh pemisah `:<space>` atau `<space>#`, diikuti oleh nilai string (ini terinspirasi oleh [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. Token footer HARUS (MUST) menggunakan `-` sebagai ganti karakter spasi putih, mis., `Acked-by` (ini membantu membedakan bagian footer dari badan multi-paragraf). Pengecualian dibuat untuk `BREAKING CHANGE`, yang BISA (MAY) juga digunakan sebagai token.
1. Nilai footer BISA (MAY) berisi spasi dan baris baru, dan penguraian HARUS (MUST) berakhir ketika pasangan token/pemisah footer yang berlaku berikutnya diamati.
1. Melanggar perubahan HARUS (MUST) ditunjukkan dalam tipe / lingkup awalan dari komit, atau sebagai entri dalam catatan kaki.
1. Jika dimasukkan sebagai footer, perubahan yang melanggar HARUS (MUST) terdiri dari teks huruf besar BREAKING CHANGE, diikuti oleh titik dua, spasi, dan deskripsi, mis., _BREAKING CHANGE: variabel lingkungan sekarang diutamakan daripada file konfigurasi_.
1. Jika termasuk dalam tipe/lingkup awalan, memecah perubahan HARUS (MUST) ditunjukkan oleh `!` Segera sebelum `:`. Jika `!` Digunakan, `BREAKING CHANGE:` BISA (MAY) dihapus dari bagian footer, dan deskripsi commit HARUS (MUST) digunakan untuk menjelaskan perubahan yang melanggar.
1. Jika termasuk dalam
awalan, memecah perubahan HARUS (MUST) ditunjukkan oleh `!` Segera sebelum `:`. Jika `!` Digunakan, `BREAKING CHANGE:` BISA (MAY) dihapus dari bagian footer, dan deskripsi commit HARUS (MUST) digunakan untuk menjelaskan perubahan yang melanggar.
1. Jenis selain `feat` dan `fix` BISA (MAY) digunakan dalam pesan komit Anda, mis., _docs: updated ref docs._
1. Unit-unit informasi yang membentuk konvensional melakukan TIDAK BOLEH (MUST NOT) diperlakukan sebagai case sensitif oleh implementor, dengan pengecualian BREAKING CHANGE yang HARUS (MUST) huruf besar.
1. BREAKING-CHANGE HARUS (MUST) identik dengan BREAKING CHANGE, bila digunakan sebagai token di footer.
## Mengapa menggunakan Komit Konvensional
## Mengapa menggunakan Conventional Konvensional
* Secara automatis menghasilkan CHANGELOGs.
* Secara automatis menentukan versi semantic (Berdasarkan tipe komit yang dilakukan).
@ -152,16 +158,16 @@ Dalam skenario terburuk, ini bukan akhir dunia jika komit mendarat yang tidak me
### Apakah semua kontributor saya perlu menggunakan spesifikasi commit konvensional?
Tidak! Jika Anda menggunakan alur kerja berbasis squash di pengelola Git dapat membersihkan pesan komit saat mereka digabung — menambahkan tidak ada beban kerja ke komuter biasa.
Tidak! Jika Anda menggunakan alur kerja berbasis squash di pengelola Git dapat membersihkan pesan komit saat mereka digabung — menambahkan tidak ada beban kerja ke committers biasa.
Alur kerja umum untuk ini adalah membuat sistem git Anda secara otomatis squash melakukan dari permintaan tarikan dan menyajikan formulir bagi pengelola utama untuk memasukkan pesan git commit yang tepat untuk penggabungan.
### Bagaimana Komit Konvensional menangani komit balik?
Mengembalikan kode bisa rumit: apakah Anda mengembalikan banyak komit? jika Anda mengembalikan fitur, haruskah rilis berikutnya sebagai tambalan?
Conventional Commits tidak membuat upaya eksplisit untuk mendefinisikan perilaku kembalikan. Alih-alih, kita serahkan pada perkakas penulis untuk menggunakan fleksibilitas _types_ dan _footers_ untuk mengembangkan logika mereka untuk menangani pengembalian.
Conventional Commits tidak membuat upaya eksplisit untuk mendefinisikan perilaku kembalikan. Alih-alih, kami menyerahkannya kepada perkakas penulis untuk menggunakan fleksibilitas _type_ dan _footers_ untuk mengembangkan logika mereka untuk menangani orang yang kembali.
One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted:
Satu rekomendasi adalah menggunakan tipe `revert`, dan foter yang merujuk komit SHA yang sedang dikembalikan:
```
revert: let us never again speak of the noodle incident
@ -176,6 +182,7 @@ Spesifikasi Conventional Commit terinspirasi oleh, dan didasarkan pada, [Angular
Draf pertama spesifikasi ini telah ditulis bersama dengan beberapa orang yang berkontribusi pada:
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): seperangkat alat untuk mem-parsing pesan komit konvensional dari riwayat git.
* [parse-commit-message](https://github.com/olstenlarck/parse-commit-message): Utilitas penguraian yang sesuai dengan spesifikasi untuk mendapatkan objek seperti `{ header: { type, scopre, subject }, body, footer }` dari string pesan komit yang diberikan.
* [bumped](https://bumped.github.io): alat untuk merilis perangkat lunak yang memudahkan untuk melakukan tindakan sebelum dan sesudah merilis versi baru perangkat lunak Anda.
* [unleash](https://github.com/netflix/unleash): alat untuk mengotomatiskan rilis perangkat lunak dan siklus penerbitan.
* [lerna](https://github.com/lerna/lerna): alat untuk mengelola monorepos, yang tumbuh dari proyek Babel.
@ -188,11 +195,11 @@ alat yang dibuat untuk membuat pesan komit mengikuti spesifikasi Komitmen Konven
Dapat dikonfigurasi dan digunakan untuk proyek PHP sebagai dependensi komposer atau dapat digunakan secara global untuk proyek non-PHP.
* [conform](https://github.com/autonomy/conform): alat yang dapat digunakan untuk menerapkan repositori, termasuk conventional commits.
* [standard-version](https://github.com/conventional-changelog/standard-version): Versi otomatis dan manajemen CHANGELOG, menggunakan tombol squash baru GitHub dan alur kerja Conventional Commits yang direkomendasikan.
* [Git Commit Template](https://plugins.jetbrains.com/plugin/9861-git-commit-template): Tambah dukungan _Komit Konvensional_ ke [JetBrains Editors](https://www.jetbrains.com/) (IntelliJ IDEA, PyCharm, PhpStorm...).
* [commitsar](https://github.com/commitsar-app/commitsar): Go tool untuk memeriksa apakah komit pada cabang sesuai komit konvensional. Dilengkapi dengan gambar Docker untuk penggunaan CI.
* [Git Commit Template](https://plugins.jetbrains.com/plugin/9861-git-commit-template): Menambahkan _Conventional Commits_ support untuk [JetBrains Editors](https://www.jetbrains.com/) (IntelliJ IDEA, PyCharm, PhpStorm...).
* [commitsar](https://github.com/commitsar-app/commitsar): Alat go (golang) untuk pengecekan jika komit dalam branch patuh pada conventional commit. Dilengkapi dengan docker image untuk kebutuhan CI.
* [semantic-release](https://github.com/semantic-release/semantic-release): Alat yang mengotomatiskan seluruh alur kerja rilis paket termasuk: menentukan nomor versi berikutnya, menghasilkan catatan rilis dan menerbitkan paket.
## Proyek Menggunakan Komit Konvensional
## Proyek Menggunakan Conventional Commits
* [yargs](https://github.com/yargs/yargs): parser argumen baris perintah bertema bajak laut favorit semua orang.
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): koleksi alat dan pustaka sumber terbuka untuk menambahkan cakupan tes ke tes JavaScript Anda.