From 48e3cc430d2680519dfd516acc943153531d9c46 Mon Sep 17 00:00:00 2001
From: Jafar Aziz <aziz@jafaraziz.com>
Date: Tue, 2 May 2023 09:05:57 +0700
Subject: [PATCH 1/5] wip: the first part

---
 .../learn/reacting-to-input-with-state.md     | 33 ++++++++++---------
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 522aa63a1d..cd0065913c 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -4,34 +4,35 @@ title: Reacting to Input with State
 
 <Intro>
 
-React provides a declarative way to manipulate the UI. Instead of manipulating individual pieces of the UI directly, you describe the different states that your component can be in, and switch between them in response to the user input. This is similar to how designers think about the UI.
+React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai keadaan komponen, dan mengubahnya sebagai respons terhadap masukan pengguna. Ini mirip dengan bagaimana desainer memikirkan tentang UI.
 
 </Intro>
 
 <YouWillLearn>
 
-* How declarative UI programming differs from imperative UI programming
-* How to enumerate the different visual states your component can be in
-* How to trigger the changes between the different visual states from code
+* Bagaimana declative UI programming berbeda dengan imperative UI programming
+* Bagaimana menjabarkan berbagai keadaan visual pada suatu komponen
+* Bagaimana cara memicu perubahan dari berbagai keadaan
 
 </YouWillLearn>
 
-## How declarative UI compares to imperative {/*how-declarative-ui-compares-to-imperative*/}
+## Bagaimana perbedaan declative UI dengan Imperative UI {/*how-declarative-ui-compares-to-imperative*/}
 
-When you design UI interactions, you probably think about how the UI *changes* in response to user actions. Consider a form that lets the user submit an answer:
+Ketika Anda mendesain interaksi antarmuka, Anda mungkin berfikir tentang bagaimana antarmuka berubah karena respon dari aksi pengguna. Sebagai contoh, suatu form yang memungkan pengguna untuk melakukan submit jawaban ketika:
 
-* When you type something into the form, the "Submit" button **becomes enabled.**
-* When you press "Submit", both the form and the button **become disabled,** and a spinner **appears.**
-* If the network request succeeds, the form **gets hidden,** and the "Thank you" message **appears.**
-* If the network request fails, an error message **appears,** and the form **becomes enabled** again.
+* Anda mengetikan sesuatu kedalam form, maka tombol submit menjadi **aktif**
+* Anda mengklik tombol "Submit", baik form maupun tombol "Submit" tersebut menjadi **nonaktif** dan _spinner_ muncul.
+* Apabila network request berhasil, form disembunyikan dan pesan "Terima Kasih" muncul
+* Apabila network request gagal, pesan galat muncul dan form menjadi aktif kembali.
 
-In **imperative programming,** the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Here's another way to think about this: imagine riding next to someone in a car and telling them turn by turn where to go.
+
+Pada **pemrograman imperatif**, yang disebutkan diatas berkaitan langsung dengan bagaimana Anda mengimplementasikan interaksi. Anda harus menulis intruksi yang tepat untuk memanipulasi UI tergantung apa yang sedang terjadi. Berikit ini adalah cara lain untuk memahami hal ini: bayangkan menumpang disebelah seseorang di dalam mobil dan memberitahu mereka kemana harus pergi disetiap belokan. 
 
 <Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
 
-They don't know where you want to go, they just follow your commands. (And if you get the directions wrong, you end up in the wrong place!) It's called *imperative* because you have to "command" each element, from the spinner to the button, telling the computer *how* to update the UI.
+Dia tidak tahu kemana Anda ingin pergi, dia hanya mengikuti perintah yang anda berikan (dan apabila Anda memberikan arah yang salah, Anda akan sampai ditempat yang salah juga). Hal tersebut dinamakan *imperatif*, karena Anda harus *memberikan perintah* setiap element, mulai dari _spinner_ hingga tombol dengan memberitahu komputer untuk mengupdate antarmuka. 
 
-In this example of imperative UI programming, the form is built *without* React. It only uses the browser [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
+Pada contoh pemrograman antarmuka imperatif, form dibangun tanpa menggunakan React, hanya mengguna browse [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
 
 <Sandpack>
 
@@ -131,11 +132,11 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-Manipulating the UI imperatively works well enough for isolated examples, but it gets exponentially more difficult to manage in more complex systems. Imagine updating a page full of different forms like this one. Adding a new UI element or a new interaction would require carefully checking all existing code to make sure you haven't introduced a bug (for example, forgetting to show or hide something).
+Memanipulasi antarmuka secara imperatif bekerja dengan baik pada contoh yang terisolasi, tetapi akan semakin sulit untuk diatur pada sistem yang kompleks. Bayangkan meng-update banyak form yang berbeda pada satu halaman seperti contoh diatas. Menambahkan elemen antarmuka atau menambah interaksi harus mengecek semua code yang ada secara hati-hati untuk memastikan bahwa Anda tidak menambahkan bug (misalnya lupa untuk menampilkan atau menyembunyikannya).
 
-React was built to solve this problem.
+React dibangun untuk mengatasi masalah ini.
 
-In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show,** and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you haven't considered!
+Pada React, Anda tidak perlu memanipulasi antarmuka secara langsung, maksudnya anda tidak perlu mengaktifkan, menonaktifkan, menampilkan, atau menyembunyikan suatu component secara langsung. Melainkan, Anda dapat **menyatakan apa yang ingin anda tampilkan**, dan React akan mengupdate antarmuka tersebut. Pikirkan Anda menyewa taksi dan memberitahu pengemudinya kemana Anda akan pergi, daripada memberitahukan dimana harus berbelok. Itu adalah tugas pengemudi untuk mencari tahu bagaimana mengantar Anda ke tujuannya, bahkan dia bisa menemukan jalan pintas yang tidak anda tahu.
 
 <Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
 

From c82ff652778d838ea11ca4cc44b0c7c1fe759564 Mon Sep 17 00:00:00 2001
From: Chris Qiang <chris@christianto.net>
Date: Wed, 30 Aug 2023 21:40:29 +0700
Subject: [PATCH 2/5] fix: Translate several parts of the page

---
 .../learn/reacting-to-input-with-state.md     | 166 +++++++++---------
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index cd0065913c..0bd515b019 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -1,38 +1,38 @@
 ---
-title: Reacting to Input with State
+title: Merespon Masukan dengan State
 ---
 
 <Intro>
 
-React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai keadaan komponen, dan mengubahnya sebagai respons terhadap masukan pengguna. Ini mirip dengan bagaimana desainer memikirkan tentang UI.
+React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai *state* komponen, dan mengubahnya sebagai respons terhadap masukan pengguna. Cara ini mirip dengan bagaimana desainer memikirkan tentang UI.
 
 </Intro>
 
 <YouWillLearn>
 
-* Bagaimana declative UI programming berbeda dengan imperative UI programming
-* Bagaimana menjabarkan berbagai keadaan visual pada suatu komponen
-* Bagaimana cara memicu perubahan dari berbagai keadaan
+* Bagaimana pemrograman UI deklaratif berbeda dari pemrograman UI imperatif
+* Bagaimana cara menjabarkan berbagai *state* visual yang berbeda pada komponen Anda
+* Bagaimana cara memicu perubahan dari berbagai *state*
 
 </YouWillLearn>
 
-## Bagaimana perbedaan declative UI dengan Imperative UI {/*how-declarative-ui-compares-to-imperative*/}
+## Membandingkan UI deklaratif dengan imperatif {/*how-declarative-ui-compares-to-imperative*/}
 
-Ketika Anda mendesain interaksi antarmuka, Anda mungkin berfikir tentang bagaimana antarmuka berubah karena respon dari aksi pengguna. Sebagai contoh, suatu form yang memungkan pengguna untuk melakukan submit jawaban ketika:
+Ketika Anda mendesain interaksi UI, Anda mungkin berpikir tentang bagaimana UI *berubah* dalam menanggapi tindakan pengguna. Pertimbangkan formulir yang memungkinkan pengguna mengirimkan jawaban:
 
-* Anda mengetikan sesuatu kedalam form, maka tombol submit menjadi **aktif**
-* Anda mengklik tombol "Submit", baik form maupun tombol "Submit" tersebut menjadi **nonaktif** dan _spinner_ muncul.
-* Apabila network request berhasil, form disembunyikan dan pesan "Terima Kasih" muncul
-* Apabila network request gagal, pesan galat muncul dan form menjadi aktif kembali.
+* Anda mengetikan sesuatu kedalam formulir, maka tombol kirim menjadi **aktif**
+* Anda mengklik tombol "Kirim", baik formulir maupun tombol "Kirim" tersebut menjadi **nonaktif** dan *spinner* muncul.
+* Apabila permintaan jaringan berhasil, formulir disembunyikan dan pesan "Terima Kasih" muncul
+* Apabila permintaan jaringan gagal, pesan kesalahan muncul dan formulir menjadi aktif kembali.
 
 
-Pada **pemrograman imperatif**, yang disebutkan diatas berkaitan langsung dengan bagaimana Anda mengimplementasikan interaksi. Anda harus menulis intruksi yang tepat untuk memanipulasi UI tergantung apa yang sedang terjadi. Berikit ini adalah cara lain untuk memahami hal ini: bayangkan menumpang disebelah seseorang di dalam mobil dan memberitahu mereka kemana harus pergi disetiap belokan. 
+Pada **pemrograman imperatif**, yang disebutkan di atas berkaitan langsung dengan bagaimana Anda mengimplementasikan interaksi tersebut. Anda harus menulis intruksi yang spesifik untuk memanipulasi UI tergantung apa yang sedang terjadi. Cara lain untuk memikirkan hal ini adalah: bayangkan menumpang disebelah seseorang di dalam mobil dan memberitahu mereka kemana harus pergi disetiap belokan. 
 
-<Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
+<Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="Di dalam mobil yang dikemudikan oleh orang yang tampak khawatir, merepresentasikan JavaScript, seorang penumpang memerintahkan pengemudi untuk melakukan serangkaian navigasi belokan demi belokan yang rumit." />
 
-Dia tidak tahu kemana Anda ingin pergi, dia hanya mengikuti perintah yang anda berikan (dan apabila Anda memberikan arah yang salah, Anda akan sampai ditempat yang salah juga). Hal tersebut dinamakan *imperatif*, karena Anda harus *memberikan perintah* setiap element, mulai dari _spinner_ hingga tombol dengan memberitahu komputer untuk mengupdate antarmuka. 
+Dia tidak tahu kemana Anda ingin pergi, dia hanya mengikuti perintah yang Anda berikan (dan apabila Anda memberikan arah yang salah, Anda akan sampai ditempat yang salah juga). Hal ini disebut *imperatif* karena Anda harus " memberi perintah" pada setiap elemen, dari pemintal hingga tombol, memberi tahu komputer *bagaimana cara* untuk memperbarui UI tersebut.
 
-Pada contoh pemrograman antarmuka imperatif, form dibangun tanpa menggunakan React, hanya mengguna browse [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
+Pada contoh pemrograman antarmuka imperatif, formulir dibangun tanpa menggunakan React, hanya mengguna browse [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
 
 <Sandpack>
 
@@ -82,13 +82,13 @@ function disable(el) {
 }
 
 function submitForm(answer) {
-  // Pretend it's hitting the network.
+  // Anggap saja sedang menghubungi jaringan.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       if (answer.toLowerCase() == 'istanbul') {
         resolve();
       } else {
-        reject(new Error('Good guess but a wrong answer. Try again!'));
+        reject(new Error('Tebakan yang bagus, tapi salah. Coba lagi!'));
       }
     }, 1500);
   });
