Cuando introduzco el término de búsqueda de tres caracteres POS, que en una comunidad lingüística se entendería como “parte del discurso”, Discourse toma un prefijo de tres letras y devuelve todo tipo de temas inapropiados. Si busco aquí POS, obtengo temas y respuestas con las palabras post, posts, position, possible, etc., o BOX, los resultados incluyen boxes. Si busco entre la comunidad LLVM PUBLICATIONS, obtengo una gran cantidad de publicaciones con código fuente de ejemplo en C/C++ que contienen la palabra public. Esta búsqueda a nivel de prefijo o lema es muy frustrante y dificulta el descubrimiento de material relevante.
Si se trata de una característica —como su traslado a esa categoría sugiere—, entonces es una mala y se vuelve inútil/
¿Por qué Feature no encaja?
Echando un vistazo a la descripción de la categoría
No se trata solo de características existentes, sino también de mejoras.
Quizás. Sin embargo, como alguien que trabajó en sistemas de recuperación de texto durante décadas, esta “característica” debería considerarse un error. Tal como está actualmente, la función de búsqueda es prácticamente inútil para cualquier cosa que no sean las búsquedas más triviales.
Puedes eliminar todos los resultados de post y position buscando \" pos \".
https://meta.discourse.org/search?q=%22%20pos%20%22
De acuerdo, funciona, pero ¿por qué no es una función accesible para el usuario? Al menos en la página de búsqueda “avanzada”, donde los usuarios podrían habilitar o deshabilitar el stemming —hacer que el no-stemming sea el predeterminado sería menos confuso— a su elección, en lugar de tener que recordar sintaxis arcanas. Y “publication” produce resultados diferentes de “publication” —incluye publicaciones— pero tal vez debamos estar satisfechos de que el stemming a public no ocurra entonces.