إجراءات i18n في Vue 3 لأكثر من 500 مفتاح دون مفاجآت في الإنتاج

ما الذي ينهار بعد تجاوز 500 مفتاح i18n

بعد أن يتجاوز تطبيقك بضع مئات من السلاسل، أول شيء ينكسر في العادة ليس Vue I18n نفسه. هو الاتساق. يضيف الناس مفاتيح بأساليب مختلفة، تتكرر نفس الفكرة بأسماء متعددة، ولا أحد متأكد أي الرسائل آمنة للحذف.

الترجمات المفقودة تتوقف عن كونها نادرة أيضًا. تظهر في مسارات المستخدم العادية، خاصة في الشاشات الأقل استخدامًا مثل الإعدادات، حالات الخطأ، الحالات الفارغة، والإشعارات.

عندما تكون الترجمة مفقودة، يرى المستخدمون عادةً أحد ثلاثة أخطاء: واجهة فارغة (زر بلا تسمية)، مفاتيح خام (مثل checkout.pay_now)، أو سلوك تراجع غريب حيث يتحول جزء من الصفحة إلى لغة أخرى. ولا يبدو أيّ من هذه أمراً بسيطًا — كلها تجعل التطبيق يبدو معطلاً.

لهذا السبب تكون إجراءات i18n في Vue 3 أكثر أهمية من المكتبة نفسها. المكتبة ستفعل ما تطلبه. على نطاق واسع، غالبًا لا تتفق الفرق على شكل «المهم».

مثال شائع: مطوِّر يطلق تدفق "دعوة زميل" جديد مع 40 سلسلة جديدة. يتم تحديث ملف الإنجليزية، لكن ملف الفرنسية لا يُحدَّث. في الـ staging، كل شيء يبدو جيدًا لأن المختبر يستخدم الإنجليزية. في الإنتاج، يرى المستخدمون الفرنسيون خليطًا من واجهة مترجمة وغير مترجمة، ويحصل فريق الدعم على لقطات شاشة للمفاتيح الخام.

الحل هو تعريف ما يعنيه "مكتمل" للواجهة المترجمة. لا يمكن أن يكون فقط "إضافة سلاسل". تعريف عملي للمكتمل عادةً يتضمن: اتباع المفاتيح لقواعد التسمية، بناء اللغات دون تحذيرات مفاتيح مفقودة، عرض الأشكال والجمل المتغيرة بشكل صحيح ببيانات حقيقية، فحص على الأقل لغة غير افتراضية واحدة، وتتبع تغييرات النص حتى لا تبقى المفاتيح القديمة.

عند وجود 500+ مفتاح، تنتصر إذا عاملت التعريب كعملية إصدار، وليس تعديل ملف في اللحظة الأخيرة.

ضع بعض القواعد قبل إضافة المزيد من النصوص

بعد بضع مئات من السلاسل، العمل الترجمي لا يكون الجزء الفوضوي — الاتساق هو. مجموعة صغيرة من القواعد تجعل سير عمل i18n في Vue 3 قابلاً للتنبؤ حتى لو لمس عدة أشخاص النص أسبوعيًا.

ابدأ بتقرير ما هي «الفكرة» واحتفظ بمصدر واحد للحقيقة لها. إذا ظهرت نفس الفكرة في خمس أماكن (مثلاً "حفظ التغييرات"), تريد مفتاحًا واحدًا، لا خمس متغيرات مثل save, saveChanges, save_update, وsaveBtn. المفاتيح المكررة تنحرف في المعنى مع الوقت، ويشعر المستخدمون بتلك التباينات.

بعد ذلك، قرِّر أين يعيش التنسيق. الفرق غالبًا تقسم هذا عن طريق الخطأ: بعض الرسائل تتضمن علامات الترقيم وحالة الأحرف، وأخرى تعتمد على الكود لإضافتها. اختر نهجًا واحدًا والتزم به.

وضع افتراضي عملي:

