* شرح للعرض عن طريق الفيديو
لنبدأ المشهد من آخره , بعد أن قمنا ببناء موقع إلكتروني أو تطبيق , والآن حان الوقت بأن نضيف لغة جديده للموقع , لكن ما قابلية ذلك الأن ؟هنا يتوقف المطورون فمنهم من يتجه إلى إعادة إضافة اللغة من خلال التطرق إلى ملفات التطبيق من جديد وتغيير الرسائل والمحتوى ليقبل اللغة الجديده , ماذا إذا أردنا إدخال المعلومات لتقبل لغة أخرى !
لذلك علينا التفكير مسبقا ببناء التطبيق المعولم منذ البداية
دعونا نعرف ما ضرورة عولمة التطبيقات , ولماذا علينا أن نفكر فيها منذ البداية خصوصا عندما ننشأ منتجا برمجيا
1. دلالات هامة
الأرقام تتحدث هناك الكثير من مستخدمي الإنترنت من مناطق جغرافية مختلفة لديها ثقافات , وما نشهده اليوم من زيادة كبيرة في المستخدمين من أنحاء مختلفة في العالم , نظرا للوعي بأهمية الإنترنت وخصوصا في المناطق التي تعتمد على محلياتها وليس لديها معرفة جيدة بلغات مشهورة كلغة الإنجليزية
ومن هذه الدلالات نستنج بأن ليس فقط اللغة الإنجليزية هيه اللغة الوحيدة التي تسيطر على الإنترنت , بل هناك احتمال كبير لزيادة الثقافات واللغات الاخرى بالذات بأن الفرصة القادمة لزيادة استخدام الإنترنت هيه في المناطق التي يوجد بها نقص والموضحه في إنتشار مستخدمي الانترنت , وعلى ذلك ينبغي علينا التفكير جديا في عملية بناء تطبيقنا ليوافق هذه التعددية.
2. تعريف
التطبيقات متعددة اللغات والثقافات : هي التطبيقات التي تتكيف مع لغات مختلفة , مناطق مختلفة , قضايا تقنية , دون الحاجة لتغيرات جذرية
حسب تعريف Wikipedia
3.أهمية عولمة التطبيقات
1- فتح أسواق جديدة
2- التسويق المستهدف (عبر المنطقة والثقافة)
3- التعاون مع محركات البحث (فرص الظهور)
4- التخفيف من حدة المنافسة
5- بناء جسور الثقة مع مستخدمين مختلفين
6- الإنتقال إلى طور النشر العالمي
7- بناء الثقة في تطبيقك يقال بأنك إذا تكلمت بلغتي فأنت تلمس قلبي
4.مصطلحات مهمة
4.1 التوطين (L10N)
وهو نمط متعارف عليه يتم تطبيقه لمخاطبة لغة وثقافة جمهور معين , وهو اختصار لكلمة localization بحيث أن 10 هيه بديل أحرف الكلمة
ولا يقتصر التوطين على اللغة فقط , بل يتعدد بأنماط المعاملات والمفاهيم الخاصة بجمهور ومنطقة محددة
ومن ذللك
USD EUR JPY GBP CAD AUD
4.2 التدويل (I18N)
وهو ما اشتهر في اللغة الإنجليزية i18n إختصار لكلمة
Internationalization (I 18 letters n)
وهيه تكييف أو تطبيق المحتوى بحيث يقبل تعدد اللغات والثقافات والبلدان , فتتعدد فيه التوطينات ويسهل تحديد كل توطين بحسب الإستهداف
خطأ شائع : بناء التطبيقات ومن ثم التفكير في عولمتها وتعدد ثقافتها
5.كيف نعولم تطبيقاتنا ؟
تنحصر العولمة في نقطتين (المحتوى , المظهر) ولكي نؤسس تطبيق معولم ينبغي علينا المرور على ثلاثة محاور عند التطوير , سنذكرها بشيء من التفصيل وهي : قواعد البيانات , التسميات والصيغ , واجهة المستخدم.
وهذه المحاور لا تكاد تخلو من أي تطبيق نقوم ببناءه بغض النظر ان كان تطبيق انترنت , او هاتف ذكي …إلخ
5.1 قواعد البيانات
يمكننا تقسيم هيكلة قواعد البيانات إلى قسمين حسب الحاجة
المركزي : أن المعلومة الواحدة يتم ترجمتها باللغات المتوفرة وبالتالي ضمان نفس المحتوى في كل اللغات
5.1.1 إضافة حقل جديد لكل لغة
مثال
id | value | Title_en | Title_ar | Title_fr |
---|---|---|---|---|
1 | 1 | Draft Engineer | مسودة مهندس | Ingénieur projet |
مميزات
– أنه يحوي كل بيانات اللغة في صف واحد مما يسهل استعماله وإجراء كافة العمليات عليه
سلبيات
– زيادة حجم بنية الجداول
5.1.2 إضافة صف جديد لكل لغة
id | Title | Value | Lang |
---|---|---|---|
1 | مسودة مهندس | 1 | ar |
2 | Draft Engineer | 1 | en |
3 | Ingénieur projet | 1 | fr |
مميزات
– مايميز هذا التصميم أنه يحافظ على خصوصية كل صف مع إمكانية إضافة أي لغة دون الحاجة لتغيير بنية الجداول
– يقبل المركزية واللامركزية
سلبيات
– تكرار نفس القيم في الصفوف في حال كانت اللغة بنظام مركزي
5.1.3 تكرار نفس القيم في الصفوف في حال كانت اللغة بنظام مركزي
بفصل المحتوى الخاص باللغة مفصول عن محتوى المعلومات الاخرى
Value | ID |
---|---|
1 | 1 |
id | Lang | Name |
---|---|---|
1 | ar | مسودة مهندس |
1 | en | Draft Engineer |
1 | fr | Ingénieur projet |
مميزات
– يقبل المركزية واللامركزية
سلبيات
– العمليات التي تحتاج إلى اللغة والمعلومات المشتركة تطلب عملية join دائما
ملاحظة
في حال كان حجم البيانات كبيرا لكل لغة , والبيانات تختلف بالكلية ( لا يوجد مشاركة بالبيانات) بمعنى لكل لغة قالبها الخاص من قيم وبيانات فيمكن عمل جداول مخصصة للغات
5.2 التسميات والصيغ
هناك تسميات وصيغ نحتاج إلى كتابتها في بنفس التطبيق وهي تتمثل في أشياء عديدة منها
( النصوص , الرسائل , العملات, العناوين , الأرقام … إلخ) , ولكنها تحتاج لأن تتغير لتوافق الثقافة واللغة المنشودة
مثال : عند إحتواء التطبيق على قيمة تاريخ مكتوب بالصيغة الميلادية , فإننا نحتاج لتحويره إلى هجري عند مخاطبة ثقافة تستخدم التاريخ الهجري
5.2.1 ترجمة النصوص
ويقصد بها أي نصوص يتم تضمينها داخل الكود الخاص بالبرنامج , وهناك حلول مختلفة لجعل النص مترجم حسب اللغة المقصودة
ومن ذلك يمكن جعل كل ملف يعمل على حده بنفس المتغيرات , وبالتالي عند طلب أي لغة يتم تحميل الملف الخاص باللغة ويتم ترجمة النظام
المتغيرات | إسم الملف |
---|---|
PAGE_TITLE=’مسودة مهندس’ ERROR_MSG=”خطأ” … |
AR.xx |
PAGE_TITLE=’Draft Engineer’ ERROR_MSG=”Error” … |
EN.xx |
PAGE_TITLE=’Ingénieur projet’ ERROR_MSG=”erreur” … |
FR.xx |
من عيوب هذه الطريقة
1- صعوبة المزامنة بين الملفات
2- إنشاء متغيرات بتسميات مختلفة لنفس النص
3- في حال عدم وجود المتغير المطلوب في ملف النصوص لا يوجد قيمة بديلة بمعنى أنه إذا كنا قد طلبنا PAGE_TITLE كما في المثال السابق ولم يكن مترجم في ملف اللغة المقصودة فلا يوجد بديل نصي عن ذلك!
لذلك جاء ال Gettext كمصدر مفتوح ليحل المشكلة :
تعتمد الفكرة فيه على وحدة النصوص بمعنى أن النص هو القيمة
مثال :
لو كانت الدالة المسؤولة عن الترجمة هي
أما عن المزامنة فهناك برامج تعمل على البحث في ملفات النظام عن الدوال الخاصة باللغة (يتم تعريفها من خلالك) وإستخراج نصوصها بشكل ديناميكي وترجمتها
5.2.2 الصيغ
الصيغ بمعنى أنه كيف بإمكاننا توفير الصيغ بما يناسب الثقافه فمثلا لو كان عندنا تاريخ مكتوب بالصيغه الميلادية كيف بإمكاننا تحويلة للصيغه الهجرية في حين تطلبت ثقافة المكان ذلك عند التعامل مع الصيغ التي تناسب ثقافة مكان معين يمكننا الإعتماد على رموز المحليات القياسية العالمية , ويمكن برمجة كل محلي من هذه المحليات بما يتناسب مع صيغه وثقافته , ولكن يفضل إستعمال مكاتب جاهزه أو المدعومة من نفس لغة البرمجة رموز المحليات دون الحاجة للتطوير مثل ال Zend Framework و CakePHP , .NET
ويوجد مستويات لرموز المحليات
أولا :ISO639-1 يدعم حرفين فقط وهو محدود بلغات
ISO639-1 example | |
Arabic | ar |
French | fr |
Dutch | nl |
German | de |
وبالتالي فإن إستعمالنا لأي من المكاتب التي تدعم المحليات وتمرير محلي مثل ar فإن الثقافة ستكون بما يلائم المناطق المتحدثة بال ar
ثانيا :ISO639-2 يدعم 3 حروف لمزيد من اللغات
http://www.loc.gov/standards/iso639-2/php/code_list.php
5.3 واجهة المستخدم
5.3.1 واجهة المستخدم الخارجية
مثال :
.ar { font-size: 85%; font-family: arial, verdana, sans-serif; }
.en { font-size: 125%; font-family: helvetica, verdana, sans-serif; }
5.3.2 واجهة الإدخال
واجهة الإدخال تختلف على حسب طريقة الإدخال وكذلك تصميم قاعدة البيانات , واجهة الإدخال بطريقة تصميم قاعدة البيانات بشكل غير مركزي سهله لأن جميع البيانات مفصولة لكل لغة وبالتالي كل لغة ستأخذ نموذج إدخال خاص بها دون الحاجة لمشاركة النموذج , أما النمط المركزي فيحتاج إلى التفكير قليلا , ولو صممنا قاعدة البيانات على طريقة النقطة المذكورة 5.1.3 وكان المدخل فرد واحد (يقوم بإدخال كافة معلومات اللغة) فإن من الحلول في ذلك مشاركة كافة اللغة في نفس النموذج مع عزله عن باقي البيانات الاساسية المثال في الصورة
أما إن كان الإدخال لمجموعة من الأفراد , فإنه يفضل فصل النموذج بحيث إن كان المدخل فردا للغات يتم تخصيص نموذج للغات ونموذج للبيانات , وان كان لكل لغة مدخل يتم تخصيص نماذج وهكذا