La columna word_count de Post y Topic parece calcularse directamente utilizando el número de espacios, lo cual es completamente inapropiado para idiomas como el chino, japonés y coreano que no usan espacios.
Esto no es un gran problema porque word_count rara vez se usa, pero encontré problemas en AI summary backfill minimum word count. Las publicaciones largas en chino serán filtradas, pero las publicaciones cortas con una mezcla de chino e inglés (con muchos espacios) serán resumidas.
Creo que deberíamos usar un segmentador de palabras que admita varios idiomas, o simplemente usar el recuento de caracteres en algo como AI summary backfill minimum word count.
Por ejemplo, si revisas el recuento de palabras de esta publicación en el Explorador de Datos, encontrarás que solo hay una.
Esto está claramente mal y puede haber afectado el cálculo del tiempo de lectura del usuario, ya que read_time_word_count depende del recuento de palabras.
Hmm, si somos inteligentes con nuestro pipeline podríamos usar cppjieba.
Requeriría que update_index! se encargara de esto:
El recuento de caracteres es probablemente lo más sencillo, dado que leer la palabra bla es mucho más rápido que leer supercalifragilisticexpialidocious.
Me pregunto si puedes hacer alguna PR que cambie para que nos basemos en el recuento de caracteres, ¿entonces podemos dividir el recuento de caracteres por 4, digamos, para inglés y 2 para chino? (a través de alguna configuración)
Para el chino, el recuento de caracteres es el método más comúnmente utilizado para medir la longitud del texto. En términos de implementación, podríamos usar una expresión regular para filtrar los caracteres chinos y luego contarlos directamente. Este enfoque es lo suficientemente eficiente y se alinea con los hábitos de uso chinos. Aunque llamarlo word_count en lugar de char_count podría parecer un poco confuso, quizás podríamos aclarar este punto en la descripción de la configuración relevante.