Nella mia documentazione ho documentato /commands formattato con la formattazione del codice in backtick. Tuttavia, se cerco “commands” non ottengo alcun risultato. La ricerca deve essere /commands affinché l’argomento venga visualizzato.
È un comportamento intenzionale? Non mi aspetto che gli utenti cerchino un comando specifico anteponendo il /. Entrambi dovrebbero trovare l’argomento secondo me.
Modifica: la formattazione del codice non è correlata, poiché semplicemente “/commands” porta allo stesso problema.
Modifica 2: non è possibile riprodurre questo problema con, ad esempio, “.command”. La ricerca di “command” in questo caso fornisce il risultato desiderato.
Giusto, non mi aspetto che i miei utenti sappiano in anticipo che devono includere “/” per trovarlo. C’è un motivo per cui questo comportamento è previsto o una possibile soluzione? Perché influisce seriamente sulla ricercabilità della mia documentazione.
La ricerca è una questione complicata Vuoi che questo venga visualizzato, ma cosa succederebbe se avessi altri documenti diversi con “comandi” e non volessi che i documenti con “/comandi” venissero visualizzati in questo caso?
Un trucco che puoi usare è avere parole chiave nel tuo post:
Concordo, é complicado! Embora /commands seja um exemplo, tenho provavelmente mais de 100 comandos documentados. Portanto, embora o uso de palavras-chave possa ser uma alternativa, não é ideal.
[quote=“Joffrey Jaffeux, post:7, topic:315217, username:j.jaffeux”]aveva anche altri documenti diversi con “comandi” e non vorresti che i documenti con “/comandi” venissero mostrati in questo caso?
[/quote]
Se la parola viene trovata da qualche parte, dovrebbe apparire nella ricerca, questa è la mia comprensione. Ad esempio:
Notare che abbiamo perso il ! nel secondo caso. Abbiamo deciso di non mantenere ! sospetto che il carattere di punteggiatura non sia considerato rilevante nella ricerca.
Capisco, secondo me anche / non dovrebbe essere rilevante? Non sono sicuro di come funzioni l’indicizzazione, ma un’impostazione per cambiarla mi aiuterebbe molto.
Ho notato che “somequery” come parte di un URL restituisce il risultato https://domain.com/somequery-article-today se questo URL si trova da qualche parte nel forum. Questo è il comportamento previsto - non so quanto siano correlati, ma ho trovato interessante che in questo caso il / non sia rilevante.
Un’altra cosa che ho notato dopo aver approfondito un po’ la questione: abbiamo una stringa separata da barre: query1/query2.
query1 restituisce un risultato, query2 non restituisce risultati, diresti che anche questo è previsto, perché mi sembra più un bug se me lo chiedi…
Ri-sollevo la questione perché credo ancora che influenzi molto la ricerca… alcuni dei fastidi che ho riscontrato ultimamente:
Link Github > né il nome utente né il nome del repository sono ricercabili..
Link X > i nomi utente non sono ricercabili
Ci sono molti altri esempi, se non ti affidi molto alla ricerca queste cose potrebbero passare inosservate, poiché non influisce realmente su ciò che vedi nella ricerca, ma su ciò che non vedi. Non dovremmo pensare costantemente se un argomento necessita o meno di una parola chiave per essere trovabile.
Questo vale soprattutto per le bozze/sezioni staff, dove i post semplicemente non sono ancora completati, a volte rimangono lì per anni, o la comunicazione è in formato più breve/interno. Questo post non sarebbe trovabile per le parole chiave staff e internal se non le avessi aggiunte… perché Discourse ha semplicemente deciso che non sono rilevanti? Perché?
Difficilmente posso concordare sul fatto che questo non sia un bug, piuttosto un approccio molto insolito per una decisione sull’indice di ricerca.
Nota che questo è in realtà il modo in cui funziona lo stemmer/tokenizer di postgres sql, abbiamo alcune soluzioni alternative in atto per casi limite come gli URL in cui può creare confusione, ma nel complesso esternalizziamo molte di queste cose a pg.
È interessante notare che avevamo una soluzione temporanea qualche anno fa per “indicizzazione aggiuntiva negli URL” che @tgxworld ha rimosso a causa del bloat dell’indice.
Suppongo che quello che posso dire è che sì, stiamo pensando a questo tipo di casi limite nella ricerca, ma ci vuole parecchio per spingerci verso soluzioni temporanee attorno al framework esistente in pg fulltext.
Capisco che si tratti di una tecnologia complessa, spero che voi troviate presto una buona soluzione alternativa - nel frattempo mi sono adattato e sto cercando di usare parole chiave nascoste e modi creativi per aggirare questa limitazione!