From c5d16d0080dcdd56d1abf5cfbbb448f5a83cbbaa Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 22 Aug 2023 13:08:58 +0300
Subject: [PATCH 01/19] Edit adding-interactivity.md

---
 src/content/learn/adding-interactivity.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/adding-interactivity.md b/src/content/learn/adding-interactivity.md
index 936c27214..d860b436c 100644
--- a/src/content/learn/adding-interactivity.md
+++ b/src/content/learn/adding-interactivity.md
@@ -798,4 +798,4 @@ function ItemList({ artworks, onToggle }) {
 
 إذهب الى [الإستجابة الى الاحداث](/learn/responding-to-events) لتقرأ هذا الفصل صفحة بصفحة!
 
-أو، إذا كنت تفهم هذه المواضيع بالفعل، لماذا لا تقرأ عن [التحكم فى الحالة](/learn/managing-state)؟
+أو، إذا كنت تفهم هذه المواضيع بالفعل، لماذا لا تقرأ عن [إدارة الحالة](/learn/managing-state)؟

From 7fdd2a74fbee22a0f3cf8b2baa3148d9ddb951e4 Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Thu, 31 Aug 2023 21:27:24 +0300
Subject: [PATCH 02/19] Translation of (Reacting to input): until step 2  -
 Translated `intro`  - Translated `What you will learn`  - Translated
 Imperative & Declartive programming  - Translated Step 1

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

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 522aa63a1..326d0158d 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -1,37 +1,39 @@
 ---
-title: Reacting to Input with State
+title: الاستجابة للمدخلات باستخدام الحالة
 ---
 
 <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 توفر طريقة تصريحيّة (declarative) لتعديل واجهة المستخدم (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
-
+* كيف تختلف البرمجة التصريحية لواجهة المستخدم (declarative UI programming) عن البرمجة الأمرية لواجهة المستخدم (imperative UI programming)
+* كيفية استعراض الحالات المرئية المختلفة التي يأخذها مكوّنك
+* كيفية تنشيط التغييرات بين الحالات المرئية المختلفة من خلال الكود
+  
 </YouWillLearn>
 
-## How declarative UI compares to imperative {/*how-declarative-ui-compares-to-imperative*/}
+## كيف تُقارَن واجهة المستخدم التصريحية (declarative UI) بالأمرية (imperative) {/*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:
+عندما تصمم تعاملات واجهة المستخدم، عليك غالبًا التفكير في كيفية *تغيّر* واجهة المستخدم كاستجابة لاجراءات المستخدم. فكر في نموذج يسمح للمستخدم بإرسال إجابة:
 
-* 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.
+* عندما تكتب شيئًا داخل النموذج، الزر "أرسل" **يصبح مفعلًا.**
+* عندما تضغط على "أرسل"، كلٌ من النموذج والزر **يصبح معطلا** ومؤشر التحميل **يظهر.**
+* لو نجح طلب الشبكة، النموج **يبدأ بالاختفاء،** ورسالة "شكرًا لك" **تظهر.**
+* لو فشل طلب الشبكة، رسالة خطأٍ **تظهر،** والنموذج **يصبح مفعلًا** مجددا.
 
-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.
+في **البرمجة الأمرية (imperative programming)**، يتوافق ما ذُكر أعلاه مباشرة مع طريقة تطبيق التعاملات. عليك أن تكتب التعليمات التامة لتعديل واجهة المستخدم معتمدا على ما حصل للتو. إليك طريقة أخرى لتفكر في هذا الأمر: تخيل نفسك راكبا إلى جانب أحدهم في سيارة مع إخباره في كل منعطف تلو الآخر عن وجهة الذهاب. 
 
 <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.
+هم لا يعلمون إلى أين تريد أن تذهب، هم يتبعون أوامرك فقط. (ولو أنك أعطيتهم الاتجاهات الخاطئة، سوف ينتهي بك المطاف لوجهة خاطئة!) هذا يطلق عليه *أمري (imperative)* لأن عليك أن "تأمر" كل عنصر، بداية من مؤشر التحميل إلى الزر، مخبرًا
+الكمبيوتر عن *كيفية* تحديث واجهة المستخدم (UI).
 
-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):
+في هذا المثال للبرمجة الأمرية لواجهة المستخدم، النموذج مبنيّ *بدون* React. إنه يستخدم [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) المتصفح فقط:
 
 <Sandpack>
 
@@ -84,10 +86,10 @@ function submitForm(answer) {
   // Pretend it's hitting the network.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
-      if (answer.toLowerCase() == 'istanbul') {
+      if (answer.toLowerCase() == 'إسطنبول') {
         resolve();
       } else {
-        reject(new Error('Good guess but a wrong answer. Try again!'));
+        reject(new Error('توقع جيد ولكن إجابة خاطئة. حاول مرة أخرى!'));
       }
     }, 1500);
   });
@@ -111,17 +113,17 @@ textarea.oninput = handleTextareaChange;
 
 ```html public/index.html
 <form id="form">
-  <h2>City quiz</h2>
+  <h2>اختبار المدينة</h2>
   <p>
-    What city is located on two continents?
+    ما هي المدينة الواقعة على قارتين؟
   </p>
   <textarea id="textarea"></textarea>
   <br />
-  <button id="button" disabled>Submit</button>
-  <p id="loading" style="display: none">Loading...</p>
+  <button id="button" disabled>أرسل</button>
+  <p id="loading" style="display: none">جارٍ التحميل...</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">هذا صحيح!</h1>
 
 <style>
 * { box-sizing: border-box; }
@@ -131,37 +133,36 @@ 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).
+تعديل واجهة المستخدم (UI) أمريًّا يعمل بشكل جيد كفاية للأمثلة المعزولة، ولكنه يصبح أكثر صعوبة بشكل استثنائي عندما تدير أنظمة أكثر تعقيدًا. تخيل تحديث صفحة مليئة بالنماذج المختلفة مثل هذه هنا. إضافة عنصر واجهة مستخدم جديد سيتطلب فحص كامل الكود الموجود بحرص للتأكد من أنك لم تقم بعمل خطأ(على سبيل المثال، نسيان إظهار أو إخفاء شيء ما).
 
-React was built to solve this problem.
+React صُنعت لحل هذه المشكلة. 
 
-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!
+في React، لن تقوم بتعديل واجهة المستخدم مباشرة -- يعني أنك لن تقوم بتفعيل، تعطيل، إظهار، أو إخفاء مكوّنات مباشرة. بدلا عن ذلك، سوف **تصف ما تريده أن يظهر،** و React سوف تدبر كيفية تحديث واجهة المستخدم. فكر في أخذ سيارة أجرة وإخبار السائق إلي أين تريد أنت تذهب بدلا من إخباره إلي أين ينعطف. وظيفة السائق هي أن يوصلك إلى هناك، وربما قد يعرف اختصارات لم تأخذها أنت بالحسبان.
 
 <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." />
 
-## Thinking about UI declaratively {/*thinking-about-ui-declaratively*/}
+## التفكير في واجهة المستخدم (UI) تصريحيًا {/*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:
+لقد رأيت كيفية تنفيذ نموذج أمريَّا أعلاه. لفهم أفضل لكيفية التفكير في React، سوف تمر بإعادة تنفيذ واجهة المستخدم (UI) هذه باستخدام 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. **عيّن** الحالات المرئية المختلفة لمكوّنك
+2. **حدد** ما ينشط تغيرات  تلك الحالات
+3. **مثّل** الحالة في الذاكرة باستخدام `useState`
+4. **احذف** أيّ متغيرات حالة غير ضرورية
+5. **اربط** معالجات الأحداث لتعيين الحالة
 
-### Step 1: Identify your component's different visual states {/*step-1-identify-your-components-different-visual-states*/}
+### الخطوة 1: عين الحالات المرئية المختلفة لمكوّنك {/*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.
+في علوم الحاسب، ربما تسمع عن ["آلة حالة (state machine)"](https://en.wikipedia.org/wiki/Finite-state_machine) كونها واحدة من ضمن "حالات" متعددة.إذا كنت تعمل مع مصمم، لربما رأيت نماذج تجريبية لـ"الحالات المرئية" المختلفة 
 
-First, you need to visualize all the different "states" of the UI the user might see:
+أولًا، أنت تحتاج لتصور جميع "الحالات" المختلفة لواجهة المستخدم (UI) التي قد يراها المستخدم: 
+*  **فارغة**: النموذج يحتوي زر "إرسال" معطل.
+* **كتابة**: النموذج يحتوي زر "إرسال" مفعّل.
+* **إرسال**: النموذج معطل تمامًا. يتم عرض مؤشر التحميل.
+* **نجاح**: يتم عرض رسالة "شكرًا لك" بدلًا من النموذج.
+* **خطأ**: مثل حالة الكتابة، ولكن مع رسالة خطأ إضافية
 
-* **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.
-
-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'`:
+تمامًا مثل المصمم، سترغب في "تجربة" أو إنشاء "نماذج تجريبية" للحالات المختلفة قبل أن تضيف المنطق. على سبيل المثال، ها هو نموذج تجريبي للجزء المرئي فقط من النموذج. هذا النموذج التجريبي متحكم به بواسطة خاصيّة تدعى `statue` مع قيمة افتراضية `'empty'`:
 
 <Sandpack>
 
