Dans ma documentation, j’ai documenté /commands formaté en code avec des backticks. Cependant, si je recherche « commands », aucun résultat n’apparaît. La recherche doit être /commands pour que le sujet apparaisse.
Est-ce un comportement intentionnel ? Je ne m’attends pas à ce que les utilisateurs recherchent une commande spécifique en préfixant le / - les deux devraient trouver le sujet, à mon avis.
Edit ; le formatage du code n’est pas pertinent, car simplement « /commands » aboutit au même problème.
Edit 2 ; je ne peux pas reproduire cela avec, par exemple, « .command », rechercher « command » donne le résultat souhaité dans ce cas.
C’est exact, je ne m’attends pas à ce que mes utilisateurs sachent à l’avance qu’ils doivent inclure “/” pour le trouver. Y a-t-il une raison pour laquelle ce comportement est attendu ou une solution de contournement possible ? Parce que cela affecte sérieusement la capacité de recherche de ma documentation.
La recherche est une affaire compliquée Vous voulez que cela apparaisse, mais que se passerait-il si vous aviez d’autres documents différents avec des « commandes » et que vous ne vouliez pas que les documents avec « /commandes » apparaissent dans ce cas ?
Une astuce que vous pouvez utiliser est d’avoir des mots-clés dans votre publication :
Je suis tout à fait d’accord, c’est compliqué ! Bien que /commands soit un exemple, j’ai probablement plus de 100 commandes documentées. Donc, bien que l’utilisation de mots-clés puisse être une alternative, ce n’est pas idéal.
Si le mot est trouvé quelque part, il devrait apparaître dans la recherche, c’est ce que je comprends. Par exemple :
Notez que nous avons perdu le ! dans le second cas. Nous avons décidé de ne pas conserver le ! ; je soupçonne que le caractère de ponctuation n’est pas considéré comme pertinent dans la recherche.
Je vois, à mon avis, / ne devrait pas être pertinent non plus ? Je ne suis pas sûr du fonctionnement de l’indexation, mais un paramètre pour changer cela m’aiderait beaucoup.
J’ai remarqué que « somequery » dans une URL renvoie le résultat https://domain.com/somequery-article-today si cette URL se trouve quelque part sur le forum. C’est un comportement attendu - je ne sais pas à quel point ils sont liés, mais j’ai trouvé intéressant que dans ce cas, le / ne soit pas pertinent.
Autre chose que j’ai remarqué après avoir examiné cela un peu plus en profondeur : nous avons une chaîne séparée par des barres obliques : query1/query2.
query1 renvoie un résultat, query2 ne renvoie aucun résultat, diriez-vous que c’est aussi attendu, car cela ressemble plus à un bug si vous me demandez…
Je remonte ce sujet car je pense toujours que cela affecte beaucoup la recherche… quelques-unes des contrariétés que j’ai rencontrées récemment :
Liens Github > ni le nom d’utilisateur ni le nom du dépôt ne sont recherchables..
Liens X > les noms d’utilisateur ne sont pas recherchables
Il y a beaucoup d’autres exemples, si vous ne comptez pas beaucoup sur la recherche, ces choses peuvent passer inaperçues, car cela n’affecte pas vraiment ce que vous voyez dans la recherche, mais ce que vous ne voyez pas. Nous ne sommes pas censés réfléchir constamment à savoir si un sujet a besoin d’un mot-clé pour être trouvable.
Ceci est particulièrement vrai pour les brouillons/sections du personnel, où les publications ne sont tout simplement pas terminées, y restent parfois pendant des années, ou la communication est sous un format plus court/interne. Ce post ne serait pas trouvable pour les mots-clés “personnel” et “interne” si je n’ajoutais pas ceci… parce que Discourse a simplement décidé qu’ils n’étaient pas pertinents ? Pourquoi ?
J’ai du mal à admettre que ce n’est pas un bug, mais plutôt une approche très inhabituelle pour une décision d’index de recherche.
Notez que c’est en fait ainsi que fonctionne le stemmer / tokenizer de postgres sql, nous avons mis en place des solutions de contournement pour les cas limites comme les URL où cela peut prêter à confusion, mais dans l’ensemble, nous externalisons une grande partie de ces choses à pg.
Il est intéressant de noter que nous avions une astuce en place il y a quelques années pour “l’indexation supplémentaire dans les URL” que @tgxworld a supprimée en raison de l’encombrement de l’index.
Je suppose que ce que je peux dire, c’est que oui, nous pensons à ce genre de cas limites dans la recherche, mais il faut beaucoup d’efforts pour que nous poussions à contourner le framework existant dans pg fulltext.
Je comprends que c’est une pièce technologique complexe, j’espère que vous trouverez un bon contournement - en attendant, je me suis adapté et j’essaie d’utiliser des mots-clés cachés et des moyens créatifs pour contourner cette limitation !
Vous voulez que cela apparaisse, mais que se passerait-il si vous aviez d’autres documents différents avec des « commandes » et que vous ne vouliez pas que les documents avec « /commandes » apparaissent dans ce cas ?
