+
+ | النوع |
+ اللغة |
+ المكتبة |
+ المحولات |
+
+
+ | قاعدة بيانات |
+ Ruby/Rails |
+ ActiveRecord |
+ MySQL, PostgreSQL, SQLite |
+
+
+ | طابور |
+ Python/Django |
+ Celery |
+ RabbitMQ, Beanstalkd, Redis |
+
+
+ | ذاكرة تخزين مؤقت |
+ Ruby/Rails |
+ ActiveSupport::Cache |
+ Memory, filesystem, Memcached |
+
+
+
+يجد المطورون أحيانًا جاذبية كبيرة في استخدام خدمة مساندة خفيفة الوزن في بيئاتهم المحلية، بينما سيتم استخدام خدمة مساندة أكثر جدية وقوة في الإنتاج. على سبيل المثال، استخدام SQLite محليًا و PostgreSQL في الإنتاج؛ أو ذاكرة العملية المحلية للتخزين المؤقت في التطوير و Memcached في الإنتاج.
+
+**يقاوم مطور العوامل الاثني عشر الرغبة في استخدام خدمات مساندة مختلفة بين التطوير والإنتاج**، حتى عندما تجرد المحولات نظريًا أي اختلافات في الخدمات المساندة. تعني الاختلافات بين الخدمات المساندة أن عدم توافق صغير يظهر، مما يتسبب في فشل الشيفرة التي عملت واجتازت الاختبارات في التطوير أو التجربة في الإنتاج. تخلق هذه الأنواع من الأخطاء احتكاكًا يثبط النشر المستمر. تكون تكلفة هذا الاحتكاك والتثبيط اللاحق للنشر المستمر عالية للغاية عند النظر إليها بشكل إجمالي على مدار عمر التطبيق.
+
+الخدمات المحلية خفيفة الوزن أقل إقناعًا مما كانت عليه من قبل. الخدمات المساندة الحديثة مثل Memcached و PostgreSQL و RabbitMQ ليس من الصعب تثبيتها وتشغيلها بفضل أنظمة الحزم الحديثة، مثل [Homebrew](http://mxcl.github.com/homebrew/) و [apt-get](https://help.ubuntu.com/community/AptGet/Howto). بدلاً من ذلك، تسمح أدوات التزويد التعريفية مثل [Chef](http://www.opscode.com/chef/) و [Puppet](http://docs.puppetlabs.com/) جنبًا إلى جنب مع البيئات الافتراضية خفيفة الوزن مثل [Docker](https://www.docker.com/) و [Vagrant](http://vagrantup.com/) للمطورين بتشغيل بيئات محلية تقارب بيئات الإنتاج بشكل وثيق. تكلفة تثبيت واستخدام هذه الأنظمة منخفضة مقارنة بفائدة التطابق بين التطوير والإنتاج والنشر المستمر.
+
+لا تزال المحولات لخدمات مساندة مختلفة مفيدة، لأنها تجعل النقل إلى خدمات مساندة جديدة غير مؤلم نسبيًا. ولكن يجب أن تستخدم جميع عمليات نشر التطبيق (بيئات المطورين، التجربة، الإنتاج) نفس النوع والإصدار لكل من الخدمات المساندة.
diff --git a/content/ar/disposability.md b/content/ar/disposability.md
new file mode 100644
index 00000000..a1db8c11
--- /dev/null
+++ b/content/ar/disposability.md
@@ -0,0 +1,12 @@
+## IX. القابلية للاستبدال (Disposability)
+### تعظيم المتانة مع بدء التشغيل السريع والإغلاق السلس
+
+**[عمليات](./processes) تطبيق العوامل الاثني عشر *قابلة للاستبدال*، مما يعني أنه يمكن بدؤها أو إيقافها في لحظة.** هذا يسهل التوسع المرن السريع، والنشر السريع لتغييرات [الشيفرة](./codebase) أو [الإعدادات](./config)، ومتانة عمليات نشر الإنتاج.
+
+يجب أن تسعى العمليات جاهدة **لتقليل وقت بدء التشغيل**. بشكل مثالي، تستغرق العملية بضع ثوانٍ من وقت تنفيذ أمر الإطلاق حتى تصبح العملية جاهزة ومستعدة لاستقبال الطلبات أو الوظائف. يوفر وقت بدء التشغيل القصير مزيدًا من الرشاقة لعملية [الإصدار](./build-release-run) والتوسع؛ ويساعد على المتانة، لأن مدير العمليات يمكنه نقل العمليات بسهولة أكبر إلى أجهزة مادية جديدة عند الاقتضاء.
+
+تغلق العمليات **بشكل سلس عندما تتلقى إشارة [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** من مدير العمليات. بالنسبة لعملية الويب، يتم تحقيق الإغلاق السلس عن طريق التوقف عن الاستماع على منفذ الخدمة (وبالتالي رفض أي طلبات جديدة)، والسماح بإنهاء أي طلبات حالية، ثم الخروج. ضمني في هذا النموذج هو أن طلبات HTTP قصيرة (لا تزيد عن بضع ثوانٍ)، أو في حالة الاستطلاع الطويل (long polling)، يجب على العميل محاولة إعادة الاتصال بسلاسة عند فقدان الاتصال.
+
+بالنسبة لعملية العامل (worker)، يتم تحقيق الإغلاق السلس عن طريق إعادة المهمة الحالية إلى طابور العمل. على سبيل المثال، في [RabbitMQ](http://www.rabbitmq.com/) يمكن للعامل إرسال [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack)؛ في [Beanstalkd](https://beanstalkd.github.io)، تتم إعادة المهمة إلى الطابور تلقائيًا كلما قطع العامل الاتصال. الأنظمة القائمة على القفل مثل [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) تحتاج إلى التأكد من تحرير قفلها على سجل المهمة. ضمني في هذا النموذج هو أن جميع المهام [reentrant](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29)، وهو ما يتم تحقيقه عادةً عن طريق تغليف النتائج في معاملة، أو جعل العملية [idempotent (قابلة للتكرار بأمان)](http://en.wikipedia.org/wiki/Idempotence).
+
+يجب أن تكون العمليات أيضًا **متينة ضد التوقف المفاجئ**، في حالة حدوث فشل في الأجهزة الأساسية. في حين أن هذا أقل شيوعًا بكثير من الإغلاق السلس باستخدام `SIGTERM`، إلا أنه لا يزال يمكن أن يحدث. النهج الموصى به هو استخدام خلفية طابور قوية، مثل Beanstalkd، التي تعيد المهام إلى الطابور عندما يقطع العملاء الاتصال أو تنتهي مهلة الاتصال. في كلتا الحالتين، تم تصميم تطبيق العوامل الاثني عشر للتعامل مع الإنهاءات غير المتوقعة وغير السلسة. [التصميم القائم على الانهيار فقط (Crash-only design)](http://lwn.net/Articles/191059/) يأخذ هذا المفهوم إلى [نتيجته المنطقية](http://docs.couchdb.org/en/latest/intro/overview.html).
diff --git a/content/ar/intro.md b/content/ar/intro.md
new file mode 100644
index 00000000..7224faa3
--- /dev/null
+++ b/content/ar/intro.md
@@ -0,0 +1,12 @@
+مقدمة
+============
+
+في العصر الحديث، يتم تقديم البرمجيات عادة كخدمة: تسمى *تطبيقات الويب*، أو *البرمجيات كخدمة*. تطبيق "العوامل الاثني عشر" هو منهجية لبناء تطبيقات "البرمجيات كخدمة" والتي:
+
+* تستخدم صيغ **تعريفية** لأتمتة الإعداد، لتقليل الوقت والتكلفة للمطورين الجدد الذين ينضمون إلى المشروع؛
+* لديها **عقد واضح** مع نظام التشغيل الأساسي، مما يوفر **أقصى درجات قابلية النقل** بين بيئات التنفيذ؛
+* مناسبة **للنشر** على **المنصات السحابية** الحديثة، مما يلغي الحاجة إلى الخوادم وإدارة الأنظمة؛
+* **تقلل الاختلاف** بين بيئة التطوير والإنتاج، مما يتيح **النشر المستمر** لأقصى قدر من المرونة؛
+* ويمكنها **التوسع** دون تغييرات كبيرة في الأدوات أو البنية التحتية أو ممارسات التطوير.
+
+يمكن تطبيق منهجية "العوامل الاثني عشر" على التطبيقات المكتوبة بأي لغة برمجة، والتي تستخدم أي مجموعة من الخدمات المساندة (قاعدة بيانات، طابور، ذاكرة مؤقتة، إلخ).
diff --git a/content/ar/logs.md b/content/ar/logs.md
new file mode 100644
index 00000000..3779cac6
--- /dev/null
+++ b/content/ar/logs.md
@@ -0,0 +1,16 @@
+## XI. السجلات (Logs)
+### التعامل مع السجلات كتدفقات للأحداث
+
+توفر *السجلات* رؤية لسلوك التطبيق الجاري تشغيله. في البيئات القائمة على الخادم، عادة ما يتم كتابتها في ملف على القرص ("ملف سجل")؛ ولكن هذا مجرد تنسيق إخراج.
+
+السجلات هي [تدفق](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) لأحداث مجمعة ومرتبة زمنياً تم جمعها من تدفقات الإخراج لجميع العمليات الجارية والخدمات المساندة. السجلات في شكلها الخام هي عادة تنسيق نصي بحدث واحد في كل سطر (على الرغم من أن تتبعات المكدس (stack traces) من الاستثناءات قد تمتد لعدة أسطر). ليس للسجلات بداية أو نهاية ثابتة، ولكنها تتدفق باستمرار طالما أن التطبيق يعمل.
+
+**لا يهتم تطبيق العوامل الاثني عشر أبدًا بتوجيه أو تخزين تدفق الإخراج الخاص به.** لا ينبغي أن يحاول الكتابة إلى ملفات السجل أو إدارتها. بدلاً من ذلك، تكتب كل عملية جارية تدفق أحداثها، غير مخزن مؤقتًا، إلى `stdout`. أثناء التطوير المحلي، سيعرض المطور هذا التدفق في مقدمة طرفيته (terminal) لمراقبة سلوك التطبيق.
+
+في عمليات نشر التجربة أو الإنتاج، سيتم التقاط تدفق كل عملية بواسطة بيئة التنفيذ، وجمعها مع جميع التدفقات الأخرى من التطبيق، وتوجيهها إلى وجهة نهائية واحدة أو أكثر للعرض والأرشفة طويلة المدى. وجهات الأرشفة هذه ليست مرئية أو قابلة للتكوين بواسطة التطبيق، وبدلاً من ذلك تتم إدارتها بالكامل بواسطة بيئة التنفيذ. تتوفر أجهزة توجيه السجلات مفتوحة المصدر (مثل [Logplex](https://github.com/heroku/logplex) و [Fluentd](https://github.com/fluent/fluentd)) لهذا الغرض.
+
+يمكن توجيه تدفق الأحداث لتطبيق ما إلى ملف، أو مشاهدته عبر التتبع في الوقت الفعلي في محطة طرفية. الأهم من ذلك، يمكن إرسال التدفق إلى نظام فهرسة وتحليل السجلات مثل [Splunk](http://www.splunk.com/)، أو نظام تخزين بيانات للأغراض العامة مثل [Hadoop/Hive](http://hive.apache.org/). تسمح هذه الأنظمة بقوة ومرونة كبيرة لفحص سلوك التطبيق بمرور الوقت، بما في ذلك:
+
+* العثور على أحداث محددة في الماضي.
+* الرسوم البيانية واسعة النطاق للاتجاهات (مثل عدد الطلبات في الدقيقة).
+* التنبيه النشط وفقًا للاستدلالات التي يحددها المستخدم (مثل تنبيه عندما تتجاوز كمية الأخطاء في الدقيقة عتبة معينة).
diff --git a/content/ar/port-binding.md b/content/ar/port-binding.md
new file mode 100644
index 00000000..c575ca91
--- /dev/null
+++ b/content/ar/port-binding.md
@@ -0,0 +1,14 @@
+## VII. ربط المنفذ (Port binding)
+### تصدير الخدمات عبر ربط المنفذ
+
+يتم تنفيذ تطبيقات الويب أحيانًا داخل حاوية خادم ويب. على سبيل المثال، قد تعمل تطبيقات PHP كوحدة نمطية داخل [Apache HTTPD](http://httpd.apache.org/)، أو قد تعمل تطبيقات Java داخل [Tomcat](http://tomcat.apache.org/).
+
+**تطبيق العوامل الاثني عشر قائم بذاته تمامًا** ولا يعتمد على حقن وقت التشغيل لخادم ويب في بيئة التنفيذ لإنشاء خدمة موجهة للويب. يقوم تطبيق الويب **بتصدير HTTP كخدمة عن طريق الربط بمنفذ**، والاستماع إلى الطلبات الواردة على ذلك المنفذ.
+
+في بيئة تطوير محلية، يزور المطور عنوان URL للخدمة مثل `http://localhost:5000/` للوصول إلى الخدمة التي يصدرها تطبيقه. في النشر، تتعامل طبقة التوجيه مع توجيه الطلبات من اسم مضيف يواجه الجمهور إلى عمليات الويب المرتبطة بالمنفذ.
+
+يتم تنفيذ هذا عادةً باستخدام [إعلان الاعتمادية](./dependencies) لإضافة مكتبة خادم ويب إلى التطبيق، مثل [Tornado](http://www.tornadoweb.org/) لـ Python، أو [Thin](http://code.macournoyer.com/thin/) لـ Ruby، أو [Jetty](http://www.eclipse.org/jetty/) لـ Java وغيرها من اللغات المستندة إلى JVM. يحدث هذا بالكامل في *مساحة المستخدم*، أي داخل شيفرة التطبيق. العقد مع بيئة التنفيذ هو الربط بمنفذ لخدمة الطلبات.
+
+HTTP ليست الخدمة الوحيدة التي يمكن تصديرها عن طريق ربط المنفذ. يمكن تشغيل أي نوع تقريبًا من برامج الخادم عبر ربط عملية بمنفذ وانتظار الطلبات الواردة. تشمل الأمثلة [ejabberd](http://www.ejabberd.im/) (الذي يتحدث [XMPP](http://xmpp.org/))، و [Redis](http://redis.io/) (الذي يتحدث [بروتوكول Redis](http://redis.io/topics/protocol)).
+
+لاحظ أيضًا أن نهج ربط المنفذ يعني أن تطبيقًا واحدًا يمكن أن يصبح [الخدمة المساندة](./backing-services) لتطبيق آخر، من خلال توفير عنوان URL للتطبيق المساند كرابط مورد في [الإعدادات](./config) للتطبيق المستهلك.
diff --git a/content/ar/processes.md b/content/ar/processes.md
new file mode 100644
index 00000000..0978dbce
--- /dev/null
+++ b/content/ar/processes.md
@@ -0,0 +1,14 @@
+## VI. العمليات (Processes)
+### تنفيذ التطبيق كعملية واحدة أو أكثر عديمة الحالة
+
+يتم تنفيذ التطبيق في بيئة التنفيذ كعملية واحدة أو أكثر من *العمليات*.
+
+في أبسط الحالات، تكون الشيفرة عبارة عن برنامج نصي مستقل، وتكون بيئة التنفيذ هي الكمبيوتر المحمول المحلي للمطور مع وقت تشغيل لغة مثبت، ويتم إطلاق العملية عبر سطر الأوامر (على سبيل المثال، `python my_script.py`). على الطرف الآخر من الطيف، قد تستخدم عملية نشر الإنتاج لتطبيق متطور العديد من [أنواع العمليات، التي يتم إنشاء مثيل لها في صفر أو أكثر من العمليات قيد التشغيل](./concurrency).
+
+**عمليات العوامل الاثني عشر عديمة الحالة و [لا تشارك شيئًا](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** أي بيانات تحتاج إلى الاستمرار يجب تخزينها في [خدمة مساندة](./backing-services) ذات حالة، عادة ما تكون قاعدة بيانات.
+
+يمكن استخدام مساحة الذاكرة أو نظام الملفات للعملية كذاكرة تخزين مؤقت وجيزة لمعاملة واحدة. على سبيل المثال، تنزيل ملف كبير، والعمل عليه، وتخزين نتائج العملية في قاعدة البيانات. لا يفترض تطبيق العوامل الاثني عشر أبدًا أن أي شيء مخزن مؤقتًا في الذاكرة أو على القرص سيكون متاحًا في طلب أو وظيفة مستقبلية -- مع تشغيل العديد من العمليات من كل نوع، هناك احتمالات كبيرة بأن يتم خدمة طلب مستقبلي بواسطة عملية مختلفة. حتى عند تشغيل عملية واحدة فقط، فإن إعادة التشغيل (التي يتم تشغيلها بواسطة نشر الشيفرة، أو تغيير الإعدادات، أو قيام بيئة التنفيذ بنقل العملية إلى موقع فعلي مختلف) ستؤدي عادةً إلى مسح كل الحالة المحلية (مثل الذاكرة ونظام الملفات).
+
+تستخدم أدوات حزم الأصول مثل [django-assetpackager](http://code.google.com/p/django-assetpackager/) نظام الملفات كذاكرة تخزين مؤقت للأصول المجمعة. يفضل تطبيق العوامل الاثني عشر القيام بهذا التجميع أثناء [مرحلة البناء](/build-release-run). يمكن تكوين أدوات حزم الأصول مثل [Jammit](http://documentcloud.github.io/jammit/) و [Rails asset pipeline](http://ryanbigg.com/guides/asset_pipeline.html) لحزم الأصول أثناء مرحلة البناء.
+
+تعتمد بعض أنظمة الويب على ["الجلسات الثابتة"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) (sticky sessions) -- أي تخزين بيانات جلسة المستخدم في ذاكرة عملية التطبيق وتوقع توجيه الطلبات المستقبلية من نفس الزائر إلى نفس العملية. الجلسات الثابتة هي انتهاك للعوامل الاثني عشر ويجب عدم استخدامها أو الاعتماد عليها أبدًا. تعد بيانات حالة الجلسة مرشحًا جيدًا لمخزن بيانات يوفر انتهاء الصلاحية الزمني، مثل [Memcached](http://memcached.org/) أو [Redis](http://redis.io/).
diff --git a/content/ar/toc.md b/content/ar/toc.md
new file mode 100644
index 00000000..8727f2c4
--- /dev/null
+++ b/content/ar/toc.md
@@ -0,0 +1,38 @@
+العوامل الاثني عشر
+==================
+
+## [I. قاعدة الشيفرة (Codebase)](./codebase)
+### قاعدة شيفرة واحدة يتم تتبعها في أنظمة إدارة الإصدارات، والعديد من عمليات النشر
+
+## [II. الاعتماديات (Dependencies)](./dependencies)
+### الإعلان عن الاعتماديات وعزلها بشكل صريح
+
+## [III. الإعدادات (Config)](./config)
+### تخزين الإعدادات في البيئة
+
+## [IV. الخدمات المساندة (Backing services)](./backing-services)
+### معاملة الخدمات المساندة كموارد مرفقة
+
+## [V. البناء، الإصدار، التشغيل (Build, release, run)](./build-release-run)
+### الفصل الصارم بين مراحل البناء والتشغيل
+
+## [VI. العمليات (Processes)](./processes)
+### تنفيذ التطبيق كعملية واحدة أو أكثر عديمة الحالة
+
+## [VII. ربط المنفذ (Port binding)](./port-binding)
+### تصدير الخدمات عبر ربط المنفذ
+
+## [VIII. التزامن (Concurrency)](./concurrency)
+### التوسع عبر نموذج العمليات
+
+## [IX. القابلية للاستبدال (Disposability)](./disposability)
+### تعظيم المتانة مع بدء التشغيل السريع والإغلاق السلس
+
+## [X. التطابق بين التطوير والإنتاج (Dev/prod parity)](./dev-prod-parity)
+### إبقاء بيئات التطوير، والتجربة، والإنتاج متشابهة قدر الإمكان
+
+## [XI. السجلات (Logs)](./logs)
+### التعامل مع السجلات كتدفقات للأحداث
+
+## [XII. عمليات الإدارة (Admin processes)](./admin-processes)
+### تشغيل مهام الإدارة/الصيانة كعمليات لمرة واحدة
diff --git a/content/ar/who.md b/content/ar/who.md
new file mode 100644
index 00000000..60e030c1
--- /dev/null
+++ b/content/ar/who.md
@@ -0,0 +1,4 @@
+من يجب أن يقرأ هذا المستند؟
+==============================
+
+أي مطور يقوم ببناء تطبيقات تعمل كخدمة. مهندسو العمليات الذين يقومون بنشر أو إدارة مثل هذه التطبيقات.
diff --git a/locales/ar.yml b/locales/ar.yml
new file mode 100644
index 00000000..76cdaebc
--- /dev/null
+++ b/locales/ar.yml
@@ -0,0 +1,7 @@
+ar:
+ # Name of language listed in locales menu
+ language: العربية (ar)
+
+ # A text to make known that the article is a translation not an original.
+ # Empty for English, original.
+ translation: (النسخة العربية)
+
+يمكن إرفاق الموارد وفصلها عن عمليات النشر حسب الرغبة. على سبيل المثال، إذا كانت قاعدة بيانات التطبيق تعاني من مشاكل بسبب مشكلة في الأجهزة، فقد يقوم مسؤول التطبيق بتشغيل خادم قاعدة بيانات جديد تمت استعادته من نسخة احتياطية حديثة. يمكن فصل قاعدة بيانات الإنتاج الحالية، وإرفاق قاعدة البيانات الجديدة -- كل ذلك دون أي تغييرات في الشيفرة البرمجية.
diff --git a/content/ar/build-release-run.md b/content/ar/build-release-run.md
new file mode 100644
index 00000000..6f1af0e6
--- /dev/null
+++ b/content/ar/build-release-run.md
@@ -0,0 +1,18 @@
+## V. البناء، الإصدار، التشغيل (Build, release, run)
+### الفصل الصارم بين مراحل البناء والتشغيل
+
+يتم تحويل [قاعدة الشيفرة](./codebase) إلى عملية نشر (غير تطويرية) عبر ثلاث مراحل:
+
+* *مرحلة البناء* هي تحويل يحول مستودع الشيفرة إلى حزمة قابلة للتنفيذ تُعرف باسم *build* (البناء). باستخدام نسخة من الشيفرة عند تعديل محدد (commit) بواسطة عملية النشر، تجلب مرحلة البناء [الاعتماديات](./dependencies) وتقوم بتجميع الثنائيات والأصول.
+* تأخذ *مرحلة الإصدار* البناء الذي أنتجته مرحلة البناء وتجمعه مع [الإعدادات](./config) الحالية لعملية النشر. يحتوي *الإصدار* الناتج على كل من البناء والإعدادات ويكون جاهزًا للتنفيذ الفوري في بيئة التنفيذ.
+* *مرحلة التشغيل* (المعروفة أيضًا باسم "وقت التشغيل") تشغل التطبيق في بيئة التنفيذ، عن طريق إطلاق مجموعة من [عمليات](./processes) التطبيق مقابل إصدار محدد.
+
+
+
+**يستخدم تطبيق العوامل الاثني عشر فصلاً صارمًا بين مراحل البناء والإصدار والتشغيل.** على سبيل المثال، من المستحيل إجراء تغييرات على الشيفرة في وقت التشغيل، حيث لا توجد طريقة لنقل تلك التغييرات مرة أخرى إلى مرحلة البناء.
+
+توفر أدوات النشر عادةً أدوات إدارة الإصدار، وأبرزها القدرة على التراجع (roll back) إلى إصدار سابق. على سبيل المثال، تخزن أداة النشر [Capistrano](https://github.com/capistrano/capistrano/wiki) الإصدارات في دليل فرعي يسمى `releases`، حيث يكون الإصدار الحالي عبارة عن رابط رمزي (symlink) لدليل الإصدار الحالي. يجعل أمر `rollback` الخاص بها من السهل التراجع بسرعة إلى إصدار سابق.
+
+يجب أن يكون لكل إصدار دائمًا معرف إصدار فريد، مثل الطابع الزمني للإصدار (مثل `2011-04-06-20:32:17`) أو رقم متزايد (مثل `v100`). الإصدارات عبارة عن سجل للإضافة فقط ولا يمكن تغيير الإصدار بمجرد إنشائه. أي تغيير يجب أن ينشئ إصدارًا جديدًا.
+
+يبدأ مطورو التطبيق عمليات البناء كلما تم نشر شيفرة جديدة. تنفيذ وقت التشغيل، على العكس من ذلك، يمكن أن يحدث تلقائيًا في حالات مثل إعادة تشغيل الخادم، أو إعادة تشغيل عملية معطلة بواسطة مدير العمليات. لذلك، يجب إبقاء مرحلة التشغيل بأقل عدد ممكن من الأجزاء المتحركة، حيث يمكن أن تتسبب المشاكل التي تمنع التطبيق من التشغيل في تعطله في منتصف الليل عندما لا يكون هناك مطورون متاحون. يمكن أن تكون مرحلة البناء أكثر تعقيدًا، حيث تكون الأخطاء دائمًا في المقدمة للمطور الذي يقود عملية النشر.
diff --git a/content/ar/codebase.md b/content/ar/codebase.md
new file mode 100644
index 00000000..d272a408
--- /dev/null
+++ b/content/ar/codebase.md
@@ -0,0 +1,17 @@
+## I. قاعدة الشيفرة (Codebase)
+### قاعدة شيفرة واحدة يتم تتبعها في أنظمة إدارة الإصدارات، والعديد من عمليات النشر
+
+يتم دائمًا تتبع تطبيق "العوامل الاثني عشر" في نظام التحكم في الإصدار، مثل [Git](http://git-scm.com/)، [Mercurial](https://www.mercurial-scm.org/)، أو [Subversion](http://subversion.apache.org/). تُعرف نسخة قاعدة بيانات تتبع الإصدارات باسم *مستودع الشيفرة*، وغالبًا ما يتم اختصارها إلى *code repo* أو مجرد *repo*.
+
+*قاعدة الشيفرة* هي أي مستودع فردي (في نظام تحكم مركزي مثل Subversion)، أو أي مجموعة من المستودعات التي تشترك في نقطة بداية مشتركة (في نظام تحكم لامركزي مثل Git).
+
+
+
+هناك دائمًا علاقة واحد لواحد بين قاعدة الشيفرة والتطبيق:
+
+* إذا كان هناك العديد من قواعد الشيفرة، فهو ليس تطبيقًا -- بل هو نظام موزع. كل مكون في النظام الموزع هو تطبيق، ويمكن لكل منها الامتثال بشكل فردي للعوامل الاثني عشر.
+* مشاركة تطبيقات متعددة لنفس الشيفرة البرمجية هو انتهاك للعوامل الاثني عشر. الحل هنا هو تحويل الشيفرة المشتركة إلى مكتبات يمكن تضمينها من خلال [مدير الاعتماديات](./dependencies).
+
+توجد قاعدة شيفرة واحدة فقط لكل تطبيق، ولكن سيكون هناك العديد من عمليات النشر للتطبيق. *النشر* هو نسخة قيد التشغيل من التطبيق. عادة ما يكون هذا موقع إنتاج، وموقع تجربة واحد أو أكثر. بالإضافة إلى ذلك، يمتلك كل مطور نسخة من التطبيق تعمل في بيئة التطوير المحلية الخاصة به، وكل منها مؤهل أيضًا كعملية نشر.
+
+قاعدة الشيفرة هي نفسها عبر جميع عمليات النشر، على الرغم من أن الإصدارات المختلفة قد تكون نشطة في كل عملية نشر. على سبيل المثال، لدى المطور بعض التعديلات (commits) التي لم يتم نشرها بعد في بيئة التجربة؛ بيئة التجربة لديها بعض التعديلات التي لم يتم نشرها بعد في بيئة الإنتاج. لكنهم جميعًا يتشاركون نفس قاعدة الشيفرة، مما يجعلهم قابلين للتعريف كعمليات نشر مختلفة لنفس التطبيق.
diff --git a/content/ar/concurrency.md b/content/ar/concurrency.md
new file mode 100644
index 00000000..74bc5c76
--- /dev/null
+++ b/content/ar/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. التزامن (Concurrency)
+### التوسع عبر نموذج العمليات
+
+يتم تمثيل أي برنامج كمبيوتر، بمجرد تشغيله، بعملية واحدة أو أكثر. اتخذت تطبيقات الويب مجموعة متنوعة من أشكال تنفيذ العمليات. على سبيل المثال، تعمل عمليات PHP كعمليات فرعية لـ Apache، يتم تشغيلها عند الطلب حسب الحاجة حسب حجم الطلبات. تتخذ عمليات Java النهج المعاكس، حيث يوفر JVM عملية ضخمة شاملة تحجز كتلة كبيرة من موارد النظام (وحدة المعالجة المركزية والذاكرة) عند بدء التشغيل، مع إدارة التزامن داخليًا عبر الخيوط (threads). في كلتا الحالتين، تكون العملية (العمليات) الجارية مرئية بشكل ضئيل فقط لمطوري التطبيق.
+
+
+
+**في تطبيق العوامل الاثني عشر، العمليات هي عناصر من الدرجة الأولى.** تأخذ العمليات في تطبيق العوامل الاثني عشر إشارات قوية من [نموذج عمليات يونكس لتشغيل خدمات النظام الخفية (daemons)](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). باستخدام هذا النموذج، يمكن للمطور هندسة تطبيقه للتعامل مع أعباء العمل المتنوعة عن طريق تعيين كل نوع من العمل إلى *نوع عملية*. على سبيل المثال، قد تتم معالجة طلبات HTTP بواسطة عملية ويب، والمهام الخلفية طويلة الأمد بواسطة عملية عامل (worker).
+
+لا يستبعد هذا العمليات الفردية من التعامل مع تعدد الإرسال الداخلي الخاص بها، عبر خيوط داخل VM وقت التشغيل، أو النموذج غير المتزامن/المدفوع بالأحداث الموجود في أدوات مثل [EventMachine](https://github.com/eventmachine/eventmachine)، [Twisted](http://twistedmatrix.com/trac/)، أو [Node.js](http://nodejs.org/). لكن VM الفردي يمكن أن ينمو فقط إلى حد معين (توسع رأسي)، لذلك يجب أن يكون التطبيق قادرًا أيضًا على الامتداد عبر عمليات متعددة تعمل على أجهزة مادية متعددة.
+
+تبرز قوة نموذج العملية حقًا عندما يحين وقت التوسع. تعني طبيعة [لا تشارك شيئًا، القابلة للتقسيم أفقيًا لعمليات تطبيق العوامل الاثني عشر](./processes) أن إضافة المزيد من التزامن هي عملية بسيطة وموثوقة. تُعرف مصفوفة أنواع العمليات وعدد العمليات من كل نوع بـ *تشكيلة العمليات*.
+
+عمليات تطبيق العوامل الاثني عشر [لا يجب أن تعمل كخدمات خفية (daemonize) أبدًا](http://dustin.github.com/2010/02/28/running-processes.html) أو تكتب ملفات PID. بدلاً من ذلك، اعتمد على مدير عمليات نظام التشغيل (مثل [systemd](https://www.freedesktop.org/wiki/Software/systemd/)، أو مدير عمليات موزع على منصة سحابية، أو أداة مثل [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) في التطوير) لإدارة [تدفقات الإخراج](./logs)، والاستجابة للعمليات المعطلة، والتعامل مع عمليات إعادة التشغيل والإغلاق التي يبدأها المستخدم.
diff --git a/content/ar/config.md b/content/ar/config.md
new file mode 100644
index 00000000..b3960a09
--- /dev/null
+++ b/content/ar/config.md
@@ -0,0 +1,22 @@
+## III. الإعدادات (Config)
+### تخزين الإعدادات في البيئة
+
+إعدادات التطبيق *config* هي كل ما يحتمل أن يختلف بين [عمليات النشر](./codebase) (التجربة، الإنتاج، بيئات المطورين، إلخ). وهذا يشمل:
+
+* معرفات الموارد لقاعدة البيانات، Memcached، و [الخدمات المساندة](./backing-services) الأخرى
+* بيانات الاعتماد للخدمات الخارجية مثل Amazon S3 أو Twitter
+* القيم لكل عملية نشر مثل اسم المضيف المتعارف عليه لعملية النشر
+
+تخزن التطبيقات أحيانًا الإعدادات كثوابت في الشيفرة البرمجية. هذا انتهاك للعوامل الاثني عشر، والتي تتطلب **فصلاً صارمًا للإعدادات عن الشيفرة**. تختلف الإعدادات بشكل كبير عبر عمليات النشر، بينما لا تختلف الشيفرة.
+
+الاختبار الحاسم (litmus test) لمعرفة ما إذا كان التطبيق قد تم فصل كل الإعدادات بشكل صحيح عن الشيفرة هو ما إذا كان يمكن جعل قاعدة الشيفرة مفتوحة المصدر في أي لحظة، دون المساس بأي بيانات اعتماد.
+
+لاحظ أن هذا التعريف لـ "الإعدادات" لا يشمل إعدادات التطبيق الداخلية، مثل `config/routes.rb` في Rails، أو كيفية [ربط وحدات الشيفرة](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) في [Spring](http://spring.io/). هذا النوع من الإعدادات لا يختلف بين عمليات النشر، ولذلك يفضل القيام به في الشيفرة.
+
+نهج آخر للإعدادات هو استخدام ملفات الإعدادات التي لا يتم فحصها في التحكم بالمراجعة، مثل `config/database.yml` في Rails. هذا تحسن كبير عن استخدام الثوابت التي يتم فحصها في مستودع الشيفرة، ولكن لا تزال بها نقاط ضعف: من السهل فحص ملف إعدادات عن طريق الخطأ في المستودع؛ هناك ميل لانتشار ملفات الإعدادات في أماكن مختلفة وتنسيقات مختلفة، مما يجعل من الصعب رؤية وإدارة كل الإعدادات في مكان واحد. علاوة على ذلك، تميل هذه التنسيقات إلى أن تكون خاصة باللغة أو الإطار.
+
+**يخزن تطبيق العوامل الاثني عشر الإعدادات في *متغيرات البيئة*** (غالبًا ما يتم اختصارها إلى *env vars* أو *env*). من السهل تغيير متغيرات البيئة بين عمليات النشر دون تغيير أي شيفرة؛ على عكس ملفات الإعدادات، هناك فرصة ضئيلة لفحصها في مستودع الشيفرة عن طريق الخطأ؛ وعلى عكس ملفات الإعدادات المخصصة، أو آليات الإعدادات الأخرى مثل خصائص نظام Java، فهي معيار غير ملزم بلغة أو نظام تشغيل.
+
+جانب آخر لإدارة الإعدادات هو التجميع. تقوم التطبيقات أحيانًا بتجميع الإعدادات في مجموعات مسماة (غالبًا ما تسمى "بيئات") مسماة بعد عمليات نشر محددة، مثل بيئات `development` (التطوير) و `test` (الاختبار) و `production` (الإنتاج) في Rails. هذه الطريقة لا تتوسع بشكل نظيف: مع إنشاء المزيد من عمليات النشر للتطبيق، تصبح هناك حاجة لأسماء بيئات جديدة، مثل `staging` (التجربة) أو `qa` (ضمان الجودة). مع نمو المشروع بشكل أكبر، قد يضيف المطورون بيئاتهم الخاصة مثل `joes-staging`، مما يؤدي إلى زيادة تعقيدية هائلة للإعدادات مما يجعل إدارة عمليات نشر التطبيق هشة للغاية.
+
+في تطبيق العوامل الاثني عشر، تكون متغيرات البيئة ضوابط دقيقة، وكل منها مستقل تمامًا عن متغيرات البيئة الأخرى. لا يتم تجميعها معًا أبدًا كـ "بيئات"، ولكن بدلاً من ذلك تتم إدارتها بشكل مستقل لكل عملية نشر. هذا نموذج يتوسع بسلاسة مع توسع التطبيق بشكل طبيعي في المزيد من عمليات النشر طوال عمره.
diff --git a/content/ar/dependencies.md b/content/ar/dependencies.md
new file mode 100644
index 00000000..cfce0360
--- /dev/null
+++ b/content/ar/dependencies.md
@@ -0,0 +1,12 @@
+## II. الاعتماديات (Dependencies)
+### الإعلان عن الاعتماديات وعزلها بشكل صريح
+
+توفر معظم لغات البرمجة نظام حزم لتوزيع مكتبات الدعم، مثل [CPAN](http://www.cpan.org/) لـ Perl أو [Rubygems](http://rubygems.org/) لـ Ruby. يمكن تثبيت المكتبات من خلال نظام حزم على مستوى النظام (تُعرف باسم "حزم النظام" أو "site packages") أو تحديد نطاقها في المجلد الذي يحتوي على التطبيق (تُعرف باسم "التضمين" أو "vendoring").
+
+**لا يعتمد تطبيق "العوامل الاثني عشر" أبدًا على الوجود الضمني للحزم على مستوى النظام.** يعلن عن جميع الاعتماديات، بشكل كامل ودقيق، عبر *ملف تعريف الاعتماديات*. علاوة على ذلك، يستخدم أداة *عزل الاعتمادية* أثناء التنفيذ لضمان عدم "تسرب" أي اعتماديات ضمنية من النظام المحيط. يتم تطبيق مواصفات الاعتمادية الكاملة والصريحة بشكل موحد على كل من الإنتاج والتطوير.
+
+على سبيل المثال، يوفر [Bundler](https://bundler.io/) لـ Ruby تنسيق ملف `Gemfile` لإعلان الاعتمادية و `bundle exec` لعزل الاعتمادية. في Python هناك أداتان منفصلتان لهذه الخطوات -- يستخدم [Pip](http://www.pip-installer.org/en/latest/) للإعلان و [Virtualenv](http://www.virtualenv.org/en/latest/) للعزل. حتى C لديها [Autoconf](http://www.gnu.org/s/autoconf/) لإعلان الاعتمادية، ويمكن أن يوفر الربط الثابت (static linking) عزل الاعتمادية. بغض النظر عن سلسلة الأدوات، يجب دائمًا استخدام إعلان الاعتمادية والعزل معًا -- واحد فقط أو الآخر لا يكفي لتلبية العوامل الاثني عشر.
+
+تتمثل إحدى فوائد إعلان الاعتمادية الصريح في أنه يبسط الإعداد للمطورين الجدد في التطبيق. يمكن للمطور الجديد سحب قاعدة الشيفرة للتطبيق على جهاز التطوير الخاص به، مما يتطلب فقط تثبيت وقت تشغيل اللغة ومدير الاعتماديات كمتطلبات أساسية. سيكونون قادرين على إعداد كل ما يلزم لتشغيل شيفرة التطبيق باستخدام *أمر بناء* حتمي. على سبيل المثال، أمر البناء لـ Ruby/Bundler هو `bundle install`، بينما لـ Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) هو `lein deps`.
+
+تطبيقات "العوامل الاثني عشر" أيضًا لا تعتمد على الوجود الضمني لأي أدوات نظام. تشمل الأمثلة استدعاء أوامر النظام (shelling out) مثل ImageMagick أو `curl`. في حين أن هذه الأدوات قد توجد في العديد أو حتى معظم الأنظمة، فلا يوجد ضمان بأنها ستوجد في جميع الأنظمة التي قد يعمل فيها التطبيق في المستقبل، أو ما إذا كان الإصدار الموجود في نظام مستقبلي سيكون متوافقًا مع التطبيق. إذا كان التطبيق يحتاج إلى استدعاء أداة نظام، فيجب تضمين تلك الأداة في التطبيق.
diff --git a/content/ar/dev-prod-parity.md b/content/ar/dev-prod-parity.md
new file mode 100644
index 00000000..cc58f22d
--- /dev/null
+++ b/content/ar/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. التطابق بين التطوير والإنتاج (Dev/prod parity)
+### إبقاء بيئات التطوير، والتجربة، والإنتاج متشابهة قدر الإمكان
+
+تاريخياً، كانت هناك فجوات كبيرة بين التطوير (مطور يقوم بتعديلات حية على [نشر](./codebase) محلي للتطبيق) والإنتاج (نشر جارٍ للتطبيق يتم الوصول إليه من قبل المستخدمين النهائيين). تظهر هذه الفجوات في ثلاثة مجالات:
+
+* **الفجوة الزمنية**: قد يعمل المطور على شيفرة تستغرق أيامًا أو أسابيع أو حتى شهورًا للدخول في الإنتاج.
+* **فجوة الأفراد**: المطورون يكتبون الشيفرة، ومهندسو العمليات ينشرونها.
+* **فجوة الأدوات**: قد يستخدم المطورون حزمة مثل Nginx و SQLite و OS X، بينما يستخدم نشر الإنتاج Apache و MySQL و Linux.
+
+**تم تصميم تطبيق العوامل الاثني عشر [للنشر المستمر](http://avc.com/2011/02/continuous-deployment/) عن طريق إبقاء الفجوة بين التطوير والإنتاج صغيرة.** بالنظر إلى الفجوات الثلاث الموصوفة أعلاه:
+
+* اجعل الفجوة الزمنية صغيرة: قد يكتب المطور شيفرة ويتم نشرها بعد ساعات أو حتى دقائق فقط.
+* اجعل فجوة الأفراد صغيرة: المطورون الذين كتبوا الشيفرة يشاركون بشكل وثيق في نشرها ومراقبة سلوكها في الإنتاج.
+* اجعل فجوة الأدوات صغيرة: حافظ على التطوير والإنتاج متشابهين قدر الإمكان.
+
+تلخيص ما سبق في جدول:
+
+