عولمة التطبيقات – بناء تطبيقات متعددة اللغات والثقافات

* شرح للعرض عن طريق الفيديو

لنبدأ المشهد من آخره , بعد أن قمنا ببناء موقع إلكتروني أو تطبيق , والآن حان الوقت بأن نضيف لغة جديده للموقع , لكن ما قابلية ذلك الأن ؟هنا يتوقف المطورون فمنهم من يتجه إلى إعادة إضافة اللغة من خلال التطرق إلى ملفات التطبيق من جديد وتغيير الرسائل والمحتوى ليقبل اللغة الجديده , ماذا إذا أردنا إدخال المعلومات لتقبل لغة أخرى !
لذلك علينا التفكير مسبقا ببناء التطبيق المعولم منذ البداية

دعونا نعرف ما ضرورة عولمة التطبيقات , ولماذا علينا أن نفكر فيها منذ البداية خصوصا عندما ننشأ منتجا برمجيا

1. دلالات هامة

الأرقام تتحدث هناك الكثير من مستخدمي الإنترنت من مناطق جغرافية مختلفة لديها ثقافات , وما نشهده اليوم من زيادة كبيرة في المستخدمين من أنحاء مختلفة في العالم , نظرا للوعي بأهمية الإنترنت وخصوصا في المناطق التي تعتمد على محلياتها وليس لديها معرفة جيدة بلغات مشهورة كلغة الإنجليزية

عدد مستخدمي كل لغة على الإنترنت

 

نسبة إستخدام كل لغة على الإنترنت

 

إنتشار مستخدمي الإنترنت حول العالم

 

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

2. تعريف

التطبيقات متعددة اللغات والثقافات : هي التطبيقات التي تتكيف مع لغات مختلفة , مناطق مختلفة , قضايا تقنية , دون الحاجة لتغيرات جذرية
حسب تعريف Wikipedia

3.أهمية عولمة التطبيقات

1- فتح أسواق جديدة
2- التسويق المستهدف (عبر المنطقة والثقافة)
3- التعاون مع محركات البحث (فرص الظهور)
4- التخفيف من حدة المنافسة
5- بناء جسور الثقة مع مستخدمين مختلفين
6- الإنتقال إلى طور النشر العالمي
7- بناء الثقة في تطبيقك يقال بأنك إذا تكلمت بلغتي فأنت تلمس قلبي

4.مصطلحات مهمة

4.1 التوطين (L10N)

وهو نمط متعارف عليه يتم تطبيقه لمخاطبة لغة وثقافة جمهور معين , وهو اختصار لكلمة localization  بحيث أن 10 هيه بديل أحرف الكلمة
ولا يقتصر التوطين على اللغة فقط , بل يتعدد بأنماط المعاملات والمفاهيم الخاصة بجمهور ومنطقة محددة

ومن ذللك

– —صياغة الأرقام والتواريخ والأوقاتمثال :

 

UK: +44 (0) 123-456-7890
France: +33 1-23-45-67-89
China: +86 10-2345-6789
USA: +1 (123) 456-7890
—- استخدام العملات
مثال : 
$ € ¥ £
USD EUR JPY GBP CAD AUD
– اختصارات لوحة المفاتيح
—- الترتيب والفرز
—- الرموز والأيقونات والألوان
—- النصوص والرسومات التي تعبر عن كائنات، أو أنشطة، أو مفاهيم والتي قد تفسر بطريقة خاطئة في بعض الثقافات.
– نطاقات المحليات
مثال :
—.ps .fr .de .uk .in .br .jp .cn
ومن أشهر من يقوم بتطبيق هذه الخاصية هو Google.com بحيث يقوم بتحويلك بشكل مباشر إلى النطاق الخاص بمنطقتك
ملاحظة : لا يقتصر التوطين على اللغة يمكن توفير توطينات عديدة لأصحاب اللغة الواحدة , وكلما زادت قدرتنا على مخاطبة الثقافة وتحديد التوطينات كلما كانت النتائج افضل
ومن أمثلة التوطينات المختلفة للغة العربية , موقع التجارة العربي Souq.com حيث يحاكي توطينات لمناطق عربية مختلفة , كذلك موقع maktoob  في تحديد الطقس والوقت الخاص بكل محلي
تعدد الثقافات في موقع Souq.com
إذن فالتوطين يعتني بكل شيء خاص بثقافة موقع جغرافي .

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 تكرار نفس القيم في الصفوف في حال كانت اللغة بنظام مركزي

وهو ما يوافق تصميم 3N ونفس فكرة عمل Fly Weight Pattern في البرمجة
بفصل المحتوى الخاص باللغة مفصول عن محتوى المعلومات الاخرى
مثال:
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 كمصدر مفتوح ليحل المشكلة :
تعتمد الفكرة فيه على وحدة النصوص بمعنى أن النص هو القيمة

