15 أبريل 2025·8 دقيقة
بناء تطبيقات متعددة اللغات والمناطق بمساعدة الذكاء الاصطناعي: دليل عملي
تعلم نهجًا عمليًا للتدويل، التوجيه الإقليمي، قواعد البيانات الإقليمية، وسير عمل المحتوى—مع استخدام الذكاء الاصطناعي لتسريع الترجمات وتقليل الأخطاء.
تعلم نهجًا عمليًا للتدويل، التوجيه الإقليمي، قواعد البيانات الإقليمية، وسير عمل المحتوى—مع استخدام الذكاء الاصطناعي لتسريع الترجمات وتقليل الأخطاء.
تطبيق متعدد اللغات يتعلق في الأساس بالـ لغة: نصوص واجهة المستخدم، الرسائل، الإيميلات، محتوى المساعدة، وأي نص يُنشئه المستخدم أو النظام ويجب أن يقرأ بشكل طبيعي بأكثر من لغة.
تطبيق متعدد المناطق يتعلق بـ أين وتحت أي قواعد تُقدَّم التجربة. تؤثر المنطقة في أكثر من مجرد الترجمة: العملة والضرائب، المناطق الزمنية وتنسيقات التواريخ، وحدات القياس، توفر الميزات، توطين البيانات ومتطلبات الخصوصية، وحتى صياغة نصوص قانونية.
فكّر في اللغة كـ “كيف نتواصل”، والمنطقة كـ “ما القواعد المطبقة”. يمكنك أن تملك:
الفرق الشائع بين الفرق أن الكثير من الأشياء "تعتمد على الـ locale". المسألة ليست سلاسل النص فقط:
يمكن للذكاء الاصطناعي إزالة الكثير من العمل المكرر: صياغة الترجمات، اقتراح مصطلحات متسقة، اكتشاف السلاسل غير المترجمة، وتسريع التكرار في سير التوطين. قوّته الأكبر في الأتمتة وفحوصات الاتساق.
لكنه ليس سحريًا؛ لا يزال مطلوبًا وجود نص مصدر واضح، جهة مسؤولة عن النصوص القانونية/الامتثال، ومراجعة بشرية للمحتوى عالي المخاطر.
هذا الدليل يبقى عمليًا: أنماط يمكنك تطبيقها، مقايضات يجب مراقبتها، وقوائم فحص يمكنك إعادة استخدامها عند الانتقال من التعريفات إلى التوجيه، وتوطين البيانات، والمدفوعات، وسير عمل الترجمات القابل للتوسع.
قبل اختيار الأدوات (أو تنبيه مترجم AI)، حدّد بوضوح ما الذي يعنيه "مختلف" لمنتجك. يفشل عمل متعدد اللغات/المناطق غالبًا عندما تفترض الفرق أنه نص واجهة المستخدم فقط.
ابدأ بجرد سريع لما يختلف عبر اللغات والمناطق:
en-GB مقابل en-US) وفي أي دول ستعمل.\n- العملات وقواعد التسعير: عرض العملة، التقريب، شرائح السعر، وهل الضرائب مضمنة أم لا.\n- الضرائب والفواتير: التعامل مع ضريبة القيمة المضافة/GST، حقول الفاتورة، أسماء الكيان القانوني.\n- قيود الامتثال: توطين البيانات، بوابات السن، متطلبات الموافقة، قواعد الحفظ.\n- الاحتياجات التشغيلية: ساعات دعم محلية، طرق التصعيد، واختلافات اتفاقيات مستوى الخدمة.اكتب هذه العناصر كـ "ضروري" مقابل "لاحق"، لأن تمدد النطاق هو أسرع طريقة لإبطاء الإصدارات.
اختر بعض المقاييس التي يمكن تتبعها من اليوم الأول:
كن صريحًا حول الأسطح، وليس مجرد "التطبيق":
سلاسل واجهة المستخدم، الدمج، رسائل المعاملات، الفواتير/الإيصالات، إشعارات الدفع، مستندات المساعدة، صفحات التسويق، رسائل الخطأ، وحتى لقطات الشاشة في الوثائق.
المصفوفة تحافظ على توافق الجميع بشأن التوليفات التي تدعمها فعليًا.
| Locale | Region | Currency | ملاحظات |
|---|---|---|---|
| en-US | US | USD | التعامل مع ضريبة المبيعات يختلف حسب الولاية |
| en-GB | GB | GBP | ضريبة القيمة المضافة مضمنة في عرض السعر |
| fr-FR | FR | EUR | نبرة رسمية، صفحات قانونية محلية |
| es-MX | MX | MXN | طرق دفع محلية مطلوبة |
تصبح هذه المصفوفة عقد النطاق: التوجيه، التنسيق، الامتثال، المدفوعات، وQA يجب أن تشير إليها.
أساس i18n هو الجزء "الممل" الذي يمنع إعادة كتابة مكلفة لاحقًا. قبل ترجمة أي سلسلة، قرّر كيف سيحدد منتجك لغة وتفضيلات إقليمية للمستخدمين، كيف يتصرّف عند فقدان شيء ما، وكيف ينسق المعلومات اليومية (المال، التواريخ، الأسماء) بشكل ثابت.
ابدأ بتقرير ما إذا كانت locales لديك بناءً على اللغة فقط (مثل fr) أو لغة-منطقة (مثل fr-CA). اللغة فقط أبسط، لكنها تنهار عندما تكون الاختلافات الإقليمية مهمة: تهجئة، نص قانوني، ساعات الدعم، وحتى نبرة واجهة المستخدم.
نهج عملي:
language-region للأسواق ذات الفروقات المعنوية (en-US, en-GB, pt-BR, pt-PT).\n- استخدم اللغة فقط عندما تكون متأكدًا أن الفروقات طفيفة ولن تحتاج محتوى منفصلًا قريبًا.ينبغي أن تكون قواعد العودة متوقعة لكل من المستخدمين والفريق. عرّف:\n\n- عودة السلاسل: إذا كانت fr-CA تفتقد مفتاحًا، هل تعود إلى fr ثم en؟\n- عودة المحتوى: إن لم يُترجم مقال أو FAQ، هل تعرض اللغة الافتراضية، تخفيه، أم تعرض رسالة "غير متاح"؟\n- عودة التنسيقات: تجنّب المزج (مثال: نص فرنسي مع تنسيقات تواريخ أمريكية).
استخدم مكتبات تراعي الـ locale لـ:\n\n- التواريخ والأوقات (بما في ذلك المناطق الزمنية)\n- الأرقام والفواصل العشرية\n- التصريفات والاختلافات النحوية\n- الأسماء والعناوين (لا تفترض "الاسم الأول/الاسم الأخير" أو سطر عنوان واحد)
اجعل المفاتيح مستقرة ووصفية، لا مرتبطة بصياغة إنجليزية. مثال:
checkout.payment_method.title
errors.rate_limit.body
settings.notifications.email.label
وثّق مكان وجود الملفات (مثال: /locales/{locale}.json) وفرض الاصطلاحات في مراجعة الكود. هذا هو الأساس الذي يجعل سير عمل الترجمة المدعوم بالذكاء الاصطناعي أكثر أمانًا وأسهل لأتمتته لاحقًا.
توجيه جيد يجعل التطبيق يبدو "محليًا" دون أن يضطر المستخدمون للتفكير في ذلك. الخدعة هي فصل اللغة (ما يقرأه الناس) عن المنطقة (القواعد والتسعير وتخزين البيانات).
ثلاث طرق شائعة لاختيار المنطقة، وكثير من المنتجات تدمج بينها:
قاعدة عملية: تذكّر آخر اختيار صريح، ولا تجرِّب الاكتشاف التلقائي إلا عندما لا يكون لديك إشارة أفضل.
اختر استراتيجية URL مبكرًا لأن تغييرها لاحقًا يؤثر على SEO والروابط المشتركة.
/en-us/…, /fr-fr/… (بسيطة للاستضافة، واضحة للمستخدم؛ تعمل جيدًا مع CDN)\n- نطاقات فرعية: us.example.com, fr.example.com (فصل نظيف؛ يتطلب إعداد DNS/شهادات وتحليل أكثر)\n- معاملات استعلام: ?lang=fr®ion=CA (سهلة التنفيذ، لكنها أضعف للـ SEO وأقل قابلية للمشاركة)لمعظم الفرق، بادئات المسارات هي الافتراض الأفضل.
بالنسبة للصفحات الموطّنة، خطط:\n\n- canonical ذاتي المرجع لكل URL محلي لتجنب التكرار العرضي.\n- مجموعة hreflang تربط كل المتغيرات اللغوية/الإقليمية، بالإضافة إلى x-default كخيار افتراضي.
توجيه الواجهة الأمامية يقرر ما يراه المستخدم، لكن توجيه المنطقة يقرر إلى أين تُرسَل الطلبات. مثال: مستخدم على /en-au/ يجب أن يصل إلى خدمة التسعير للأستراليا، قواعد الضرائب الأسترالية، وعند الحاجة تخزين بيانات في أستراليا—حتى وإن كانت واجهة المستخدم بالإنجليزية.
حافظ على الاتساق بتمرير قيمة "المنطقة" واحدة عبر الطلبات (رأس، مطالبة توكن، أو جلسة) واستخدمها لاختيار نقاط النهاية المناسبة وقواعد قواعد البيانات.
توطين البيانات يعني أين تُخزَّن وتُعالَج بيانات عملائك. بالنسبة للتطبيقات متعددة المناطق، هذا مهم لأن بعض المنظمات (وبعض القوانين) تتوقع أن تظل بيانات الأشخاص في بلد أو منطقة اقتصادية معينة، أو على الأقل تُعالَج بحماية إضافية.
كما أنه مسألة ثقة: العملاء يريدون أن يعرفوا أن بياناتهم لن تُنقل عبر الحدود بدون علم.
ابدأ بسرد ما تجمعه وأين ينتهي به المطاف. فئات حساسة شائعة:
ثم خرّط تلك الفئات إلى مواقع التخزين: قاعدة البيانات الأساسية، أدوات التحليلات، السجلات، مستودع البيانات، فهرس البحث، النسخ الاحتياطية، والمزودين الخارجيين. كثير من الفرق تنسى أن السجلات والنسخ الاحتياطية قد تنتهك توقعات التوطين إذا كانت مركزية.
ليس هناك نهج واحد "صحيح"؛ بل تحتاج سياسة واضحة وتنفيذ يطابقها.
احتفظ بمستخدمي الاتحاد الأوروبي في مخازن بيانات داخل الاتحاد، ومستخدمي الولايات المتحدة في مخازن داخل الولايات المتحدة، الخ. هذا أوضح لقواعد التوطين لكنه يزيد التعقيد التشغيلي.
استخدم أقسام/مخططات مبنية على المنطقة وفرض "منع القراءات/الكتابات العابرة" على طبقة التطبيق وعن طريق قواعد IAM.
خزن البيانات في أي مكان، لكن احتفظ بمفاتيح تشفير خاصة بكل منطقة بحيث لا تستطيع الخدمات خارج المنطقة فك تشفير الحقول الحساسة. هذا يقلل المخاطر، لكنه قد لا يفي بمتطلبات التوطين الصارمة وحده.
عامل الامتثال كمجموعة متطلبات يمكنك اختبارها:\n\n- وثّق تدفقات البيانات والمُعالِجين الفرعيين (انظر /security)\n- حدّد سياسات الحفظ والحذف حسب المنطقة\n- تأكّد من وجود تقارير عن الخروقات، ضوابط الوصول، وسجلات التدقيق
احصل على استشارة قانونية لحالتك الخاصة—هذا القسم يهدف لبناء الأساس التقني دون تقديم وعود لا يمكنك التحقق منها.
المدفوعات والتسعير هي حيث يصبح "متعدد المناطق" واقعًا ملموسًا. مستخدمان قد يقرأان نفس صفحة المنتج بنفس اللغة لكن يحتاجان أسعارًا مختلفة، ضرائب مختلفة، فواتير مختلفة، وطرق دفع محلية تختلف حسب مكانهما.
قبل البناء، اذكر البنود التي تختلف حسب البلد/المنطقة وقرّر من "يمتلك" كل قاعدة (المنتج، المالية، القانون). الاختلافات الشائعة:
هذا الجرد يصبح مصدر الحقيقة ويمنع الاستثناءات العشوائية في واجهة المستخدم.
قرّر إن كنت ستحافظ على قوائم أسعار إقليمية (موصى به لهوامش متوقعة) أو تحول من عملة أساسية. إن اخترت التحويل، حدد:\n\n- مصدر سعر الصرف وتكرار التحديث\n- قواعد التقريب (لكل بند أم للمجموع)\n- التسعير النفسي (مثال: 9.99) والحدود الدنيا للرسوم
اجعل هذه القواعد متسقة عبر صفحة الدفع، الإيميلات، الفواتير، وعمليات الاسترداد. أسوأ طريقة لفقدان الثقة هي إجمالي يتغير بين الشاشات.
تجربة الدفع غالبًا ما تنهار عند النماذج والتحقق. خصّص:\n\n- تنسيقات العناوين (الرموز البريدية، الولاية/المقاطعة، حقول الشقة)\n- تنسيقات أرقام الهاتف ومطلوبية رمز البلد\n- الحقول المطلوبة لفحوصات الاحتيال أو الفوترة (الهوية الضريبية، اسم الشركة)
إن كنت تستخدم صفحات دفع طرف ثالث، تأكّد أنها تدعم locales وقواعد الامتثال الإقليمية لديك.
بعض المناطق تتطلب تعطيل ميزات، إخفاء منتجات، أو عرض شروط مختلفة. نفّذ الحجب كقاعدة عمل واضحة (مثال: بحسب بلد الفوترة)، لا بحسب اللغة.
يمكن للذكاء الاصطناعي مساعدة في تلخيص متطلبات المزودين وصياغة جداول القواعد، لكن اجعل البشر يوافقون على أي شيء يؤثر على الأسعار أو الضرائب أو النصوص القانونية.
توسيع التوطين يتعلق أقل بالترجمة الأسرع، وأكثر بالحفاظ على المحتوى متوقعًا: ما الذي يُترجم، من قبل من، وكيف تنتقل التغييرات من المسودة إلى الإنتاج.
عامل نصوص واجهة المستخدم القصيرة (أزرار، أخطاء، تنقل) كـ سلاسل كود تُشحن مع التطبيق، عادةً في ملفات ترجمة تدار في المستودع. احتفظ بصفحات التسويق، مقالات المساعدة، والنصوص الطويلة في نظام إدارة محتوى (CMS) حيث يمكن للمحررين العمل دون نشرات جديدة.
هذا الانقسام يمنع فشل شائع: مهندسون يحررون محتوى CMS "لتصحيح ترجمة"، أو محررون يغيرون نص واجهة المستخدم الذي يجب أن يُنسخ مع الإصدارات.
دورة حياة قابلة للتوسع بسيطة وقابلة للتكرار:
اجعل الملكية صريحة:
التوطين يُكسر عندما لا تستطيع الفرق معرفة ما الذي تغيّر. رقم السلاسل بجانب الإصدارات، احتفظ بسجل تغييرات للنص المصدر، وتعقب حالة الترجمة لكل locale. حتى قاعدة خفيفة—"لا تغيّر نص المصدر بدون تذكرة"—تقلّل من مفاجآت الانحدار وتحافظ على تزامن اللغات.
يمكن للذكاء الاصطناعي إزالة الكثير من العمل المتكرر لكن فقط عندما تعامل معه كمساعد، لا كمرجع نهائي. الهدف هو تسريع التكرار دون السماح بتآكل الجودة عبر اللغات أو المناطق أو أسطح المنتج.
إذا كنت تبني أسطحًا جديدة بسرعة، فهذا أيضًا المكان الذي يساعد فيه "vibe-coding"—منصات مثل Koder.ai تتيح للفرق تصميم ونشر تدفقات التطبيق عبر الدردشة، ثم التكرار على التوطين والتوجيه وقواعد المنطقة دون الانغماس في بناء يدوي بطيء. الجزء المهم يبقى نفسه: اجعل قرارات locale/region صريحة، ثم أتمتة الأعمال المجهدة.
صياغة الترجمات على نطاق واسع مناسبة جدًا. زوّد أداة AI بالقاموس (مصطلحات معتمدة، أسماء منتجات، عبارات قانونية) ودليل نغمة (رسمي مقابل ودي، مواجهة بـ "أنت" أم "نحن"، قواعد علامات الترقيم). ضمن هذه القيود، يمكن للـ AI إنتاج ترجمات أولية كافية لمراجعة سريعة.
AI مفيد أيضًا في العثور على المشاكل قبل أن يفعل المستخدمون:\n\n- مفاتيح ترجمة مفقودة أو سلاسل تعود للغة افتراضية دون قصد\n- مصطلحات غير متسقة (مثال: "workspace" مقابل "project")\n- عناصر نائب مكسورة أو تنسيق خاطئ (مثل {name} يختفي)\n- تغيّرات طول مريبة قد تكسر واجهات المستخدم
أخيرًا، يمكن للـ AI اقتراح متغيرات مناسبة لكل منطقة. مثلاً، يمكنه اقتراح اختلافات en-US مقابل en-GB ("Zip code" مقابل "Postcode") مع الحفاظ على المعنى. اعتبر هذه الاقتراحات، لا استبدالات تلقائية.
بعض المحتوى يحمل مخاطر منتجية أو قانونية أو سمعة ويجب ألا يُنشر بدون موافقة بشرية:\n\n- صفحة الدفع، التسعير، الضرائب، ونص الإلغاء\n- بيانات الأمن/الخصوصية، نصوص الموافقة، وإشعارات الامتثال\n- تعليمات الدعم التي قد تسبب فقدان بيانات ("حذف"، "إعادة ضبط"، "إلغاء")
حارس عملي بسيط: AI يصيغ، والبشر يوافقون على المحتوى الحرج. اجعل الموافقات صريحة في سير العمل (مثال: حالة "مُراجَع" لكل سلسلة أو لكل صفحة) حتى تتحرك بسرعة دون التخمين ما الآمن نشره.
الاتساق هو ما يجعل التطبيق المترجم يبدو "محليًا" بدلًا من مجرد مترجم. يلاحظ المستخدمون حين تكون نفس الزر "Checkout" في شاشة و"Pay" في أخرى، أو حين تتقلب المقالات بين لغة ودية ولغة رسمية بشكل مريب.
ابدأ معجمًا يشمل مصطلحات المنتج ("workspace", "seat", "invoice"), عبارات قانونية، ولغة الدعم. أضف تعريفات، ترجمات مسموح بها، وملاحظات مثل "لا تُترجم" لأسماء العلامات أو الرموز التقنية.
اجعل المعجم متاحًا لكل من يكتب: المنتج، التسويق، القانون، والدعم. عندما يتغير مصطلح (مثال: "Projects" تصبح "Workspaces"), حدّث المعجم أولًا ثم الترجمات.
النبرة ليست عالمية. قرّر—لكل لغة—هل تستخدم مخاطبة رسمية أم غير رسمية، طول الجمل المفضل، قواعد علامات الترقيم، وكيف تتعامل مع كلمات إنجليزية معارة.
اكتب دليل نمط قصير لكل locale (صفحة واحدة كافية):\n\n- الصوت: ودي أم موثوق\n- الرسمية: أمثلة عن مخاطبة "tu" مقابل "vous"، "du" مقابل "Sie"\n- اعراف واجهة المستخدم: حالة العنوان، الاختصارات، الأرقام
ذاكرة الترجمة تخزن الترجمات المعتمدة لعبارات مكررة حتى تُنتج نفس النص عند تكرار المصدر. هذا ذو قيمة خاصة لـ:\n\n- تسميات التنقل وأزرار الدعوة إلى الإجراء (CTA)\n- رسائل الخطأ ونصوص التحقق\n- بنود قانونية متكرّرة
TM تقلّل التكلفة ووقت المراجعة، وتساعد مخرجات AI على الالتزام بقرارات سابقة.
هل "Close" فعل (إغلاق مودال) أم صفة (قريب)؟ قدّم سياقًا عبر لقطات شاشة، حدود حروف، وموقع الواجهة. فضّل المفاتيح البنيوية والبيانات الوصفية بدلًا من لصق السلاسل في جدول—المترجمون والـ AI ينتجون نواتج أفضل وأكثر اتساقًا عندما يعرفون المقصد.
أخطاء التوطين غالبًا ما تبدو "صغيرة" حتى تصل للمستخدمين: إيميل دفع بلغة خاطئة، تاريخ يُحلل بطريقة خاطئة، أو تسمية زر مقطوعة على الجوال. الهدف ليس تغطية مثالية من اليوم الأول—بل اعتماد نهج اختباري يلتقط أغلاط التكلفة العالية تلقائيًا، ويُبقي الاختبار اليدوي للجزء الإقليمي الحقيقي.
تمدد النصوص واختلاف السكريبتات هي أسرع طريقة لكسر الواجهات.
"pseudo-locale" خفيف (سلاسل أطول + أحرف مزخرفة) هو بوابة CI ممتازة لأنه يجد المشاكل دون الحاجة لترجمات حقيقية.
التوطين ليس مجرد نص—إنه يغير التحليل والترتيب.
أضف فحوصات سريعة تعمل على كل PR:\n\n- الترجمات المفقودة لكل locale (افشل البناء للشاشات "المطلوبة")\n- المفاتيح غير المستخدمة (حافظ على الكتالوج نظيفًا)\n- عدم تطابق العناصر النائبة (مثال: {count} موجودة في لغة وغير موجودة في أخرى)
هذه حمايات بسيطة تمنع انحدارات "تعمل بالإنجليزية فقط".
خطط جولات مستهدفة لكل منطقة للFlows حيث القواعد المحلية مهمة جدًا:
احتفظ بقائمة فحص صغيرة وقابلة للتكرار لكل منطقة وقُم بتشغيلها قبل توسيع النشر أو تغيير التسعير/الامتثال.
تطبيق متعدد اللغات والمناطق قد يبدو "سليمًا" إجمالًا بينما يفشل بشكل سيئ للـ locale أو الجغرافيا واحدة. تحتاج المراقبة لتقطيع حسب locale (اللغة + قواعد التنسيق) وregion (أين تُخدم الحركة، أين تُخزن البيانات، وأين تُعالج المدفوعات)، حتى تكتشف المشاكل قبل أن يبلغك المستخدمون.
أدخِل المقاييس الأساسية للمنتج مع وسوم locale/region: إتمام الشراء، معدل الانسحاب عند التسجيل، نجاح البحث، واعتماد الميزات الرئيسية. اقترن هذه بالمؤشرات التقنية مثل معدلات الخطأ والكمون. تراجع كمون صغير في منطقة واحدة قد يخفض التحويل في تلك السوق.
للحفاظ على لوحات قابلة للقراءة، أنشئ "عرضًا عالميًا" بالإضافة إلى بعض القطاعات ذات الأولوية (أهم اللغات، أحدث منطقة، أعلى الأسواق إيرادًا). كل شيء آخر للتفصيل.
مشاكل الترجمة غالبًا ما تكون صامتة. سجّل واتّبع:
ارتفاع مفاجئ في استخدام fallback بعد إصدار هو إشارة قوية أن الحزمة المحلية لم تُحدَّث في البناء.
اضبْط تنبيهات محددة بالمنطقة لحالات توجيه وCDN (مثال: 404/503 مرتفعة، مهلات المنشأ)، بالإضافة لإخفاقات موفرين محددة مثل رفضات دفع ناجمة عن تعطل أو تغيير تكوين إقليمي. اجعل التنبيهات قابلة للتنفيذ: ضع المنطقة المتأثرة، الـ locale، وآخر نشر/تغيير بعلامة ميزة.
وسم تذاكر الدعم تلقائيًا حسب اللغة/المنطقة ووجّهها إلى القائمة الصحيحة. أضف مطالبات خفيفة داخل التطبيق ("هل كانت هذه الصفحة واضحة؟") موزعة محليًا، حتى تلتقط الالتباس الناتج عن الترجمة أو المصطلحات أو التوقعات المحلية—قبل أن يصبح سببًا لفقدان المستخدمين.
تطبيق متعدد اللغات والمناطق ليس "مكتملًا" أبداً—إنه منتج يتعلم باستمرار. هدف النشر هو تقليل المخاطر: قدّم شيئًا صغيرًا يمكنك مراقبته، ثم وسّع بثقة.
ابدأ بإطلاق "شق رفيع": لغة واحدة + منطقة إضافية بخلاف سوقك الأساسي. يجب أن يشمل هذا الشق الرحلة الكاملة (التسجيل، التدفقات الرئيسية، نقاط الدعم، والفوترة إن اقتضى الأمر). ستكتشف مشكلات لا تظهر في المواصفات أو لقطات الشاشة: تنسيقات التواريخ، حقول العنوان، رسائل الخطأ، وصياغات قانونية لحالات الحواف.
عامل كل توليفة locale/region كوحدة إصدار مضبوطة. أعلام الميزات بحسب locale/region تمكّنك من:\n\n- تفعيل ترجمات جديدة لمجموعة تجريبية فقط\n- الرجوع السريع إذا كسرت سلسلة واجهة المستخدم التخطيط أو المعنى\n- مقارنة مقاييس التحويل/الدعم عبر المناطق دون انتظار نشر عالمي
إذا كنت تستخدم الأعلام بالفعل، أضف قواعد استهداف لـ locale, country, وcurrency عند الحاجة.
أنشئ حلقة صيانة خفيفة حتى لا ينحرف التوطين:\n\n- التحديثات: كل سلسلة واجهة جديدة تدخل خط الأنابيب (المصدر → المراجعة → النشر)\n- إعادة الترجمة: عند تغيير المعنى، فرض موافقة جديدة (لا تعيد استخدام ترجمات قديمة دون مراجعة)\n- الإيقاف: احذف المفاتيح غير المستخدمة بانتظام حتى لا يضيع جهد المترجمين\n- الملكية: عيّن من يوافق تغييرات المعجم/النبرة ومن يمكنه نشر تجاوزات إقليمية
الخطوات التالية: حوّل هذه القائمة إلى خطة إصدار يستخدمها فريقك فعليًا، واحتفظ بها قرب خارطة الطريق (أو أضفها إلى مستنداتك الداخلية). إن أردت أفكارًا إضافية لسير العمل، انظر /blog.
تطبيق متعدد اللغات يغير كيفية عرض النص (سلاسل واجهة المستخدم، الرسائل، الوثائق) عبر لغات مختلفة. تطبيق متعدد المناطق يغير القواعد المطبقة اعتمادًا على المكان الذي يُقدَّم إليه العميل—العملة، الضرائب، التوفر، الامتثال، وموقع تخزين البيانات. كثير من المنتجات تحتاج الاثنتين معًا، والتحدي الحقيقي هو فصل اللغة عن منطق الأعمال الإقليمي.
ابدأ بمصفوفة بسيطة تسرد التوليفات التي ستدعمها فعلاً (مثال: en-GB + GB + GBP). أضف ملاحظات عن الفروقات الجوهرية (الضريبة مضمنة أم تُضاف، نسخ الصفحات القانونية، طرق الدفع المطلوبة). اعتبر هذه المصفوفة عقد نطاق تُشير إليه التوجيهات والتنسيق والدفع والاختبار.
فضّل language-region عندما تكون الفروقات الإقليمية مهمة (تهجئة، نصوص قانونية، سلوك الدعم، قواعد التسعير)، مثل en-US مقابل en-GB أو pt-BR مقابل pt-PT. استخدم locales بدون جزء المنطقة (fr) فقط عندما تتأكد أن الاختلافات بسيطة ولن تحتاج متغيرات إقليمية قريبًا، لأن التقسيم لاحقًا قد يسبب تعطيلًا.
حدد ثلاثة أنواع من قواعد العودة (fallbacks) بشكل صريح ووضّحها:
fr-CA → fr → en.اكتب هذه القواعد حتى يتوقعها المهندسون وفرق QA والدعم بنفس الطريقة.
استخدم مكتبات تراعي الـ locale لـ:
كما قرّر من أين يأتي قيمة "المنطقة" (إعداد الحساب، اختيار المستخدم، اقتراح GeoIP) بحيث تتطابق التنسيقات مع قواعد المنطقة التي تطبّقها في الخدمات الخلفية.
الافتراض الافتراضي هو مُسبق المسارات (path prefixes) مثل /en-us/... لأنها واضحة، صديقة لـ CDN، وقابلة للمشاركة. إن كنت تهتم بتحسين محركات البحث (SEO)، خطط:
hreflang يربط جميع المتغيرات بالإضافة إلى x-defaultاختر نمط URL مبكرًا—تغييره لاحقًا يؤثر على الفهرسة والتحليلات والروابط المشتركة.
واجهات المستخدم تختار ما يراه المستخدم؛ بينما توجيه المنطقة يحدد إلى أين تذهب الطلبات وأي قواعد تُطبَّق. مرّر مُعرِّف region واحدًا عبر الطلبات (رأس، مطالبة توكن، أو جلسة) واستخدمه لاختيار:
تجنّب استنتاج المنطقة من اللغة؛ فهما بعدان منفصلان.
الامتثال لموقع البيانات يختصر إلى أين تُخزن وتُعالَج بيانات العملاء. ابدأ بتخطيط البيانات الحساسة عبر قاعدة البيانات الرئيسية، السجلات، النسخ الاحتياطية، التحليلات، البحث، والمزودين—فالنسخ الاحتياطية والسجلات غالبًا ما تكون ثغرات غير مرصودة. خيارات المعمارية النموذجية:
اعتبر الامتثال كمتطلبات يمكن اختبارها واحصل على مراجعة قانونية قبل نشر وعود للعملاء.
قرّر إن كنت ستحافظ على قوائم أسعار إقليمية (مستحسن لثبات الهامش) أو ستحوّل من عملة أساسية. إذا اخترت التحويل، نوِّح عن وتوثّق:
ثم طبّق نفس القواعد في صفحة الدفع، الرسائل الإلكترونية/الإيصالات، عمليات الاسترداد، وأدوات الدعم لتجنّب اختلافات تفقد الثقة.
استخدم الذكاء الاصطناعي لتسريع المسودات وفحوصات الاتساق، لكن لا تجعله القرار النهائي. استخدامات مناسبة قوية:
اطلب موافقة بشرية للمحتوى عالي المخاطر مثل التسعير/الضرائب، النصوص القانونية/الخصوصية/الموافقات، وتعليمات الدعم التي قد تسبب فقدان بيانات.