• ضع القواعد النحوية، علامات الترقيم، وصياغة العرض للمستخدم (مثل “(اختياري)”) داخل الرسالة.
• احتفظ بتنسيق البيانات الخالص في الكود (التواريخ، العملات، الوحدات)، ثم مرّر النتيجة إلى i18n.
• استخدم عناصر نائب للأسماء والعدّادات، لا دمج النصوص عن طريق الربط.
• اعتبر HTML داخل الرسائل حالة خاصة مع قاعدة واضحة (مسموح أم لا).

ثم حدِّد الملكية. قرّر من يمكنه إضافة مفاتيح جديدة، من يراجع نص اللغة الأساسية، ومن يوافق على بقية اللغات. بدون هذا، تُضاف السلاسل بسرعة ولا تُراجع أبدًا.

أخيرًا، اختر واستند إلى استراتيجية تراجع مُوثقة. إذا كان المفتاح مفقودًا، ماذا يرى المستخدم: اسم المفتاح، نص اللغة الافتراضية، أم رسالة عامة آمنة؟ في الإنتاج، تفضّل العديد من الفرق التراجع إلى اللغة الافتراضية مع تسجيل المشكلة، حتى لا يُحجب المستخدم بينما لا يزال لديك إشارة أن شيئًا ما خاطئ.

إذا تبنيت تطبيقات Vue 3 باستخدام مولد مثل AppMaster (Vue3 web UI plus real backend code)، فهذه القواعد تظل سارية. عامل الترجمات كمحتوى منتج، لا كنص "للمطورين فقط"، وستتجنب معظم المفاجآت المتأخرة.

قواعد تسمية المفاتيح التي تبقى قابلة للقراءة

بعد بضع مئات من السلاسل، الاتساق هو العامل الأكبر. اختر نمط مفتاح واحد (معظم الفرق تستخدم مسارات بالنقاط مثل billing.invoice.title) واجعله قاعدة. مزج النقاط، الشرطات، snake_case، وأنماط حالة الأحرف العشوائية يجعل البحث والمراجعات بطيئة.

استخدم مفاتيح مستقرة تصمد أمام تغيّر النسخ. مفتاح مثل "Please enter your email" سينكسر بمجرد تعديل التسويق للجملة. الأفضل أسماء تعتمد النية مثل auth.email.required أو auth.email.invalid.

جمّع المفاتيح حسب منطقة المنتج أو سطح الواجهة أولًا، ثم حسب الهدف. فكر بنفس مجموعات التطبيق الموجودة لديك: auth, billing, settings, support, dashboard. هذا يجعل ملفات اللغة سهلة الفحص ويقلل التكرار عندما تحتاج شاشتان نفس الفكرة.

داخل كل منطقة، احتفظ بمجموعة صغيرة من الأنماط لقطع الواجهة الشائعة:

• الأزرار: *.actions.save, *.actions.cancel
• الوسوم: *.fields.email.label, *.fields.password.label
• الملاحظات/نص المساعدة: *.fields.email.hint
• الأخطاء/التحقق: *.errors.required, *.errors.invalidFormat
• الإشعارات/التوستات: *.notices.saved, *.notices.failed

يجب أن تصف الرسائل الديناميكية ما يتغير، لا كيف يتغير. سمّ الرسالة بالهدف واستخدم معلمات للأجزاء المتغيّرة. مثلاً billing.invoice.dueInDays مع {days} أوضح من billing.invoice.dueIn3Days.

مثال (يعمل جيدًا في سير عمل i18n لـ Vue 3): orders.summary.itemsCount مع {count} للعدد، وorders.summary.total مع {amount} للمال. عندما يقرأ شخص ما المفتاح في الكود، يجب أن يعرف أين ينتمي ولماذا موجود، حتى لو تغيّرت النسخة النهائية لاحقًا.

قواعد الجمع وتنسيق الرسائل بدون مفاجآت

نصوص الجمع تنهار بهدوء عندما تعامل كل لغة كأنها الإنجليزية. قرر مبكرًا متى ستستخدم تركيب رسائل ICU ومتى يكفي عنصر نائب بسيط.

