كيفية تدقيق المصطلحات التقنية، واستخدام الأحرف الكبيرة، والتسميات المترجمة
عند مراجعة الوثائق التقنية، تحقق من كل مصطلح بالرجوع إلى جدول مصطلحات واضح وصريح بدلاً من الاعتماد على الذاكرة أو على قاعدة واحدة للأحرف الكبيرة. سجّل الصيغة المعتمدة، والتهجئة وحالة الأحرف التي ينبغي للقراء رؤيتها، والمتغيرات المقبولة، ومعرّفات الشيفرة البرمجية أو واجهات برمجة التطبيقات (API) الحرفية، وأي ترجمة لا تزال قيد الانتظار لاتخاذ قرار بشأنها. بعد ذلك، قم بتدقيق النصوص الإنشائية، وتسميات الواجهة، والمعرّفات كعناصر منفصلة. تكتشف هذه الطريقة المصطلحات غير المتسقة مع الحفاظ على الأسماء والشيفرات البرمجية التي يجب أن تظل دقيقة تماماً.
لماذا لا يمكن لقاعدة واحدة للأحرف الكبيرة أن تحسم كل مصطلح؟
توفر أدلة الأسلوب معايير افتراضية مفيدة، ولكن قد يكون لمنتج أو مجال معين أسماء راسخة تتطلب معالجة مختلفة. يوصي دليل المطورين من Google باستخدام الأحرف الكبيرة القياسية باللغة الإنجليزية الأمريكية وحالة الجملة (sentence case) للعناوين والقوائم والجداول، مع الحفاظ على أسماء المنتجات الرسمية وصيغ الشيفرات البرمجية. كما يفضل دليل Microsoft أيضاً أسلوب حالة الجملة، لكنه يخصص صراحةً الأحرف الكبيرة لأسماء العلم مثل علاماتها التجارية ومنتجاتها وخدماتها. هذا المعيار المشترك بينهما هو نقطة انطلاق، وليس دليلاً على أن مصطلحاً تقنياً معيناً يُعد عاماً. [إرشادات Google بشأن استخدام الأحرف الكبيرة](https://developers.google.com/style/capitalization) [إرشادات Microsoft بشأن استخدام الأحرف الكبيرة](https://learn.microsoft.com/en-us/style-guide/capitalization)
يمكن لقائمة الكلمات أن تجيب عن سؤال مختلف مقارنةً بصفحة الإرشادات العامة للأحرف الكبيرة: ما هي التهجئة أو الاستخدام الذي يفضله دليل تحريري معين لمصطلحات محددة. توجه قائمة كلمات Google، على سبيل المثال، القراء إلى قاموسها المفضل للمفردات التي لا تغطيها، وتفرّق بين إرشادات الأسلوب والتحقق من تعريف تقني في وثائق موثوقة. هذا الفصل مفيد: فالاتساق التحريري والدقة التقنية يحتاجان إلى أدلة مستمدة من المصادر المناسبة لكل سؤال. [قائمة كلمات Google](https://developers.google.com/style/word-list)
ما الذي ينبغي تضمينه في جدول تدقيق المصطلحات؟
أنشئ صفاً واحداً لكل مصطلح يمكن تغييره بشكل غير متسق أو ترجمته بشكل خاطئ. يوضح هذا المثال الافتراضي الحقول ومنطق اتخاذ القرار؛ إن مصطلح "رمز المزامنة" (Sync token) وترجمته معروضان للتوضيح فقط، وليسا ادعاءات حول منتج حقيقي أو مصطلحات معتمدة.
تتمثل مهمة الجدول في حفظ القرارات وحدودها. يجب ألا تتحول الصيغة المسموح بها بالأحرف الصغيرة ضمناً إلى اسم منتج ثانٍ؛ ويجب عدم "تصحيح" المعرّف ليتطابق مع النص الإنشائي؛ ويجب أن تظل الترجمة غير المحسومة واضحة بأنها غير محسومة. عندما يتعارض مصدر رسمي مع مسرد محلي، سجّل التعارض ومصدر القرار النهائي بدلاً من دمج الصيغ في قائمة غير مفسرة.
كيف تقرر التهجئة وحالة الأحرف المعروضة؟
حدد أولاً إلى ماذا يشير المصطلح: أهو مفهوم عادي، أم اسم علامة تجارية أو منتج، أم تسمية واجهة مستخدم، أم معرّف حرفي. راجع وثائق المنتج أو المسرد ذي الصلة لمعرفة الصيغة الرسمية. بعد ذلك، طبّق قواعد أسلوب المنشور المستهدف على النصوص العادية والعناوين والتسميات، مع الاحتفاظ بالاستثناءات الموثقة للأسماء والمعرّفات. تنصح Google بعدم استخدام الأحرف الكبيرة غير الضرورية وتحذر من استخدام حالة الأحرف وحدها للتمييز بين المعاني؛ وبالمثل تنص Microsoft على استخدام الأحرف الصغيرة باستثناء بدايات الجمل وأسماء العلم في نهج حالة الجملة المتبع لديها. [إرشادات Google بشأن استخدام الأحرف الكبيرة](https://developers.google.com/style/capitalization) [إرشادات Microsoft بشأن استخدام الأحرف الكبيرة](https://learn.microsoft.com/en-us/style-guide/capitalization)
بعد ذلك، قارن الصيغة بقائمة الكلمات والقاموس الخاصين بالمؤسسة المستهدفة عند الاقتضاء. سجّل المصدر وإصداره أو تاريخ التحقق حتى يتمكن محرر آخر من تتبع سبب الاختيار. لا تستنتج الصفة الرسمية من تهجئة تبدو جذابة بالأحرف الكبيرة، أو من نتيجة بحث، أو من ترجمة تشبه المصطلح الإنجليزي. إذا اختلفت المصادر أو لم تحدد الصيغة، فضع علامة على الصف لاتخاذ قرار بشأنه بدلاً من تقديم تخمين على أنه مصطلح محسوم.
كيف ينبغي فحص الترجمات وتسميات الواجهة؟
تعامل مع الترجمة كقرار يتعلق بالمعنى والسياق، وليس كتحويل آلي لحالة الأحرف. قد تكون التسمية مقيدة بالواجهة، أو بمصطلحات المنتج المعربة والمستقرة، أو بصيغة نحوية مختلفة في اللغة الهدف. قارن الصيغة المقترحة بالمواد المعربة المعتمدة وبالسياق الذي سيواجهه القراء. إذا لم تكن هناك صيغة معربة موثوقة متاحة، فضع علامة على الترجمة بأنها غير محسومة واطلب قراراً بالمصطلح المناسب؛ لا تبتكر مقابلاً وتدعي أنه رسمي.
بعد اتخاذ القرار بشأن المصطلح، قم بتدقيق التسمية الفعلية في مكانها. تحقق مما إذا كانت حالة الأحرف تتبع قواعد اللغة المختارة وأسلوب المنتج أو الدليل الداخلي المعمول به. احتفظ بالتسمية الأصلية ظاهرة في سجل المصطلح، جنباً إلى جنب مع مصدرها وحالتها، حتى لا يخطئ تحرير لاحق ويعتبر الترجمة المؤقتة ترجمة معتمدة. إذا تمت الإشارة إلى التسمية أيضاً في التعليمات، فتأكد من أن النص الإنشائي يطابق نفس النص الظاهر على الشاشة.
كيف تحمي معرّفات الشيفرة البرمجية وواجهات برمجة التطبيقات (API)؟
افصل النصوص الحرفية عن النص التحريري قبل تغيير حالة الأحرف. قارن المعرّفات حرفاً بحرف مع مرجع واجهة برمجة التطبيقات، أو المخطط (schema)، أو الشيفرة البرمجية، أو الواجهة ذات الصلة. احتفظ بالشرطات السفلية، وحالة الأحرف، والمسافات، وعلامات الترقيم كما يحددها المصدر؛ فتوحيد الأسلوب مكانه في الشرح المحيط، وليس في القيمة الحرفية. يسمح دليل Google صراحةً باستخدام صيغ الأحرف الكبيرة الكاملة أو صيغة سنام الجمل (camelCase) في الأسماء الرسمية أو عند الإشارة إلى شيفرة تستخدمها. [إرشادات Google بشأن استخدام الأحرف الكبيرة](https://developers.google.com/style/capitalization)
تحدد المراجعة العملية المعرّفات المحمية في جدول المصطلحات ثم تفحص كل موضع ورود مقارنةً بهذا المرجع. إذا استخدمت جملة إنشائية مصطلحاً بصيغة برمجية كاسم عادي، فقرر ما إذا كان من الأفضل شرحه بصياغة واضحة للقارئ مع الحفاظ على المعرّف الحرفي كما هو بتنسيق الشيفرة البرمجية. عندما يكون التعريف المعتمد نفسه غير واضح، سجّل عدم اليقين هذا؛ فدليل الأسلوب لا يمكنه تحديد سلوك واجهة برمجة التطبيقات أو الاسم القياسي للحقل.
ما هو التسلسل الموثوق لعملية التدقيق اللغوي؟
هذا التسلسل هو أداة مساعدة للتدقيق، وليس ترجمة آلية أو قاعدة عامة لحالة الأحرف. تكمن قيمته في أنه يجعل كل قرار تحريري قابلاً للمراجعة والفحص: ما هي الصيغة التي تم اختيارها، ومن أين أتت، وأين تنطبق، وما الذي لا يزال بحاجة إلى قرار. بالنسبة لمستند قصير، قد يكون جدول مصغر كافياً؛ أما بالنسبة لمجموعة مصطلحات كبيرة، فاحتفظ بنفس الحقول في مسار عمل المسرد المعتمد لدى الفريق.