لإضافة مقال جديد، أنشئ طلب سحب (Pull Request) يتضمن الملف الجديد فقط وأي تغييرات ضرورية مرتبطة به.
الملف ومجلد التصنيف
- استخدم اسم ملف باللغة الإنجليزية فقط، بأحرف صغيرة وبصيغة
kebab-case، مثلhow-to-configure-git.md. - استخدم امتداد
.mdأو.mdxفقط. - ضع الملف في مجلد التصنيف المناسب داخل
src/content/posts/. - إذا لم يكن مجلد التصنيف موجوداً، فأنشئه قبل إضافة المقال.
تنسيق المقال
- اتبع تنسيق
src/content/posts/template.txt، بما في ذلك البيانات الوصفية في بداية الملف. - لا تنشئ مكونات جديدة لاستخدامها في ملفات
.mdx. - استخدم التوجيهات التالية للملاحظات والنصائح المهمة بدلاً من المكونات المخصصة:
:::tip
نصيحة مفيدة.
:::
:::note
ملاحظة مهمة.
:::
المصادر وحقوق النشر
- أضف جميع الموارد التي استخدمتها في قسم واضح في نهاية المقال، مثل
## المصادر. - لا تنسخ محتوى من مواقع أخرى، ولا تُعِد نشره أو توزيعه.
- يمكنك إعادة نشر مقالك المنشور سابقاً فقط إذا كان من عملك وتملك حقوق نشره، مع إضافة رابط للمصدر الأصلي عند توفره.
أسلوب الكتابة
المحتوى العربي في هذا الموقع يتبع أسلوباً محدداً مستخلصاً من المقالات المنشورة. التزم بالإرشادات التالية عند كتابة مقالك أو تحريره.
اللغة والصياغة
- استخدم العربية الفصحى المبسطة، بعيدة عن التكلف والتزويق.
- اكتب جملاً مترابطة تشرح السياق كاملاً قبل الانتقال إلى النقطة التالية.
- النبرة هادئة ومعلوماتية لا تسويقية، فتجنب علامات التعجب إلا نادراً.
- ممنوع استخدام الشرطة الطويلة (em-dash) في أي مكان.
ضمير المخاطب والمتكلم
- خاطب القارئ بضمير ”أنت/أنك“ (موقعك، تستطيع، سنفترض أنك تملك).
- استخدم ”سنقوم بـ“ للخطوات العملية التي يتبعها الكاتب والقارئ معاً، و”سأفترض“ عند وضع الفرضيات.
- الأسلوب تشاركي: الكاتب يتعلم مع القارئ ويهدف إلى الفهم، ولا يدّعي الكمال.
- إن وقفت عند حدود معرفتك فصرّح بها بوضوح بدل إخفائها.
المصطلحات التقنية
- تبقى المصطلحات الإنجليزية الراسخة كما هي دون تعريب قسري: WordPress، HTML، Markdown، JavaScript، GitHub.
- ما هو اسم لشيء محدد يبقى كما هو، أما المفاهيم العامة فتُعرَّب إلى كلمة عربية أصيلة: نقول ”النص البرمجي“ وليس ”كود“، و”سطر الأوامر“ وليس ”طرفية“، و”الذكاء الصنعي“ وليس ”الاصطناعي“.
- تكتب المصطلحات بصيغتها الأصلية أو داخل backticks حسب السياق: الوحدات النصية (Tokens)،
template_redirect. - الالتصاق بالـ التعريف شائع ومقبول: الـ HTML، الوحدات النصية (Tokens)، الـ URL.
- استخدم “ال” التعريف مع المصطلح العربي المعتمد عند الحديث عن المفهوم نفسه: ”الواجهة البرمجية“ و”النص البرمجي“، وليس الصيغة النكرة المجردة.
- التنوين بالألف والتاء المفتوحة حسب قواعد الفصحى الحديثة: دائماً، تماماً، غالباً.
بنية المقال
- ابدأ بمقدمة تربط الموضوع بواقع ملموس أو مشكلة حقيقية قبل الدخول في التقنية.
- استخدم عناوين واضحة ومباشرة: ”المشكلة الأساسية“، ”الحل للمشكلة“، ”المتطلبات“.
- الشرح النظري يأتي قبل النص البرمجي، والنص يُبنى تدريجياً: مقطع صغير، شرح، مقطع تال، ثم النص الكامل في النهاية.
- اجعل الختام عملياً: أظهر النتيجة النهائية (مثل مخرجات أمر من سطر الأوامر) بدل خلاصة إنشائية.
التعامل مع النص البرمجي
- استخدم أمثلة حقيقية قابلة للتشغيل، بأوامر كاملة تتضمن مخرجاتها الفعلية.
- أظهر المشكلة أولاً بمخرجات حقيقية قبل عرض الحل.
- اشرح ”لماذا“ هذا السطر موجود، وليس فقط ”ماذا“ يفعل.
- اربط النص البرمجي بمصادره الرسمية عبر روابط (التوثيق الرسمي، مستودعات GitHub).
- إن اختصرت شيئاً فاعترف بذلك صراحة للقارئ.
عناصر مساعدة
- استخدم صناديق الملاحظات الموضحة أعلاه:
:::tipللتوسع والروابط الإضافية، و:::noteللفرضيات والمتطلبات المسبقة. - يمكنك استخدام مخططات Mermaid لتبسيط التدفقات المعقدة.
- أضف الصور عند الحاجة لدعم نقطة (مثل مخطط إحصائي)، وليس للزينة.
ما يجب تجنبه
- اللغة التسويقية والمبالغة (”الأفضل على الإطلاق“، ”ثورة في عالم“).
- التعريب القسري للمصطلحات الراسخة إنجليزياً.
- الكلمات الدخيلة حيث توجد كلمة عربية أصيلة، مثل ”كود“ بدل ”نص برمجي“.
- الشرح السطحي الذي يقفز مباشرة إلى النص البرمجي دون تأسيس المشكلة.
- ادعاء الكمال أو إخفاء حدود المعرفة.
- الشرطة الطويلة والتعجب المفرط.