@@ -170,19 +171,19 @@ export default function Form({
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>هذا صحيح!</h1>
   }
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>اختبار المدينة</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        في أي مدينة يوجد لوحة إعلانية تقوم بتحويل الهواء لمياه صالحة للشرب؟
       </p>
       <form>
         <textarea />
         <br />
         <button>
-          Submit
+          أرسل
         </button>
       </form>
     </>
@@ -192,23 +193,23 @@ 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:
+يمكنك تسمية الخاصيّة أيّ شيء تريد، التسمية ليست مهمة. جرب تعديل `status = 'empty'` إلى `status = 'success'` لترى رسالة النجاح تظهر. التجربة تتيح لك التكرار السريع على واجهة المستخدم قبل ربط أي منطق. ها هو نموذج تجريبي أكثر تفصيلًا لنفس المكوّن، يظل "متحكم" بواسطة الخاصية `status`:
 
 <Sandpack>
 
 ```js
 export default function Form({
-  // Try 'submitting', 'error', 'success':
+  // جرب 'submitting'، 'error'، 'success':
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>هذا صحيح!</h1>
   }
   return (
     <>
       <h2>City quiz</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        في أي مدينة يوجد لوحة إعلانية تقوم بتحويل الهواء لمياه صالحة للشرب؟
       </p>
       <form>
         <textarea disabled={
@@ -219,11 +220,11 @@ export default function Form({
           status === 'empty' ||
           status === 'submitting'
         }>
-          Submit
+          أرسل
         </button>
         {status === 'error' &&
           <p className="Error">
-            Good guess but a wrong answer. Try again!
+            توقع جيد ولكن إجابة خاطئة. حاول مرة أخرى!
           </p>
         }
       </form>
@@ -240,9 +241,9 @@ export default function Form({
 
 <DeepDive>
 
-#### Displaying many visual states at once {/*displaying-many-visual-states-at-once*/}
+#### عرض عديد من الحالات المرئية مرة واحدة {/*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:
+لو أن لمكون العديد من الحالات المرئية، قد يكون ملائما عرضها جميعها في صفحة واحدة: 
 
 <Sandpack>
 
@@ -262,7 +263,7 @@ export default function App() {
     <>
       {statuses.map(status => (
         <section key={status}>
-          <h4>Form ({status}):</h4>
+          <h4>نموذج ({status}):</h4>
           <Form status={status} />
         </section>
       ))}
@@ -274,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>هذا صحيح!</h1>
   }
   return (
     <form>
@@ -286,11 +287,11 @@ export default function Form({ status }) {
         status === 'empty' ||
         status === 'submitting'
       }>
-        Submit
+        أرسل
       </button>
       {status === 'error' &&
         <p className="Error">
-          Good guess but a wrong answer. Try again!
+          توقع جيد ولكن إجابة خاطئة. حاول مرة أخرى!
         </p>
       }
     </form>
@@ -307,7 +308,7 @@ body { margin: 0; }
 
 </Sandpack>
 
-Pages like this are often called "living styleguides" or "storybooks".
+صفحات مثل هذه غالبًا يطلق عليها "living styleguides" أو "storybooks" 
 
 </DeepDive>
 

From c93d998fcc4a49ac5e6a7b06531140246434e148 Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Mon, 18 Sep 2023 12:06:35 +0300
Subject: [PATCH 03/19] Translation of (Reacting to input): until step 5

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

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 326d0158d..20d857faf 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -312,57 +312,57 @@ body { margin: 0; }
 
 </DeepDive>
 
-### Step 2: Determine what triggers those state changes {/*step-2-determine-what-triggers-those-state-changes*/}
+###  الخطوة 2: حدد ما ينشط تغيرات تلك الحالة {/*step-2-determine-what-triggers-those-state-changes*/}
 
-You can trigger state updates in response to two kinds of inputs:
+يمكنك تنشيط تحديثات الحالة كاستجابة إلى نوعين من المدخلات:
 
-* **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.
+* **مدخلات الإنسان،** مثل الضغط على زر، الكتابة في حقل، زيارة رابط.
+* **مدخلات الكمبيوتر** مثل وصول رد الشبكة، استكمال المؤقت، تحميل الصورة
 
 <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" />
 </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:
+في كلتا الحالتين، **يجب عليك تعيين [متغيرات الحالة (state variables)](/learn/state-a-components-memory#anatomy-of-usestate) لتُحدّث واجهة المستخدم (UI).** من أجل النموذج الذي تطوره، سوف تحتاج لتغيير الحالة كنتيجة لقليل من المدخلات المختلفة:
 
-* **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.
 
 <Note>
 
-Notice that human inputs often require [event handlers](/learn/responding-to-events)!
+لاحظ أن مدخلات الإنسان غالبًا تتطلب [معالجات أحداث (event handlers)](/learn/responding-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.
+للمساعدة على تصوّر هذا التدفق، جرّب رسم كل حالة على ورقة كدائرة مُعنّوَنة. وكل تغيّر بين حالتين كسهم. تستطيع رسم العديد من التدفقات بهذه الطريقة وحل الأخطاء مبكرًا قبل التنفيذ.
 
 <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'.">
 
-Form states
+حالات النموذج
 
 </Diagram>
 
 </DiagramGroup>
 
-### Step 3: Represent the state in memory with `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
+### الخطوة 3: مثّل الحالة في الذاكرة باستخدام `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!
+يلي ذلك ستحتاج لتمثّل الحالات المرئية لمكوّنك في الذاكرة باستخدام [`useState`.](/reference/react/useState) البساطة هي المفتاح: كل قطعة من الحالة هي "قطعة متحركة"، و**التقليل من "القطع المتحركة" قدر الإمكان هذا ما تريده.** ;كثرة التعقيدات تؤدي إلى كثرة الأخطاء!
 
-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:
+ابدأ بالحالة التي *لا بدّ* من وجودها. على سبيل المثال، سوف تحتاج لتخزين الإجابة `answer` للمدخل، والخطأ `error` (لو وُجد) لتخزين آخر خطأ: 
 
 ```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.
+بعد ذلك، سوف تحتاج لمتغير حالة يمثّل أي من الحالات المرئية التي تريد عرضها. يوجد غالبًا أكثر من طريقة واحدة لتمثيل ذلك في الذاكرة، لذلك سوف يتعين عليك تجريبها.
 
-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:
+إذا واجهت صعوبة في التفكير في أفضل طريقة على الفور، ابدا بإضافة حالة كافية حتى تكون متأكدًا *تمامًا* من تغطية جميع الحالات المرئية المحتملة: 
 
 ```js
 const [isEmpty, setIsEmpty] = useState(true);
@@ -372,19 +372,19 @@ 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!
+خطوتك المبدأئية على الأرجح لن تكون هي الأفضل، ولكن هذا لا بأس به -- إعادة تصميم الحالة هو جزء من العملية!
 
-### Step 4: Remove any non-essential state variables {/*step-4-remove-any-non-essential-state-variables*/}
+### خطوة 4: احذف أيّ متغيرات حالة غير ضرورية {/*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!)
+ما تريده هو تجنب تكرار محتوى الحالة لذلك أنت فقط تقوم بتعقب ما هو ضروري. قضاء قليل من الوقت في إعادة تصميم هيكل حالتك سوف يجعل مكوّنك أسهل للفهم، يقلل التكرار، ويتجنب المعاني غير المقصودة. هدفك هو **منع الأوضاع التي تكون بها الحالة في الذاكرة لا تمثل أي واجهة مستخدم صالحة تود للمستخدم أن يراها.** )u(على سبيل المثال، لن تريد أبدًا إظهار رسالة خطأ مع تعطيل الإدخال في نفس الوقت، أو أن المستخدم لن يكون قادرًا على تصحيح الخطأ!)
 
-Here are some questions you can ask about your state variables:
+هنا بعض الاسئلة التي يمكن أن تسألها عن متغيرات الحالة:
 
-* **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.
+* **هل هذه الحالة تسبب معضلة؟** على سبيل المثال، `isTyping` و `isSubmitting` لا يمكن لكليهما أن يكونا بقيمة `true`. المعضلة غالبا تعني أن الحالة ليست مقيدة بالشكل الكافي. هناك أربع احتمالات ممكنة لاثنين من نوع boolean، لكن ثلاث منها فقط يوافقن حالات صالحة. لحذف الحالة "المستحيلة"، يمكنك جمع تلك الحالات داخل `status` التي يجب يجب أن تكون واحدة من ثلاث قيم: `'typing'`, `'submitting'`, أو `'success'`.
+* **هل نفس المعلومات متاحة بالفعل لمتغير حالة آخر؟** معضلة أخرى: `isEmpty` و `isTyping` لا يمكنها أن يكونا `true` في نفس الوقت. بجعلهما متغيرين حالة منفصلين، تخاطر بفقدان الترابط بينهما وإحداث الأخطاء. لحسن الحظ، يمكن حذف `isEmpty` والتحقق من `answer.length === 0` بدلًا عن ذلك.
+* **هل يمكنك الحصول على نفس المعلومات من من عكس متغير حالة آخر؟** `isError` غير ضروري لأنه يمكنك التحقق من `error !== null` بدلًا عن ذلك.
 
-After this clean-up, you're left with 3 (down from 7!) *essential* state variables:
+بعد هذا التبسيط، تبقى لديك 3 (من أصل 7!) متغيرات حالة *ضرورية*:
 
 ```js
 const [answer, setAnswer] = useState('');
@@ -392,18 +392,19 @@ const [error, setError] = useState(null);
 const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'
 ```
 
-You know they are essential, because you can't remove any of them without breaking the functionality.
+أنت تعلم أنها ضرورية، لأنك لا تستطيع إزالة أيّ منها بدون تخريب آلية العمل
 
 <DeepDive>
 
-#### Eliminating “impossible” states with a reducer {/*eliminating-impossible-states-with-a-reducer*/}
+#### إزالة الحالات "المستحيلة" باستخدام مخفض (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!
+هذه الثلاث متغيرات تمثيل جيد كفاية لحالة النموذج. مع ذلك، لا تزال هناك بعض الحالات المتوسطة التي لا تشكّل معنى بصورة تامة. على سبيل المثال، `error` التي لا تحمل القيمة null ليس لها معنى عندما تكون `status` تحمل قيمة `success`. لتمثيل الحالة بطريقة أكثر دقة، يمكنك [استخلاصها إلى مخفض.](/learn/extracting-state-logic-into-a-reducer) المخفضات تتيح ليك توحيد العديد من متغيرات الحالة داخل كائن (object) واحد وتجميع كل المنطق المتعلق بها.
 
 </DeepDive>
 
-### Step 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
+### الخطوة 5: اربط معالجات الأحداث لتعيين الحالة {/*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:
 
 <Sandpack>
