خدمات توطين البرمجيات

يبدو توطين البرمجيات بسيطًا حتى تقوم بإطلاقه. يكتب الفريق en.json ويفترض أن الإسبانية والألمانية والعربية ستتبع نفس المسار. لن تفعل. كل تنسيق ملف له مشكلة تعطّل البناء لدى وكالة غير مستعدة. بعد 14 عامًا وعدة آلاف من إصدارات SaaS، لدينا قائمة قصيرة من الحالات التي تصطاد حتى فرق الهندسة الناضجة.

JSON وYAML ومشكلة الفاصلة العليا

JSON العادي لا يحتوي على تعليقات ولا دعم للجمع، مناسب للإنجليزية، هش في الإنتاج بمجرد أن يضيف المترجمون فواصل عليا منحنية (' مقابل ')، أو مسافات غير منفصلة ضيقة حول علامات الترقيم الفرنسية، أو علامات الاقتباس الألمانية (»، «). المترجم الفرنسي الذي يكتب L'application الصحيحة بفاصلة عليا طباعية سينجح في ضمان الجودة اللغوية ويعطّل محلل JSON الهش. نُطبّع الفواصل العليا عند الاستيراد، ونتحقق من وجود UTF-8 BOM، ونجري فحص بناء جملة قبل شحن أي لغة.

Android strings.xml: تهريب الأحرف الصامت

يخزّن Android الفواصل العليا كـ \' وعلامات العطف كـ &. يلصق المترجمون بانتظام أحرف Microsoft Word المنحنية التي تبدو متطابقة ويشحنون، حتى يعرض التخطيط نصًا مشوهًا عند التشغيل. نستخدم رحلة XLIFF مخصصة لموارد Android حتى لا يرى المترجم XML الخام أبدًا، ونعيد تهريب الأحرف عند التصدير.

iOS .strings و.stringsdict

المشكلة الكلاسيكية هي قواعد الجمع. يستخدم iOS فئات الجمع في CLDR (صفر، واحد، اثنان، قليل، كثير، آخر) من خلال .stringsdict. المترجم الساذج سيعامل الملف واحدًا لواحد ويفقد متغيرات الجمع، يقول تطبيقك الألماني حينها "1 Nachrichten". نستخدم محررًا مدركًا للجمع يعرض كل فئة CLDR حسب الحاجة للغة الهدف ويرفض التصدير إذا كانت أي فئة مفقودة.

.NET .resx وJava .properties

يقبل resx تعليقات XML ومراجع كود مضمنة؛ يستخدم .properties ISO-8859-1 افتراضيًا (سلاسل الأدوات الحديثة تدعم UTF-8، لكن التركيبة الخاطئة لا تزال تشحن تسلسلات تهريب \uXXXX التي تُحبط المترجمين). نفرض UTF-8 عند الاستيراد ونُصدِر إخفاءات أصلية فقط في وقت البناء.

رحلة XLIFF ذهابًا وإيابًا

كلما أمكن، نستخرج الملفات المصدرية إلى XLIFF 1.2 أو 2.0، ونترجم داخل محررنا مع السياق المرفق، ونعيد الدمج. يتيح هذا للمترجمين رؤية تعليق المصدر، ولقطة الشاشة، والقيد (حد الأحرف، صيغة الجمع ICU، علامة انعكاس RTL) دون لمس الملف المصدري أبدًا. يدمج مسار البناء مرة أخرى في التنسيق الذي أرسله مطوروك.

إذا كان منتجك يحتوي على سلسلة نصية مثل "دعت ماري 3 أصدقاء إلى حدثك"، فأنت على وشك اكتشاف ICU MessageFormat. تحتاج الإنجليزية إلى ثلاثة متغيرات. تحتاج الروسية إلى أربعة أشكال جمع (1، 2-4، ⁨5+⁩، كسري). تحتاج العربية إلى ستة. للبولندية قواعد مختلفة مرة أخرى. تشحن العديد من المنتجات بسلسلة مسطحة مثل {name} invited {count} friends وتقبل بهدوء قواعد نحوية معطلة في 80% من اللغات.

النمط الصحيح

