diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md
index 4241a04dd..43bedc863 100644
--- a/content/docs/faq-structure.md
+++ b/content/docs/faq-structure.md
@@ -1,18 +1,19 @@
 ---
 id: faq-structure
-title: File Structure
+title: بنية ملفات المشروع
 permalink: docs/faq-structure.html
 layout: docs
 category: FAQ
 ---
 
-### Is there a recommended way to structure React projects? {#is-there-a-recommended-way-to-structure-react-projects}
+### هل هناك طريقة مفضّلة لترتيب بنية ملفّات مشاريع React؟ {#is-there-a-recommended-way-to-structure-react-projects}
 
-React doesn't have opinions on how you put files into folders. That said there are a few common approaches popular in the ecosystem you may want to consider.
+ليس هنالك رأي لمكتبة React حول كيفيّة وضع الملفّات ضمن المجلدات. ولكن يُقال أنّه هناك بعض المقاربات الشائعة المستخدمة التي قد تأخذها بعين الاعتبار.
 
-#### Grouping by features or routes {#grouping-by-features-or-routes}
 
-One common way to structure projects is locate CSS, JS, and tests together inside folders grouped by feature or route.
+#### التجميع عن طريق الميزات أو الطرق (routes) {#grouping-by-features-or-routes}
+
+إحدى الطرق الشائعة لترتيب بنية المشاريع هي وضع ملفّات CSS، و JavaScript، والاختبارات معًا بداخل مجلّدات مُجمَّعة حس الميزة أو الطريق (route):
 
 ```
 common/
@@ -35,11 +36,12 @@ profile/
   ProfileAPI.js
 ```
 
-The definition of a "feature" is not universal, and it is up to you to choose the granularity. If you can't come up with a list of top-level folders, you can ask the users of your product what major parts it consists of, and use their mental model as a blueprint.
+تعريف الميزة ليس عالميًّا، ولك حرية قرار اختيار التقسيمات. إن لم تستطع أن تأتي بقائمة بالمجلّدات ذات المستوى الأعلى، فبإمكانك سؤال مستخدمي منتجك حول الأجزاء الأهم التي يتكوّن منها واستخدام النموذج الذي أخبروك به كمخطط.
+
 
-#### Grouping by file type {#grouping-by-file-type}
+#### التجميع عن طريق نوع الملفّات {#grouping-by-file-type}
 
-Another popular way to structure projects is to group similar files together, for example:
+من الطرق الأخرى الشائعة لترتيب بنية ملفّات المشروع هي تجميع الملفّات المتشابهة معًا، على سبيل المثال:
 
 ```
 api/
@@ -59,16 +61,18 @@ components/
   ProfileHeader.css
 ```
 
-Some people also prefer to go further, and separate components into different folders depending on their role in the application. For example, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) is a design methodology built on this principle. Remember that it's often more productive to treat such methodologies as helpful examples rather than strict rules to follow.
+يفضّل بعض الأشخاص الذهاب بعيدًا أكثر من ذلك وفصل المكوّنات في مجلّدات مختلفة بناءً على دورها في التطبيق. على سبيل المثال, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) هي منهجيّة تصميم مبنيّة على هذا المبدأ. تذكّر أنّك ستكون أكثر إنتاجيّة عندما تتعامل مع هذه المنهجيّات كأمثلة مساعدة بدلًا من قواعد صارمة يجب اتباعها.
+
+#### تجنّب الكثير من التداخل {#avoid-too-much-nesting}
+
+هناك العديد من الصعوبات المرتبطة بالتداخل العميق للمجلّدات في مشاريع JavaScript، حيث يُصبِح من الأصعب كتابة استيرادات نسبيّة بينها، أو تحديث هذه الاستيرادات عند إزالة الملفّات. ما لم يكن هنالك سبب مقنع جدًّا لاستخدام بنية مجلّدات عميقة، فانظر في تحديد نفسك إلى ثلاثة أو أربعة مجلّدات متداخلة كحد أقصى ضمن المشروع الواحد. هذه مجرّد توصيات طبعًا وقد لا يكون لها علاقة بمشروعك.
 
-#### Avoid too much nesting {#avoid-too-much-nesting}
 
-There are many pain points associated with deep directory nesting in JavaScript projects. It becomes harder to write relative imports between them, or to update those imports when the files are moved. Unless you have a very compelling reason to use a deep folder structure, consider limiting yourself to a maximum of three or four nested folders within a single project. Of course, this is only a recommendation, and it may not be relevant to your project.
+#### لا تفرط في التفكير بهذا الموضوع {#dont-overthink-it}
 
-#### Don't overthink it {#dont-overthink-it}
+إن كنت قد بدأت للتو بالمشروع, [فلا تأخذ أكثر من خمسة دقائق](https://en.wikipedia.org/wiki/Analysis_paralysis) اختيار بنية الملفّات. اختر أي من الطرق المذكورة في الأعلى (أو استخدم طريقتك) وابدأ بكتابة الشيفرة! على الأغلب أنك ستعيد النظر في الموضوع على أيّة حال بعد أن تكتب بعض الشيفرة.
 
-If you're just starting a project, [don't spend more than five minutes](https://en.wikipedia.org/wiki/Analysis_paralysis) on choosing a file structure. Pick any of the above approaches (or come up with your own) and start writing code! You'll likely want to rethink it anyway after you've written some real code.
+إذا كنت تشعر بأنّك عالق تمامًا، فابدأ بالاحتفاظ بالملفّات في مجلّد واحد، وبالنهاية ستكبر الملفّات لدرجة ستحتاج إلى فصل بعض الملفّات عن البقيّة. في ذلك الوقت سيكون لديك معرفة كافية لكي تدرك أي ملفّات تحتاج إلى تحريرها غالبًا معًا. بشكلٍ عام من الجيد الاحتفاظ بالملفّات التي تتغيّر عادةً قريبة من بعضها البعض. يُدعى هذا المبدأ بالرصف "colocation".
 
-If you feel completely stuck, start by keeping all files in a single folder. Eventually it will grow large enough that you will want to separate some files from the rest. By that time you'll have enough knowledge to tell which files you edit together most often. In general, it is a good idea to keep files that often change together close to each other. This principle is called "colocation".
+عندما تكبر المشاريع ستستخدم عادةً خليط من المقاربات المذكورة بالأعلى. لذا لن يكون من الهام كثيرًا اختيار الطريقة الصحيحة منذ البداية.
 
-As projects grow larger, they often use a mix of both of the above approaches in practice. So choosing the "right" one in the beginning isn't very important.