سلوك البحث غير المتوقع: عندما لا يعثر 'commands' على '/commands'

في وثائقي، قمت بتوثيق /commands بتنسيق الكود باستخدام علامات الاقتباس المائلة. ومع ذلك، إذا بحثت عن “commands” فلا يوجد نتيجة. يجب أن يكون البحث هو /commands حتى يظهر الموضوع.

هل هذا سلوك مقصود؟ لا أتوقع من المستخدمين البحث عن أمر معين مسبوقًا بـ / - يجب أن يؤدي كلاهما إلى العثور على الموضوع في رأيي.

تعديل؛ تنسيق الكود غير مرتبط، حيث أن مجرد “/commands” يؤدي إلى نفس المشكلة.

تعديل 2؛ لا يمكن تكرار هذا على سبيل المثال مع “.command”، البحث عن “command” يعطي النتيجة المرجوة في هذه الحالة.

إعجابَين (2)

تحديث متفائل. :smile:

لا أقوم بإعادة إنتاج هذا عند البحث عن /commands:

لقد فشلنا للتو في العثور على commands، والتي يمكننا مناقشة أنها يجب أن تجدها، لكنها ليست خطأ بحد ذاتها.

بحثت عن إعدادات متعلقة بـ “البحث”، لكنني لم أجد شيئًا واضحًا. هل لديك أي فكرة عما أبحث عنه؟

لا، أعتقد أن السلوك متوقع

صحيح، لا أتوقع من مستخدمي معرفة مسبقًا أنهم بحاجة إلى تضمين “/” للعثور على هذا. هل هناك سبب لهذا السلوك المتوقع أو حل بديل ممكن؟ لأن هذا يؤثر بشكل خطير على قابلية البحث في وثائقي.

البحث مسألة معقدة :slight_smile: تريد أن يظهر هذا، ولكن ماذا لو كان لديك مستندات أخرى مختلفة تحتوي على “commands” ولا تريد أن تظهر المستندات التي تحتوي على “/commands” في هذه الحالة؟

إحدى الحيل التي يمكنك استخدامها هي وضع كلمات مفتاحية في منشورك:

<small>Keywords: commands</small>

إعجاب واحد (1)

أوافق تمامًا على أنه أمر معقد! بينما يُعد /commands مثالاً، لديّ ربما أكثر من 100 أمر موثق. لذا، بينما يمكن أن تكون الكلمات المفتاحية بديلاً، إلا أنها ليست مثالية.

إذا تم العثور على الكلمة في مكان ما، فيجب أن تظهر في البحث، هذا هو فهمي. على سبيل المثال:

/testcommand > query: testcommand > :no_entry_sign:

betacommand! > query: betacommand > :white_check_mark:

!betacommand > query: betacommand > :white_check_mark:

ما الذي يجعل “/” مختلفًا عن “!” هنا؟

هذا بسبب الطريقة التي نفهرس بها البيانات:

“test /command” → “‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”
“test !command” → “‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”

لاحظ أننا فقدنا علامة ! في الحالة الثانية. لقد قررنا عدم الاحتفاظ بعلامة ! وأعتقد أن حرف علامة الترقيم لا يعتبر ذا صلة في البحث.

إعجابَين (2)

حسنًا، في رأيي لا ينبغي أن يكون / ذا صلة أيضًا؟ لست متأكدًا من كيفية عمل الفهرسة، ولكن إعدادًا لتغيير هذا سيساعدني كثيرًا.

لاحظت أن “somequery” كجزء من عنوان URL يعيد النتيجة https://domain.com/somequery-article-today إذا كان عنوان URL هذا موجودًا في مكان ما في المنتدى. هذا سلوك متوقع - لا أعرف مدى ارتباط هذه الأمور، لكنني وجدت أنه من المثير للاهتمام أنه في هذه الحالة لا يكون / ذا صلة.

شيء آخر لاحظته بعد التعمق في هذا قليلاً: لدينا سلسلة مفصولة بشرطة مائلة: query1/query2.

query1 يعيد نتيجة، query2 لا يعيد نتائج، هل تقول إن هذا متوقع أيضًا، لأن هذا يبدو أشبه بخطأ إذا سألتني.. :thinking:

إعجاب واحد (1)

أقوم بتحديث هذا الموضوع حيث ما زلت أعتقد أنه يؤثر بشكل كبير على البحث.. بعض الإزعاجات التي واجهتها مؤخرًا:

روابط Github > لا يمكن البحث عن اسم المستخدم أو اسم المستودع..
روابط X > لا يمكن البحث عن أسماء المستخدمين

هناك العديد من الأمثلة الأخرى، إذا كنت لا تعتمد على البحث كثيرًا فقد تمر هذه الأشياء دون أن يلاحظها أحد، لأنها لا تؤثر حقًا على ما تراه في البحث، بل على ما لا تراه. لا يُفترض بنا أن نفكر باستمرار فيما إذا كان الموضوع يحتاج إلى كلمة مفتاحية لسهولة العثور عليه أم لا.

هذا ينطبق خاصة على المسودات/أقسام الموظفين، حيث لم يتم الانتهاء من المشاركات ببساطة، وأحيانًا تبقى هناك لسنوات، أو يكون التواصل بتنسيق أقصر/داخلي. لن يكون هذا المنشور قابلاً للعثور عليه بالكلمات المفتاحية “موظفين” و “داخلي” إذا لم أضف هذا.. لأن Discourse قرر ببساطة أنها غير ذات صلة؟ لماذا؟

أجد صعوبة في الموافقة على أن هذا ليس خطأ، بل هو نهج غير شائع جدًا لقرار فهرسة البحث.

4 إعجابات

من بعض الاختبارات التي أجريتها اليوم، يبدو أن هذا قد تم إصلاحه؟ لست متأكدًا مما إذا كان ذلك متعمدًا، ولكن شكرًا لك!

تعديل؛ لا تهتم.. لا يزال السلوك كما هو. :frowning:

إعجاب واحد (1)

لاحظ أن هذه هي الطريقة التي يعمل بها محفز / محلل postgres sql، ولدينا بعض الحلول البديلة للحالات الهامشية مثل عناوين URL حيث يمكن أن يصبح الأمر مربكًا، ولكن بشكل عام نقوم بتفويض الكثير من هذه الأمور إلى pg.

ومن المثير للاهتمام أننا كان لدينا اختراق في الماضي لـ “فهرسة إضافية في عناوين URL” قام @tgxworld بإزالته بسبب تضخم الفهرس.

أعتقد أن ما يمكنني قوله هو نعم، نحن نفكر في هذه الأنواع من الحالات الهامشية في البحث، ولكنه يتطلب الكثير لدفعنا نحو اختراق الإطار الحالي في pg fulltext.

إعجاب واحد (1)

أنا أقدر ردك يا سام!
أتفهم أن هذه قطعة تقنية معقدة، آمل أن تجدوا حلاً بديلاً جيدًا - في هذه الأثناء، لقد تكيفت وأحاول استخدام الكلمات المفتاحية المخفية والطرق الإبداعية للتغلب على هذا القيد!

إعجاب واحد (1)

أعتقد أن الكلمات الرئيسية المخفية كمواطنين من الدرجة الأولى مثيرة للاهتمام

تم اقتراح ذلك في هذا الموضوع، في الواقع؛ Unexpected Search Behavior: When 'commands' Doesn't Find '/commands' - #7 by j.jaffeux