@@ -438,9 +439,9 @@ export default function Form() {
 
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>اختبار المدينة</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        في أي مدينة يوجد لوحة إعلانية تقوم بتحويل الهواء إلى مياه صالحة للشرب؟
       </p>
       <form onSubmit={handleSubmit}>
         <textarea
@@ -466,7 +467,7 @@ export default function Form() {
 }
 
 function submitForm(answer) {
-  // Pretend it's hitting the network.
+  // محاكاة للتواصل باستخدام الشبكة.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       let shouldError = answer.toLowerCase() !== 'lima'
@@ -486,17 +487,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.
+بالرغم من أن هذا الكود أطول من المثال الأمريّ الأصلي، إلا أنه أقل هشاشة بكثير. التعبير عن جميع الأوامر على أنها تغيّرات في الحالة يتيح لك لاحقًا إضافة حالات مرئية جديدة دون تعطيل الحالات القائمة بالفعل. كما يتيح لك أيضًا تغيير ما يجب عرضه في كل حالة دون تغيير منطق الأمر نفسه.
 
 <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.
+* البرمجة التصريحية تعني وصف واجهة المستخدم لكل حالة مرئية عوضًا عن الإدارة التفصيلية لواجهة المستخدم (الأمريّة).
+* عند تطوير مكوّن:
+  1. حدد كل حالاته المرئية.
+  2. عيّن منشطات الإنسان والكمبيوتر لتغيّرات الحالة.
+  3. مثل الحالة عن طريق `useState`.
+  4. احذف الحالة غير الضرورية لتجنب الأخطاء والمعضلات.
+  5. اربط معالجات الأحداث لتعيين الحالة.
 
 </Recap>
 

From c6b4cc506030f5f8d7f4d54de2635cfb948fae5d Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Sun, 24 Sep 2023 22:27:20 +0300
Subject: [PATCH 04/19] Translation of (Reacting to input): Primary Page
 Translation Finished. - Translation of Challegnes

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

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 20d857faf..bb30f314c 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -326,10 +326,10 @@ body { margin: 0; }
 
 في كلتا الحالتين، **يجب عليك تعيين [متغيرات الحالة (state variables)](/learn/state-a-components-memory#anatomy-of-usestate) لتُحدّث واجهة المستخدم (UI).** من أجل النموذج الذي تطوره، سوف تحتاج لتغيير الحالة كنتيجة لقليل من المدخلات المختلفة:
 
-**تغيرت مدخل النص** (الإنسان) سوف يغيرها من الحالة *الفارغة* إلى حالة *الكتابة* أو العكس، يعتمد على ما إذا كان حقل النص فارغًا أم لا.
-**الضغط على زر الإرسال** (الإنسان) سوف يغيرها إلى حالة *الإرسال*
-* **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.
+* **تغيرت مدخل النص** (الإنسان) سوف يغيرها من الحالة *الفارغة* إلى حالة *الكتابة* أو العكس، يعتمد على ما إذا كان حقل النص فارغًا أم لا.
+* **الضغط على زر الإرسال** (الإنسان) سوف يغيرها إلى حالة *الإرسال*
+* **استجابة ناجحة للشبكة** (الكمبيوتر) سوف يغيرها إلى حالة *النجاح*.
+* **استجابة فاشلة للشبكة** (الكمبيوتر) سوف يغيرها إلى حالة *الخطأ* مع رسالة الخطأ المناسبة.
 
 <Note>
 
@@ -376,11 +376,11 @@ const [isError, setIsError] = useState(false);
 
 ### خطوة 4: احذف أيّ متغيرات حالة غير ضرورية {/*step-4-remove-any-non-essential-state-variables*/}
 
-ما تريده هو تجنب تكرار محتوى الحالة لذلك أنت فقط تقوم بتعقب ما هو ضروري. قضاء قليل من الوقت في إعادة تصميم هيكل حالتك سوف يجعل مكوّنك أسهل للفهم، يقلل التكرار، ويتجنب المعاني غير المقصودة. هدفك هو **منع الأوضاع التي تكون بها الحالة في الذاكرة لا تمثل أي واجهة مستخدم صالحة تود للمستخدم أن يراها.** )u(على سبيل المثال، لن تريد أبدًا إظهار رسالة خطأ مع تعطيل الإدخال في نفس الوقت، أو أن المستخدم لن يكون قادرًا على تصحيح الخطأ!)
+ما تريده هو تجنب تكرار محتوى الحالة لذلك أنت فقط تقوم بتعقب ما هو ضروري. قضاء قليل من الوقت في إعادة تصميم هيكل حالتك سوف يجعل مكوّنك أسهل للفهم، يقلل التكرار، ويتجنب المعاني غير المقصودة. هدفك هو **منع الأوضاع التي تكون بها الحالة في الذاكرة لا تمثل أي واجهة مستخدم صالحة تود للمستخدم أن يراها.** (على سبيل المثال، لن تريد أبدًا إظهار رسالة خطأ مع تعطيل الإدخال في نفس الوقت، أو أن المستخدم لن يكون قادرًا على تصحيح الخطأ!)
 
 هنا بعض الاسئلة التي يمكن أن تسألها عن متغيرات الحالة:
 
-* **هل هذه الحالة تسبب معضلة؟** على سبيل المثال، `isTyping` و `isSubmitting` لا يمكن لكليهما أن يكونا بقيمة `true`. المعضلة غالبا تعني أن الحالة ليست مقيدة بالشكل الكافي. هناك أربع احتمالات ممكنة لاثنين من نوع boolean، لكن ثلاث منها فقط يوافقن حالات صالحة. لحذف الحالة "المستحيلة"، يمكنك جمع تلك الحالات داخل `status` التي يجب يجب أن تكون واحدة من ثلاث قيم: `'typing'`, `'submitting'`, أو `'success'`.
+* **هل هذه الحالة تسبب معضلة؟** على سبيل المثال، `isTyping` و `isSubmitting` لا يمكن لكليهما أن يكونا بقيمة `true`. المعضلة غالبا تعني أن الحالة ليست مقيدة بالشكل الكافي. هناك أربع احتمالات ممكنة لقيميتين منطقيتين (boolean). لكن ثلاث منها فقط يوافقن حالات صالحة. لحذف الحالة "المستحيلة"، يمكنك جمع تلك الحالات داخل `status` التي يجب يجب أن تكون واحدة من ثلاث قيم: `'typing'`, `'submitting'`, أو `'success'`.
 * **هل نفس المعلومات متاحة بالفعل لمتغير حالة آخر؟** معضلة أخرى: `isEmpty` و `isTyping` لا يمكنها أن يكونا `true` في نفس الوقت. بجعلهما متغيرين حالة منفصلين، تخاطر بفقدان الترابط بينهما وإحداث الأخطاء. لحسن الحظ، يمكن حذف `isEmpty` والتحقق من `answer.length === 0` بدلًا عن ذلك.
 * **هل يمكنك الحصول على نفس المعلومات من من عكس متغير حالة آخر؟** `isError` غير ضروري لأنه يمكنك التحقق من `error !== null` بدلًا عن ذلك.
 
@@ -405,7 +405,6 @@ const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 's
 ### الخطوة 5: اربط معالجات الأحداث لتعيين الحالة {/*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:
 
 <Sandpack>
 
@@ -505,11 +504,11 @@ function submitForm(answer) {
 
 <Challenges>
 
-#### Add and remove a CSS class {/*add-and-remove-a-css-class*/}
+#### إضافة وحذف صنف (class) 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.
+نفذ ذلك بحيث يكون النقر على الصورة *يحذف* صنف CSS `background--active`من الـ`<div>` الخارجي، لكن *يضيف* الصنف `picture--active` لـ`<img>`. النقر على الخلفية مجددًا يجب أن يعيد أصناف CSS الأصلية.
 
-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.
+عمليًا، يمكنك توقع أن النقر على الصورة يحذف الخلفية البنفسجية ويقوم بتحديد (highlight) إطار الصورة. النقر خارج الصورة يقوم بتحديد الخلفيةـ ولكن يحذف تحديد إطار الصورة.
 
 <Sandpack>
 
@@ -558,14 +557,13 @@ 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:
+هذا المكوّن لديه حالتين مرئيتين: عندما تكون الصورة نشطة، وعندما تكون الصورة غير نشطة:
 
-* 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`.
+* عندما تكون الصورة نشطة، أصناف CSS هي `background` و `picture picture--active`.
+* عندما تكون الصورة غير نشطة، أصناف CSS هي `background background--active` و `picture`.
+متغير حالة قيمة منطقية (boolean) واحد كافي لتذكر ما إذا كانت نشطة. المهمة الأصلية كانت إزالة أو إضافة أصناف CSS. على أية حال، في React تحتاج لـ*تصف* ما تريد رؤيته فضلًا عن *تعديل* عناصر واجهة المستخدم. لذلك تحتاج لحساب كلا صنفيّ CSS اعتمادًا على الحالة الحالية. تحتاج أيضًا إلى [إيقاف الانتشار (propagation)](/learn/responding-to-events#stopping-propagation) بحيث لا يتم تسجيل النقر على الصورة كنقر على الخلفية. 
 
-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.
-
-Verify that this version works by clicking the image and then outside of it:
+تأكد من أن هذا الإصدار يعمل عن طريق النقر على الصور وخارجها:
 
 <Sandpack>
 
@@ -632,7 +630,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Alternatively, you could return two separate chunks of JSX:
+بديلًا عن ذلك، يمكنك إرجاع (return) جزئين مختلفين من JSX:
 
 <Sandpack>
 
@@ -699,27 +697,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.
+ضع في الحسبان أنه إذا وصف جزئين مختلفين من JSX الشجرة نفسها، فتضمينهما (أول `<div>` → أول `<img>`) يجب أن يصطف. وإلا تغيّر `isActive` سوف يعيد إنشاء الشجرة بأكملها أدناه و [يعيد تعيين حالتها.](/learn/preserving-and-resetting-state) هذا هو السبب، إذا كان يتم إرجاع شجرة JSX مشابهة في كلا الحالتين، فمن الأفضل كتابتهما على كجزء واحد من JSX.
 
 </Solution>
 
-#### Profile editor {/*profile-editor*/}
+#### محرر الملف الشخصي {/*profile-editor*/}
 
-Here is a small form implemented with plain JavaScript and DOM. Play with it to understand its behavior:
+ها هو نموذج مصغر تم تنفيذه بواسطة JavaScript و DOM خالصيّن. جربه لتفهم طريقة عمله:
 
 <Sandpack>
 
 ```js index.js active
 function handleFormSubmit(e) {
   e.preventDefault();
-  if (editButton.textContent === 'Edit Profile') {
-    editButton.textContent = 'Save Profile';
+  if (editButton.textContent === 'عدّل الملف الشخصي') {
+    editButton.textContent = 'احفظ الملف الشخصي';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'عدّل الملف الشخصي';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -730,7 +728,7 @@ function handleFormSubmit(e) {
 function handleFirstNameChange() {
   firstNameText.textContent = firstNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'أهلًا ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -739,7 +737,7 @@ function handleFirstNameChange() {
 function handleLastNameChange() {
   lastNameText.textContent = lastNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'أهلًا ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -774,7 +772,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    الأسم الأول:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -782,15 +780,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    اسم العائلة
     <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">عدّل الملف الشخصي</button>
+  <p><i id="helloText">أهلًا، Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -802,11 +800,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.
+هذا النموذج يتغيّر بين وضعين: في وضع التعديل، ترى حقول الإدخال، وفي وضع المعاينة، ترى النتيجة فقط. عنوان الزر يتغيّر ما بين "عدّل" و"احفظ" اعتمادًا على الوضع الذي أنت عليه. عندما تقوم بتغيير حقول الإدخال، رسالة الترحيب في الأسفل يتم تحديثها للوقت الحالي.
 
-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.
+مهمتك هي إعادة تنفيذها بواسطة React في الـsandbox أدناه. لضمان راحتك، تم تحويل التوصيف (markup) إلى JSX, لكن يتعين عليك جعلها تُظهر وتُخفي المدخلات كما تفعل الأصلية.
 
-Make sure that it updates the text at the bottom, too!
+تأكد من أنها تقوم بتحد النص في الأسفل أيضًا!
 
 <Sandpack>
 
@@ -815,19 +813,19 @@ export default function EditProfile() {
   return (
     <form>
       <label>
-        First name:{' '}
+        الاسم الأول:{' '}
         <b>Jane</b>
         <input />
       </label>
       <label>
-        Last name:{' '}
+        اسم العائلة:{' '}
         <b>Jacobs</b>
         <input />
       </label>
       <button type="submit">
-        Edit Profile
+        عدّل الملف الشخصي
       </button>
-      <p><i>Hello, Jane Jacobs!</i></p>
+      <p><i>أهلًا، Jane Jacobs!</i></p>
     </form>
   );
 }
@@ -841,9 +839,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`.
+ستحتاج لمتغيريّ حالة لحمل قيم الإدخال: `firstName` و `lastName`. سوف تحتاج أيَا متغير حالة `isEditing` الذي يحمل ما إذا كان سيعرض حقول الإدخال أم لا. _ليس_ عليك استعمال متغير `fullName` لأن الاسم الكامل يمكن دائمًا إيجاده من الاسم الأول `firstName` واسم العائلة `lastName`.
 
-Finally, you should use [conditional rendering](/learn/conditional-rendering) to show or hide the inputs depending on `isEditing`.
+أخيرًا، يمكنك استخدام [التصيّير الشرطي](/learn/conditional-rendering) لإظهار أو إخفاء حقول الإدخال اعتمادًا على `isEditing`.
 
 <Sandpack>
 
@@ -901,27 +899,27 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-Compare this solution to the original imperative code. How are they different?
+قارن بين هذا الحل والكود الأمريّ الأصلي. ما مدى الاختلاف؟
 
 </Solution>
 
-#### Refactor the imperative solution without React {/*refactor-the-imperative-solution-without-react*/}
+#### إعادة تصميم الحل الأمري بدون React {/*refactor-the-imperative-solution-without-react*/}
 
-Here is the original sandbox from the previous challenge, written imperatively without React:
+ها هي الـ sandbox الأصلية من التحدي الماضي، مكتوبة بشكل أمري بدون React:
 
 <Sandpack>
 
 ```js index.js active
 function handleFormSubmit(e) {
   e.preventDefault();
-  if (editButton.textContent === 'Edit Profile') {
-    editButton.textContent = 'Save Profile';
+  if (editButton.textContent === 'عدّل الملف الشخصي') {
+    editButton.textContent = 'احفظ الملف الشخصي';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'عدّل الملف الشخصي';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -932,7 +930,7 @@ function handleFormSubmit(e) {
 function handleFirstNameChange() {
   firstNameText.textContent = firstNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'أهلًا ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -941,7 +939,7 @@ function handleFirstNameChange() {
 function handleLastNameChange() {
   lastNameText.textContent = lastNameInput.value;
   helloText.textContent = (
-    'Hello ' +
+    'أهلًا ' +
     firstNameInput.value + ' ' +
     lastNameInput.value + '!'
   );
@@ -976,7 +974,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    الاسم الأول:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -984,15 +982,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    اسم العائلة:
     <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">عدّل الملف الشخصي</button>
+  <p><i id="helloText">أهلًا، Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1004,9 +1002,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?
+تصوّر لو أن React غير موجودة. هل يمكنك إعادة تصميم الكود بطريقة تجعل المنطق أقل هشاشة وأكثر مقاربة لنسخة React؟ كيف سيبدو لو كانت حالته بيّنة، كما هو الحال في 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.)
+إذا كنت تواجه صعوبة في تحديد من أين تبدأ، فالمُلق أدناه يحتوي أغلب الهيكل معدًّا. لو بدأت من هنا، املئ المنطق المفقود داخل الدالة `updateDOM`. (راجع الكود الكود الأصلي عند الحاجة.)
 
 <Sandpack>
 
@@ -1045,13 +1043,13 @@ function setIsEditing(value) {
 
 function updateDOM() {
   if (isEditing) {
-    editButton.textContent = 'Save Profile';
-    // TODO: show inputs, hide content
+    editButton.textContent = 'احفظ الملف الشخصي';
+    // قائمة المهام: إظهار حقول الإدخال، إخفاء المحتوى
   } else {
-    editButton.textContent = 'Edit Profile';
-    // TODO: hide inputs, show content
+    editButton.textContent = 'عدّل الملف الشخصي';
+    // قائمة المهام: إخفاء حقول الإدخال، إظهار المحتوى
   }
-  // TODO: update text labels
+  // (text labels) قائمة المهام: تحديث عنواين النص
 }
 
 function hide(el) {
@@ -1083,7 +1081,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    الاسم الأول:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -1091,15 +1089,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    اسم العائلة:
     <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">عدّل الملف الشخصي</button>
+  <p><i id="helloText">أهلًا، Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1113,7 +1111,7 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-The missing logic included toggling the display of inputs and content, and updating the labels:
+المنطق المفقود تضمّن تغيير عرض حقول الإدخال والمحتوى، وتحديث العناوين: 
 
 <Sandpack>
 
@@ -1152,13 +1150,13 @@ function setIsEditing(value) {
 
 function updateDOM() {
   if (isEditing) {
-    editButton.textContent = 'Save Profile';
+    editButton.textContent = 'احفظ الملف الشخصي';
     hide(firstNameText);
     hide(lastNameText);
     show(firstNameInput);
     show(lastNameInput);
   } else {
-    editButton.textContent = 'Edit Profile';
+    editButton.textContent = 'عدّل الملف الشخصي';
     hide(firstNameInput);
     hide(lastNameInput);
     show(firstNameText);
@@ -1167,7 +1165,7 @@ function updateDOM() {
   firstNameText.textContent = firstName;
   lastNameText.textContent = lastName;
   helloText.textContent = (
-    'Hello ' +
+    'أهلًا ' +
     firstName + ' ' +
     lastName + '!'
   );
@@ -1202,7 +1200,7 @@ lastNameInput.oninput = handleLastNameChange;
 ```html public/index.html
 <form id="form">
   <label>
-    First name:
+    الاسم الأول:
     <b id="firstNameText">Jane</b>
     <input
       id="firstNameInput"
@@ -1210,15 +1208,15 @@ lastNameInput.oninput = handleLastNameChange;
       style="display: none">
   </label>
   <label>
-    Last name:
+    اسم العائلة:
     <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">عدّل الملف الشخصي</button>
+  <p><i id="helloText">أهلًا، Jane Jacobs!</i></p>
 </form>
 
 <style>
@@ -1230,7 +1228,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.)
+الدالة `updateDOM` التي كتبتها تظهر ما تقوم به React تحت الستار عندم تقوم بتعيين الحالة. (مع ذلك، React تتجنب المس بالـ DOM لأجل الخصائص التي لم تتغير من أخر مرة تم تعيينها فيها.)
 
 </Solution>
 

From d92ae1f273cb6686a043f95fcb2de10783509e18 Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 26 Sep 2023 15:26:18 +0300
Subject: [PATCH 05/19] Fix a typo

---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index bb30f314c..970b4e79b 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -504,7 +504,7 @@ function submitForm(answer) {
 
 <Challenges>
 
-#### إضافة وحذف صنف (class) CSS { /*add-and-remove-a-css-class*/}
+#### إضافة وحذف صنف (class) CSS {/*add-and-remove-a-css-class*/}
 
 نفذ ذلك بحيث يكون النقر على الصورة *يحذف* صنف CSS `background--active`من الـ`<div>` الخارجي، لكن *يضيف* الصنف `picture--active` لـ`<img>`. النقر على الخلفية مجددًا يجب أن يعيد أصناف CSS الأصلية.
 

From 0e242dd2935379c5f889e3d6e04c35bf617c1293 Mon Sep 17 00:00:00 2001
From: Rumbustious <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 26 Sep 2023 22:00:54 +0300
Subject: [PATCH 06/19] Translation of (Reacting to input): Finished
 Translation     - personal revision     - Fix typos & Errors     - Rephrasing
     - Add rtl styling

---
 .../learn/reacting-to-input-with-state.md     | 113 +++++++++---------
 src/sidebarLearn.json                         |   2 +-
 2 files changed, 59 insertions(+), 56 deletions(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 970b4e79b..a18fbc5a3 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -4,36 +4,35 @@ title: الاستجابة للمدخلات باستخدام الحالة
 
 <Intro>
 
-React توفر طريقة تصريحيّة (declarative) لتعديل واجهة المستخدم (UI). بدلا من تعديل أجزاء منفردة من واجهة المستخدم مباشرة، يمكنك وصف الحالات المختلفة التي يأخذها مكوّنك، والانتقال بينهم كاستجابة لمدخلات المستخدم. هذا مشابه لتصور المصممين عن واجهة المستخدم. 
+React توفر طريقة تصريحيّة (declarative) لتعديل واجهة المستخدم (UI). بدلًا من تعديل أجزاء منفردة من واجهة المستخدم مباشرةً، يمكنك وصف الحالات المختلفة التي يأخذها مكوّنك، والانتقال بينهم كاستجابة لمدخلات المستخدم. هذا مشابه لتصوّر المصمّمين عن واجهة المستخدم. 
 
 
 </Intro>
 
 <YouWillLearn>
 
-* كيف تختلف البرمجة التصريحية لواجهة المستخدم (declarative UI programming) عن البرمجة الأمرية لواجهة المستخدم (imperative UI programming)
+* كيف تختلف البرمجة التصريحيّة لواجهة المستخدم (declarative UI programming) عن البرمجة الأمريّة لواجهة المستخدم (imperative UI programming)
 * كيفية استعراض الحالات المرئية المختلفة التي يأخذها مكوّنك
 * كيفية تنشيط التغييرات بين الحالات المرئية المختلفة من خلال الكود
   
 </YouWillLearn>
 
-## كيف تُقارَن واجهة المستخدم التصريحية (declarative UI) بالأمرية (imperative) {/*how-declarative-ui-compares-to-imperative*/}
+## كيف تُقارَن واجهة المستخدم التصريحيّة (declarative UI) بالأمريّة (imperative) {/*how-declarative-ui-compares-to-imperative*/}
 
-عندما تصمم تعاملات واجهة المستخدم، عليك غالبًا التفكير في كيفية *تغيّر* واجهة المستخدم كاستجابة لاجراءات المستخدم. فكر في نموذج يسمح للمستخدم بإرسال إجابة:
+عندما تصمم تعاملات واجهة المستخدم، عليك غالبًا التفكير في كيفية *تغيّر* واجهة المستخدم كاستجابة لإجراءات المستخدم. فكر في نموذج يسمح للمستخدم بإرسال إجابة:
 
-* عندما تكتب شيئًا داخل النموذج، الزر "أرسل" **يصبح مفعلًا.**
-* عندما تضغط على "أرسل"، كلٌ من النموذج والزر **يصبح معطلا** ومؤشر التحميل **يظهر.**
-* لو نجح طلب الشبكة، النموج **يبدأ بالاختفاء،** ورسالة "شكرًا لك" **تظهر.**
-* لو فشل طلب الشبكة، رسالة خطأٍ **تظهر،** والنموذج **يصبح مفعلًا** مجددا.
+* عندما تكتب شيئًا داخل النموذج، يصبح الزر "أرسل" **مفعلًا.**
+* عندما تضغط على "أرسل"، يصبح كلٌ من النموذج والزر **معطلا** و**يظهر** مؤشر التحميل.
+* لو نجح طلب الشبكة، يبدأ النموج **بالاختفاء،** و**تظهر** رسالة "شكرًا لك".
+* لو فشل طلب الشبكة،**تظهر** رسالة خطأٍ، ويصبح النموذج **مفعلًا** مجددا.
 
-في **البرمجة الأمرية (imperative programming)**، يتوافق ما ذُكر أعلاه مباشرة مع طريقة تطبيق التعاملات. عليك أن تكتب التعليمات التامة لتعديل واجهة المستخدم معتمدا على ما حصل للتو. إليك طريقة أخرى لتفكر في هذا الأمر: تخيل نفسك راكبا إلى جانب أحدهم في سيارة مع إخباره في كل منعطف تلو الآخر عن وجهة الذهاب. 
+في **البرمجة الأمرية (imperative programming)**، يتوافق ما ذُكر أعلاه مباشرة مع طريقة تطبيق التعاملات. عليك أن تكتب التعليمات التامّة لتعديل واجهة المستخدم معتمدًا على ما حصل للتوّ. إليك طريقة أخرى لتفكر في هذا الأمر: تخيل نفسك راكبًا إلى جانب أحدهم في سيارة مع إخباره في كل منعطف تلو الآخر عن وجهة الذهاب. 
 
 <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." />
 
-هم لا يعلمون إلى أين تريد أن تذهب، هم يتبعون أوامرك فقط. (ولو أنك أعطيتهم الاتجاهات الخاطئة، سوف ينتهي بك المطاف لوجهة خاطئة!) هذا يطلق عليه *أمري (imperative)* لأن عليك أن "تأمر" كل عنصر، بداية من مؤشر التحميل إلى الزر، مخبرًا
-الكمبيوتر عن *كيفية* تحديث واجهة المستخدم (UI).
+هو لا يعلم إلى أين تريد أن تذهب، هو يتبع أوامرك فقط. (ولو أنك أعطيته الاتجاهات الخاطئة، سوف ينتهي بك المطاف لوجهة خاطئة!) هذا يطلق عليه *أمري (imperative)* لأن عليك أن "تأمر" كل عنصر، بداية من مؤشر التحميل إلى الزر، مخبرًا الكمبيوتر عن *كيفية* تحديث واجهة المستخدم (UI).
 
-في هذا المثال للبرمجة الأمرية لواجهة المستخدم، النموذج مبنيّ *بدون* React. إنه يستخدم [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) المتصفح فقط:
+في هذا المثال للبرمجة الأمريّة لواجهة المستخدم، النموذج مبنيّ *بدون* React. باستخدام [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) الخاص بالمتصفح فقط:
 
 <Sandpack>
 
@@ -86,7 +85,7 @@ function submitForm(answer) {
   // Pretend it's hitting the network.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
-      if (answer.toLowerCase() == 'إسطنبول') {
+      if (answer.toLowerCase() == 'istanbul') {
         resolve();
       } else {
         reject(new Error('توقع جيد ولكن إجابة خاطئة. حاول مرة أخرى!'));
@@ -127,17 +126,17 @@ textarea.oninput = handleTextareaChange;
 
 <style>
 * { box-sizing: border-box; }
-body { font-family: sans-serif; margin: 20px; padding: 0; }
+body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 </style>
 ```
 
 </Sandpack>
 
-تعديل واجهة المستخدم (UI) أمريًّا يعمل بشكل جيد كفاية للأمثلة المعزولة، ولكنه يصبح أكثر صعوبة بشكل استثنائي عندما تدير أنظمة أكثر تعقيدًا. تخيل تحديث صفحة مليئة بالنماذج المختلفة مثل هذه هنا. إضافة عنصر واجهة مستخدم جديد سيتطلب فحص كامل الكود الموجود بحرص للتأكد من أنك لم تقم بعمل خطأ(على سبيل المثال، نسيان إظهار أو إخفاء شيء ما).
+تعديل واجهة المستخدم (UI) أمريًّا يعمل بشكل جيد كفاية للأمثلة المعزولة، ولكنه يصبح أكثر صعوبة بشكل استثنائي عندما تدير أنظمة أكثر تعقيدًا. تخيل تحديث صفحة مليئة بالنماذج المختلفة مثل هذه هنا. إضافة عنصر واجهة مستخدم جديد سيتطلب فحص كامل الكود الموجود بحرص للتأكد من أنك لم تقم بعمل خطأ (على سبيل المثال، نسيان إظهار أو إخفاء شيء ما).
 
 React صُنعت لحل هذه المشكلة. 
 
-في React، لن تقوم بتعديل واجهة المستخدم مباشرة -- يعني أنك لن تقوم بتفعيل، تعطيل، إظهار، أو إخفاء مكوّنات مباشرة. بدلا عن ذلك، سوف **تصف ما تريده أن يظهر،** و React سوف تدبر كيفية تحديث واجهة المستخدم. فكر في أخذ سيارة أجرة وإخبار السائق إلي أين تريد أنت تذهب بدلا من إخباره إلي أين ينعطف. وظيفة السائق هي أن يوصلك إلى هناك، وربما قد يعرف اختصارات لم تأخذها أنت بالحسبان.
+في React، لن تقوم بتعديل واجهة المستخدم مباشرة -- يعني أنك لن تقوم بتفعيل، تعطيل، إظهار، أو إخفاء مكوّنات مباشرة. بدلًا عن ذلك، سوف **تصف ما تريده أن يظهر،** و React سوف تدبر كيفية تحديث واجهة المستخدم. فكر في أخذ سيارة أجرة وإخبار السائق إلي أين تريد أنت تذهب بدلًا من إخباره إلي أين ينعطف. وظيفة السائق هي أن يوصلك إلى هناك، وربما قد يعرف اختصارات لم تأخذها أنت بالحُسبان.
 
 <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." />
 
@@ -146,18 +145,18 @@ React صُنعت لحل هذه المشكلة.
 لقد رأيت كيفية تنفيذ نموذج أمريَّا أعلاه. لفهم أفضل لكيفية التفكير في React، سوف تمر بإعادة تنفيذ واجهة المستخدم (UI) هذه باستخدام React أدناه:
 
 1. **عيّن** الحالات المرئية المختلفة لمكوّنك
-2. **حدد** ما ينشط تغيرات  تلك الحالات
+2. **حدد** ما ينشط تغييرات  تلك الحالات
 3. **مثّل** الحالة في الذاكرة باستخدام `useState`
 4. **احذف** أيّ متغيرات حالة غير ضرورية
 5. **اربط** معالجات الأحداث لتعيين الحالة
 
-### الخطوة 1: عين الحالات المرئية المختلفة لمكوّنك {/*step-1-identify-your-components-different-visual-states*/}
+### الخطوة 1: عيّن الحالات المرئية المختلفة لمكوّنك {/*step-1-identify-your-components-different-visual-states*/}
 
-في علوم الحاسب، ربما تسمع عن ["آلة حالة (state machine)"](https://en.wikipedia.org/wiki/Finite-state_machine) كونها واحدة من ضمن "حالات" متعددة.إذا كنت تعمل مع مصمم، لربما رأيت نماذج تجريبية لـ"الحالات المرئية" المختلفة 
+في علوم الحاسب، ربما تسمع عن ["آلة الحالة (state machine)"](https://en.wikipedia.org/wiki/Finite-state_machine) كونها واحدة من ضمن "حالات" متعددة. إذا كنت تعمل مع مصمم، لربما رأيت نماذج تجريبية لـ"الحالات المرئية" المختلفة 
 
-أولًا، أنت تحتاج لتصور جميع "الحالات" المختلفة لواجهة المستخدم (UI) التي قد يراها المستخدم: 
-*  **فارغة**: النموذج يحتوي زر "إرسال" معطل.
-* **كتابة**: النموذج يحتوي زر "إرسال" مفعّل.
+أولًا، أنت تحتاج لتصوّر جميع "الحالات" المختلفة لواجهة المستخدم (UI) التي قد يراها المستخدم: 
+*  **فارغة**: النموذج يحتوي على زر "إرسال" معطل.
+* **كتابة**: النموذج يحتوي على زر "إرسال" مفعّل.
 * **إرسال**: النموذج معطل تمامًا. يتم عرض مؤشر التحميل.
 * **نجاح**: يتم عرض رسالة "شكرًا لك" بدلًا من النموذج.
 * **خطأ**: مثل حالة الكتابة، ولكن مع رسالة خطأ إضافية
@@ -193,7 +192,7 @@ export default function Form({
 
 </Sandpack>
 
-يمكنك تسمية الخاصيّة أيّ شيء تريد، التسمية ليست مهمة. جرب تعديل `status = 'empty'` إلى `status = 'success'` لترى رسالة النجاح تظهر. التجربة تتيح لك التكرار السريع على واجهة المستخدم قبل ربط أي منطق. ها هو نموذج تجريبي أكثر تفصيلًا لنفس المكوّن، يظل "متحكم" بواسطة الخاصية `status`:
+يمكنك تسمية الخاصيّة أيّ شيء تريد، التسمية ليست مهمة. جرب تعديل `status = 'empty'` إلى `status = 'success'` لترى رسالة النجاح تظهر. التجربة تتيح لك التكرار السريع على واجهة المستخدم قبل ربط أي منطق. ها هو نموذج تجريبي أكثر تفصيلًا لنفس المكوّن، يظل "متحكمًا به" بواسطة الخاصية `status`:
 
 <Sandpack>
 
@@ -234,6 +233,7 @@ export default function Form({
 ```
 
 ```css
+body { direction: rtl; }
 .Error { color: red; }
 ```
 
@@ -243,7 +243,7 @@ export default function Form({
 
 #### عرض عديد من الحالات المرئية مرة واحدة {/*displaying-many-visual-states-at-once*/}
 
-لو أن لمكون العديد من الحالات المرئية، قد يكون ملائما عرضها جميعها في صفحة واحدة: 
+لو أن لمكون العديد من الحالات المرئية، قد يكون ملائمًا عرضها جميعها في صفحة واحدة: 
 
 <Sandpack>
 
@@ -302,7 +302,7 @@ export default function Form({ status }) {
 ```css
 section { border-bottom: 1px solid #aaa; padding: 20px; }
 h4 { color: #222; }
-body { margin: 0; }
+body { margin: 0; direction: rtl; }
 .Error { color: red; }
 ```
 
@@ -312,22 +312,22 @@ body { margin: 0; }
 
 </DeepDive>
 
-###  الخطوة 2: حدد ما ينشط تغيرات تلك الحالة {/*step-2-determine-what-triggers-those-state-changes*/}
+###  الخطوة 2: حدد ما ينشط تغييرات تلك الحالة {/*step-2-determine-what-triggers-those-state-changes*/}
 
 يمكنك تنشيط تحديثات الحالة كاستجابة إلى نوعين من المدخلات:
 
 * **مدخلات الإنسان،** مثل الضغط على زر، الكتابة في حقل، زيارة رابط.
-* **مدخلات الكمبيوتر** مثل وصول رد الشبكة، استكمال المؤقت، تحميل الصورة
+* **مدخلات الكمبيوتر،** مثل وصول رد الشبكة، استكمال المؤقت، تحميل الصورة.
 
 <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="مدخلات الإنسان" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
+  <Illustration caption="مدخلات الكمبيوتر" alt="Ones and zeroes." src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-في كلتا الحالتين، **يجب عليك تعيين [متغيرات الحالة (state variables)](/learn/state-a-components-memory#anatomy-of-usestate) لتُحدّث واجهة المستخدم (UI).** من أجل النموذج الذي تطوره، سوف تحتاج لتغيير الحالة كنتيجة لقليل من المدخلات المختلفة:
+في كلتا الحالتين، **يجب عليك تعيين [متغيرات الحالة (state variables)](/learn/state-a-components-memory#anatomy-of-usestate) لتُحدّث واجهة المستخدم (UI).** من أجل تطوير النموذج سوف تحتاج لتغيير الحالة كنتيجة لبعض من المدخلات المختلفة:
 
-* **تغيرت مدخل النص** (الإنسان) سوف يغيرها من الحالة *الفارغة* إلى حالة *الكتابة* أو العكس، يعتمد على ما إذا كان حقل النص فارغًا أم لا.
-* **الضغط على زر الإرسال** (الإنسان) سوف يغيرها إلى حالة *الإرسال*
+* **تغيّر حقل إدخال النص** (الإنسان) سوف يغيرها من الحالة *الفارغة* إلى حالة *الكتابة* أو العكس، يعتمد على ما إذا كان حقل النص فارغًا أم لا.
+* **الضغط على زر الإرسال** (الإنسان) سوف يغيرها إلى حالة *الإرسال*.
 * **استجابة ناجحة للشبكة** (الكمبيوتر) سوف يغيرها إلى حالة *النجاح*.
 * **استجابة فاشلة للشبكة** (الكمبيوتر) سوف يغيرها إلى حالة *الخطأ* مع رسالة الخطأ المناسبة.
 
@@ -372,17 +372,17 @@ const [isSuccess, setIsSuccess] = useState(false);
 const [isError, setIsError] = useState(false);
 ```
 
-خطوتك المبدأئية على الأرجح لن تكون هي الأفضل، ولكن هذا لا بأس به -- إعادة تصميم الحالة هو جزء من العملية!
+خطوتك المبدئية على الأرجح لن تكون هي الأفضل، ولكن هذا لا بأس به -- إعادة تصميم الحالة هو جزء من العملية!
 
-### خطوة 4: احذف أيّ متغيرات حالة غير ضرورية {/*step-4-remove-any-non-essential-state-variables*/}
+### الخطوة 4: احذف أيّ متغيرات حالة غير ضرورية {/*step-4-remove-any-non-essential-state-variables*/}
 
-ما تريده هو تجنب تكرار محتوى الحالة لذلك أنت فقط تقوم بتعقب ما هو ضروري. قضاء قليل من الوقت في إعادة تصميم هيكل حالتك سوف يجعل مكوّنك أسهل للفهم، يقلل التكرار، ويتجنب المعاني غير المقصودة. هدفك هو **منع الأوضاع التي تكون بها الحالة في الذاكرة لا تمثل أي واجهة مستخدم صالحة تود للمستخدم أن يراها.** (على سبيل المثال، لن تريد أبدًا إظهار رسالة خطأ مع تعطيل الإدخال في نفس الوقت، أو أن المستخدم لن يكون قادرًا على تصحيح الخطأ!)
+ما تريده هو تجنب تكرار محتوى الحالة لذلك أنت تقوم بتعقب ما هو ضروري فقط. قضاء قليل من الوقت في إعادة تصميم هيكل حالتك سوف يجعل مكوّنك أسهل للفهم، يقلل التكرار، ويتجنب المعاني غير المقصودة. هدفك هو **منع الأوضاع التي تكون بها الحالة في الذاكرة لا تمثل أي واجهة مستخدم صالحة من التي تود للمستخدم أن يراها.** (على سبيل المثال، لن تريد أبدًا إظهار رسالة خطأ مع تعطيل الإدخال في نفس الوقت، أو أن المستخدم لن يكون قادرًا على تصحيح الخطأ!)
 
 هنا بعض الاسئلة التي يمكن أن تسألها عن متغيرات الحالة:
 
-* **هل هذه الحالة تسبب معضلة؟** على سبيل المثال، `isTyping` و `isSubmitting` لا يمكن لكليهما أن يكونا بقيمة `true`. المعضلة غالبا تعني أن الحالة ليست مقيدة بالشكل الكافي. هناك أربع احتمالات ممكنة لقيميتين منطقيتين (boolean). لكن ثلاث منها فقط يوافقن حالات صالحة. لحذف الحالة "المستحيلة"، يمكنك جمع تلك الحالات داخل `status` التي يجب يجب أن تكون واحدة من ثلاث قيم: `'typing'`, `'submitting'`, أو `'success'`.
+* **هل هذه الحالة تسبب معضلة؟** على سبيل المثال، `isTyping` و `isSubmitting` لا يمكن لكليهما أن يكونا بقيمة `true`. المعضلة غالبًا تعني أن الحالة ليست مقيدة بالشكل الكافي. هناك أربع احتمالات ممكنة لقيميتين منطقيتين (boolean). لكن ثلاث منهن فقط يوافقن حالات صالحة. لحذف الحالة "المستحيلة"، يمكنك جمع تلك الحالات داخل `status` التي يجب أن تكون واحدة من ثلاث قيم: `'typing'`, `'submitting'`, أو `'success'`.
 * **هل نفس المعلومات متاحة بالفعل لمتغير حالة آخر؟** معضلة أخرى: `isEmpty` و `isTyping` لا يمكنها أن يكونا `true` في نفس الوقت. بجعلهما متغيرين حالة منفصلين، تخاطر بفقدان الترابط بينهما وإحداث الأخطاء. لحسن الحظ، يمكن حذف `isEmpty` والتحقق من `answer.length === 0` بدلًا عن ذلك.
-* **هل يمكنك الحصول على نفس المعلومات من من عكس متغير حالة آخر؟** `isError` غير ضروري لأنه يمكنك التحقق من `error !== null` بدلًا عن ذلك.
+* **هل يمكنك الحصول على نفس المعلومات من عكس متغير حالة آخر؟** `isError` غير ضروري لأنه يمكنك التحقق من `error !== null` بدلًا عن ذلك.
 
 بعد هذا التبسيط، تبقى لديك 3 (من أصل 7!) متغيرات حالة *ضرورية*:
 
@@ -392,13 +392,13 @@ const [error, setError] = useState(null);
 const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'
 ```
 
-أنت تعلم أنها ضرورية، لأنك لا تستطيع إزالة أيّ منها بدون تخريب آلية العمل
+أنت تعلم أنها ضرورية، لأنك لا تستطيع إزالة أيّ منها بدون تخريب آلية العمل.
 
 <DeepDive>
 
 #### إزالة الحالات "المستحيلة" باستخدام مخفض (reducer) {/*eliminating-impossible-states-with-a-reducer*/}
 
-هذه الثلاث متغيرات تمثيل جيد كفاية لحالة النموذج. مع ذلك، لا تزال هناك بعض الحالات المتوسطة التي لا تشكّل معنى بصورة تامة. على سبيل المثال، `error` التي لا تحمل القيمة null ليس لها معنى عندما تكون `status` تحمل قيمة `success`. لتمثيل الحالة بطريقة أكثر دقة، يمكنك [استخلاصها إلى مخفض.](/learn/extracting-state-logic-into-a-reducer) المخفضات تتيح ليك توحيد العديد من متغيرات الحالة داخل كائن (object) واحد وتجميع كل المنطق المتعلق بها.
+هذه الثلاث متغيرات تمثيل جيد كفاية لحالة النموذج. مع ذلك، لا تزال هناك بعض الحالات المتوسطة الغير منطقية بشكل كافٍ. على سبيل المثال، `error` التي لا تحمل القيمة null غير منطقية عندما تكون `status` تحمل قيمة `success`. لتمثيل الحالة بطريقة أكثر دقة، يمكنك [استخلاصها إلى مخفض.](/learn/extracting-state-logic-into-a-reducer) المخفضات تتيح ليك توحيد العديد من متغيرات الحالة داخل كائن (object) واحد وتجميع كل المنطق المتعلق بها.
 
 </DeepDive>
 
@@ -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('توقع جيد ولكن إجابة خاطئة. حاول مرة أخرى!'));
       } else {
         resolve();
       }
@@ -481,6 +481,7 @@ function submitForm(answer) {
 ```
 
 ```css
+body { direction: rtl; }
 .Error { color: red; }
 ```
 
@@ -493,7 +494,7 @@ function submitForm(answer) {
 * البرمجة التصريحية تعني وصف واجهة المستخدم لكل حالة مرئية عوضًا عن الإدارة التفصيلية لواجهة المستخدم (الأمريّة).
 * عند تطوير مكوّن:
   1. حدد كل حالاته المرئية.
-  2. عيّن منشطات الإنسان والكمبيوتر لتغيّرات الحالة.
+  2. عيّن المنشطات الوادة الإنسان والكمبيوتر لتغيّرات الحالة.
   3. مثل الحالة عن طريق `useState`.
   4. احذف الحالة غير الضرورية لتجنب الأخطاء والمعضلات.
   5. اربط معالجات الأحداث لتعيين الحالة.
@@ -561,7 +562,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 * عندما تكون الصورة نشطة، أصناف CSS هي `background` و `picture picture--active`.
 * عندما تكون الصورة غير نشطة، أصناف CSS هي `background background--active` و `picture`.
-متغير حالة قيمة منطقية (boolean) واحد كافي لتذكر ما إذا كانت نشطة. المهمة الأصلية كانت إزالة أو إضافة أصناف CSS. على أية حال، في React تحتاج لـ*تصف* ما تريد رؤيته فضلًا عن *تعديل* عناصر واجهة المستخدم. لذلك تحتاج لحساب كلا صنفيّ CSS اعتمادًا على الحالة الحالية. تحتاج أيضًا إلى [إيقاف الانتشار (propagation)](/learn/responding-to-events#stopping-propagation) بحيث لا يتم تسجيل النقر على الصورة كنقر على الخلفية. 
+متغير حالة قيمة منطقية (boolean) واحد يكفي لتذكر ما إذا كانت نشطة. المهمة الأصلية كانت إزالة أو إضافة أصناف CSS. على أية حال، في React تحتاج لـ*تصف* ما تريد رؤيته فضلًا عن *تعديل* عناصر واجهة المستخدم. لذلك تحتاج لحساب كلا صنفيّ CSS اعتمادًا على الحالة الحالية. تحتاج أيضًا إلى [إيقاف الانتشار (propagation)](/learn/responding-to-events#stopping-propagation) بحيث لا يتم تسجيل النقر على الصورة كنقر على الخلفية. 
 
 تأكد من أن هذا الإصدار يعمل عن طريق النقر على الصور وخارجها:
 
@@ -697,7 +698,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-ضع في الحسبان أنه إذا وصف جزئين مختلفين من JSX الشجرة نفسها، فتضمينهما (أول `<div>` → أول `<img>`) يجب أن يصطف. وإلا تغيّر `isActive` سوف يعيد إنشاء الشجرة بأكملها أدناه و [يعيد تعيين حالتها.](/learn/preserving-and-resetting-state) هذا هو السبب، إذا كان يتم إرجاع شجرة JSX مشابهة في كلا الحالتين، فمن الأفضل كتابتهما على كجزء واحد من JSX.
+ضع في الحسبان أنه إذا وصف جزئين مختلفين من JSX الشجرة نفسها، فتضمينهما (أول `<div>` ← أول `<img>`) يجب أن يصطف. وإلا تغيّر `isActive` سوف يعيد إنشاء الشجرة بأكملها أدناه و [يعيد تعيين حالتها.](/learn/preserving-and-resetting-state) هذا هو السبب، إذا كان يتم إرجاع شجرة JSX مشابهة في كلا الحالتين، فمن الأفضل كتابتهما كجزء واحد من JSX.
 
 </Solution>
 
@@ -793,18 +794,18 @@ lastNameInput.oninput = handleLastNameChange;
 
 <style>
 * { box-sizing: border-box; }
-body { font-family: sans-serif; margin: 20px; padding: 0; }
+body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 label { display: block; margin-bottom: 20px; }
 </style>
 ```
 
 </Sandpack>
 
-هذا النموذج يتغيّر بين وضعين: في وضع التعديل، ترى حقول الإدخال، وفي وضع المعاينة، ترى النتيجة فقط. عنوان الزر يتغيّر ما بين "عدّل" و"احفظ" اعتمادًا على الوضع الذي أنت عليه. عندما تقوم بتغيير حقول الإدخال، رسالة الترحيب في الأسفل يتم تحديثها للوقت الحالي.
+هذا النموذج يتغيّر بين وضعين: في وضع التعديل، ترى حقول الإدخال، وفي وضع المعاينة، ترى النتيجة فقط. عنوان الزر يتغيّر ما بين "عدّل" و"احفظ" اعتمادًا على الوضع الذي أنت عليه. عندما تقوم بتغيير حقول الإدخال، يتم تحديث رسالة الترحيب في الأسفل للوقت الحالي.
 
 مهمتك هي إعادة تنفيذها بواسطة React في الـsandbox أدناه. لضمان راحتك، تم تحويل التوصيف (markup) إلى JSX, لكن يتعين عليك جعلها تُظهر وتُخفي المدخلات كما تفعل الأصلية.
 
-تأكد من أنها تقوم بتحد النص في الأسفل أيضًا!
+تأكد من أنها تقوم بتحديث النص في الأسفل أيضًا!
 
 <Sandpack>
 
@@ -832,6 +833,7 @@ export default function EditProfile() {
 ```
 
 ```css
+body { direction: rtl; }
 label { display: block; margin-bottom: 20px; }
 ```
 
@@ -859,7 +861,7 @@ export default function EditProfile() {
       setIsEditing(!isEditing);
     }}>
       <label>
-        First name:{' '}
+        الاسم الأول:{' '}
         {isEditing ? (
           <input
             value={firstName}
@@ -872,7 +874,7 @@ export default function EditProfile() {
         )}
       </label>
       <label>
-        Last name:{' '}
+        اسم العائلة:{' '}
         {isEditing ? (
           <input
             value={lastName}
@@ -885,15 +887,16 @@ export default function EditProfile() {
         )}
       </label>
       <button type="submit">
-        {isEditing ? 'Save' : 'Edit'} Profile
+        {isEditing ? 'اخفظ' : 'عدّل'} الملف الشخصي
       </button>
-      <p><i>Hello, {firstName} {lastName}!</i></p>
+      <p><i>أهلًا، {firstName} {lastName}!</i></p>
     </form>
   );
 }
 ```
 
 ```css
+body { direction: rtl; }
 label { display: block; margin-bottom: 20px; }
 ```
 
@@ -995,7 +998,7 @@ lastNameInput.oninput = handleLastNameChange;
 
 <style>
 * { box-sizing: border-box; }
-body { font-family: sans-serif; margin: 20px; padding: 0; }
+body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl: }
 label { display: block; margin-bottom: 20px; }
 </style>
 ```
@@ -1004,7 +1007,7 @@ label { display: block; margin-bottom: 20px; }
 
 تصوّر لو أن React غير موجودة. هل يمكنك إعادة تصميم الكود بطريقة تجعل المنطق أقل هشاشة وأكثر مقاربة لنسخة React؟ كيف سيبدو لو كانت حالته بيّنة، كما هو الحال في React؟
 
-إذا كنت تواجه صعوبة في تحديد من أين تبدأ، فالمُلق أدناه يحتوي أغلب الهيكل معدًّا. لو بدأت من هنا، املئ المنطق المفقود داخل الدالة `updateDOM`. (راجع الكود الكود الأصلي عند الحاجة.)
+إذا كنت تواجه صعوبة في تحديد من أين تبدأ، فالمُلحق أدناه يحتوي أغلب الهيكل معدًّا. لو بدأت من هنا، املئ المنطق المفقود داخل الدالة `updateDOM`. (راجع الكود الكود الأصلي عند الحاجة.)
 
 <Sandpack>
 
@@ -1102,7 +1105,7 @@ lastNameInput.oninput = handleLastNameChange;
 
 <style>
 * { box-sizing: border-box; }
-body { font-family: sans-serif; margin: 20px; padding: 0; }
+body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 label { display: block; margin-bottom: 20px; }
 </style>
 ```
@@ -1221,14 +1224,14 @@ lastNameInput.oninput = handleLastNameChange;
 
 <style>
 * { box-sizing: border-box; }
-body { font-family: sans-serif; margin: 20px; padding: 0; }
+body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 label { display: block; margin-bottom: 20px; }
 </style>
 ```
 
 </Sandpack>
 
-الدالة `updateDOM` التي كتبتها تظهر ما تقوم به React تحت الستار عندم تقوم بتعيين الحالة. (مع ذلك، React تتجنب المس بالـ DOM لأجل الخصائص التي لم تتغير من أخر مرة تم تعيينها فيها.)
+الدالة `updateDOM` التي كتبتها تُظهر ما تقوم به React تحت الستار عندما تقوم بتعيين الحالة. (مع ذلك، React تتجنب المسّ بالـ DOM لأجل الخصائص التي لم تتغير من أخر مرة تم تعيينها فيها.)
 
 </Solution>
 
diff --git a/src/sidebarLearn.json b/src/sidebarLearn.json
index 56de0f4c4..e14e4a8dd 100644
--- a/src/sidebarLearn.json
+++ b/src/sidebarLearn.json
@@ -130,7 +130,7 @@
       "tags": ["intermediate"],
       "routes": [
         {
-          "title": "Reacting to Input with State",
+          "title": "الاستجابة للمدخلات باستخدام الحالة",
           "path": "/learn/reacting-to-input-with-state"
         },
         {

From dcd12d0e9ecc754536754ea6d41100bfdbb72141 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:41:56 +0300
Subject: [PATCH 07/19] Update
 src/content/learn/reacting-to-input-with-state.md

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index a18fbc5a3..ce32d9497 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: الاستجابة للمدخلات باستخدام الحالة
 
 <Intro>
 
-React توفر طريقة تصريحيّة (declarative) لتعديل واجهة المستخدم (UI). بدلًا من تعديل أجزاء منفردة من واجهة المستخدم مباشرةً، يمكنك وصف الحالات المختلفة التي يأخذها مكوّنك، والانتقال بينهم كاستجابة لمدخلات المستخدم. هذا مشابه لتصوّر المصمّمين عن واجهة المستخدم. 
+توفر React طريقة تصريحيّة (declarative) لتعديل واجهة المستخدم (UI). فبدلًا من تعديل أجزاء منفردة من واجهة المستخدم مباشرةً، يمكنك وصف الحالات المختلفة التي يأخذها مكوّنك، والانتقال بينهم كاستجابة لمدخلات المستخدم. هذا مشابه لتصوّر المصمّمين عن واجهة المستخدم. 
 
 
 </Intro>

From a77392e520831d0d36d14524899e1240d60932b2 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:44:48 +0300
Subject: [PATCH 08/19] Fix a typo

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index ce32d9497..6fd715e00 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -24,7 +24,7 @@ title: الاستجابة للمدخلات باستخدام الحالة
 * عندما تكتب شيئًا داخل النموذج، يصبح الزر "أرسل" **مفعلًا.**
 * عندما تضغط على "أرسل"، يصبح كلٌ من النموذج والزر **معطلا** و**يظهر** مؤشر التحميل.
 * لو نجح طلب الشبكة، يبدأ النموج **بالاختفاء،** و**تظهر** رسالة "شكرًا لك".
-* لو فشل طلب الشبكة،**تظهر** رسالة خطأٍ، ويصبح النموذج **مفعلًا** مجددا.
+* لو فشل طلب الشبكة، **تظهر** رسالة خطأٍ، ويصبح النموذج **مفعلًا** مجددا.
 
 في **البرمجة الأمرية (imperative programming)**، يتوافق ما ذُكر أعلاه مباشرة مع طريقة تطبيق التعاملات. عليك أن تكتب التعليمات التامّة لتعديل واجهة المستخدم معتمدًا على ما حصل للتوّ. إليك طريقة أخرى لتفكر في هذا الأمر: تخيل نفسك راكبًا إلى جانب أحدهم في سيارة مع إخباره في كل منعطف تلو الآخر عن وجهة الذهاب. 
 

From 464a131f40fed38c7b7c4f099a05db0c36c05719 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:46:06 +0300
Subject: [PATCH 09/19] Translation of (Reacting to input): Translate alt
 attribute

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 6fd715e00..82225bf42 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -28,7 +28,7 @@ title: الاستجابة للمدخلات باستخدام الحالة
 
 في **البرمجة الأمرية (imperative programming)**، يتوافق ما ذُكر أعلاه مباشرة مع طريقة تطبيق التعاملات. عليك أن تكتب التعليمات التامّة لتعديل واجهة المستخدم معتمدًا على ما حصل للتوّ. إليك طريقة أخرى لتفكر في هذا الأمر: تخيل نفسك راكبًا إلى جانب أحدهم في سيارة مع إخباره في كل منعطف تلو الآخر عن وجهة الذهاب. 
 
-<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="في سيارة يقودها شخص يبدو عليه القلق يمثل جافا سكريبت، يأمر أحد الركاب السائق بتنفيذ سلسلة من المنعطفات المعقدة للتنقل." />
 
 هو لا يعلم إلى أين تريد أن تذهب، هو يتبع أوامرك فقط. (ولو أنك أعطيته الاتجاهات الخاطئة، سوف ينتهي بك المطاف لوجهة خاطئة!) هذا يطلق عليه *أمري (imperative)* لأن عليك أن "تأمر" كل عنصر، بداية من مؤشر التحميل إلى الزر، مخبرًا الكمبيوتر عن *كيفية* تحديث واجهة المستخدم (UI).
 

From 359d500ec7ba172f0a0a9290aa4c8273e118256e Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:46:31 +0300
Subject: [PATCH 10/19] Fix a typo

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 82225bf42..f9f73bfc9 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -134,7 +134,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 
 تعديل واجهة المستخدم (UI) أمريًّا يعمل بشكل جيد كفاية للأمثلة المعزولة، ولكنه يصبح أكثر صعوبة بشكل استثنائي عندما تدير أنظمة أكثر تعقيدًا. تخيل تحديث صفحة مليئة بالنماذج المختلفة مثل هذه هنا. إضافة عنصر واجهة مستخدم جديد سيتطلب فحص كامل الكود الموجود بحرص للتأكد من أنك لم تقم بعمل خطأ (على سبيل المثال، نسيان إظهار أو إخفاء شيء ما).
 
-React صُنعت لحل هذه المشكلة. 
+صُنعت React لحل هذه المشكلة. 
 
 في React، لن تقوم بتعديل واجهة المستخدم مباشرة -- يعني أنك لن تقوم بتفعيل، تعطيل، إظهار، أو إخفاء مكوّنات مباشرة. بدلًا عن ذلك، سوف **تصف ما تريده أن يظهر،** و React سوف تدبر كيفية تحديث واجهة المستخدم. فكر في أخذ سيارة أجرة وإخبار السائق إلي أين تريد أنت تذهب بدلًا من إخباره إلي أين ينعطف. وظيفة السائق هي أن يوصلك إلى هناك، وربما قد يعرف اختصارات لم تأخذها أنت بالحُسبان.
 

From 18242ceaf94aac7f05b2548b47b416e72fd2e569 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:47:09 +0300
Subject: [PATCH 11/19] Translation of (Reacting to input): Fix

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index f9f73bfc9..906ed533d 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -152,7 +152,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 
 ### الخطوة 1: عيّن الحالات المرئية المختلفة لمكوّنك {/*step-1-identify-your-components-different-visual-states*/}
 
-في علوم الحاسب، ربما تسمع عن ["آلة الحالة (state machine)"](https://en.wikipedia.org/wiki/Finite-state_machine) كونها واحدة من ضمن "حالات" متعددة. إذا كنت تعمل مع مصمم، لربما رأيت نماذج تجريبية لـ"الحالات المرئية" المختلفة 
+في علوم الحاسب، ربما تسمع عن ["آلة الحالة (state machine)"](https://ar.wikipedia.org/wiki/%D8%A2%D9%84%D8%A9_%D9%85%D8%AD%D8%AF%D9%88%D8%AF%D8%A9_%D8%A7%D9%84%D8%AD%D8%A7%D9%84%D8%A7%D8%AA) كونها واحدة من ضمن "حالات" متعددة. إذا كنت تعمل مع مصمم، لربما رأيت نماذج تجريبية لـ"الحالات المرئية" المختلفة 
 
 أولًا، أنت تحتاج لتصوّر جميع "الحالات" المختلفة لواجهة المستخدم (UI) التي قد يراها المستخدم: 
 *  **فارغة**: النموذج يحتوي على زر "إرسال" معطل.

From aff6f6d713748b23696f8d1149a7322cbb21d80a Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:47:56 +0300
Subject: [PATCH 12/19] Translation of (Reacting to input): Translate alt
 attribute

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 906ed533d..4672a7ac8 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -138,7 +138,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 
 في React، لن تقوم بتعديل واجهة المستخدم مباشرة -- يعني أنك لن تقوم بتفعيل، تعطيل، إظهار، أو إخفاء مكوّنات مباشرة. بدلًا عن ذلك، سوف **تصف ما تريده أن يظهر،** و React سوف تدبر كيفية تحديث واجهة المستخدم. فكر في أخذ سيارة أجرة وإخبار السائق إلي أين تريد أنت تذهب بدلًا من إخباره إلي أين ينعطف. وظيفة السائق هي أن يوصلك إلى هناك، وربما قد يعرف اختصارات لم تأخذها أنت بالحُسبان.
 
-<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="في سيارة يقودها React، يطلب أحد الركاب نقله إلى مكان محدد على الخريطة. تكتشف React كيفية القيام بذلك." />
 
 ## التفكير في واجهة المستخدم (UI) تصريحيًا {/*thinking-about-ui-declaratively*/}
 

From efb649a58715640a14478c91a1b1de3c0a53a1d0 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:48:25 +0300
Subject: [PATCH 13/19] Fix a typo

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 4672a7ac8..4cc03c84d 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -161,7 +161,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; direction: rtl; }
 * **نجاح**: يتم عرض رسالة "شكرًا لك" بدلًا من النموذج.
 * **خطأ**: مثل حالة الكتابة، ولكن مع رسالة خطأ إضافية
 
-تمامًا مثل المصمم، سترغب في "تجربة" أو إنشاء "نماذج تجريبية" للحالات المختلفة قبل أن تضيف المنطق. على سبيل المثال، ها هو نموذج تجريبي للجزء المرئي فقط من النموذج. هذا النموذج التجريبي متحكم به بواسطة خاصيّة تدعى `statue` مع قيمة افتراضية `'empty'`:
+تمامًا مثل المصمم، سترغب في "تجربة" أو إنشاء "نماذج تجريبية" للحالات المختلفة قبل أن تضيف المنطق. على سبيل المثال، ها هو نموذج تجريبي للجزء المرئي فقط من النموذج. هذا النموذج التجريبي متحكم به بواسطة خاصيّة تدعى `status` مع قيمة افتراضية `'empty'`:
 
 <Sandpack>
 

From 426ee163b544184bb6cab188ceae53fafa5ae6ef Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:48:38 +0300
Subject: [PATCH 14/19] Fix a typo

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 4cc03c84d..82157b4b0 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -317,7 +317,7 @@ body { margin: 0; direction: rtl; }
 يمكنك تنشيط تحديثات الحالة كاستجابة إلى نوعين من المدخلات:
 
 * **مدخلات الإنسان،** مثل الضغط على زر، الكتابة في حقل، زيارة رابط.
-* **مدخلات الكمبيوتر،** مثل وصول رد الشبكة، استكمال المؤقت، تحميل الصورة.
+* **مدخلات الكمبيوتر،** مثل وصول رد الشبكة، أو استكمال المؤقت، أو تحميل الصورة.
 
 <IllustrationBlock>
   <Illustration caption="مدخلات الإنسان" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />

From 93aa3c8b725ff6a10c4264e0e8cbbd3b547836b5 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:49:03 +0300
Subject: [PATCH 15/19] Translation of (Reacting to input): Translate alt
 attributes

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 82157b4b0..f989332ab 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -321,7 +321,7 @@ body { margin: 0; direction: rtl; }
 
 <IllustrationBlock>
   <Illustration caption="مدخلات الإنسان" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
-  <Illustration caption="مدخلات الكمبيوتر" alt="Ones and zeroes." src="/images/docs/illustrations/i_inputs2.png" />
+  <Illustration caption="مدخلات الكمبيوتر" alt="آحاد وأصفار" src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
 في كلتا الحالتين، **يجب عليك تعيين [متغيرات الحالة (state variables)](/learn/state-a-components-memory#anatomy-of-usestate) لتُحدّث واجهة المستخدم (UI).** من أجل تطوير النموذج سوف تحتاج لتغيير الحالة كنتيجة لبعض من المدخلات المختلفة:

From a537b06601c745e81514718034f11e4be7759183 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:49:18 +0300
Subject: [PATCH 16/19] Translation of (Reacting to input): Translate alt
 attributes

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index f989332ab..a99579e26 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -341,7 +341,7 @@ body { margin: 0; direction: rtl; }
 
 <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="مخطط التدفق يتحرك من اليسار إلى اليمين مع 5 عناصر. العقدة الأولى المسماة 'فارغة' لها حافة واحدة تسمى 'بدء الكتابة' متصلة بالعقدة المسماة 'الكتابة'. تحتوي هذه العقدة على حافة واحدة تسمى 'اضغط إرسال' متصلة بعقدة تسمى 'إرسال'، والتي لها حافتان. الحافة'اليسرى تحمل علامة 'خطأ في الشبكة' وهي متصلة بعقدة تحمل اسم 'خطأ'. الحافة اليمنى تحمل علامة 'نجاح الشبكة' وتتصل بعقدة تحمل اسم 'النجاح'.">
 
 حالات النموذج
 

From b11aead447fa83c9a94f9f6e5ba1ccbf2ac902ad Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 06:51:50 +0300
Subject: [PATCH 17/19] Translation of (Reacting to input): Rephrasing

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index a99579e26..d32a156f0 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -351,7 +351,7 @@ body { margin: 0; direction: rtl; }
 
 ### الخطوة 3: مثّل الحالة في الذاكرة باستخدام `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
 
-يلي ذلك ستحتاج لتمثّل الحالات المرئية لمكوّنك في الذاكرة باستخدام [`useState`.](/reference/react/useState) البساطة هي المفتاح: كل قطعة من الحالة هي "قطعة متحركة"، و**التقليل من "القطع المتحركة" قدر الإمكان هذا ما تريده.** ;كثرة التعقيدات تؤدي إلى كثرة الأخطاء!
+بعد ذلك ستحتاج لتمثّل الحالات المرئية لمكوّنك في الذاكرة باستخدام [`useState`.](/reference/react/useState) البساطة هي المفتاح: كل قطعة من الحالة هي "قطعة متحركة"، **وبالـتأكيد تريد تقليل "القطع المتحركة" قدر الإمكان.** ;كثرة التعقيدات تؤدي إلى كثرة الأخطاء!
 
 ابدأ بالحالة التي *لا بدّ* من وجودها. على سبيل المثال، سوف تحتاج لتخزين الإجابة `answer` للمدخل، والخطأ `error` (لو وُجد) لتخزين آخر خطأ: 
 

From 050ca6513d7173fd73fb4b3e08cf07378cd58fab Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 07:01:22 +0300
Subject: [PATCH 18/19] Translation of (Reacting to input): Fix a typo

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index d32a156f0..68f0069c9 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -316,7 +316,7 @@ body { margin: 0; direction: rtl; }
 
 يمكنك تنشيط تحديثات الحالة كاستجابة إلى نوعين من المدخلات:
 
-* **مدخلات الإنسان،** مثل الضغط على زر، الكتابة في حقل، زيارة رابط.
+* **مدخلات الإنسان،** مثل الضغط على زر، أو الكتابة في حقل، أو زيارة رابط.
 * **مدخلات الكمبيوتر،** مثل وصول رد الشبكة، أو استكمال المؤقت، أو تحميل الصورة.
 
 <IllustrationBlock>

From d654195755412886ad52787932a89433dba61ab0 Mon Sep 17 00:00:00 2001
From: Ahmed Shazly <99288580+Rumbustious@users.noreply.github.com>
Date: Tue, 10 Oct 2023 07:01:33 +0300
Subject: [PATCH 19/19] Translation of (Reacting to input): Translate alt
 attribute

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
---
 src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md
index 68f0069c9..3144fe729 100644
--- a/src/content/learn/reacting-to-input-with-state.md
+++ b/src/content/learn/reacting-to-input-with-state.md
@@ -320,7 +320,7 @@ body { margin: 0; direction: rtl; }
 * **مدخلات الكمبيوتر،** مثل وصول رد الشبكة، أو استكمال المؤقت، أو تحميل الصورة.
 
 <IllustrationBlock>
-  <Illustration caption="مدخلات الإنسان" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
+  <Illustration caption="مدخلات الإنسان" alt="إصبع" src="/images/docs/illustrations/i_inputs1.png" />
   <Illustration caption="مدخلات الكمبيوتر" alt="آحاد وأصفار" src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>