إجراءات السحب

الحافّتان منطقيتان، فتتبادلان مواضعهما مع اتجاه الواجهة: ما عرّفته leading يظهر عند يمين الشاشة في العربية، وما عرّفته trailing يظهر عند يسارها. هذا سلوك المنصّة الصحيح لا خلل فيه، فـ SwiftUI تأخذ HorizontalEdge في ‎.swipeActions(edge:)‎، و UIKit يفصل بين tableView(_:leadingSwipeActionsConfigurationForRowAt:)‎ و tableView(_:trailingSwipeActionsConfigurationForRowAt:)‎، وكلاهما يُحلّ من الاتجاه الفعّال للواجهة. أمّا الفريق الذي كتب مواصفته بكلمتَي «يمين» و«يسار» فسيجد الحذف تحت الإبهام الخطأ بعد التعريب: الحركة التي تعوّد المستخدم أنها «أرشفة» صارت «حذف».

أرقام المؤشّر لا تعرف اتجاه الواجهة ولا تنقلب معه. الفرق بين clientX الحالي وقيمته عند بداية الجرّة موجب عند التحرّك يميناً في الاتجاهين معاً، و dX التي يمرّرها ItemTouchHelper.onChildDraw إزاحة فيزيائية كذلك، ومثلها ما تعيده UIPanGestureRecognizer.translation(in:)‎ لأن نظام إحداثيات العرض لا ينعكس. لذلك على كلّ تنفيذ يدوي أن يضرب الإزاحة في إشارة اتجاه قبل أن يقرّر أيّ حافّة انكشفت: getComputedStyle(el).direction === "rtl" ? -1 : 1 على الويب، و LocalLayoutDirection.current == LayoutDirection.Rtl في Compose، و traitCollection.layoutDirection == .rightToLeft في UIKit؛ أمّا المكوّنات الجاهزة فتتكفّل بهذا عنك، إذ ItemTouchHelper يعرّف START و END النسبيّتين ويحوّلهما إلى LEFT و RIGHT عبر convertToAbsoluteDirection حسب اتجاه التخطيط، بينما LEFT و RIGHT مطلقتان لا تنقلبان أبداً.

اللوح المكشوف يرسو على الحافّة التي يخصّها، فثبّت لوح الخاتمة بـ inset-inline-end: 0 ولوح البادئة بـ inset-inline-start: 0 بدل right و left، فينتقلان وحدهما عند الانعكاس. وداخل كلّ زرّ يُبقي text-align: start مع padding-inline-start النصَّ والأيقونةَ في جهة القراءة، أمّا text-align: left فيلصق النصّ العربي بالطرف البعيد من زرّ عرضه ٦٠ بكسل فيبدو خللاً في العرض لا اختياراً في التصميم. أمّا إزاحة الصفّ فوق اللوح فبـ transform، وهي خاصّية فيزيائية بلا مكافئ منطقي في CSS، فاكتبها translateX(calc(var(--reveal) * var(--dir) * -1)) واضبط ‎--dir: -1 داخل [dir="rtl"]، وإلّا انزلق الصفّ فوق اللوح الخطأ وكشف الحافّة المقابلة.

أيقونات الإجراءات لا تنعكس: سلّة المهملات وصندوق الأرشيف والعلم والجرس رسوم لأشياء مادّية لا يتغيّر معناها باتجاه الصفحة، فقاعدة شاملة مثل [dir="rtl"] svg { transform: scaleX(-1) } تقلبها بلا سبب وتجعلها تبدو مرسومة بالمقلوب. الاستثناء أسهم «ردّ» و«إعادة توجيه» وحدها، ولا ينقلب منها شيء تلقائياً: اضبط android:autoMirrored="true" على الـ vector drawable في أندرويد، واستدعِ imageFlippedForRightToLeftLayoutDirection()‎ على UIImage في iOS، واقصر قاعدة scaleX(-1) على صنف تلك الأيقونة وحدها في الويب، ورموز SF التي لها نسخة RTL هي الوحيدة التي تتكفّل بنفسها.

إيماءة الرجوع في iOS تبدأ من الحافّة البادئة، ومثلها إجراء الحافّة البادئة، فالتنافس بين interactivePopGestureRecognizer وبينه قائم في العربية كما كان في الإنجليزية: الاثنان ينعكسان معاً ولا يتبدّل غير الجانب. والحالة التي تُوقع الفرق هي المتصفّح، لأن Safari يحسب حافّة الرجوع من لغة واجهة المتصفّح لا من سمة dir في صفحتك، فصفحة عربية داخل Safari إنجليزي تبقى بادئتها يميناً بينما يظلّ شريط الرجوع يساراً. وعلى الويب يمنع touch-action: pan-y المتصفّحَ من سحب الصفّ لكنه لا يلغي إيماءة الحافّة، ولا سبيل إلى إلغائها من الصفحة أصلاً، فابدأ الجرّة بعيداً عن الطرفين معاً، وعلى أندرويد ١٠ فما فوق حيث الطرفان كلاهما منطقة رجوع احجز شريطك بـ View.setSystemGestureExclusionRects.