{count, plural,
 one {# friend}
 few {# friends}
 many {# friends}
 other {# friends}
}

هذا جيد في الإنجليزية والفرنسية والألمانية. في العربية تحتاج zero، one، two، few، many، other. في البولندية تغطي few الأعداد 2-4 فقط عندما يكون الرقم الأخير 2-4 والعدد ليس 12-14 - للبولندية تقريبًا 5 فئات جمع. وللويلزية فئاتها الخاصة. نترجم وفقًا لمجموعة قواعد الجمع في CLDR لكل لغة، وليس وفقًا للقالب الإنجليزي.

الفاعل المرتبط بالجنس النحوي

الإسبانية والإيطالية والباشتو جميعها تحتاج لمعرفة ما إذا كان الفاعل مذكرًا أو مؤنثًا أو محايدًا لتصريف الفعل. الترجمة الساذجة لـ "You are invited" تفترض المذكر افتراضيًا؛ تُشاهد المستخدمة المؤنثة قواعد نحوية معطلة في 50% من اللغات. يتعامل select في ICU مع هذا:

{gender, select,
 female {Estás invitada}
 male {Estás invitado}
 other {Te han invitado}
}

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

لماذا يهم هذا لتحسين محركات البحث والثقة

تشير مراجعات App Store وGoogle Play بانتظام إلى أشكال الجمع المعطلة: "التطبيق به خلل، يقول '1 messages'". تتراكم المراجعات بنجمة واحدة وتخفض الترتيب. إصلاح أشكال الجمع بعد الإطلاق يكلف أكثر من الترجمة الواعية بـ ICU مقدمًا.

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

خصائص CSS المنطقية

الخطأ الأكثر شيوعًا في الإنتاج: يكتب المطورون margin-left: 16px بدلًا من margin-inline-start: 16px. في لغة من اليسار إلى اليمين هما متطابقان. في العربية، الأول يُثبّت الهامش على يسار الشاشة؛ الثاني ينعكس بشكل صحيح إلى اليمين. نُدقّق ورقة الأنماط الخاصة بك بحثًا عن خصائص فيزيائية (left، right، padding-left، border-right) قبل أن نلمس السلاسل النصية.

النص ثنائي الاتجاه داخل الفقرات

الفقرة العربية التي تذكر اسم علامة تجارية إنجليزية، أو عنوان URL، أو رقمًا تصبح سلسلة مختلطة الاتجاه. تتعامل المتصفحات مع هذا باستخدام خوارزمية Unicode ثنائية الاتجاه، لكن الخوارزمية استكشافية وتخطئ في حالات يمكن التنبؤ بها، غالبًا عندما تنتهي جملة برقم أو علامة ترقيم لاتينية. نُدرج علامات U+202A/U+202C (LRE/PDF) أو نستخدم علامات <bdi> حول رموز غير شفافة مثل أسماء المستخدمين ومعرفات المنتجات.

الأيقونات التي لها اتجاه

أيقونات الأسهم، علامة "رجوع"، التراجع والإعادة، اتجاهات المنزلق، أشرطة التقدم، كل أيقونة اتجاهية تحتاج إلى متغير RTL أو تحويل CSS. لدى Lucide وHeroicons متغيرات مدركة لـ RTL؛ تتطلب مجموعة أيقونات Material فئة انعكاس. نُفهرس كل أيقونة اتجاهية في نظام التصميم الخاص بك ونُعلّم أي منها لم ينعكس في التدقيق.

الخطوط والعرض

تفتقر مجموعات الخطوط الغربية بانتظام إلى الحروف الرسومية العربية - Helvetica Neue وInter وRoboto جميعها تحتاج إلى خط عربي احتياطي. الخط الافتراضي للنظام (Geeza Pro على iOS، Noto Naskh Arabic على Android) يُعرض، لكن ارتفاع السطر خاطئ والتقنين ضعيف. نختبر العرض على الأجهزة الفعلية التي يمتلكها مستخدموك، وليس فقط Chrome على macOS - ونُعلّم إصلاحات مجموعة الخطوط كجزء من مراجعة pseudo-locale.

لماذا هذا مجالنا الأساسي

العربية هي أكبر زوج لغوي منفرد لدينا. علامتنا الشقيقة arabictranslation.co.uk تُقدّم خدمات توطين العربية منذ 2012. رسوم RTL الإضافية التي تضيفها معظم الوكالات في المملكة المتحدة (20-30%) تعكس أن هذا عمل غير اعتيادي بالنسبة لها؛ إنه العمل الذي نقوم به أكثر. لا نفرض رسومًا إضافية على RTL.

إذا كان فريق الهندسة لديك يشحن الإنجليزية كل ثلاثاء، فيجب أن تُشحن الألمانية والفرنسية والعربية كل ثلاثاء أيضًا. أي شيء آخر هو مشكلة تنسيق إصدار متنكرة كمشكلة ترجمة. هناك ثلاثة أنماط تكامل ندعمها؛ النمط الصحيح يعتمد على كيفية تنظيم مستودعك.

النمط 1: سير عمل PR مدفوع بـ webhook

يناسب معظم فرق SaaS. يُطلق webhook في GitHub على كل دفع إلى main. تفحص خدمتنا الفرق بحثًا عن سلاسل جديدة أو متغيرة، تُسوّد اللغات، ترسلها إلى لغوي للمراجعة، وتفتح PR عودة. تضمن حماية الفرع أن PR لا يمكن دمجه قبل المراجعة. الوقت النموذجي من البداية إلى النهاية: 18-24 ساعة لـ 35 لغة على التزام 200 سلسلة.

النمط 2: خطوة CI في عملية البناء لديك

إذا كان فريقك يفضل تدفق تغييرات اللغة من خلال نظام البناء الخاص بك (CircleCI، GitHub Actions، GitLab Runners)، نعرض واجهة سطر أوامر: lingosecure pull يسحب أحدث الترجمات إلى مستودعك كخطوة بناء، lingosecure push يُحمّل أي تغييرات في سلاسل المصدر للترجمة. يُستخدم من قبل فرق تُدير قطارات الإصدار ولا تريد PRs ترجمة في تدفقها.

النمط 3: مزامنة TMS (Phrase / Lokalise / Crowdin)

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

ذاكرة الترجمة وقاعدة المصطلحات

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

التحكم في الإصدارات والتراجع

نُثبّت إصدار ذاكرة الترجمة بإصدار المنتج. لن يشحن الإصدار v4.2 الخاص بك عن طريق الخطأ مع السلاسل المترجمة من v4.1. إذا احتاج فريقك إلى التراجع عن إصدار، تتراجع ذاكرة الترجمة معه. هذا مهم للمنتجات الخاضعة للتنظيم حيث يجب أن يتطابق الإفصاح المترجم مع نسخة الإنجليزية التي تمت الموافقة عليها.

قبل أن نرسل سلسلة إلى المترجم، نُشغّل منتجك من خلال بناء pseudo-locale. تُغلَّف كل سلسلة إنجليزية بأحرف ذات علامات صوتية وتُبطَّن بنسبة 30%: "Submit" يصبح "[Ŝûbmît⏎ⓅⒶⒹ]". الهدف ليس اختبار جودة الترجمة؛ بل اختبار منتجك. يُحاكي التبطين توسع الألمانية بنسبة 30-40%؛ تفرض العلامات الصوتية مسارًا لعرض Unicode؛ تكشف الأقواس السلاسل المسلسلة (سيظهر أي جزء إنجليزي مثبّت في الشيفرة بدون غلاف).

ما يكتشفه pseudo-locale

• الاقتطاع - أزرار تناسب "OK" لكن ليس "Aceptar"
• سلاسل مثبّتة في الشيفرة - أي نص غير مغلّف بالدالة t()
• أخطاء التسلسل - "Hello " + username سينكسر في اللغات ذات ترتيب الكلمات المختلف
• افتراضات العرض الثابت - منتقي التواريخ، القوائم المنسدلة، علامات التبويب
• الخطوط الاحتياطية - النص الذي يتحول إلى مستطيلات لأن الخط لا يغطي Latin Extended-A
• أخطاء انعكاس RTL - كل أيقونة اتجاهية وتخطيط ينعكس في pseudo-RTL

نُسلّم بناء pseudo-locale كنشر Storybook أو فرع ميزة يمكن لفريق ضمان الجودة الخاص بك اختباره. يذهب سجل العيوب مباشرة إلى Linear أو Jira أو GitHub Issues الخاص بك. نصلح القضايا الخاصة باللغة؛ يصلح فريقك القضايا الخاصة بالمنتج، قبل الدفع مقابل كلمة واحدة من الترجمة البشرية.

ضمان الجودة المرئية مع فرق لقطة الشاشة

بالنسبة للمنتجات الناضجة نُجري تمريرة إضافية: تُلتقط كل شاشة بالإنجليزية، pseudo-EN، الألمانية، العربية، والصينية، وتُقارن الفروقات. تظهر تراجعات التخطيط فورًا. يعمل نفس سير العمل ضد كل PR إذا أردت ذلك كـ GitHub Action.

يكتشف اختبار pseudo-locale ما ينكسر قبل الترجمة؛ ويكتشف اختبار الجودة اللغوية LQA ما ينكسر بعدها. بعد دمج السلاسل المترجمة، يعمل مختبِر ناطق أصلي على البناء الفعلي، لا على جدول بيانات، وعلى أجهزة حقيقية: كل شاشة وكل نافذة حوار وكل رسالة خطأ، باللغة قيد الاختبار. تُسجَّل العيوب اللغوية (كلمة ألمانية مركّبة مقتطعة، تنسيق تاريخ لم يُوطَّن، سلسلة تبدو صحيحة منفردة لكنها خاطئة بجوار الزر الذي تجاوره) إلى جانب العيوب الوظيفية (نماذج ترفض الإدخال غير اللاتيني، روابط تعطي 404 في بناء اللغة، تخطيطات تنهار في RTL).

كيف تجري تمريرة الاختبار

• مراجعة لغوية في السياق: يراجع لغوي أصلي كل سلسلة معروضة في الواجهة، حيث تظهر قيود المساحة وتصادمات المعنى فعليًا
• فحوصات وظيفية لكل لغة: التنقل والنماذج والدفع وتدفقات الحساب تُختبَر بكل لغة مستهدفة على iOS وAndroid ومتصفحات سطح المكتب
• العيوب تُسجَّل حيث يعمل فريقك: Linear أو Jira أو GitHub Issues، مع لقطة شاشة واللغة والجهاز ودرجة الخطورة في كل تذكرة؛ نصلح نحن قضايا اللغة ويصلح فريقك قضايا المنتج
• إيقاع متوافق مع السبرنت: يعمل LQA كمرحلة في خط الإصدار لديك لا كتدقيق لمرة واحدة، بسعر 40-60 جنيهًا إسترلينيًا في الساعة أو بتسعير لكل إصدار

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

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

الاختيار الصحيح يعتمد على مرحلتك. SaaS في مراحله المبكرة مع 3-5 أسواق يستفيد أكثر من LingoSecure وعقد خدمات شهري ثابت. السلسلة B وما بعدها مع ⁨12+⁩ لغة عادة ما تحتفظ بـ TMS الموجود لديها وتستخدمنا كطبقة لغوية. المنصات الخاضعة للتنظيم مع عمليات تدقيق امتثال تريد بوابة LingoSecure ومسار تدقيق لكل مقطع. سنخبرك بصراحة أي مسار يناسب.

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

لا نشحن ترجمة آلية غير مراجعة

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

لا نفعل التسليم في نفس اليوم بحجم المؤسسة

إصلاح طارئ من 50 سلسلة في 4 ساعات واقعي عبر معظم اللغات الرئيسية. إطلاق منتج من 5,000 سلسلة في 24 ساعة غير واقعي ولن نلتزم به. نُجدول بشكل عكسي من تاريخ إصدارك مع حاجز ضمان جودة مدمج؛ إذا كان جدولك الزمني أقصر، سنخبرك بما هو قابل للتحقيق فعليًا.

لا نتعاقد من الباطن على العربية

توجه معظم الوكالات في المملكة المتحدة العربية إلى استوديو في القاهرة أو بيروت. نترجم داخليًا مع لغويين مسمّين. نفس الشخص الذي ترجم سلاسل v1 الخاصة بك هو الشخص الذي يترجم v4.7. اتساق المصطلحات هو وظيفة الاستمرارية؛ تتطلب الاستمرارية عدم التعاقد من الباطن.