@@ -112,17 +112,17 @@ textarea.oninput = handleTextareaChange;
 
 ```html public/index.html
 <form id="form">
-  <h2>City quiz</h2>
+  <h2>Kuis kota</h2>
   <p>
-    What city is located on two continents?
+    Kota apa yang terletak di dua benua?
   </p>
   <textarea id="textarea"></textarea>
   <br />
-  <button id="button" disabled>Submit</button>
-  <p id="loading" style="display: none">Loading...</p>
+  <button id="button" disabled>Kirim</button>
+  <p id="loading" style="display: none">Memuat...</p>
   <p id="error" style="display: none; color: red;"></p>
 </form>
-<h1 id="success" style="display: none">That's right!</h1>
+<h1 id="success" style="display: none">Benar sekali!</h1>
 
 <style>
 * { box-sizing: border-box; }
@@ -132,37 +132,37 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-Memanipulasi antarmuka secara imperatif bekerja dengan baik pada contoh yang terisolasi, tetapi akan semakin sulit untuk diatur pada sistem yang kompleks. Bayangkan meng-update banyak form yang berbeda pada satu halaman seperti contoh diatas. Menambahkan elemen antarmuka atau menambah interaksi harus mengecek semua code yang ada secara hati-hati untuk memastikan bahwa Anda tidak menambahkan bug (misalnya lupa untuk menampilkan atau menyembunyikannya).
+Memanipulasi UI secara imperatif bekerja dengan cukup baik untuk contoh-contoh yang terpencil, tetapi menjadi jauh lebih sulit untuk dikelola dalam sistem yang lebih kompleks. Bayangkan jika Anda memperbarui halaman yang penuh dengan berbagai macam formulir seperti formulir di atas. Menambahkan elemen UI baru atau interaksi baru akan memerlukan pemeriksaan yang hati-hati terhadap semua kode yang ada untuk memastikan bahwa Anda tidak membuat bug (misalnya, lupa menampilkan atau menyembunyikan sesuatu).
 
 React dibangun untuk mengatasi masalah ini.
 
-Pada React, Anda tidak perlu memanipulasi antarmuka secara langsung, maksudnya anda tidak perlu mengaktifkan, menonaktifkan, menampilkan, atau menyembunyikan suatu component secara langsung. Melainkan, Anda dapat **menyatakan apa yang ingin anda tampilkan**, dan React akan mengupdate antarmuka tersebut. Pikirkan Anda menyewa taksi dan memberitahu pengemudinya kemana Anda akan pergi, daripada memberitahukan dimana harus berbelok. Itu adalah tugas pengemudi untuk mencari tahu bagaimana mengantar Anda ke tujuannya, bahkan dia bisa menemukan jalan pintas yang tidak anda tahu.
+Pada React, Anda tidak perlu memanipulasi antarmuka secara langsung, maksudnya Anda tidak perlu mengaktifkan, menonaktifkan, menampilkan, atau menyembunyikan suatu component secara langsung. Melainkan, Anda dapat **mendeklarasikan apa yang ingin Anda tampilkan**, dan React akan mengupdate antarmuka tersebut. Pikirkan Anda menyewa taksi dan memberitahu pengemudinya kemana Anda akan pergi, daripada memberitahukan di mana ia harus berbelok. Itu adalah tugas pengemudi untuk mencari tahu bagaimana mengantar Anda ke tujuan, bahkan dia bisa menemukan jalan pintas yang tidak Anda tahu!
 
-<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
+<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="Di dalam mobil yang dikemudikan oleh React, seorang penumpang meminta untuk diantarkan ke tempat tertentu pada peta. React akan mencari cara menuju ke tempat tersebut." />
 
-## Thinking about UI declaratively {/*thinking-about-ui-declaratively*/}
+## Berpikir tentang UI secara deklaratif {/*thinking-about-ui-declaratively*/}
 
-You've seen how to implement a form imperatively above. To better understand how to think in React, you'll walk through reimplementing this UI in React below:
+Anda telah melihat bagaimana cara mengimplementasikan sebuah formulir secara imperatif di atas. Untuk lebih memahami cara berpikir dalam React, Anda akan mempelajari cara mengimplementasikan ulang UI berikut ini dalam React:
 
-1. **Identify** your component's different visual states
-2. **Determine** what triggers those state changes
-3. **Represent** the state in memory using `useState`
-4. **Remove** any non-essential state variables
-5. **Connect** the event handlers to set the state
+1. **Identifikasi** berbagai *state* komponen visual Anda
+2. **Tentukan** apa yang menyebabkan perubahan *state* tersebut
+3. **Representasikan** *state* tersebut dalam memori dengan menggunakan `useState`
+4. **Hapus** variabel *state* yang tidak esensial
+5. **Hubungkan** *event handler* untuk mengatur *state* tersebut
 
-### Step 1: Identify your component's different visual states {/*step-1-identify-your-components-different-visual-states*/}
+### Langkah 1: Identifikasi berbagai *state* komponen visual Anda {/*step-1-identify-your-components-different-visual-states*/}
 
-In computer science, you may hear about a ["state machine"](https://en.wikipedia.org/wiki/Finite-state_machine) being in one of several “states”. If you work with a designer, you may have seen mockups for different "visual states". React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration.
+Dalam ilmu komputer, Anda mungkin pernah mendengar tentang ["*state machine*"](https://en.wikipedia.org/wiki/Finite-state_machine) yang merupakan salah satu dari beberapa "*state*". Jika Anda bekerja dengan seorang desainer, Anda mungkin pernah melihat model visual untuk "*visual state*" yang berbeda. React terletak pada persimpangan antara desain dan ilmu komputer, sehingga kedua ide ini menjadi sumber inspirasi.
 
-First, you need to visualize all the different "states" of the UI the user might see:
+Pertama, Anda perlu memvisualisasikan seluruh "*state*" UI yang mungkin akan dilihat oleh pengguna:
 
-* **Empty**: Form has a disabled "Submit" button.
-* **Typing**: Form has an enabled "Submit" button.
-* **Submitting**: Form is completely disabled. Spinner is shown.
-* **Success**: "Thank you" message is shown instead of a form.
-* **Error**: Same as Typing state, but with an extra error message.
+* **Kosong**: Formulir memiliki tombol "Kirim" yang dinonaktifkan.
+* **Mengetik**: Formulir memiliki tombol "Kirim" yang diaktifkan.
+* **Mengirimkan**: Formulir sepenuhnya dinonaktifkan. *Spinner* ditampilkan.
+* **Sukses**: Pesan "Terima kasih" ditampilkan, menggantikan formulir.
+* **Kesalahan**: Sama seperti *state* Mengetik, namun dengan tambahan pesan kesalahan.
 
-Just like a designer, you'll want to "mock up" or create "mocks" for the different states before you add logic. For example, here is a mock for just the visual part of the form. This mock is controlled by a prop called `status` with a default value of `'empty'`:
+Sama seperti seorang desainer, Anda pasti ingin "model visual" atau membuat "tiruan" untuk berbagai state sebelum menerapkan logika. Sebagai contoh, berikut ini adalah *mock* hanya untuk bagian visual dari formulir. *Mock* ini dikontrol oleh sebuah *prop* yang disebut `status` dengan nilai *default* `'empty'`:
 
 <Sandpack>
 
@@ -171,19 +171,19 @@ export default function Form({
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>Benar sekali!</h1>
   }
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>Kuis kota</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        Di kota manakah terdapat papan reklame yang mengubah udara menjadi air yang dapat diminum?
       </p>
       <form>
         <textarea />
         <br />
         <button>
-          Submit
+          Kirim
         </button>
       </form>
     </>
@@ -193,7 +193,7 @@ export default function Form({
 
 </Sandpack>
 
-You could call that prop anything you like, the naming is not important. Try editing `status = 'empty'` to `status = 'success'` to see the success message appear. Mocking lets you quickly iterate on the UI before you wire up any logic. Here is a more fleshed out prototype of the same component, still "controlled" by the `status` prop:
+Anda dapat menamai *prop* tersebut dengan nama apa pun yang Anda inginkan, penamaannya tidaklah penting. Cobalah mengubah `status = 'kosong'` menjadi `status = 'sukses'` untuk melihat pesan sukses muncul. *Mock* memungkinkan Anda melakukan iterasi dengan cepat pada UI sebelum Anda menyambungkan logika apa pun. Berikut ini adalah prototipe yang lebih matang dari komponen yang sama, yang masih " dikontrol" oleh *prop* `status`:
 
 <Sandpack>
 
@@ -203,13 +203,13 @@ export default function Form({
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>Benar sekali!</h1>
   }
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>Kuis kota</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        Di kota manakah terdapat papan reklame yang mengubah udara menjadi air yang dapat diminum?
       </p>
       <form>
         <textarea disabled={
@@ -224,7 +224,7 @@ export default function Form({
         </button>
         {status === 'error' &&
           <p className="Error">
-            Good guess but a wrong answer. Try again!
+            Tebakan yang bagus, tapi salah. Coba lagi!
           </p>
         }
       </form>
@@ -241,9 +241,9 @@ export default function Form({
 
 <DeepDive>
 
-#### Displaying many visual states at once {/*displaying-many-visual-states-at-once*/}
+#### Menampilkan banyak *state* visual sekaligus {/*displaying-many-visual-states-at-once*/}
 
-If a component has a lot of visual states, it can be convenient to show them all on one page:
+Jika suatu komponen memiliki banyak state visual, mungkin akan lebih mudah untuk menampilkan semuanya pada satu halaman:
 
 <Sandpack>
 
@@ -263,7 +263,7 @@ export default function App() {
     <>
       {statuses.map(status => (
         <section key={status}>
-          <h4>Form ({status}):</h4>
+          <h4>Formulir ({status}):</h4>
           <Form status={status} />
         </section>
       ))}
@@ -275,7 +275,7 @@ export default function App() {
 ```js Form.js
 export default function Form({ status }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>Benar sekali!</h1>
   }
   return (
     <form>
@@ -291,7 +291,7 @@ export default function Form({ status }) {
       </button>
       {status === 'error' &&
         <p className="Error">
-          Good guess but a wrong answer. Try again!
+          Tebakan yang bagus, tapi salah. Coba lagi!
         </p>
       }
     </form>
@@ -308,61 +308,61 @@ body { margin: 0; }
 
 </Sandpack>
 
-Pages like this are often called "living styleguides" or "storybooks".
+Halaman seperti ini sering disebut "*living styleguides*" atau "*storybooks*".
 
 </DeepDive>
 
-### Step 2: Determine what triggers those state changes {/*step-2-determine-what-triggers-those-state-changes*/}
+### Langkah 2: Tentukan apa yang menyebabkan perubahan *state* tersebut {/*step-2-determine-what-triggers-those-state-changes*/}
 
-You can trigger state updates in response to two kinds of inputs:
+Anda dapat memicu pembaruan state sebagai respons terhadap dua jenis masukan:
 
-* **Human inputs,** like clicking a button, typing in a field, navigating a link.
-* **Computer inputs,** like a network response arriving, a timeout completing, an image loading.
+* **Masukan manusia,** seperti mengklik tombol, mengetik di kolom, navigasi tautan.
+* **Masukan komputer,** seperti respon jaringan yang diterima, batas waktu selesai, pemuatan gambar.
 
 <IllustrationBlock>
-  <Illustration caption="Human inputs" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
-  <Illustration caption="Computer inputs" alt="Ones and zeroes." src="/images/docs/illustrations/i_inputs2.png" />
+  <Illustration caption="Human inputs" alt="Sebuah jari." src="/images/docs/illustrations/i_inputs1.png" />
+  <Illustration caption="Computer inputs" alt="Satu dan nol." src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-In both cases, **you must set [state variables](/learn/state-a-components-memory#anatomy-of-usestate) to update the UI.** For the form you're developing, you will need to change state in response to a few different inputs:
+Pada kedua kasus tersebut, **Anda harus mengatur [variabel *state*](/learn/state-a-components-memory#anatomy-of-usestate) untuk memperbarui UI.** Untuk form yang Anda kembangkan, Anda perlu mengubah *state* sebagai respons terhadap berbagai masukan yang berbeda:
 
-* **Changing the text input** (human) should switch it from the *Empty* state to the *Typing* state or back, depending on whether the text box is empty or not.
-* **Clicking the Submit button** (human) should switch it to the *Submitting* state.
-* **Successful network response** (computer) should switch it to the *Success* state.
-* **Failed network response** (computer) should switch it to the *Error* state with the matching error message.
+* **Mengubah input teks** (manusia) akan mengubahnya dari *state* *Kosong* ke *state* *Mengetik* atau sebaliknya, tergantung apakah kotak teks kosong atau tidak.
+* **Mengklik tombol Kirim** (manusia) akan mengalihkannya ke *state* *Mengirimkan*.
+* **Respons jaringan yang berhasil** (komputer) akan mengalihkannya ke *state* *Sukses*.
+* **Respon jaringan gagal** (komputer) akan mengalihkannya ke *state* *Kesalahan* dengan pesan kesalahan yang sesuai.
 
 <Note>
 
-Notice that human inputs often require [event handlers](/learn/responding-to-events)!
+Perhatikan bahwa masukan dari manusia sering kali membutuhkan [*event handler*](/learn/respon-to-events)!
 
 </Note>
 
-To help visualize this flow, try drawing each state on paper as a labeled circle, and each change between two states as an arrow. You can sketch out many flows this way and sort out bugs long before implementation.
+Untuk membantu memvisualisasikan alur ini, cobalah gambar setiap *state* di atas kertas sebagai lingkaran berlabel, dan setiap perubahan di antara dua *state* sebagai tanda panah. Anda dapat membuat kerangka alur dengan cara ini dan mencegah *bug* jauh sebelum implementasi.
 
 <DiagramGroup>
 
-<Diagram name="responding_to_input_flow" height={350} width={688} alt="Flow chart moving left to right with 5 nodes. The first node labeled 'empty' has one edge labeled 'start typing' connected to a node labeled 'typing'. That node has one edge labeled 'press submit' connected to a node labeled 'submitting', which has two edges. The left edge is labeled 'network error' connecting to a node labeled 'error'. The right edge is labeled 'network success' connecting to a node labeled 'success'.">
+<Diagram name="responding_to_input_flow" height={350} width={688} alt="Diagram alur bergerak dari kiri ke kanan dengan 5 simpul. Simpul pertama yang berlabel 'kosong' memiliki satu edge berlabel 'mulai mengetik' yang terhubung ke simpul berlabel 'mengetik'. Simpul tersebut memiliki satu edge berlabel 'tekan kirim' yang terhubung ke simpul berlabel 'kirim', yang memiliki dua edge. Edge di kiri diberi label 'kesalahan jaringan' yang terhubung ke simpul berlabel 'kesalahan'. Edge di kanan berlabel 'keberhasilan jaringan' yang terhubung ke simpul berlabel 'sukses'.">
 
-Form states
+Berbagai *state* formulir
 
 </Diagram>
 
 </DiagramGroup>
 
-### Step 3: Represent the state in memory with `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
+### Langkah 3: Representasikan *state* tersebut dalam memori dengan menggunakan `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
 
-Next you'll need to represent the visual states of your component in memory with [`useState`.](/reference/react/useState) Simplicity is key: each piece of state is a "moving piece", and **you want as few "moving pieces" as possible.** More complexity leads to more bugs!
+Selanjutnya Anda harus merepresentasikan *state* visual dari komponen Anda di dalam memori dengan [`useState`.](/reference/react/useState) Kesederhanaan adalah kuncinya: setiap bagian dari *state* adalah sebuah "bagian yang bergerak", dan **Anda ingin sesedikit mungkin "bagian yang bergerak"** Semakin kompleks maka akan semakin banyak bug!
 
-Start with the state that *absolutely must* be there. For example, you'll need to store the `answer` for the input, and the `error` (if it exists) to store the last error:
+Mulailah dengan state yang *mutlak harus* ada di sana. Sebagai contoh, Anda harus menyimpan `answer` untuk masukan, dan `error` (jika ada) untuk menyimpan kesalahan sebelumnya:
 
 ```js
 const [answer, setAnswer] = useState('');
 const [error, setError] = useState(null);
 ```
 
-Then, you'll need a state variable representing which one of the visual states that you want to display. There's usually more than a single way to represent that in memory, so you'll need to experiment with it.
+Kemudian, Anda akan membutuhkan variabel *state* yang mewakili salah satu status visual yang ingin Anda tampilkan. Biasanya ada lebih dari satu cara untuk merepresentasikannya dalam memori, jadi Anda perlu bereksperimen dengannya.
 
-If you struggle to think of the best way immediately, start by adding enough state that you're *definitely* sure that all the possible visual states are covered:
+Jika Anda kesulitan untuk menemukan cara terbaik dengan segera, mulailah dengan menambahkan cukup banyak *state* sehingga Anda *yakin* bahwa semua keadaan visual yang ada sudah tercakup:
 
 ```js
 const [isEmpty, setIsEmpty] = useState(true);
@@ -372,9 +372,9 @@ const [isSuccess, setIsSuccess] = useState(false);
 const [isError, setIsError] = useState(false);
 ```
 
-Your first idea likely won't be the best, but that's ok--refactoring state is a part of the process!
+Ide pertama Anda mungkin bukan yang terbaik, tapi itu bukan masalah, menulis ulang *state* adalah bagian dari proses!
 
-### Step 4: Remove any non-essential state variables {/*step-4-remove-any-non-essential-state-variables*/}
+### Langkah 4: Hapus variabel *state* yang tidak esensial {/*step-4-remove-any-non-essential-state-variables*/}
 
 You want to avoid duplication in the state content so you're only tracking what is essential. Spending a little time on refactoring your state structure will make your components easier to understand, reduce duplication, and avoid unintended meanings. Your goal is to **prevent the cases where the state in memory doesn't represent any valid UI that you'd want a user to see.** (For example, you never want to show an error message and disable the input at the same time, or the user won't be able to correct the error!)
 
@@ -402,7 +402,7 @@ These three variables are a good enough representation of this form's state. How
 
 </DeepDive>
 
-### Step 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
+### Langkah 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
 
 Lastly, create event handlers that update the state. Below is the final form, with all event handlers wired up:
 
@@ -417,7 +417,7 @@ export default function Form() {
   const [status, setStatus] = useState('typing');
 
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>Benar sekali!</h1>
   }
 
   async function handleSubmit(e) {
@@ -438,9 +438,9 @@ export default function Form() {
 
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>Kuis kota</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        Di kota manakah terdapat papan reklame yang mengubah udara menjadi air yang dapat diminum?
       </p>
       <form onSubmit={handleSubmit}>
         <textarea
@@ -471,7 +471,7 @@ function submitForm(answer) {
     setTimeout(() => {
       let shouldError = answer.toLowerCase() !== 'lima'
       if (shouldError) {
-        reject(new Error('Good guess but a wrong answer. Try again!'));
+        reject(new Error('Tebakan yang bagus, tapi salah. Coba lagi!'));
       } else {
         resolve();
       }

From 598d070c94bbe4b30e58fa22ce4a928866df5850 Mon Sep 17 00:00:00 2001
From: Chris Qiang <chris@christianto.net>
Date: Sat, 2 Sep 2023 16:34:56 +0700
Subject: [PATCH 3/5] fix: continue translation

---
 .../learn/reacting-to-input-with-state.md     | 184 +++++++++---------
 1 file changed, 92 insertions(+), 92 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 0bd515b019..faf676b5bf 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -199,7 +199,7 @@ Anda dapat menamai *prop* tersebut dengan nama apa pun yang Anda inginkan, penam
 
 ```js
 export default function Form({
-  // Try 'submitting', 'error', 'success':
+  // Cobalah 'submitting', 'error', 'success':
   status = 'empty'
 }) {
   if (status === 'success') {
@@ -376,35 +376,35 @@ Ide pertama Anda mungkin bukan yang terbaik, tapi itu bukan masalah, menulis ula
 
 ### Langkah 4: Hapus variabel *state* yang tidak esensial {/*step-4-remove-any-non-essential-state-variables*/}
 
-You want to avoid duplication in the state content so you're only tracking what is essential. Spending a little time on refactoring your state structure will make your components easier to understand, reduce duplication, and avoid unintended meanings. Your goal is to **prevent the cases where the state in memory doesn't represent any valid UI that you'd want a user to see.** (For example, you never want to show an error message and disable the input at the same time, or the user won't be able to correct the error!)
+Anda ingin menghindari duplikasi pada konten *state* sehingga Anda hanya perlu mencatat *state* yang penting saja. Luangkan sedikit waktu untuk melakukan penulisan ulang pada struktur *state* Anda akan membuat komponen Anda lebih mudah dipahami, mengurangi duplikasi, dan menghindari ambiguitas yang tidak diinginkan. Target Anda adalah untuk **mencegah kasus di mana *state* dalam memori tidak merepresentasikan UI valid yang Anda harapkan untuk dilihat oleh pengguna** (Sebagai contoh, Anda tidak akan pernah ingin menampilkan pesan kesalahan dan menonaktifkan input pada waktu yang sama, atau pengguna tidak akan bisa memperbaiki kesalahan tersebut!)
 
-Here are some questions you can ask about your state variables:
+Berikut adalah beberapa hal yang dapat Anda pertimbangkan tentang variabel *state* Anda:
 
-* **Does this state cause a paradox?** For example, `isTyping` and `isSubmitting` can't both be `true`. A paradox usually means that the state is not constrained enough. There are four possible combinations of two booleans, but only three correspond to valid states. To remove the "impossible" state, you can combine these into a `status` that must be one of three values: `'typing'`, `'submitting'`, or `'success'`.
-* **Is the same information available in another state variable already?** Another paradox: `isEmpty` and `isTyping` can't be `true` at the same time. By making them separate state variables, you risk them going out of sync and causing bugs. Fortunately, you can remove `isEmpty` and instead check `answer.length === 0`.
-* **Can you get the same information from the inverse of another state variable?** `isError` is not needed because you can check `error !== null` instead.
+* **Apakah keadaan ini menimbulkan kondisi paradoks?** Sebagai contoh, `isTyping` dan `isSubmit` tidak mungkin bernilai `true` bersamaan. Kondisi paradoks biasanya menandakan bahwa *state* tidak dibatasi dengan baik. Ada empat kemungkinan kombinasi dari dua boolean, tetapi hanya tiga yang sesuai dengan *state* yang sesuai. Untuk menghilangkan *state* yang "tidak mungkin", Anda dapat menyatukannya menjadi sebuah `status` yang harus merupakan salah satu dari tiga nilai: `'typing'` (mengetik), `'submitting'` (mengirim), atau `'success'` (sukses).
+* **Apakah informasi yang sama sudah tersedia di variabel status yang lain?** Kondisi paradoks lain: `isEmpty` dan `isTyping` tidak dapat bernilai `true` pada saat yang bersamaan. Dengan menjadikannya variabel *state* yang terpisah, Anda berisiko membuat keduanya tidak sinkron dan mengakibatkan bug. Untungnya, Anda dapat menghapus `isEmpty` dan sebagai gantinya memeriksa `answer.length === 0`.
+* **Bisakah Anda mendapatkan informasi yang sama dari kebalikan dari variabel state yang lain?** `isError` tidak diperlukan karena Anda bisa memeriksa `error !== null` sebagai gantinya.
 
-After this clean-up, you're left with 3 (down from 7!) *essential* state variables:
+Setelah pembersihan ini, Anda akan memiliki 3 ( berkurang dari 7!) variabel *state* yang *esensial*:
 
 ```js
 const [answer, setAnswer] = useState('');
 const [error, setError] = useState(null);
-const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'
+const [status, setStatus] = useState('typing'); // 'typing', 'submitting', atau 'success'
 ```
 
-You know they are essential, because you can't remove any of them without breaking the functionality.
+Anda tahu mereka sangat penting, karena Anda tidak dapat menghapus salah satu dari variabel-variabel tersebut tanpa merusak fungsionalitasnya.
 
 <DeepDive>
 
-#### Eliminating “impossible” states with a reducer {/*eliminating-impossible-states-with-a-reducer*/}
+#### Menghilangkan *state-state* "tidak mungkin" dengan *reducer* {/*eliminating-impossible-states-with-a-reducer*/}
 
-These three variables are a good enough representation of this form's state. However, there are still some intermediate states that don't fully make sense. For example, a non-null `error` doesn't make sense when `status` is `'success'`. To model the state more precisely, you can [extract it into a reducer.](/learn/extracting-state-logic-into-a-reducer) Reducers let you unify multiple state variables into a single object and consolidate all the related logic!
+Ketiga variabel ini merupakan representasi yang cukup baik dari *state* formulir ini. Namun, masih ada beberapa *state* lanjutan yang tidak sepenuhnya masuk akal. Sebagai contoh, `error` yang non-null tidak masuk akal ketika `status` adalah `'success'`. Untuk memodelkan *state* dengan lebih akurat, Anda dapat [mengekstraknya ke sebuah reducer.](/learn/extracting-state-logic-into-a-reducer) Reducer memungkinkan Anda menyatukan beberapa variabel *state* ke dalam satu objek dan menggabungkan semua logika yang berhubungan!
 
 </DeepDive>
 
-### Langkah 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
+### Langkah 5: Hubungkan *event handler* untuk mengatur *state* tersebut {/*step-5-connect-the-event-handlers-to-set-state*/}
 
-Lastly, create event handlers that update the state. Below is the final form, with all event handlers wired up:
+Terakhir, buatlah *event handler* yang memperbarui *state*. Berikut ini adalah bentuk akhir, dengan semua *event handler* yang terhubung:
 
 <Sandpack>
 
@@ -466,7 +466,7 @@ export default function Form() {
 }
 
 function submitForm(answer) {
-  // Pretend it's hitting the network.
+  // Anggap saja sedang menghubungi jaringan.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       let shouldError = answer.toLowerCase() !== 'lima'
@@ -486,17 +486,17 @@ function submitForm(answer) {
 
 </Sandpack>
 
-Although this code is longer than the original imperative example, it is much less fragile. Expressing all interactions as state changes lets you later introduce new visual states without breaking existing ones. It also lets you change what should be displayed in each state without changing the logic of the interaction itself.
+Meskipun kode ini lebih panjang daripada contoh imperatif semula, kode ini lebih tidak mudah rusak. Mengekspresikan semua interaksi sebagai perubahan *state* memungkinkan Anda untuk memperkenalkan *state* visual baru tanpa merusak *state* yang sudah ada. Hal ini juga memungkinkan Anda untuk mengubah apa yang harus ditampilkan di setiap *state* tanpa mengubah logika interaksi itu sendiri.
 
 <Recap>
 
-* Declarative programming means describing the UI for each visual state rather than micromanaging the UI (imperative).
-* When developing a component:
-  1. Identify all its visual states.
-  2. Determine the human and computer triggers for state changes.
-  3. Model the state with `useState`.
-  4. Remove non-essential state to avoid bugs and paradoxes.
-  5. Connect the event handlers to set state.
+* Pemrograman deklaratif berarti mendeskripsikan UI untuk setiap *visual state* daripada mengelola UI secara terperinci (imperatif).
+* Saat mengembangkan sebuah komponen:
+  1. Identifikasi semua *visual state*-nya.
+  2. Tentukan pemicu dari pengguna dan komputer untuk perubahan *state*.
+  3. Memodelkan *state* dengan `useState`.
+  4. Hapus *state* yang tidak esensial untuk menghindari bug dan kondisi paradoks.
+  5. Hubungkan event handler untuk menyetel *state*.
 
 </Recap>
 
@@ -504,11 +504,11 @@ Although this code is longer than the original imperative example, it is much le
 
 <Challenges>
 
-#### Add and remove a CSS class {/*add-and-remove-a-css-class*/}
+#### Menambah dan menghapus kelas CSS {/*add-and-remove-a-css-class*/}
 
-Make it so that clicking on the picture *removes* the `background--active` CSS class from the outer `<div>`, but *adds* the `picture--active` class to the `<img>`. Clicking the background again should restore the original CSS classes.
+Buatlah agar mengklik gambar *menghapus* kelas CSS `background--active` dari `<div>` bagian luar, tetapi *menambahkan* kelas `picture--active` ke `<img>`. Mengklik latar belakang lagi akan mengembalikan kelas CSS semula.
 
-Visually, you should expect that clicking on the picture removes the purple background and highlights the picture border. Clicking outside the picture highlights the background, but removes the picture border highlight.
+Secara visual, Anda seharusnya dapat memperkirakan bahwa dengan mengeklik gambar, Anda akan menghilangkan latar belakang ungu dan menyorot tepian gambar. Mengklik di luar gambar akan menyorot latar belakang, tetapi menghilangkan sorotan tepian gambar tersebut.
 
 <Sandpack>
 
@@ -518,7 +518,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="Rumah Pelangi di Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -557,14 +557,14 @@ body { margin: 0; padding: 0; height: 250px; }
 
 <Solution>
 
-This component has two visual states: when the image is active, and when the image is inactive:
+Komponen ini memiliki dua status visual: apabila gambar aktif, dan apabila gambar tidak aktif:
 
-* When the image is active, the CSS classes are `background` and `picture picture--active`.
-* When the image is inactive, the CSS classes are `background background--active` and `picture`.
+* Saat gambar aktif, kelas CSS adalah `background` dan `picture picture--active`.
+* Ketika gambar tidak aktif, kelas CSS adalah `background background--active` dan `picture`.
 
-A single boolean state variable is enough to remember whether the image is active. The original task was to remove or add CSS classes. However, in React you need to *describe* what you want to see rather than *manipulate* the UI elements. So you need to calculate both CSS classes based on the current state. You also need to [stop the propagation](/learn/responding-to-events#stopping-propagation) so that clicking the image doesn't register as a click on the background.
+Sebuah variabel *state* boolean sudah cukup untuk menyimpan informasi, apakah gambar tersebut aktif atau tidak. Tugas awalnya adalah menghapus atau menambahkan kelas CSS. Namun, di React Anda perlu *mendeskripsikan* apa yang ingin Anda lihat daripada *memanipulasi* elemen UI. Jadi, Anda perlu menghitung kedua kelas CSS berdasarkan *state* saat ini. Anda juga perlu [menghentikan propagasi](/learn/responing-to-events#stopping-propagation) agar mengklik gambar tidak terdeteksi sebagai klik pada latar belakang.
 
-Verify that this version works by clicking the image and then outside of it:
+Pastikan bahwa versi ini berfungsi dengan baik, dengan mengeklik gambar dan kemudian klik kembali di luar gambar tersebut:
 
 <Sandpack>
 
@@ -593,7 +593,7 @@ export default function Picture() {
           setIsActive(true);
         }}
         className={pictureClassName}
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="Rumah Pelangi di Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -631,7 +631,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Alternatively, you could return two separate chunks of JSX:
+Atau, Anda dapat mengembalikan dua potongan JSX yang terpisah:
 
 <Sandpack>
 
@@ -648,7 +648,7 @@ export default function Picture() {
       >
         <img
           className="picture picture--active"
-          alt="Rainbow houses in Kampung Pelangi, Indonesia"
+          alt="Rumah Pelangi di Kampung Pelangi, Indonesia"
           src="https://i.imgur.com/5qwVYb1.jpeg"
           onClick={e => e.stopPropagation()}
         />
@@ -659,7 +659,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="Rumah Pelangi di Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
         onClick={() => setIsActive(true)}
       />
@@ -698,27 +698,27 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Keep in mind that if two different JSX chunks describe the same tree, their nesting (first `<div>` → first `<img>`) has to line up. Otherwise, toggling `isActive` would recreate the whole tree below and [reset its state.](/learn/preserving-and-resetting-state) This is why, if a similar JSX tree gets returned in both cases, it is better to write them as a single piece of JSX.
+Perlu diingat bahwa jika dua potongan JSX yang berbeda mendeskripsikan pohon yang sama, susunannya (`<div>` pertama → `<img>` pertama) harus sama. Jika tidak, penggantian `isActive` akan menyebabkan pembuatan ulang seluruh pohon di dalamnya dan [mereset *state*-nya.](/learn/preserving-and-reset-state) Inilah sebabnya, jika pohon JSX dari kedua kasus tersebut menghasilkan pohon serupa, lebih baik penulisannya digabungkan menjadi sepotong JSX.
 
 </Solution>
 
-#### Profile editor {/*profile-editor*/}
+#### Editor profil {/*profile-editor*/}
 
-Here is a small form implemented with plain JavaScript and DOM. Play with it to understand its behavior:
+Berikut ini adalah formulir kecil yang diimplementasikan dengan JavaScript biasa dan DOM. Silakan dicoba untuk memahami perilakunya:
 
 <Sandpack>
 
 ```js index.js active
 function handleFormSubmit(e) {
   e.preventDefault();
-  if (editButton.textContent === 'Edit Profile') {
-    editButton.textContent = 'Save Profile';
+  if (editButton.textContent === 'Ubah Profil') {
+    editButton.textContent = 'Simpan Profil';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'Ubah Profil';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -729,7 +729,7 @@ function handleFormSubmit(e) {
 function handleFirstNameChange() {
   firstNameText.textContent = firstNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'Halo ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -738,7 +738,7 @@ function handleFirstNameChange() {
 function handleLastNameChange() {
   lastNameText.textContent = lastNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'Halo ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -773,7 +773,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    Nama depan:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -781,15 +781,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    Nama belakang:
     <b id="lastNameText">Jacobs</b>
     <input
       id="lastNameInput"
       value="Jacobs"
       style="display: none">
   </label>
-  <button type="submit" id="editButton">Edit Profile</button>
-  <p><i id="helloText">Hello, Jane Jacobs!</i></p>
+  <button type="submit" id="editButton">Ubah Profil</button>
+  <p><i id="helloText">Halo, Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -801,11 +801,11 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-This form switches between two modes: in the editing mode, you see the inputs, and in the viewing mode, you only see the result. The button label changes between "Edit" and "Save" depending on the mode you're in. When you change the inputs, the welcome message at the bottom updates in real time.
+Formulir ini dapat berganti-ganti di antara dua mode: dalam mode ubah, Anda dapat melihat masukannya, dan dalam mode tampilan, Anda hanya dapat melihat hasilnya. Label tombol berubah antara "Ubah" dan "Simpan", tergantung pada mode yang aktif. Apabila Anda mengubah masukan, pesan selamat datang di bagian bawah akan diperbarui secara langsung.
 
-Your task is to reimplement it in React in the sandbox below. For your convenience, the markup was already converted to JSX, but you'll need to make it show and hide the inputs like the original does.
+Tugas Anda adalah mengimplementasikannya kembali di React pada *sandbox* berikut ini. Untuk kenyamanan Anda, *markup* sudah dikonversi ke JSX, tetapi Anda harus membuatnya menampilkan dan menyembunyikan masukan seperti versi awal.
 
-Make sure that it updates the text at the bottom, too!
+Pastikan juga memperbarui teks di bagian bawah!
 
 <Sandpack>
 
@@ -814,19 +814,19 @@ export default function EditProfile() {
   return (
     <form>
       <label>
-        First name:{' '}
+        Nama depan:{' '}
         <b>Jane</b>
         <input />
       </label>
       <label>
-        Last name:{' '}
+        Nama belakang:{' '}
         <b>Jacobs</b>
         <input />
       </label>
       <button type="submit">
-        Edit Profile
+        Ubah Profil
       </button>
-      <p><i>Hello, Jane Jacobs!</i></p>
+      <p><i>Halo, Jane Jacobs!</i></p>
     </form>
   );
 }
@@ -840,9 +840,9 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-You will need two state variables to hold the input values: `firstName` and `lastName`. You're also going to need an `isEditing` state variable that holds whether to display the inputs or not. You should _not_ need a `fullName` variable because the full name can always be calculated from the `firstName` and the `lastName`.
+Anda akan membutuhkan dua variabel state untuk menyimpan nilai input: `firstName` dan `lastName`. Anda juga akan membutuhkan variabel state `isEditing` yang menyimpan informasi apakah akan menampilkan masukan atau tidak. Anda seharusnya tidak memerlukan variabel `fullName` karena nama lengkap selalu dapat ditentukan dari `firstName` dan `lastName`.
 
-Finally, you should use [conditional rendering](/learn/conditional-rendering) to show or hide the inputs depending on `isEditing`.
+Terakhir, Anda harus menggunakan [pe-*render*-an bersyarat](/learn/conditional-rendering) untuk menampilkan atau menyembunyikan masukan, tergantung dari *state* `isEditing`.
 
 <Sandpack>
 
@@ -860,7 +860,7 @@ export default function EditProfile() {
       setIsEditing(!isEditing);
     }}>
       <label>
-        First name:{' '}
+        Nama depan:{' '}
         {isEditing ? (
           <input
             value={firstName}
@@ -873,7 +873,7 @@ export default function EditProfile() {
         )}
       </label>
       <label>
-        Last name:{' '}
+        Nama belakang:{' '}
         {isEditing ? (
           <input
             value={lastName}
@@ -886,9 +886,9 @@ export default function EditProfile() {
         )}
       </label>
       <button type="submit">
-        {isEditing ? 'Save' : 'Edit'} Profile
+        {isEditing ? 'Simpan' : 'Ubah'} Profile
       </button>
-      <p><i>Hello, {firstName} {lastName}!</i></p>
+      <p><i>Halo, {firstName} {lastName}!</i></p>
     </form>
   );
 }
@@ -900,27 +900,27 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-Compare this solution to the original imperative code. How are they different?
+Bandingkan solusi ini dengan kode imperatif yang awal. Apa perbedaannya?
 
 </Solution>
 
-#### Refactor the imperative solution without React {/*refactor-the-imperative-solution-without-react*/}
+#### Menulis ulang solusi imperatif tanpa React {/*refactor-the-imperative-solution-without-react*/}
 
-Here is the original sandbox from the previous challenge, written imperatively without React:
+Berikut ini adalah *sandbox* awal dari tantangan sebelumnya, yang ditulis secara imperatif tanpa React:
 
 <Sandpack>
 
 ```js index.js active
 function handleFormSubmit(e) {
   e.preventDefault();
-  if (editButton.textContent === 'Edit Profile') {
-    editButton.textContent = 'Save Profile';
+  if (editButton.textContent === 'Ubah Profil') {
+    editButton.textContent = 'Simpan Profil';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'Ubah Profil';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -931,7 +931,7 @@ function handleFormSubmit(e) {
 function handleFirstNameChange() {
   firstNameText.textContent = firstNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'Halo ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -940,7 +940,7 @@ function handleFirstNameChange() {
 function handleLastNameChange() {
   lastNameText.textContent = lastNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'Halo ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -975,7 +975,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    Nama depan:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -983,15 +983,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    Nama belakang:
     <b id="lastNameText">Jacobs</b>
     <input
       id="lastNameInput"
       value="Jacobs"
       style="display: none">
   </label>
-  <button type="submit" id="editButton">Edit Profile</button>
-  <p><i id="helloText">Hello, Jane Jacobs!</i></p>
+  <button type="submit" id="editButton">Ubah Profil</button>
+  <p><i id="helloText">Halo, Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1003,9 +1003,9 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-Imagine React didn't exist. Can you refactor this code in a way that makes the logic less fragile and more similar to the React version? What would it look like if the state was explicit, like in React?
+Bayangkan jika React tidak ada. Dapatkah Anda menuliskan ulang kode ini dengan cara yang membuat logikanya tidak mudah rusak dan lebih mirip dengan versi React? Bagaimana jadinya jika state dibuat eksplisit seperti di React?
 
-If you're struggling to think where to start, the stub below already has most of the structure in place. If you start here, fill in the missing logic in the `updateDOM` function. (Refer to the original code where needed.)
+Jika Anda kesulitan untuk memulai dari mana, contoh di bawah ini sudah menyediakan sebagian besar strukturnya. Jika Anda memulai dari sini, isi logika yang kosong dalam fungsi `updateDOM`. (Lihat kode awal jika diperlukan).
 
 <Sandpack>
 
@@ -1044,13 +1044,13 @@ function setIsEditing(value) {
 
 function updateDOM() {
   if (isEditing) {
-    editButton.textContent = 'Save Profile';
-    // TODO: show inputs, hide content
+    editButton.textContent = 'Simpan Profil';
+    // TODO: tampilkan seluruh masukan, sembunyikan konten
   } else {
-    editButton.textContent = 'Edit Profile';
-    // TODO: hide inputs, show content
+    editButton.textContent = 'Ubah Profil';
+    // TODO: sembunyikan seluruh masukan, tampilkan konten
   }
-  // TODO: update text labels
+  // TODO: perbarui label teks
 }
 
 function hide(el) {
@@ -1082,7 +1082,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    Nama depan:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -1090,15 +1090,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    Nama belakang:
     <b id="lastNameText">Jacobs</b>
     <input
       id="lastNameInput"
       value="Jacobs"
       style="display: none">
   </label>
-  <button type="submit" id="editButton">Edit Profile</button>
-  <p><i id="helloText">Hello, Jane Jacobs!</i></p>
+  <button type="submit" id="editButton">Ubah Profil</button>
+  <p><i id="helloText">Halo, Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1112,7 +1112,7 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-The missing logic included toggling the display of inputs and content, and updating the labels:
+Logika yang kosong mencakup peralihan tampilan masukan dan konten, serta memperbarui label:
 
 <Sandpack>
 
@@ -1151,13 +1151,13 @@ function setIsEditing(value) {
 
 function updateDOM() {
   if (isEditing) {
-    editButton.textContent = 'Save Profile';
+    editButton.textContent = 'Simpan Profil';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'Ubah Profil';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -1166,7 +1166,7 @@ function updateDOM() {
   firstNameText.textContent = firstName;
   lastNameText.textContent = lastName;
   helloText.textContent = (
-    'Hello ' +
+    'Halo ' +
     firstName + ' ' +
     lastName + '!'
   );
@@ -1201,7 +1201,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    Nama depan:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -1209,15 +1209,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    Nama belakang:
     <b id="lastNameText">Jacobs</b>
     <input
       id="lastNameInput"
       value="Jacobs"
       style="display: none">
   </label>
-  <button type="submit" id="editButton">Edit Profile</button>
-  <p><i id="helloText">Hello, Jane Jacobs!</i></p>
+  <button type="submit" id="editButton">Ubah Profil</button>
+  <p><i id="helloText">Halo, Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1229,7 +1229,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-The `updateDOM` function you wrote shows what React does under the hood when you set the state. (However, React also avoids touching the DOM for properties that have not changed since the last time they were set.)
+Fungsi `updateDOM` yang Anda tulis menunjukkan apa yang dilakukan React di balik layar ketika Anda menyetel *state*. (Namun, React juga menghindari pengubahan DOM untuk properti yang tidak berubah sejak terakhir kali *state* disetel).
 
 </Solution>
 

From 3196028d55464195d1e89168a0d5ebe0c1eb43a4 Mon Sep 17 00:00:00 2001
From: Chris Qiang <chris@christianto.net>
Date: Sat, 2 Sep 2023 18:53:47 +0700
Subject: [PATCH 4/5] fix: 2nd iteration of the translations

---
 .../learn/reacting-to-input-with-state.md     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index faf676b5bf..b97d44b4e5 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -4,7 +4,7 @@ title: Merespon Masukan dengan State
 
 <Intro>
 
-React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai *state* komponen, dan mengubahnya sebagai respons terhadap masukan pengguna. Cara ini mirip dengan bagaimana desainer memikirkan tentang UI.
+React menyediakan cara deklaratif untuk memanipulasi UI. Dibandingan dengan memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai *state* komponen, dan menggunakan *state* tersebut sebagai respons terhadap masukan pengguna. Cara ini mirip dengan bagaimana desainer memikirkan tentang UI.
 
 </Intro>
 
@@ -12,13 +12,13 @@ React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi
 
 * Bagaimana pemrograman UI deklaratif berbeda dari pemrograman UI imperatif
 * Bagaimana cara menjabarkan berbagai *state* visual yang berbeda pada komponen Anda
-* Bagaimana cara memicu perubahan dari berbagai *state*
+* Bagaimana cara memicu perubahan ke berbagai *state*
 
 </YouWillLearn>
 
 ## Membandingkan UI deklaratif dengan imperatif {/*how-declarative-ui-compares-to-imperative*/}
 
-Ketika Anda mendesain interaksi UI, Anda mungkin berpikir tentang bagaimana UI *berubah* dalam menanggapi tindakan pengguna. Pertimbangkan formulir yang memungkinkan pengguna mengirimkan jawaban:
+Ketika Anda mendesain interaksi UI, Anda mungkin berpikir tentang bagaimana UI *berubah* dalam menanggapi tindakan pengguna. Pertimbangkan sebuah formulir yang memungkinkan pengguna mengirimkan jawaban:
 
 * Anda mengetikan sesuatu kedalam formulir, maka tombol kirim menjadi **aktif**
 * Anda mengklik tombol "Kirim", baik formulir maupun tombol "Kirim" tersebut menjadi **nonaktif** dan *spinner* muncul.
@@ -32,7 +32,7 @@ Pada **pemrograman imperatif**, yang disebutkan di atas berkaitan langsung denga
 
 Dia tidak tahu kemana Anda ingin pergi, dia hanya mengikuti perintah yang Anda berikan (dan apabila Anda memberikan arah yang salah, Anda akan sampai ditempat yang salah juga). Hal ini disebut *imperatif* karena Anda harus " memberi perintah" pada setiap elemen, dari pemintal hingga tombol, memberi tahu komputer *bagaimana cara* untuk memperbarui UI tersebut.
 
-Pada contoh pemrograman antarmuka imperatif, formulir dibangun tanpa menggunakan React, hanya mengguna browse [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model):
+Pada contoh pemrograman antarmuka imperatif, formulir dibangun tanpa menggunakan React, hanya menggunakan [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) peramban:
 
 <Sandpack>
 
@@ -132,11 +132,11 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-Memanipulasi UI secara imperatif bekerja dengan cukup baik untuk contoh-contoh yang terpencil, tetapi menjadi jauh lebih sulit untuk dikelola dalam sistem yang lebih kompleks. Bayangkan jika Anda memperbarui halaman yang penuh dengan berbagai macam formulir seperti formulir di atas. Menambahkan elemen UI baru atau interaksi baru akan memerlukan pemeriksaan yang hati-hati terhadap semua kode yang ada untuk memastikan bahwa Anda tidak membuat bug (misalnya, lupa menampilkan atau menyembunyikan sesuatu).
+Memanipulasi UI secara imperatif bekerja dengan cukup baik untuk contoh-contoh tertentu, tetapi menjadi jauh lebih sulit untuk dikelola dalam sistem yang lebih kompleks. Bayangkan jika Anda memperbarui halaman yang penuh dengan berbagai macam formulir seperti formulir di atas. Menambahkan elemen UI baru atau interaksi baru akan memerlukan pemeriksaan yang hati-hati terhadap semua kode yang ada untuk memastikan bahwa Anda tidak membuat bug (misalnya, lupa menampilkan atau menyembunyikan sesuatu).
 
 React dibangun untuk mengatasi masalah ini.
 
-Pada React, Anda tidak perlu memanipulasi antarmuka secara langsung, maksudnya Anda tidak perlu mengaktifkan, menonaktifkan, menampilkan, atau menyembunyikan suatu component secara langsung. Melainkan, Anda dapat **mendeklarasikan apa yang ingin Anda tampilkan**, dan React akan mengupdate antarmuka tersebut. Pikirkan Anda menyewa taksi dan memberitahu pengemudinya kemana Anda akan pergi, daripada memberitahukan di mana ia harus berbelok. Itu adalah tugas pengemudi untuk mencari tahu bagaimana mengantar Anda ke tujuan, bahkan dia bisa menemukan jalan pintas yang tidak Anda tahu!
+Pada React, Anda tidak perlu memanipulasi antarmuka secara langsung, maksudnya Anda tidak perlu mengaktifkan, menonaktifkan, menampilkan, atau menyembunyikan suatu component secara langsung. Melainkan, Anda dapat **mendeklarasikan apa yang ingin Anda tampilkan**, dan React akan memperbarui antarmuka tersebut. Bayangkan Anda menyewa taksi dan memberitahu pengemudinya kemana Anda akan pergi, daripada memberitahukan di mana ia harus berbelok. Itu adalah tugas pengemudi untuk mencari tahu bagaimana mengantar Anda ke tujuan, bahkan dia bisa menemukan jalan pintas yang tidak Anda tahu!
 
 <Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="Di dalam mobil yang dikemudikan oleh React, seorang penumpang meminta untuk diantarkan ke tempat tertentu pada peta. React akan mencari cara menuju ke tempat tersebut." />
 
@@ -324,7 +324,7 @@ Anda dapat memicu pembaruan state sebagai respons terhadap dua jenis masukan:
   <Illustration caption="Computer inputs" alt="Satu dan nol." src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-Pada kedua kasus tersebut, **Anda harus mengatur [variabel *state*](/learn/state-a-components-memory#anatomy-of-usestate) untuk memperbarui UI.** Untuk form yang Anda kembangkan, Anda perlu mengubah *state* sebagai respons terhadap berbagai masukan yang berbeda:
+Pada kedua kasus tersebut, **Anda harus mengatur [variabel *state*](/learn/state-a-components-memory#anatomy-of-usestate) untuk mengganti UI.** Untuk form yang Anda kembangkan, Anda perlu mengubah *state* sebagai respons terhadap berbagai masukan yang berbeda:
 
 * **Mengubah input teks** (manusia) akan mengubahnya dari *state* *Kosong* ke *state* *Mengetik* atau sebaliknya, tergantung apakah kotak teks kosong atau tidak.
 * **Mengklik tombol Kirim** (manusia) akan mengalihkannya ke *state* *Mengirimkan*.
@@ -376,11 +376,11 @@ Ide pertama Anda mungkin bukan yang terbaik, tapi itu bukan masalah, menulis ula
 
 ### Langkah 4: Hapus variabel *state* yang tidak esensial {/*step-4-remove-any-non-essential-state-variables*/}
 
-Anda ingin menghindari duplikasi pada konten *state* sehingga Anda hanya perlu mencatat *state* yang penting saja. Luangkan sedikit waktu untuk melakukan penulisan ulang pada struktur *state* Anda akan membuat komponen Anda lebih mudah dipahami, mengurangi duplikasi, dan menghindari ambiguitas yang tidak diinginkan. Target Anda adalah untuk **mencegah kasus di mana *state* dalam memori tidak merepresentasikan UI valid yang Anda harapkan untuk dilihat oleh pengguna** (Sebagai contoh, Anda tidak akan pernah ingin menampilkan pesan kesalahan dan menonaktifkan input pada waktu yang sama, atau pengguna tidak akan bisa memperbaiki kesalahan tersebut!)
+Anda ingin menghindari duplikasi pada konten *state* sehingga Anda hanya perlu mencatat *state* yang penting saja. Luangkan sedikit waktu untuk melakukan penulisan ulang pada struktur *state* Anda akan membuat komponen Anda lebih mudah dipahami, mengurangi duplikasi, dan menghindari ambiguitas yang tidak diinginkan. Target Anda adalah untuk **mencegah kasus di saat *state* dalam memori tidak merepresentasikan UI valid yang Anda harapkan untuk dilihat oleh pengguna** (Sebagai contoh, Anda tidak akan pernah ingin menampilkan pesan kesalahan dan menonaktifkan masukan pada waktu yang sama, atau pengguna tidak akan bisa memperbaiki kesalahan tersebut!)
 
 Berikut adalah beberapa hal yang dapat Anda pertimbangkan tentang variabel *state* Anda:
 
-* **Apakah keadaan ini menimbulkan kondisi paradoks?** Sebagai contoh, `isTyping` dan `isSubmit` tidak mungkin bernilai `true` bersamaan. Kondisi paradoks biasanya menandakan bahwa *state* tidak dibatasi dengan baik. Ada empat kemungkinan kombinasi dari dua boolean, tetapi hanya tiga yang sesuai dengan *state* yang sesuai. Untuk menghilangkan *state* yang "tidak mungkin", Anda dapat menyatukannya menjadi sebuah `status` yang harus merupakan salah satu dari tiga nilai: `'typing'` (mengetik), `'submitting'` (mengirim), atau `'success'` (sukses).
+* **Apakah keadaan ini menimbulkan kondisi paradoks?** Sebagai contoh, `isTyping` dan `isSubmit` tidak mungkin bernilai `true` bersamaan. Kondisi paradoks biasanya menandakan bahwa *state* tidak dibatasi dengan baik. Ada empat kemungkinan kombinasi dari dua *boolean*, tetapi hanya tiga yang sesuai dengan *state* yang sesuai. Untuk menghilangkan *state* yang "tidak mungkin", Anda dapat menyatukannya menjadi sebuah `status` yang harus merupakan salah satu dari tiga nilai: `'typing'` (mengetik), `'submitting'` (mengirim), atau `'success'` (sukses).
 * **Apakah informasi yang sama sudah tersedia di variabel status yang lain?** Kondisi paradoks lain: `isEmpty` dan `isTyping` tidak dapat bernilai `true` pada saat yang bersamaan. Dengan menjadikannya variabel *state* yang terpisah, Anda berisiko membuat keduanya tidak sinkron dan mengakibatkan bug. Untungnya, Anda dapat menghapus `isEmpty` dan sebagai gantinya memeriksa `answer.length === 0`.
 * **Bisakah Anda mendapatkan informasi yang sama dari kebalikan dari variabel state yang lain?** `isError` tidak diperlukan karena Anda bisa memeriksa `error !== null` sebagai gantinya.
 
@@ -404,7 +404,7 @@ Ketiga variabel ini merupakan representasi yang cukup baik dari *state* formulir
 
 ### Langkah 5: Hubungkan *event handler* untuk mengatur *state* tersebut {/*step-5-connect-the-event-handlers-to-set-state*/}
 
-Terakhir, buatlah *event handler* yang memperbarui *state*. Berikut ini adalah bentuk akhir, dengan semua *event handler* yang terhubung:
+Terakhir, buatlah *event handler* yang mengganti *state*. Berikut ini adalah bentuk akhir, dengan semua *event handler* terhubung:
 
 <Sandpack>
 
@@ -562,9 +562,9 @@ Komponen ini memiliki dua status visual: apabila gambar aktif, dan apabila gamba
 * Saat gambar aktif, kelas CSS adalah `background` dan `picture picture--active`.
 * Ketika gambar tidak aktif, kelas CSS adalah `background background--active` dan `picture`.
 
-Sebuah variabel *state* boolean sudah cukup untuk menyimpan informasi, apakah gambar tersebut aktif atau tidak. Tugas awalnya adalah menghapus atau menambahkan kelas CSS. Namun, di React Anda perlu *mendeskripsikan* apa yang ingin Anda lihat daripada *memanipulasi* elemen UI. Jadi, Anda perlu menghitung kedua kelas CSS berdasarkan *state* saat ini. Anda juga perlu [menghentikan propagasi](/learn/responing-to-events#stopping-propagation) agar mengklik gambar tidak terdeteksi sebagai klik pada latar belakang.
+Sebuah variabel *state boolean* sudah cukup untuk menyimpan informasi, apakah gambar tersebut aktif atau tidak. Tugas awalnya adalah menghapus atau menambahkan kelas CSS. Namun, di React Anda perlu *mendeskripsikan* apa yang ingin Anda lihat dibandingkan dengan *memanipulasi* elemen UI. Jadi, Anda perlu menentukan kedua kelas CSS berdasarkan *state* saat ini. Anda juga perlu [menghentikan propagasi](/learn/responing-to-events#stopping-propagation) agar mengklik gambar tidak terdeteksi sebagai klik pada latar belakang.
 
-Pastikan bahwa versi ini berfungsi dengan baik, dengan mengeklik gambar dan kemudian klik kembali di luar gambar tersebut:
+Pastikan bahwa versi ini berfungsi dengan baik, dengan mengeklik gambar dan kemudian klik kembali bagian di luar gambar tersebut:
 
 <Sandpack>
 
@@ -698,7 +698,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Perlu diingat bahwa jika dua potongan JSX yang berbeda mendeskripsikan pohon yang sama, susunannya (`<div>` pertama → `<img>` pertama) harus sama. Jika tidak, penggantian `isActive` akan menyebabkan pembuatan ulang seluruh pohon di dalamnya dan [mereset *state*-nya.](/learn/preserving-and-reset-state) Inilah sebabnya, jika pohon JSX dari kedua kasus tersebut menghasilkan pohon serupa, lebih baik penulisannya digabungkan menjadi sepotong JSX.
+Perlu diingat bahwa jika dua potongan JSX yang berbeda mendeskripsikan pohon yang serupa, susunannya (`<div>` pertama → `<img>` pertama) harus sama. Jika tidak, penggantian `isActive` akan menyebabkan pembuatan ulang seluruh pohon di dalamnya dan [mereset *state*-nya.](/learn/preserving-and-reset-state) Inilah sebabnya, jika pohon JSX dari kedua kasus tersebut menghasilkan pohon serupa, lebih baik penulisannya digabungkan menjadi sepotong JSX.
 
 </Solution>
 
@@ -842,7 +842,7 @@ label { display: block; margin-bottom: 20px; }
 
 Anda akan membutuhkan dua variabel state untuk menyimpan nilai input: `firstName` dan `lastName`. Anda juga akan membutuhkan variabel state `isEditing` yang menyimpan informasi apakah akan menampilkan masukan atau tidak. Anda seharusnya tidak memerlukan variabel `fullName` karena nama lengkap selalu dapat ditentukan dari `firstName` dan `lastName`.
 
-Terakhir, Anda harus menggunakan [pe-*render*-an bersyarat](/learn/conditional-rendering) untuk menampilkan atau menyembunyikan masukan, tergantung dari *state* `isEditing`.
+Terakhir, Anda harus menggunakan [pe-*render*-an kondisional](/learn/conditional-rendering) untuk menampilkan atau menyembunyikan masukan, tergantung dari *state* `isEditing`.
 
 <Sandpack>
 

From b57d2ff328f8c520f7ce27ecfd8230555007a30d Mon Sep 17 00:00:00 2001
From: Resi Respati <resir014@gmail.com>
Date: Wed, 28 Feb 2024 11:03:37 +0700
Subject: [PATCH 5/5] Apply suggestions from code review

Co-authored-by: Zain Fathoni <zain.fathoni@gmail.com>
---
 .../learn/reacting-to-input-with-state.md        | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index b97d44b4e5..892cb8c076 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -4,26 +4,26 @@ title: Merespon Masukan dengan State
 
 <Intro>
 
-React menyediakan cara deklaratif untuk memanipulasi UI. Dibandingan dengan memanipulasi bagian-bagian UI secara langsung, Anda dapat membuat berbagai *state* komponen, dan menggunakan *state* tersebut sebagai respons terhadap masukan pengguna. Cara ini mirip dengan bagaimana desainer memikirkan tentang UI.
+React menyediakan cara deklaratif untuk memanipulasi UI. Alih-alih memanipulasi bagian-bagian UI secara langsung, Anda deskripsikan berbagai *state* yang berbeda yang dapat terjadi di dalam komponen Anda, dan mengalihkan antara berbagai kemungkinan *state* tersebut sebagai respons terhadap masukan pengguna. Cara ini mirip dengan bagaimana desainer berpikir tentang UI.
 
 </Intro>
 
 <YouWillLearn>
 
 * Bagaimana pemrograman UI deklaratif berbeda dari pemrograman UI imperatif
-* Bagaimana cara menjabarkan berbagai *state* visual yang berbeda pada komponen Anda
-* Bagaimana cara memicu perubahan ke berbagai *state*
+* Bagaimana cara melakukan enumerasi atas berbagai *state* visual yang berbeda dapat terjadi pada komponen Anda
+* Bagaimana cara memicu perubahan antara berbagai *state* visual yang berbeda melalui kode
 
 </YouWillLearn>
 
 ## Membandingkan UI deklaratif dengan imperatif {/*how-declarative-ui-compares-to-imperative*/}
 
-Ketika Anda mendesain interaksi UI, Anda mungkin berpikir tentang bagaimana UI *berubah* dalam menanggapi tindakan pengguna. Pertimbangkan sebuah formulir yang memungkinkan pengguna mengirimkan jawaban:
+Ketika Anda mendesain interaksi UI, Anda mungkin berpikir tentang bagaimana UI *berubah* dalam menanggapi tindakan pengguna. Pertimbangkan sebuah formulir yang memungkinkan pengguna mengirimkan sebuah jawaban:
 
-* Anda mengetikan sesuatu kedalam formulir, maka tombol kirim menjadi **aktif**
-* Anda mengklik tombol "Kirim", baik formulir maupun tombol "Kirim" tersebut menjadi **nonaktif** dan *spinner* muncul.
-* Apabila permintaan jaringan berhasil, formulir disembunyikan dan pesan "Terima Kasih" muncul
-* Apabila permintaan jaringan gagal, pesan kesalahan muncul dan formulir menjadi aktif kembali.
+* Ketika Anda mengetikkan sesuatu kedalam formulir, maka tombol "Kirim" **menjadi aktif**
+* Ketika Anda menekan tombol "Kirim", baik formulir maupun tombol "Kirim" tersebut **menjadi nonaktif** dan sebuah *spinner* **muncul.**
+* Apabila permintaan jaringan berhasil, formulir **disembunyikan** dan pesan "Terima Kasih" **muncul.**
+* Apabila permintaan jaringan gagal, sebuah pesan kesalahan **muncul,** dan formulir **menjadi aktif** kembali.
 
 
 Pada **pemrograman imperatif**, yang disebutkan di atas berkaitan langsung dengan bagaimana Anda mengimplementasikan interaksi tersebut. Anda harus menulis intruksi yang spesifik untuk memanipulasi UI tergantung apa yang sedang terjadi. Cara lain untuk memikirkan hal ini adalah: bayangkan menumpang disebelah seseorang di dalam mobil dan memberitahu mereka kemana harus pergi disetiap belokan.