En mi documentación he documentado /commands con formato de código entre comillas invertidas. Sin embargo, si busco “commands” no obtengo ningún resultado. La búsqueda tiene que ser /commands para que aparezca el tema.
¿Es este un comportamiento intencionado? No espero que los usuarios busquen un comando específico anteponiendo la /; en mi opinión, ambos deberían encontrar el tema.
Edición; el formato de código no está relacionado, ya que simplemente “/commands” resulta en el mismo problema.
Edición 2; no puedo reproducir esto con, por ejemplo, “.command”, ya que buscar “command” da el resultado deseado en este caso.
Correcto, no espero que mis usuarios sepan de antemano que necesitan incluir “/” para encontrar esto. ¿Alguna razón por la que este comportamiento sea esperado o una posible solución? Porque afecta seriamente la capacidad de búsqueda de mi documentación.
La búsqueda es un asunto complicado Quieres que esto aparezca, pero ¿y si también tuvieras otros documentos diferentes con “comandos” y no quisieras que los documentos con “/comandos” aparecieran en este caso?
Un truco que puedes usar es tener palabras clave en tu publicación:
¡Oh, estoy de acuerdo en que es complicado! Si bien /commands es un ejemplo, tengo probablemente más de 100 comandos documentados. Así que, si bien usar palabras clave podría ser una alternativa, no es ideal.
[quote=“Joffrey Jaffeux, post:7, topic:315217, username:j.jaffeux”]¿También tenías otros documentos diferentes con “commands” y no querrías que aparecieran documentos con “/commands” en este caso?
[/quote]
Si la palabra se encuentra en algún lugar, debería aparecer en la búsqueda, esa es mi comprensión. Por ejemplo:
Observa que perdimos el ! en el segundo caso. Decidimos no mantener el ! sospecho que el carácter de puntuación no se considera relevante en la búsqueda.
Entiendo, ¿en mi opinión / tampoco debería ser relevante? No estoy seguro de cómo funciona la indexación, pero una configuración para cambiar esto me ayudaría mucho.
Noté que “somequery” como parte de una URL devuelve el resultado https://domain.com/somequery-article-today si esta URL está en algún lugar del foro. Este es un comportamiento esperado; no sé cuán relacionados están, pero me pareció interesante que en este caso el / no sea relevante.
Otra cosa que noté después de investigar un poco más a fondo: tenemos una cadena separada por barras: query1/query2.
query1 devuelve un resultado, query2 no devuelve resultados, ¿dirías que esto también es esperado, porque eso se parece más a un error si me preguntas a mí?
Reabro este tema ya que sigo creyendo que afecta mucho a la búsqueda… algunas de las molestias que he tenido últimamente:
Enlaces de Github > ni el nombre de usuario ni el nombre del repositorio son buscables..
Enlaces de X > los nombres de usuario no son buscables
Hay muchos más ejemplos, si no dependes mucho de la búsqueda, estas cosas pueden pasar desapercibidas, ya que no afecta realmente a lo que ves en la búsqueda, sino a lo que no ves. No se supone que debamos pensar constantemente si un tema necesita o no una palabra clave para que sea encontrable.
Esto es especialmente cierto para los borradores/secciones de personal, donde las publicaciones simplemente no están terminadas, a veces permanecen allí durante años, o la comunicación es en un formato más corto/interno. ¿Esta publicación no sería encontrable para las palabras clave personal e interno si no las añadiera… porque Discourse simplemente decidió que no son relevantes? ¿Por qué?
Apenas puedo estar de acuerdo en que esto no sea un error, sino un enfoque muy poco común para la decisión de un índice de búsqueda.
Tenga en cuenta que, de hecho, así es como funciona el stemmer/tokenizador de postgres sql, tenemos algunas soluciones provisionales para casos extremos como las URL en las que puede resultar confuso, pero en general externalizamos muchas de estas cosas a pg.
Curiosamente, tuvimos un hack hace unos años para “indexación adicional en URL” que @tgxworld eliminó debido a la hinchazón del índice.
Supongo que lo que puedo decir es que sí, estamos pensando en este tipo de casos extremos en la búsqueda, pero nos cuesta mucho impulsar el hackeo del marco existente en pg fulltext.
Entiendo que esta es una pieza tecnológica compleja, ¡espero que alguna vez encuentren una buena solución alternativa! Mientras tanto, me he adaptado y estoy tratando de usar palabras clave ocultas y formas creativas de sortear esta limitación.
Quieres que esto aparezca, pero ¿y si también tuvieras otros documentos diferentes con “comandos” y no quisieras que los documentos con “/comandos” aparecieran en este caso?
