He encontrado un comportamiento inconsistente con las etiquetas de emoji en el compositor de temas y lo he reproducido en main sin modificar, en el commit 802125b979b5bb848a7cfc52409ef3176ffd4d82.
Para una etiqueta de emoji existente, escribir su nombre puede mostrar la opción Crear en lugar de la etiqueta existente y su recuento de uso. Seleccionar esa opción y publicar aún así adjunta la etiqueta existente. Una etiqueta de emoji genuinamente nueva es un caso aparte: se puede seleccionar en el compositor, pero desaparece después de publicar.
Para reproducir el problema de la etiqueta existente:
- Usa un sitio con una etiqueta de emoji existente, como
😊, y otras etiquetas más frecuentemente usadas. - Abre el compositor de temas e introduce el nombre de la etiqueta de emoji.
- Si esa etiqueta está fuera del límite de etiquetas populares devuelto, el menú desplegable muestra una opción de creación y etiquetas populares no relacionadas, sin el recuento de uso de la etiqueta existente.
- Selecciona la opción de creación, publica y actualiza. El tema sigue usando el registro original de la etiqueta.
En una prueba aislada en el navegador, usé una etiqueta de emoji existente con un recuento de 17, una etiqueta no relacionada con un recuento de 100 y un límite de búsqueda de 1. El menú desplegable mostró Create: '😊' y popular x100; después de publicar, la etiqueta de emoji existente se reutilizó correctamente. Sin ningún registro existente de 😊, la misma operación devolvió HTTP 200 pero no guardó ninguna etiqueta.
La causa está en DiscourseTagging.clean_tag, que se usa tanto para los términos de búsqueda como para guardar nuevos nombres. Elimina los caracteres de emoji. La búsqueda luego recurre a resultados populares, mientras que al guardar aún puede encontrar una etiqueta existente por su nombre original antes de limpiar los nuevos nombres.
Tengo un pequeño parche que preserva los grafemas completos de emoji reconocidos por los datos existentes de Emoji.unicode_replacements. Mantiene el filtrado ASCII existente y elimina caracteres inválidos del texto no relacionado con emojis. También permite que las sugerencias de etiquetas deshabilitadas coincidan con el inicio de un nombre, ya que la expresión actual de límite de palabra pasa por alto nombres que comienzan con emoji, como 😊-restricted.
El parche modifica dos archivos de implementación y añade cobertura de regresión en tres archivos de prueba. No añade una migración de base de datos, cambios en el frontend, una nueva API ni otra caché de emojis.
Validación local: 572 ejemplos relacionados del backend y 8 ejemplos del navegador pasaron. Las pruebas del navegador verifican que una etiqueta de emoji existente muestre x17, y que tanto esta como una 😊 genuinamente nueva permanezcan después de publicar y actualizar.
Actualización — 23 de octubre de 2026
La corrección se ha enviado ahora como PR #44994: FIX: Preserve emoji tags during search and saving y está lista para revisión.
La CI completa en mi fork ha pasado: los 10 trabajos de la matriz de pruebas, linting y comprobaciones de licencia.
Para esta ejecución, usé una rama de validación separada con la misma corrección y aumenté el tiempo de espera del trabajo de pruebas de 20/30 minutos a 90 minutos, ya que la ejecución anterior agotó el tiempo de espera en el runner del fork. Los comandos de prueba, la matriz y las aserciones no cambiaron. El ajuste del tiempo de espera no forma parte de la PR upstream. La PR no ha sido fusionada; la CI upstream aún espera la aprobación del mantenedor.
Rama del parche:
Informes y discusiones relacionados:
Estos informes describen limitaciones anteriores de las etiquetas de emoji. Este parche aborda los fallos de búsqueda y guardado en el compositor reproducidos anteriormente; no afirma resolver todos los problemas de etiquetas de emoji.