Operations · 8 يوليو 2026
يجب أن تجيب حالات الترجمة عن السؤال التالي
يوضح تصميم الحالة الجيد للمحررين ما الذي اكتمل، وما الذي تعذّر، وأي إجراء متاح، من دون كشف تفاصيل تنفيذ العامل.

تنتج أنظمة الترجمة الكثير من الحالات. تُدرج المهام في قائمة الانتظار، ويردّ المزوّدون، وتُحفَظ المسودات، وتُحدَّث Contentful، وتُنشر الإدخالات، وتبدأ إعادة المحاولة.
إن عرض كل هذا النشاط لا يجعل التقدّم واضحًا تلقائيًا.
يجب أن تجيب الحالة المفيدة عن السؤال التالي الذي يدور في ذهن المحرر.
يحتوي الطلب الواحد على عدة دورات حياة
غالبًا ما يمرّ الطلب متعدد اللغات عبر ثلاث مراحل رئيسية:
- الترجمة
- الدفع
- النشر
يمكن أن تكون كل مرحلة خاملة، أو في قائمة الانتظار، أو قيد العمل، أو ناجحة، أو متخطاة، أو فاشلة. ويؤدي اختزال هذه الحالات في كلمة واحدة إلى فقدان معلومات مهمة.
قد تعني "مكتمل" أن مسودة الترجمة جاهزة للمراجعة، أو أن اللغة المستهدفة كُتبت إلى Contentful، أو أن الإدخال أصبح منشورًا. وهذه نتائج مختلفة جوهريًا.
يجب أن تسمّي الواجهة المرحلة وحالتها معًا.
يجب أن تقترن الحالة بالإجراء
يقرأ المحررون الحالة ليقرروا ما الذي يمكنهم فعله بعد ذلك.
- يمكن مراجعة الترجمة الجاهزة.
- يمكن دفع الترجمة المعتمدة.
- يمكن نشر الدفع الناجح.
- يمكن إعادة محاولة الفشل المؤقت.
- قد يكون من الممكن إلغاء العمل النشط.
إذا لم يتطابق الإجراء المتاح مع الحالة المعروضة، فسيبدو المنتج غير متسق. ووجود زر نشر بجانب طلب لم يُدفَع قط ليس مجرد أمر مربك؛ بل يضعف الثقة في سير العمل الأساسي.
يجب أن تحدد الواجهة الخلفية مدى التوفّر استنادًا إلى الحالة الدائمة والأذونات، ثم يجب أن تعكس واجهة المستخدم هذا القرار باستمرار.
تحتاج حسابات التقدم إلى مقام ثابت
يصبح تقدّم الدفعات مضللًا عندما تستخدم كل مرحلة إجماليًا مختلفًا من دون توضيح ذلك.
قد تحتوي دفعة تضم عشرة طلبات ترجمة على عشر ترجمات، وثماني عمليات دفع، وست عمليات نشر، لأن بعض اللغات كانت للمراجعة فقط أو لأن التشغيل الآلي كان معطّلًا.
يجب أن يميّز التقدم بين:
- إجمالي الطلبات
- الطلبات المؤهلة للمرحلة الحالية
- الطلبات المكتملة، والنشطة، والفاشلة، والمتخطاة
تُعد حالة التخطي مهمة بشكل خاص. فهي قرار نهائي، وليست عملًا غير مكتمل.
حافظ على السجل من دون ازدحام الشاشة
يجب أن تظل الحالة الحالية موجزة، لكن يظل المشغّلون بحاجة إلى السجل عندما يحدث خطأ ما.
يمكن لخط زمني قابل للتوسيع للأحداث أن يوضح وقت إدراج الطلب في قائمة الانتظار، وأي محاولة فشلت، وما إذا كانت إعادة محاولة تلقائية قد نُفِّذت، ومتى قبلت Contentful التحديث. وهذا يدعم تصحيح الأخطاء من دون تحويل كل صف في الجدول إلى عارض سجلات.
استخدم لغة بشرية للحالة الرئيسية، واحتفظ بالمعرّفات التقنية والطوابع الزمنية في عرض التفاصيل.
يجب أن تظل الحالات النهائية نهائية
قد تصل أحداث الاستطلاع والأحداث الآنية بترتيب غير صحيح. ويجب ألا يؤدي حدث "قيد العمل" الأقدم إلى إعادة طلب مكتمل إلى الوراء. ويجب ألا تُظهر الصفحة المُحدَّثة مؤقتًا حالة الاصطفاف بعد أن يكون نجاح العملية قد سُجِّل بالفعل في قاعدة البيانات.
تحتاج انتقالات الحالة إلى ترتيب وإمكانية تكرار آمنة. ويجب أن تدمج الواجهة التحديثات باستخدام الطابع الزمني أو الإصدار المعتمد، لا أن تقبل ببساطة آخر رسالة وصلت إلى المتصفح.
الخلاصة
تصميم الحالة جزء من سير العمل، وليس مجرد زينة حوله.
افصل بين مراحل الترجمة، والدفع، والنشر. واربط كل حالة بالإجراء الذي تتيحه، واحسب العمل المتخطى بصدق، واحتفظ بسجل تفصيلي قريبًا. أفضل حالة هي تلك التي تجعل القرار التالي واضحًا.