In meiner Dokumentation habe ich /commands in Backtick-Codeformatierung dokumentiert. Wenn ich jedoch nach „commands“ suche, gibt es kein Ergebnis. Die Suche muss /commands lauten, damit das Thema angezeigt wird.
Ist das beabsichtigt? Ich erwarte nicht, dass Benutzer nach einem bestimmten Befehl suchen, dem ein / vorangestellt ist – beides sollte meiner Meinung nach das Thema finden.
Bearbeitung; Die Codeformatierung ist unerheblich, da „/commands“ allein zum selben Problem führt.
Bearbeitung 2; Dies kann beispielsweise nicht mit „.command“ reproduziert werden. Die Suche nach „command“ liefert in diesem Fall das gewünschte Ergebnis.
Ich habe nach Einstellungen gesucht, die mit „Suchen“ zu tun haben, aber nichts Offensichtliches gefunden. Haben Sie eine Ahnung, wonach ich suchen soll?
Richtig, ich erwarte nicht, dass meine Benutzer im Voraus wissen, dass sie “/” einfügen müssen, um dies zu finden. Gibt es einen Grund, warum dieses Verhalten erwartet wird oder eine mögliche Problemumgehung? Denn es beeinträchtigt die Suchbarkeit meiner Dokumentation erheblich.
Suche ist eine komplizierte Angelegenheit Du möchtest, dass dies angezeigt wird, aber was ist, wenn du auch andere verschiedene Dokumente mit „Befehlen“ hättest und in diesem Fall keine Dokumente mit „/Befehlen“ angezeigt werden sollten?
Ein Trick, den du anwenden kannst, ist, Schlüsselwörter in deinen Beitrag aufzunehmen:
Ich stimme zu, dass es kompliziert ist! Während /commands ein Beispiel ist, habe ich wahrscheinlich über 100 Befehle dokumentiert. Daher ist die Verwendung von Schlüsselwörtern zwar eine Alternative, aber nicht ideal.
Wenn das Wort irgendwo gefunden wird, sollte es bei der Suche angezeigt werden, das ist mein Verständnis. Zum Beispiel:
Beachten Sie, dass wir im zweiten Fall das ! verloren haben. Wir haben uns entschieden, ! nicht beizubehalten. Ich vermute, dass Satzzeichen bei der Suche nicht als relevant erachtet werden.
Ich verstehe, meiner Meinung nach sollte / auch keine Rolle spielen? Ich bin mir nicht sicher, wie die Indizierung funktioniert, aber eine Einstellung, um dies zu ändern, würde mir sehr helfen.
Mir ist aufgefallen, dass „somequery“ als Teil einer URL das Ergebnis https://domain.com/somequery-article-today zurückgibt, wenn diese URL irgendwo im Forum steht. Das ist erwartetes Verhalten – ich weiß nicht, wie relevant diese sind, aber ich fand es interessant, dass in diesem Fall das / keine Rolle spielt.
Eine weitere Sache, die mir nach etwas tieferer Recherche aufgefallen ist: Wir haben einen durch Schrägstriche getrennten String: query1/query2.
query1 gibt ein Ergebnis zurück, query2 gibt keine Ergebnisse zurück. Würden Sie sagen, dass dies auch erwartet wird, denn das erscheint mir eher wie ein Fehler…
Ich stoße dies erneut an, da ich immer noch glaube, dass es die Suche stark beeinträchtigt. Einige der Ärgernisse, die ich in letzter Zeit hatte:
Github-Links > Weder Benutzername noch Repository-Name sind durchsuchbar.
X-Links > Benutzernamen sind nicht durchsuchbar.
Es gibt noch viele weitere Beispiele. Wenn Sie die Suche nicht intensiv nutzen, fallen Ihnen diese Dinge vielleicht nicht auf, da sie nicht wirklich das beeinflussen, was Sie in der Suche sehen, sondern das, was Sie nicht sehen. Wir sollen nicht ständig darüber nachdenken, ob ein Thema ein Schlüsselwort für die Auffindbarkeit benötigt oder nicht.
Dies gilt insbesondere für Entwürfe/Mitarbeiterbereiche, in denen Beiträge einfach noch nicht fertig sind, manchmal jahrelang dort verbleiben oder die Kommunikation in einem kürzeren/internen Format erfolgt. Dieser Beitrag wäre für die Schlüsselwörter Mitarbeiter und intern nicht auffindbar, wenn ich dies nicht hinzufügen würde… weil Discourse einfach entschieden hat, dass sie nicht relevant sind? Warum?
Ich kann kaum zustimmen, dass dies kein Fehler ist, sondern eher ein sehr ungewöhnlicher Ansatz für eine Entscheidung des Suchindex.
Basierend auf einigen Tests, die ich heute durchgeführt habe, scheint dies behoben worden zu sein? Ich bin mir nicht sicher, ob es beabsichtigt war, aber danke!
Bearbeiten: Vergessen Sie es.. das Verhalten ist immer noch dasselbe.
Beachten Sie, dass dies tatsächlich die Funktionsweise des PostgreSQL-Stemmers/Tokenizers ist. Wir haben einige Workarounds für Ausnahmefälle wie URLs, bei denen es verwirrend werden kann, aber insgesamt lagern wir vieles davon an pg aus.
Interessanterweise hatten wir vor einigen Jahren einen Hack für „zusätzliche Indizierung in URLs“, den @tgxworld aufgrund von Index-Bloat entfernt hat.
Ich kann wohl sagen, dass wir über diese Art von Ausnahmefällen bei der Suche nachdenken. Es erfordert jedoch ziemlich viel Aufwand, um den bestehenden Framework in pg fulltext zu umgehen.
Ich schätze deine Antwort, Sam!
Ich verstehe, dass dies ein komplexes Stück Technik ist, hoffentlich findet ihr Jungs jemals eine gute Lösung – in der Zwischenzeit habe ich mich angepasst und versuche, versteckte Schlüsselwörter und kreative Wege zu finden, um diese Einschränkung zu umgehen!