استخدم الاستبدالات البسيطة للوسوم والنصوص القصيرة التي لا تتغيّر بتغيّر العدد (مثال: "Welcome, {name}"). انتقل إلى ICU لأي شيء قائم على العدد، لأنه يحفظ كل الأشكال في مكان واحد ويجعل القواعد صريحة.

{
  "notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}

اكتب رسائل العدِّ بحيث تكون سهلة الترجمة. فضّل جملة كاملة وضع عنصر الرقم (#) قريبًا من الاسم. تجنّب الاختصارات الذكية مثل إعادة استخدام نفس المفتاح لـ "1 عنصر" و"2 عنصر" في الكود. المترجمون يحتاجون لرؤية الرسالة كاملة، لا التخمين كيف ستُركب.

خطط وجود =0 وone وother على الأقل، ووثّق ما تتوقعه لـ 0. بعض المنتجات تريد "0 عناصر"، وأخرى تريد "لا عناصر". اختر نمطًا واحدًا والتزم به حتى تبدو الواجهة متسقة.

راقب أيضًا اللغات التي لديها فئات جمع أكثر مما تتوقع. العديد من اللغات لا تتبع قاعدة "واحد مقابل كثير". إذا أضفت لغة جديدة لاحقًا، رسالة تحتوي فقط one وother قد تكون نحويًا خاطئة بالرغم من أنها تعرض.

قبل الإطلاق، اختبر الجمع بأعداد حقيقية في الواجهة، لا بمجرد التحديق في JSON. فحص سريع يلتقط معظم المشاكل هو: 0، 1، 2، 5، و21.

إذا طوّرت تطبيق ويب Vue3 (مثلاً داخل AppMaster)، قم بهذا الاختبار على الشاشة الفعلية حيث يظهر النص. تظهر مشاكل التخطيط، النص المقتطع، والصياغات المحرجة هناك أولًا.

تنظيم ملفات اللغة للنمو

بعد بضع مئات من السلاسل، يصبح ملف en.json الكبير عنق زجاجة. يلمس الناس نفس الملف، تتزايد تعارضات الدمج، وتفقد أين تعيش النصوص. بنية جيدة تحافظ على سير عمل i18n في Vue 3 ثابتًا حتى مع تغير المنتج.

هياكل مقترحة

بالنسبة لـ 2 إلى 5 لغات، التقسيم حسب الميزة عادة يكفي. احتفظ بنفس تخطيط الملفات في كل لغة حتى يكون إضافة مفتاح تحريرًا متوقعًا.

• locales/en/common.json, locales/en/auth.json, locales/en/billing.json
• locales/es/common.json, locales/es/auth.json, locales/es/billing.json
• locales/index.ts (يحمل ويُدمج الرسائل)

بالنسبة لأكثر من 20 لغة، طوّر نفس الفكرة لكن اجعل الانحراف أصعب. عامل الإنجليزية كمصدر للحقيقة وفرض أن كل لغة تعكس نفس اسم المجلد والملف. إذا ظهر نطاق جديد (مثلاً notifications)، يجب أن يوجد لكل لغة حتى لو كان النص مؤقتًا.

التقسيم حسب المجال يقلل صراعات الدمج لأن شخصين يمكنهما إضافة سلاسل في ملفات مختلفة دون التعارض. يجب أن تطابق المجالات بنية تطبيقك: common, navigation, errors, settings, reports، بالإضافة إلى مجلدات الميزات للمناطق الأكبر.

الحفاظ على اتساق المفاتيح

داخل كل ملف، حافظ على نفس شكل المفاتيح عبر اللغات: نفس التعشيش، نفس أسماء المفاتيح، نص مختلف. تجنّب المفاتيح "الإبداعية" لكل لغة، حتى لو كانت عبارة صعبة الترجمة. إذا احتاجت الإنجليزية billing.invoice.status.paid, كل لغة يجب أن تملك هذا المفتاح بالضبط.

ركز التجميع المركزي على ما يتكرر فعلاً في كل مكان: تسميات الأزرار، أخطاء التحقق العامة، والتنقل العام. حافظ على نصوص الميزات قرب مجال الميزة، حتى لو بدا أنها قابلة لإعادة الاستخدام. "حفظ" ينتمي إلى common. "حفظ طريقة الدفع" ينتمي إلى billing.

المحتوى الطويل

نصوص المساعدة الطويلة، خطوات الإعداد، وقوالب البريد الإلكتروني تتلف بسرعة. بعض القواعد تساعد:

• ضع السلاسل الطويلة في مجال منفصل (مثلاً help أو onboarding) وتجنّب التعشيش العميق.
• فضّل الفقرات القصيرة بدل سلسلة واحدة هائلة، حتى يعمل المترجمون بأمان.
• إذا كان قسم التسويق أو الدعم يحرر النص كثيرًا، ضع تلك الرسائل في ملف مخصص لتقليل التغيّر في أماكن أخرى.
• بالنسبة للبريد الإلكتروني، خزّن الموضوع والمحتوى بشكل منفصل وحافظ على اتساق العناصر النائبة (الأسماء، التواريخ، المبالغ).

هذا الإعداد يجعل من السهل مراجعة التغييرات، الترجمة تدريجيًا، وتجنب فجوات مفاجئة قبل الإصدار.

سير عمل خطوة بخطوة لإضافة ونشر السلاسل

سير عمل i18n ثابت في Vue 3 أقل ارتباطًا بالأدوات وأكثر ارتباطًا بتكرار نفس الخطوات الصغيرة في كل مرة. لا تصل نصوص الواجهة إلى الإنتاج دون مفتاح، ونص افتراضي، وحالة ترجمة واضحة.

ابدأ بإضافة المفتاح إلى لغتك الأساسية (غالبًا en). اكتب النص الافتراضي كنص حقيقي، لا كعنصر نائب. هذا يمنح المنتج وQA شيئًا مقروءًا للمراجعة، ويمنع "السلاسل الغامضة" لاحقًا.

عندما تستخدم المفتاح داخل مكوّن، أدرج المعاملات ومنطق الجمع منذ اليوم الأول حتى يرى المترجمون الشكل الكامل للرسالة.

// simple param
$t('billing.invoiceDue', { date: formattedDate })

// plural
$t('files.selected', count, { count })

إذا لم تكن الترجمات جاهزة، لا تترك مفاتيحًا مفقودة. أضف ترجمات مؤقتة في اللغات الأخرى أو وسمها كقيد (مثلاً بادئة TODO:). الجزء المهم هو أن التطبيق يقدم عرضًا متوقعًا والمراجعون يستطيعون رؤية النصوص غير المكتملة.

قبل الدمج، شغّل فحوصًا آلية سريعة. اجعلها مملة وصارمة: المفاتيح المفقودة عبر اللغات، المفاتيح غير المستخدمة، عدم تطابق العناصر النائبة (غياب {count}، {date}، أو أقواس خاطئة)، أشكال جمع غير صالحة للغات المدعومة، وتجاوزات عرضية.

وأجرِ نَسخة قصيرة من الواجهة بلغة غير أساسية واحدة على الأقل. اختر لغة بكلمات أطول (غالبًا الألمانية أو الفرنسية) لالتقاط مشاكل الامتداد، الأزرار المقتطعة، وانقطاع الأسطر. إذا كان واجهتك منتَجَة أو مُدارة بجانب أجزاء أخرى من المنتج (مثلاً تطبيق ويب Vue3 مُنتَج من AppMaster)، تظل هذه الخطوة مهمة لأن التخطيطات تتغير مع تطور الميزات.

عامل هذه الخطوات كتعريف الإنجاز لأي ميزة تضيف نصًا.

أخطاء شائعة تستمر الفرق في تكرارها

أسرع طريقة لجعل التعريب مؤلمًا هي معاملة مفاتيح i18n كـ "مجرد نصوص". بعد بضع مئات من المفاتيح، العادات الصغيرة تتحول إلى أخطاء في الإنتاج.

مفاتيح تنجرف، تتصادم، أو تكذب

الأخطاء المطبعية واختلاف حالة الأحرف أسباب كلاسيكية للنص المفقود: checkout.title في مكان، Checkout.title في مكان آخر. يبدو جيدًا في مراجعة الكود، ثم تُشحن لغتك الاحتياطية بهدوء.

مشكلة شائعة أخرى هي إعادة استخدام مفتاح واحد لمعاني مختلفة. "فتح" قد تعني "فتح تذكرة" في شاشة الدعم و"افتح الآن" في صفحة المتجر. إذا أعيد استخدام مفتاح واحد، ستكون إحدى الشاشتين خاطئة في لغات أخرى، وسيخمن المترجمون.

قاعدة بسيطة تساعد: مفتاح واحد يساوي معنى واحد. إذا تغيّر المعنى، أنشئ مفتاحًا جديدًا حتى لو كانت الإنجليزية نفسها.

أخطاء تخطيط تسببها افتراضات "مشكلة-على-هيئة-نص"

الفرق غالبًا تدخل علامات ترقيم، مسافات، أو أجزاء HTML داخل الترجمات. هذا يعمل حتى تحتاج لغة إلى علامات ترقيم مختلفة، أو يقوم واجهتك بالتعقيم أو بعرض الوسوم بشكل مختلف. احتفظ بقرارات الوسم في القوالب، واجعل الرسائل مركّزة على النص.

الموبايل هو المكان الذي تختبئ فيه المشاكل. وسم يناسب الإنجليزية قد ينكسر إلى ثلاث أسطر بالألمانية، أو يتجاوز الحد في التايلاندية. إذا اختبرت حجم شاشة واحد فقط، ستفوتها.

راقب المكررين: افتراض ترتيب كلمات الإنجليزية عند إدخال المتغيرات (أسماء، عدّاد، تواريخ)، بناء الرسائل بربط أجزاء بدل استخدام رسالة واحدة، نسيان اختبار القيم الطويلة (أسماء المنتجات، العناوين، تفاصيل الخطأ)، الشحن مع تراجع صامت ممكّن بحيث تبدو المفاتيح المفقودة "بخير" بالإنجليزية، والنسخ واللصق للمفاتيح مع تعديل قيمة الإنجليزية فقط.

إذا أردت سير عمل i18n في Vue 3 يظل هادئًا عند 500+ مفتاح، عامل المفاتيح كجزء من API لديك: مستقرة، محددة، ومختبرة كأي شيء آخر.

خطوات ضمان الجودة التي تكتشف الترجمات المفقودة مبكرًا

الترجمات المفقودة سهلة الفوت لأن التطبيق ما يزال "يعمل". لكنه يتراجع إلى المفتاح، اللغة الخاطئة، أو سلسلة فارغة. عامل تغطية الترجمات كالاختبارات: تريد تغذية راجعة سريعة قبل وصول أي شيء للإنتاج.

فحوص آلية (تشغّل على كل PR)

ابدأ بفحوص تفشل البناء، لا التي تطبع تحذيرات لا يقرأها أحد.

• امسح قاعدة الكود عن استخدامات $t('...') وt('...')، ثم تحقق أن كل مفتاح مستخدم موجود في اللغة الأساسية.
• قارن مجموعات المفاتيح عبر اللغات وافشل إذا كانت أي لغة تفتقد مفاتيح (ما لم يكن المفتاح في قائمة استثناء قصيرة ومراجَعَة مثل "en-only legal notes").
• علم المفاتيح اليتيمة الموجودة في ملفات اللغة ولكنها غير مستخدمة.
• تحقق من صحة تركيب الرسائل (العناصر النائبة، كتل ICU/الجمع). رسالة واحدة مكسورة قد تعطل الصفحة في وقت التشغيل.
• اعتبر المفاتيح المكررة أو اختلافات حالة الأحرف كأخطاء.

اجعل قائمة الاستثناء قصيرة ومملوكة من الفريق، لا "ما يمر في CI".

فحوص وقت التشغيل والبصرية (staging)

حتى مع CI، لا تزال تريد شبكة أمان في staging لأن مسارات المستخدم الحقيقية تطلق سلاسل ربما نسيت أنها ديناميكية.

فعل تسجيل الترجمات المفقودة في staging وضمّن سياقًا كافيًا للإصلاح سريعًا: اللغة، المسار، اسم المكوّن (إن أمكن)، والمفتاح المفقود. اجعله مزعجًا. إذا سهل تجاهله، سيُتجاهل.

أضف شبه-لغة (pseudo-locale) واستخدمها لمرور سريع على الواجهة. نهج بسيط هو تحويل كل نص (جعله أطول وإضافة علامات) حتى تقفز مشاكل التخطيط، مثلاً: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]. هذا يلتقط الأزرار المقتطعة، رؤوس الجداول المكسورة، والمسافات المفقودة قبل الشحن.

أخيرًا، قم بتمرير معاينة قصيرة قبل الإصدار لأهم المسارات في 2-3 لغات: تسجيل الدخول، الدفع/الخروج، الإعدادات الأساسية، والميزة الجديدة التي تُطلق. هنا تكتشف أخطاء مثل "ترجمت لكنها تحتوي على عنصر نائب خاطئ".

التعامل مع لغات جديدة وتغييرات النص المستمرة

إضافة لغة جديدة تتعقد عندما تعاملها كـ "عمل نصّي" بدل إصدار منتج صغير. أسهل طريقة للحفاظ على استقرار i18n في Vue 3 هي جعل التطبيق يبنى حتى لو كانت اللغة ناقصة، مع إبقاء الفجوات واضحة قبل رؤية المستخدمين لها.

عند إضافة لغة جديدة، ابدأ بتوليد نفس شكل الملفات كما في المصدر (غالبًا en). لا تترجم أولًا، هيكل أولًا.

• أنشئ مجلد/ملف اللغة الجديد بمجموعة المفاتيح الكاملة من المصدر.
• وسم القيم كعناصر TODO حتى تكون السلاسل المفقودة مرئية في QA.
• أضِف اللغة إلى مختار اللغات فقط بعد تغطية الأساسيات.
• نفّذ تمريرة شاشة بشاشة لالتقاط مشاكل التخطيط (كلمات أطول، التفاف).

الترجمات غالبًا تصل متأخرة، فقرر مسبقًا ما معنى "جزئي" لمنتجك. إذا كانت ميزة موجهة للعملاء، ضع في اعتبارك فلاغ ميزة حتى تُشحن الميزة ونصوصها معًا. إذا اضطررت للشحن دون ترجمات كاملة، فضّل تراجعًا واضحًا (مثل الإنجليزية) على التسميات الفارغة، لكن اجعل ذلك صاخبًا في staging.

تغييرات النص هي المكان الذي تكسر فيه الفرق المفاتيح. إذا غيرت صياغة، احتفظ بالمفتاح ثابتًا. يجب أن تصف المفاتيح النية، لا الجملة بالضبط. احفظ إعادة تسمية المفتاح للحالات التي يتغير فيها المعنى، وحتى ذلك الحين، قم بترحيل منضبط.

لتجنّب "السلاسل الزومبي"، قم بإهمال المفاتيح عمداً: وسمها كمُهملة مع تاريخ واستبدال، احتفظ بها لدورة إصدار واحدة، ثم أزلها بعد التأكد من عدم وجود أي إشارات.

احتفظ بملاحظات الترجمة قريبة من المفتاح. إذا كان تنسيق JSON لا يدعم التعليقات، خزّن الملاحظات في مستند مرافق صغير أو ملف بيانات مجاور (مثلاً "يستخدم في شاشة نجاح الدفع"). هذا مفيد خصوصًا عندما يُولَّد تطبيق Vue 3 من أداة مثل AppMaster ويعمل عدة أشخاص على النص والواجهة.

مثال: إطلاق ميزة بـ 60 سلسلة جديدة

في سبرينت واحد، يطلق فريقك ثلاث أمور معًا: صفحة إعدادات جديدة، شاشة فواتير، وثلاثة قوالب بريد إلكتروني (إيصال، فشل الدفع، انتهاء التجربة). هذا حوالي 60 سلسلة، وهنا يبدأ عادة فوضى i18n.

اتفقت الفريق على تجميع المفاتيح حسب الميزة ثم حسب سطح الواجهة. أنشئ ملفًا جديدًا لكل ميزة، وتلتزم المفاتيح بنفس النمط في كل مكان: feature.area.element.

// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",

// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",

// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"

قبل بدء الترجمة، تُختبر سلاسل الجمع بقيم حقيقية، لا بتخمينات. بالنسبة لـ billing.invoice.count، يختبر QA الأرقام 0، 1، 2، و5 باستخدام بيانات مهيأة (أو تبديل مطور بسيط). هذا يلتقط حالات محرجة مبكرًا، مثل "0 invoice".

ثم يقوم QA بجريان مركز يكشف عادة المفاتيح المفقودة: افتح Settings وBilling وانقر كل تبويب مرة، فعّل كل قالب بريد إلكتروني في staging بحسابات اختبار، شغّل التطبيق بلغة غير افتراضية، وأفشل البناء إذا ظهرت أي تحذيرات ترجمة مفقودة في السجلات.

في هذا السبرينت، يعثر QA على مفتاحين مفقودين: وسم واحد على شاشة Billing وموضوع بريد إلكتروني واحد. يصلح الفريقهما قبل الإصدار.

عند تقرير ما إذا كان يجب حظر الإصدار أو السماح بالتراجع، يستخدمون قاعدة بسيطة: الشاشات الموجهة للمستخدم ورسائل البريد الحركية تحظر الإصدار؛ نصوص الإدارة منخفضة المخاطر يمكن أن تتراجع مؤقتًا إلى اللغة الافتراضية، لكن فقط مع تذكرة وموعد نهائي واضح.

الخطوات التالية وقائمة تحقق بسيطة للإصدار

سير عمل i18n في Vue 3 يبقى ثابتًا عندما تعامل الترجمات ككود: أضفها بنفس الطريقة في كل مرة، اختبرها، وراقب النتائج.

قائمة التحقق للإصدار (قبل الدمج بخمس دقائق)

• المفاتيح: اتبع نمط التسمية، وحافظ على نطاق واضح (صفحة، ميزة، مكوّن).
• الجمع: تأكد أن أشكال الجمع تعرض بشكل صحيح على الأقل في لغة واحدة ذات قواعد جمع مختلفة.
• العناصر النائبة: تحقق أن المتغيرات موجودة، مسماة بنفس الشكل في كل مكان، وتبدو صحيحة ببيانات حقيقية.
• التراجعات: أكد أن سلوك المفتاح المفقود يطابق سياستك الحالية.
• الشاشات: افحص سريعًا الشاشات الأكثر عرضة للكسر (الجداول، التوستات، النوافذ المنبثقة، الحالات الفارغة).

قرر ما ستقيسه (لكي تظهر المشاكل مبكرًا)

اختر بعض الأرقام البسيطة وراجعها بانتظام: معدل المفاتيح المفقودة في اختبارك، عدد السلاسل غير المترجمة في اللغات غير الافتراضية، وعدد المفاتيح غير المستخدمة. راقبها لكل إصدار إن أمكن، حتى ترى الاتجاهات بدل الأخطاء المتفرقة.

اكتب الخطوات الدقيقة لإضافة سلسلة، تحديث الترجمات، والتحقق من النتيجة. اجعلها قصيرة، وضمّن أمثلة لأسماء المفاتيح واستخدام الجمع. يجب أن يستطيع المساهمون الجدد اتباعها دون سؤال.

إذا طورت أدوات داخلية، AppMaster (appmaster.io) يمكن أن يكون وسيلة عملية للحفاظ على تناسق نصوص الواجهة ومفاتيح الترجمة عبر تطبيق ويب Vue3 وتطبيقات محمولة مصاحبة، لأن كل شيء يُدار في مكان واحد.

حدد مهمة صحة i18n صغيرة كل سبرينت: احذف المفاتيح الميتة، صحّح العناصر النائبة غير المتناسقة، واستعرض الإغلاقات الأخيرة. التنظيفات الصغيرة تفوق مطاردات الترجمة الطارئة في الإنتاج.