مثال :

لو كانت الدالة المسؤولة عن الترجمة هي

—Translate(“ مسودة مهندس”)
– في المثال أعلاه في حال كنا قد عينا اللغة الإفتراضية الإنجليزية وكانت لا تحتوي على ترجمة “ مسودة مهندس” فإن المخرج سيكون “ مسودة مهندس”
  في هذه الحالة ضمنا وحدة النص ( عند كتابة نفس النص داخل الدالة في أي مكان أخر سيتم ترجمته بنفس الترجمة)

أما عن المزامنة فهناك برامج تعمل على البحث في ملفات النظام عن الدوال الخاصة باللغة (يتم تعريفها من خلالك) وإستخراج نصوصها بشكل ديناميكي وترجمتها

– ومن أشهر هذه البرامج poedit يمكن تحميله من http://www.poedit.net/

– حيث يقوم بالبحث عن النصوص عند طلب ذلك وتحديث الملفات باخر المستجدات من النصوص , ويحفظ صيغتين صيغة للقراءة (.mo) وصيغة للتعديل (.po)
– ومن أشهر الذين يعملون بهذه الطريقة WordPress

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 حروف لمزيد من اللغات

—رابط يحوي ISO 639-2 , ISO 639-1

http://www.loc.gov/standards/iso639-2/php/code_list.php

ثالثا :ISO639-3 يحوي المحليات تفصيلا مثال (abv    عربي بحريني, عربي تونسي aeb)
وبهذه الطريقة يمكننا تحديد ثقافة بلد عربي محدد
ملاحظة : إختيار الترميز يتم على مقدار دعمك للمحليات المحددة , فكلما زاد دعمك للمحليات كلما زاد تخصيصك للفئة.

5.3 واجهة المستخدم

5.3.1 واجهة المستخدم الخارجية

—تعد واجهة المستخدم من أهم العوامل التي تحقق مبدأ ال I18N فهي تختلف عن السابق بأنها الواجهة الحقيقية للمستخدم
—هناك خصائص عديدة يمكن حصرها للغات حتى يتسنى لنا تعريف لغات دون الحاجة لتغيير كبير في واجهة المستخدم مثل:
– —الإتجاه , هناك بعض اللغات يكون إتجاها يختلف من اليمين إلى اليسار والعكس صحيح وبالتالي واجهة المستخدم يجب أن تقبل التغيير (RTL\LTR)

– —إختلاف طول الكلمات والمدخلات في المحليات
—- إستخدام أكواد ال HTML في الويب للمحافظة على المحلية بشكل أكبر ومن ذلك —Meta Tags
–  في حال إعتماده يمكنه دعم العديد من اللغات دون الحاجة لإستخدام تشفير معين واذا لزم الأمر يمكن تخصيص ترميز لكل لغة Encoding UTF-8
– —إستخدام خواص ال CSS  على حسب كل لغة

 مثال :

.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 وكان المدخل فرد واحد (يقوم بإدخال كافة معلومات اللغة) فإن من الحلول في ذلك مشاركة كافة اللغة في نفس النموذج مع عزله عن باقي البيانات الاساسية المثال في الصورة

فكرة لوحة إدخال بلغات مختلفة لقاعدة بيانات مركزية

أما إن كان الإدخال لمجموعة من الأفراد , فإنه يفضل فصل النموذج بحيث إن كان المدخل فردا للغات يتم تخصيص نموذج للغات ونموذج للبيانات , وان كان لكل لغة مدخل يتم تخصيص نماذج وهكذا

6. ملخص سريع

– التفكير عند تصميم البرمجيات في تعددية اللغات منذ اللحظة الأولى
– تصميم قواعد البيانات على حسب مستقبل المشروع , مع قابلية إضافة أي توطينات لاحقا
– تعريف خواص كل لغة (الرمز , الإتجاه , الكلمات المفتاحية ….إلخ) , يساعدك في عملية الديناميكية
– عند تعريف أي توطين فكر دائما بإستهداف هذه الثقافة
– كلما زاد دعمك لتخصيص المحليات كان ذلك له أثر مهم بمعنى أنك حتى لو اخترت العربية كلغة وحيدة يمكنك دعم المناطق العربية بمحلياتها , مما يسهل عليك إستهدافها المباشر في القضايا التي تهمها .
—مثال : عربي سعودي —  المسجد الحرام
           عربي مصري– الأهرام
           عربي فلسطيني – القدس
– الإعتماد على وحدة النص , وإعتماد لغة وثقافة أساسية عند كتابة الكود الخاص بالبرمجية
– الإهتمام بتفصيل واجهة المستخدم حتى يسهل على المستخدم التعامل معها وتحليلها لتسهيل دعمها للتعدد
دمتم بود … إلى تدوينة أخرى

شارك هذا الموضوع: