عند تعريب الخدمة ، من المهم التفكير بعناية في تنسيق التحويلات بين بعضها البعض. تحدث ألكسندر بونيل ، رئيس فريق تطوير أندرويد عميل Yandex.Taxi ، عن الممارسات والأدوات التي تبسط التعريب. في الجزء الثاني من التقرير ، شاركت Sasha في تجربة دعم RTL في التطبيق: ما هو جيد وما لا يصلح لنظام Android خارج الصندوق ، ما هي المشاكل التي تنشأ بسبب دعم RTL وكيفية تقليلها في المستقبل.
- في تقريري ، أود أن أخبرك بالأفكار والممارسات الأساسية التي نستخدمها في فرق تطوير تطبيقات الهاتف المحمول Taxis لحل المشكلات المتعلقة بترجمة وتحديث الترجمات في طلباتنا. بعد ذلك ، سأخبرك بكيفية تطبيقنا لدعم العمل في وضع الرسم من اليمين إلى اليسار في التطبيق.
سأبدأ مع الترجمة. بادئ ذي بدء ، أود توضيح المصطلحات. وفقًا لملاحظاتي ، يعتقد عدد كبير من الناس أن التعريب يقتصر على الترجمات فقط ، على الرغم من أنه في الواقع يحل المشكلات المرتبطة بأرقام التنسيق والتواريخ والوقت والعمل مع النصوص والرموز والجوانب القانونية وتقديم المحتوى للمستهلك بهذه الطريقة كان لديه قيمة الدلالية بالنسبة له ولم ينظر إليه بشكل غامض. وأكثر من ذلك بكثير.
(التواصل مع الجمهور حول من لديه عدد اللغات المدعومة في التطبيقات - Ed.)أريد أن أحكي لك قصة حدثت معنا عام 2014. قمنا بعد ذلك بإعادة تصميم كبرى لتطبيق سيارات الأجرة. في أحد الإصدارات التالية ، منحنا المستخدمين الفرصة للإشارة إلى رقم المدخل ، وكذلك إلقاء نظرة على هذه المعلومات على شاشة معلومات الرحلة ، والأهم من ذلك ، على شاشة تصنيف الطلب ، التي أظهرناها لجميع المستخدمين ، لأننا بالتأكيد أردنا الحصول على تصنيف للرحلة .
في ذلك الوقت ، كنا متحمسين إلى حد ما بشأن عملية الترجمة والترجمات. بالنسبة للجزء الأكبر ، كانت العملية برمتها اليدوي. تم تحديث النصوص في ملفات XML الضرورية ، مع إضافة ترجمات جديدة يدويًا. والعامل البشري لعبت دورا. حدد المطور النقل التالي وليس في الإعدادات الافتراضية. هذا أدى إلى حقيقة أنه بالنسبة للمستخدمين الذين لديهم لغة نظام مختلفة عن اللغة الروسية ، إذا طلبوا المدخل ، تعطل التطبيق في نهاية الرحلة. والناس لا يستطيعون تقديم طلب آخر.
في ذلك الوقت ، كان لدينا لغتين مدعومتين في التطبيق: الروسية والإنجليزية. وعملنا فقط في روسيا في ثلاث مدن: موسكو ، يكاترينبرج ، سانت بطرسبرغ.
نعمل حاليًا في 16 بلدًا وترجمنا إلى 18 لغة. أعتقد أنك تفهم المشكلة برمتها ، إذا كنا في تلك الحالة في ذلك الوقت. لقد أدركنا بالفعل أن هناك حاجة لتغيير شيء ما.
في Yandex ، يستخدم معظم مطوري تطبيقات الأجهزة المحمولة الخدمة التي تم تطويرها داخليًا لحل المشكلات المتعلقة بالتوطين. يحتوي على واجهة مستخدم مريحة للغاية ، ومن الممكن تحديد مشروعك ، وتعيين مجموعة من المفاتيح ، ومجموعة من اللغات التي تحتاج إلى ترجمة المشروع إليها. وبعد ظهور الترجمات ، يمكن تحميلها بأي تنسيق مناسب. لديه أيضًا تكامل جيد جدًا مع خدماتنا الداخلية. هناك الإصدار. لكن بالنسبة لي شخصياً ، كمطور ، فإن الشيء الأكثر أهمية هو أنه يمتلك واجهة برمجة تطبيقات ، لأن هذا يشير بالفعل إلى أنه يمكن أتمتة جميع الأعمال اليدوية المرتبطة بالترجمات. الذي فعلناه. قمنا بتطوير البرنامج المساعد ل Gradle. في الواقع ، يعود تحديث الترجمة في التطبيق الآن إلى حقيقة أن المطور يؤدي مهمة واحدة: updateTranslations.
في التقريب الأول ، يذهب إلى خدمة التعريب. يقوم بالتحقق من الترجمات الحديثة وتحميلها إلى المشروع ووضعها في الملفات الضرورية. ولكن بالإضافة إلى ذلك ، يتحقق أيضًا من حالة الترجمات في خدمة التعريب فيما يتعلق بما هو الآن في المشروع.
في المرة التالية التي يتم فيها تنفيذ حالة git ، يرى المطور في دليل العمل الخاص به الملفات التي تغيرت.
يمكنه أيضًا البحث في تقرير HTML الذي تم إنشاؤه عن أي مفتاح للقيمة التي تغيرت بها اللغة.
ويمكنه أيضًا معرفة المشكلات الموجودة حاليًا في ترجمة مشروعه.
البرنامج المساعد هو شكلي. يمكننا تحديد عدد اللغات التي يدعمها تطبيقنا. من المهم جدًا أن يبدأ المترجمون بلغة جديدة ، ويتسربون عن غير قصد إلى المشروع ، حيث أنهم لم يجتازوا التدقيق اللغوي والتدقيق اللغوي.
هناك أيضا ميزة إعادة تعيين محددة. سأتحدث عنها لاحقًا بمزيد من التفصيل عندما أتحدث عن RTL.
ما هي المشاكل التي يحللها هذا البرنامج المساعد الآن؟ المشكلة التي واجهناها في عام 2014 هي مشكلة شائعة ، ونقص الترجمة. الآن ، من أجل إضافة سطر جديد ، ترجمة جديدة للمشروع ، لا يكفي للمطور تعريفه ببساطة في ملف XML.
أولاً ، إذا لم يفعل ذلك في اللغة الافتراضية ، فسيختفي مفتاح الجرح الجديد أثناء المزامنة التالية ، وسيعرف ذلك في مرحلة التجميع.
إذا حدد المفتاح في الملف الافتراضي ، ولكن نسي القيام به في خدمة التعريب ، فسيتم تنفيذ التحويلات في المرة القادمة ، وسوف يتلقى خطأً من المكوّن الإضافي ، والذي سيخبره: "هذا المفتاح موجود في مشروعك ، لكنه ليس في خدمة التعريب ، فهو موجود بحاجة للبدء. "
المشكلة الثانية النموذجية هي عدم وجود ترجمة. لدينا قائمة من الروابط إلى تلك المفاتيح التي لا توجد بها ترجمة ، وكقاعدة عامة ، نحيلها إلى مديرنا حتى يقوموا فيما بعد بإعداد التواصل مع المترجمين. غالبًا ما تحدث النقطة الثالثة عندما قرروا إعادة النظر في استخدام وسيطات التنسيق بطريقة ما ، وعلى سبيل المثال ، بدلاً من تنسيق عدد صحيح ، بدأوا في استخدام تنسيق السلسلة.
لكن في الوقت نفسه ، في بعض الترجمات نسوا تغيير الرقم على الخط.
والمشكلة الرابعة هي أيضا بسبب العامل البشري ، وخاصة في الترجمة. إذا تم استخدام أحرف Unicode في الترجمة ، فمن السهل جدًا أن تتشوش في تحديد موضع الأحرف وبدلاً من مساحة لا تنفصم للتخلص من الواصلة إلى سطر آخر - هذا ما نحاول التخلص منه.
هذا هو كل شيء عن الترجمة.
الآن أريد أن أتحدث عن تجربة تنفيذ الدعم للتقديم من اليمين إلى اليسار في التطبيق باستخدام مثال إسرائيل. أطلقنا في عام 2018 تحت اسم العلامة التجارية Yango في إسرائيل. كما اتضح ، في إسرائيل يقرأ الناس بشكل مختلف عنك وأنا. قرأوا من اليمين إلى اليسار.
من أين تريد أن تبدأ؟ مع Android ، من حيث المبدأ ، يتم تنفيذ دعم التقديم من اليمين إلى اليسار بشكل جيد.
يبدأ بحقيقة أنه في بيان التطبيق ، في عنصر التطبيق ، تحتاج إلى إعلان السمة supportRtl = "true". لكنني أريد إرضاءك: إذا قمت بدمج Facebook SDK للحصول على ترخيص اجتماعي في تطبيقاتك ، فإن مطوري Facebook المهتمين قاموا بهذا بالفعل من أجلك. وإذا لم تقم بالتحقق من صحة البيان عند الدمج ، فستتوافق هذه السمة مع القيمة الحقيقية في التطبيق الخاص بك ، وستكون قادرة بالفعل على Rtl. هذا شيء للتفكير فيه.
أعتقد أن معظم أولئك الذين يجلسون على الجمهور ربما لديهم الحد الأدنى من الدعم لنظام Android 4.4. شخص أكثر حظًا - هذا هو 5.0 وأعلى. شخص ما قد يكون أقل حظًا ، ويدعم 4.0 ، أو لا سمح الله ، 2.3. في هذه الحالة ، ستواجه مشكلات كبيرة ، لأن دعم Rtl الكامل في Android قد ظهر منذ الإصدار 4.2. لذلك ، مع minSdk 17 ، سوف تبسط حياتك بترتيب من الضخامة.
يبدأ نقل مشروع للعمل مع Rtl باستخدام أداة إعادة المعالجة في Android Studio - إضافة دعم RTL حيثما كان ذلك ممكنًا. يجب أن نشيد ، وهو يعمل بشكل جيد للغاية. يمر عبر ملفات XML الخاصة بالعلامة ، وينظر إلى وجود سمات ذات قيم يسار ويمين للجاذبية ، وللحشوات ، والهوامش ، واستبدالها ببداية ونهاية. إذا كنت تريد أن ترى كيف يعمل التطبيق الخاص بك افتراضيًا في الوضع من اليمين إلى اليسار ، فلن تحتاج إلى امتلاك محتوى به ما يسمى الأحرف القوية RTL - باللغة العبرية أو العربية. تحتاج فقط إلى تمكين Force RTL Layout Direction في إعدادات المطور.
ما هي خيارات تخصيص واجهة المستخدم وتقديم النص الذي يوفره Android لـ RTL؟
النقطة الأولى هي سمة layoutDirection ، والتي تستخدم خيار Force RTL Layout Direction الموضح. لديها فقط أربعة معاني ممكنة. وهذا هو ، هو افتراضيا الموروثة من الأصل. يمكننا القول أن التصميم مرسوم بناءً على الإعدادات المحلية المحددة. يمكنك أن تقول بوضوح أنها مرسومة من اليمين إلى اليسار أو من اليسار إلى اليمين.
العنصر الثاني الذي يغلب على الكثير من الناس تجاوزه عادة عندما ينخرطون في محاذاة النص هو textAlignment. لا يزال العديد من الاستمرار في استخدام الجاذبية. لا تستخدم الجاذبية لمحاذاة النص ، ولكن استخدم textAlignment.
السمة الثالثة هي اتجاه تقديم النص ، textDirection. لديها تكوين مرن إلى حد ما. يتيح لك تحديد كيفية تقديم النص اعتمادًا على الحرف الأول القوي في النص ، سواء كان من مجموعة أحرف LTR اللاتينية القوية أو من RTL العبرية القوية. ولكن إذا كنت تدعم RTL بشكل كامل في التطبيق ، فلن تحتاج إلى تجاوزه ، لأن تجاهل مثل هذه الأداة المضحكة يحدث.
إما أن تكون هذه هي بيضة عيد الفصح ، أم أنها تأثير جانبي في تنفيذ editText: تلميحك في editText يبدأ في التشتت. لذلك ، في أي حال ، يجب عليك تعيين بعض القيمة بالنسبة له.
إذا كنت بحاجة إلى ملاحظة عرض معين لبعض الموارد الرسومية أو الترميز في وضع RTL ، فإن Android يوفر القدرة على تعيين ldrtl المؤهل في والدك ، حيث يمكنك وضع أي مورد ، وسيتم رسمه في وضع عرض RTL كما حددته.
في بعض الأحيان ، هناك حاجة لوقت التشغيل لرسم النص الوارد من الواجهة الخلفية كما هو ، وكيف جاء ، مع تجاهل الوضع الذي يعمل به التطبيق حاليًا. في الواقع ، في العارض النصي يتم ذلك بسبب حقيقة أن النص مؤطر بأحرف التحكم Bidi Unicode. يحتوي منطق العمل مع هذه الأحرف في حد ذاته على فئة BidiFormatter ، مع توفير طريقة unicodeWrap واحدة فقط. يأخذ CharSequence كمدخلات ، ويعيد سلسلة مؤطرة بهذه الأحرف. هناك عدد كبير منهم ، ومن حيث المبدأ ، ينبغي أن يحل معظم مشاكلك.
ولكن إذا كان هناك شيء محدد للغاية ، فإن w3.org لديه
مقال جيد حول كيفية استخدام هذه الرموز.
ما هي المشاكل التي واجهناها عندما بدأنا دعم RTL في طلبنا؟ بادئ ذي بدء ، إنه تعارض في معايير الترجمة.
BCP47 هو معيار التعريب الأحدث ، والذي قام على وجه الخصوص بتغيير أكواد بعض اللغات. والحقيقة هي أن هناك مشكلة في لغة جافا المحلية. يعمل بشكل افتراضي في وضع التوافق مع الإصدارات السابقة ، ويقوم بتحويل أكواد اللغة من BCP إلى ISO. بمعنى آخر ، رأينا هذا عندما بدأت شفرة iw بدلاً من كود الانتقال إلى الواجهة الخلفية لدينا في رأس Accept-Language.
إذا كنت تتذكر الشريحة التي تحتوي على تهيئة المكون الإضافي الخاص بنا ، فستكون هناك حاجة لإعادة تعيين الخريطة لهذا الغرض - من أجل ترجمة المحتوى من هو إلى iw.
إذا كنت بحاجة إلى استخدام تنسيق BCP ، فسيتم تنفيذ ذلك بالكامل في مشروع Apache Cordova. لديهم فئة العولمة وتطبيق localeToBcp47Language.
النقطة الأخرى التي "توفر" مع دعم RTL في التطبيق هي الرسوم المتحركة. هنا ، الفائدة هي ، في الواقع ، الرسوم المتحركة فقط على المحور X تتأثر ، وربما يكون الحل أو النهج الوحيد الذي سيساعدك على تجنب المزيد من المشاكل هو القدرة على إعادة النظر في الرسوم المتحركة المطلقة في اتجاه الرسوم المتحركة النسبية.
إحدى المشكلات التي ربما لا يتم حلها إلا عن طريق الانعكاس ، لأنه يتم تنفيذها بشكل صارم في المكون نفسه هي محاذاة تلميح TextInputLayout. الحقيقة هي أنه إذا تم تحديد تلميح في أحرف RTL القوية باللغة العبرية ، فسيتم محاذاته بوضوح إلى اليمين ، على الرغم من أن المحتوى الذي تدخله في نص التحرير يمكن أن يكون من أحرف لاتينية. والعكس صحيح. إذا كانت تلميحك باللغة اللاتينية ، فسيتم محاذاته بوضوح إلى اليسار. هذا لا يمكن إلا أن تحل مع انعكاس.
في النهاية ، بعد قيامك بتطبيق RTL في التطبيق الخاص بك ، فمن المنطقي أن تعيد النظر في شدة مشكلات RTL التي يحللها Lint. لا يوجد سوى أربعة منهم. إذا كنت لا تدعم RTL في التطبيق الخاص بك ، ولكنك تستخدم سمات RTL المحددة بشكل صريح في مكان ما ، فهذا RtlEnabled (سوف يخبرك Lint بهذا).
إذا كنت تدعم RTL في التطبيق ، ولكن minSdkVersion للتطبيق الخاص بك أقل من 17 ، فيجب عليك أيضًا الاستمرار في استخدام سمات من النوع الأيسر والأيمن ، لا يمكنك استخدام سمات البداية والنهاية فقط في الترميز. هذا ما يوزع RtlCompat. يقسم RtlSymmetry عندما ترى حشوات غير متماثلة. بشكل عام ، رأيي هو أن aapt ، عند معالجة الموارد ، يجب أن تتعطل إذا صادفت حشيات متماثلة. إذا كنت بحاجة إلى نوع من عمليات الوصول غير المتماثلة ، فاستخدم الهوامش كمعلمة تخطيط كاملة.
أخيرًا ، المشكلة الرابعة هي RTL الثابت الترميز. هذا هو بالضبط أنه في السمات يتم الإشارة فقط إلى قيم اليسار واليمين. بشكل أساسي ، يؤدي هذا إلى إلغاء أداة إعادة التنظيم إضافة دعم RTL حيثما كان ذلك ممكنًا. كل ذلك يأتي من لينت على دخول RTL. تطبيق التحليل متاح أيضًا في AOSP في فئة RtlDetector. أي أنه إذا سمح لك الخيال ، فيمكنك التوصل إلى شيء خاص بك من خلال النظر في كيفية إجراء التحليل الآن.
تقريري يقترب من نهايته. أريد أن أقدم بعض الأطروحات حول بناء الترجمة الصحيحة في طلبنا ، والتي وصلنا إليها بمرور الوقت.
بادئ ذي بدء ، في بداية المشروع ، فكر في التدويل. لم أذكرها حقًا. هذا ليس على الإطلاق نفس التعريب. في الواقع ، التدويل يجعل التعريب ممكنًا في التطبيق ، في المنتج. يعمل هذا خارج منطقة الجزاء في Java نظرًا لحقيقة أنه يحتوي على دعم Unicode الكامل ، وفي Android - بسبب نظام الموارد الثري. ولعل الشيء الوحيد الذي يمكن أن يحدث هنا هو تثبيتنا كمطورين على السمة التي "أكتب التطبيق باللغة الروسية فقط ، مما يعني أنني سوف أتحقق منه فقط باللغة الروسية". وعند البدء في استخدام اللغات الأرمينية أو الجورجية أو العبرية أو العربية في التطبيق ، تبدو الصورة مختلفة تمامًا وتنهار حول النموذج المعتاد.
اللحظة الثانية. النظر في تضمين الترجمة في CI الخاص بك. من المخيب للآمال أن تتعرف على المشكلات المرتبطة بالترجمات أثناء مرحلة الاختبار لمرشح الإصدار ، والتي يمكنك الإعداد لها لعدة أسابيع. أي أننا نقوم الآن بتشغيل هذه المهمة لكل طلب تجميع ، حتى نتمكن من التأكد مسبقًا من أن كل شيء على ما يرام مع الترجمات وأنه يمكننا تجميد الكود الجديد في الفرع الرئيسي للمشروع.
النقطة الثالثة. احترم عمل المترجمين وميزانيتك. أولاً ، احذف الموارد غير المستخدمة لأن بإمكان الأشخاص الاستمرار في قضاء الوقت والمال في ترجمة الجمل التي لا تستخدمها في مشروعك في النهاية. ثانياً ، اتبع الترجمات الموجودة في المستودع الخاص بك في خدمة الترجمة ، ولكنها غير موجودة في الكود.
من الناحية المثالية ، إذا كانت واجهة برمجة التطبيقات لخدمة الترجمة الخاصة بك توفر معلومات حول وقت فتح مفتاح معين ، ويمكنك استخدام الأساليب البحثية مثل "إذا تم فتح المفتاح منذ أكثر من شهر" ، فتحقق من وجوده في أحدث مراجعة لبرنامج الغداء المتأخر. إذا لم يكن هناك ، على الأرجح ، فهذا مرشح واضح لإزالته وبالتالي فإن السكان المحليين لا يقضون وقتًا فيه.
مرشح عالمي أكثر أو أقل للرصاصة الفضية هو تخزين السلاسل على الواجهة الخلفية ، وليس على العميل. على الأقل ، سيتيح لك هذا الفرصة لإبقائها ذات صلة دائمًا في جانب التطبيق.
لدينا جمهور مستخدم متنوع للغاية ، حيث يدرك الجميع محتوى العالم والتطبيق بطريقته الخاصة. مهمتنا كمطورين هي المساعدة في الحفاظ على هذا التصور. تقريري حول هذا الموضوع قد انتهى. شكرا جزيلا