أولاً، شكرًا جزيلاً لك على مساعدتك! إنها بالفعل خطأ مثير للاهتمام.
المشكلة هي أنني قد أحتاج إلى تغيير اسم المستخدم عبر قاعدة البيانات، لأن المسار غير متاح 
هل يمكنك تزويدي بالاستعلام المطلوب؟
أعتقد أن هذا غير ممكن، لأنه في هذه الحالة سأمنع العديد من الأسماء التي تبدأ بحرف Σ في اليونان (وسأكسر فعليًا تسجيل الدخول عبر فيسبوك لهؤلاء المستخدمين). هل يمكنني منع نمط تعبير منتظم (regex) محدد؟ بحيث أتأكد من أن حرف Σ موجود على الأقل في النهاية؟
عضو آخر سجل مع نفس المشكلة تمامًا. نقطي هنا هي أنه بالنسبة لنا، هذه ليست حالة هامشية. هناك literally آلاف الأسماء اليونانية التي تستخدم حرف Σ (أو ς) في نهاية الاسم.
وبشكل غير محظوظ، نظرًا لفئتنا العمرية الأساسية (> 40)، هناك العديد من الأعضاء الذين تظهر أسماءهم مكتوبة بأحرف كبيرة على فيسبوك ()، لذا عندما يستخدمون تسجيل الدخول عبر فيسبوك، يتم نسخ اسمهم إلى حقل اسم المستخدم…
لا تقلق بشأن Postgres. يجب أن نقارن دائمًا بـ username_lower في SQL ولا نعتمد على LOWER()، لأن username_lower ليس مجرد النسخة الصغيرة من اسم المستخدم. نحن نطبق أيضًا التطبيع Unicode.
أتفق معك. إضافة حل مؤقت إلى User.normalize_username يجب أن يكون كافياً حتى الآن. هناك بالفعل بعض النقاش في عيب Ruby ويبدو أنه لا يوجد حل سهل. ومع ذلك، نحن محظوظون، لأن كل ما نحتاجه هو التحقق من آخر حرف في اسم المستخدم. هذا أسهل بكثير من القيام بذلك في جملة كاملة.
حسنًا… كيف سيتم التعامل مع هذا اسم المستخدم؟
بالأحرف الكبيرة: ΧΡΗΣΤΟΣ_ΠΑΝΑΓΙΩΤΑΚΟΠΟΥΛΟΣ
بالأحرف الصغيرة: χρηστος_παναγιωτακοπουλος أو χρηστοσ_παναγιωταكوπουλος
يتعامل NodeJs مع هذا بشكل صحيح، لكن إذا قمت بفحص الحرف الأخير في اسم المستخدم فقط، فستستمر المشكلة.
(تنتهي تقريبًا جميع الأسماء الذكرية في اليونانية -سواء الأسماء الأولى أو العائلية- بحرف Σ)
صحيح. ومع ذلك، يجب أن يكون الأمر أسهل بكثير من التنفيذ الكامل، حيث أننا بحاجة للقلق فقط بشأن رموز معينة مثل الشرطة السفلية والشرطة العلوية وربما الأرقام؟ يجب أن يكون ذلك ممكنًا.
أعلم أنني أبتعد عن مناقشة هذه المشكلة المحددة، لكن عندما أفكر في هذه القضية، لا يمكنني تجاهل حقيقة أنه يمكن تجنبها.
لقد اكتشفت أن هناك بعض مسارات API في Discourse تشير إلى مستخدم عبر userId، بينما أخرى تشير إلى مستخدم عبر username. ألا ينبغي أن يكون هذا أكثر اتساقًا (بمصلحة userId)؟
ربما بتطبيق شيء مشابه لما يحدث حاليًا مع التصنيفات/الوسوم؟ بحيث يتوفر كل من username وuserId في الرابط، على سبيل المثال: https://meta.discourse.org/u/chrispanag/4387
فكرة فقط
سيكون هذا الأمر يتطلب جهد تنظيف، فقد رأيت بالتأكيد بعض استدعاءات LOWER().
ظهر هذا الموضوع على مر السنين: Update quotes and mentions when username is changed - #10 by sam
في عام 2016، كان @eviltrout ضد ذلك، ولا أعرف موقفه الحالي منه.
على أي حال، لدي حل بديل في Discourse في هذا طلب الدمج:
سيتم من خلاله معالجة مشكلة التسجيل الجديدة في فيسبوك عن طريق تحويل أي اسم مستخدم يحتوي على حرف السيجما في البداية إلى أحرف صغيرة. هذا يعني أن كل ما تحتاجه هو تعديل اسم مستخدم سبيروس وأي مستخدمين آخرين لديهم سيجما نهائية بتحويلها إلى أحرف صغيرة، وستختفي المشكلة على المدى الطويل.
(انتظار دمج طلب الدمج)
شكرًا جزيلاً لك يا @sam! كان مساعدتك عظيمة.
هل توجد طريقة للقيام بذلك من وحدة تحكم Rails؟ (لأن المستخدم معطل، فلا توجد طريقة للقيام بذلك عبر لوحة الإدارة…)
نعم، هذا يجب أن ينجز المهمة
./launcher enter app
rails c
u = User.find_by(username: 'ΣΠΥΡΟΣ')
u.username = 'σπυρος'
u.username_lower = 'σπυρος'
u.save!
ما زلت لا أحب استخدام المعرفات (IDs) في كل مكان، لكنني أدرك أن هناك العديد من الحالات التي يكون فيها ذلك منطقيًا.
في تلك الحالات، سأفضل شيئًا مثل id-username حيث يكون username أي شيء يمكننا وضعه في عنوان URL. يمكن تجاهله حتى بواسطة الموجه. لكن على الأقل عند مشاركة الرابط، ستحصل على فكرة عما تشير إليه.
بشأن PostgreSQL، يبدو أن إعداد الترتيبات (collations) المناسبة يحل المشكلة:
➜ discoursesmall git:(master) psql -d discourse_development
psql (13.1 (Ubuntu 13.1-1.pgdg20.10+1))
Type "help" for help.
discourse_development=# SELECT lower('ΣΠΥΡΟΣ');
lower
--------
σπυροσ
(1 row)
discourse_development=# SELECT lower('ΣΠΥΡΟΣ' COLLATE "und-x-icu");
lower
--------
σπυρος
(1 row)
المصدر: https://www.postgresql.org/message-id/5d80ac2d-3f1f-4d60-88a8-5602eb9978a3%40manitou-mail.org
يبدو أن هناك أحرف يونيكود أخرى تخضع لتحولات مماثلة، مثل: ‘ß’ → ‘SS’ (الألمانية)
من المثير للاهتمام استكشاف كيفية معالجة Discourse لها…
كما يمكنك أيضًا الاطلاع على هذا المورد:
شخصيًا، أنا من المعجبين الكبار بنظام التوجيه الخاص بـ Stack Overflow للمستخدمين:
https://stackoverflow.com/users/17174/sam-saffron
في عالم Discourse، سيكون هذا على الشكل التالي:
https://meta.discourse.org/u/17174/sam-saffron
هذا النهج يمنحك أفضل ما في العالمين. نعم، أفهم تمامًا الاعتراض القائل بـ “لا أحب ظهور الرقم 17174 في أي مكان ضمن الرابط، فالأسماء المستعارة مستقرة”.
ومع ذلك، فقد استمررنا في العمل بمساراتنا الحالية لفترة طويلة، والمشكلة الوحيدة هي أن بعض الحالات الهامشية تظهر بين الحين والآخر كل بضع سنوات.
أعتقد أنه سيكون من المفيد استخدام المعرف (ID) بدلاً من اسم المستخدم (أو كلاهما، ولكن الاعتماد فقط على المعرف، كما هو موضح أعلاه) على الأقل في صفحة ملف المستخدم، بحيث يتمكن المسؤول من تغيير اسم المستخدم باستخدام واجهة مستخدم Discourse دون الحاجة إلى تشغيل الأمر في وحدة تحكم Rails إذا حدث خطأ ما مع اسم المستخدم.
علينا أن نقلق فقط بشأن الأحرف التي تختلف فيها تحويلات الحروف الصغيرة بين تنفيذي JavaScript وRuby. وليس العكس.
لا توجد قاعدة تحدد كيفية تحويل الحرف الصغير الألماني “ß” إلى حروف كبيرة. فقد يكون التحويل إلى “SS” أو “SZ” أو حتى الحرف الكبير الجديد “ẞ” (نعم، هناك فرق دقيق). ولا يمكن عكس هذه العملية إلا في حالة “ẞ”، وهذا يعمل بشكل صحيح في Ruby وJavaScript.
أعتقد أننا يجب أن نتخذ الخطوات التالية:
LOWER(username) من استعلامات SQL، لأن ذلك مجرد ممارسة سيئة ™ (مثلًا: عدم وجود تطبيع يونيكود).غير متأكد مما إذا كان الأمر مرتبطًا، لكن لدينا عدد من المستخدمين بأسماء يونيكود، وهي موزعة عبر /log
ActionView::Template::Error (No route matches {:action=>"show", :controller=>"users", :username=>"ζηεδψ"}, possible unmatched constraints: [:username])