Ho trovato un comportamento incoerente con i tag emoji nel compositore di argomenti e l’ho riprodotto su main non modificato al commit 802125b979b5bb848a7cfc52409ef3176ffd4d82.
Per un tag emoji esistente, la digitazione del suo nome può mostrare Crea invece del tag esistente e del relativo conteggio di utilizzo. Selezionando tale opzione e pubblicando, viene comunque allegato il tag esistente. Un tag emoji genuinamente nuovo è un caso a parte: può essere selezionato nel compositore, ma scompare dopo la pubblicazione.
Per riprodurre il problema del tag esistente:
- Usa un sito con un tag emoji esistente, come
😊, e altri tag più frequentemente utilizzati. - Apri il compositore di argomenti e inserisci il nome del tag emoji.
- Se quel tag è al di fuori del limite dei tag popolari restituiti, il menu a discesa mostra un’opzione di creazione e tag popolari non correlati, senza il conteggio di utilizzo del tag esistente.
- Seleziona l’opzione di creazione, pubblica e aggiorna la pagina. L’argomento utilizza ancora il record originale del tag.
In un test isolato nel browser, ho utilizzato un tag emoji esistente con un conteggio di 17, un tag non correlato con un conteggio di 100 e un limite di ricerca di 1. Il menu a discesa ha mostrato Crea: '😊' e popolari x100; dopo la pubblicazione, il tag emoji esistente è stato correttamente riutilizzato. In assenza di un record esistente per 😊, la stessa operazione ha restituito HTTP 200 ma non ha salvato alcun tag.
La causa risiede in DiscourseTagging.clean_tag, che viene utilizzato sia per i termini di ricerca che per il salvataggio di nuovi nomi. Esso rimuove i caratteri emoji. La ricerca passa quindi ai risultati popolari, mentre il salvataggio può comunque trovare un tag esistente tramite il suo nome originale prima della pulizia dei nuovi nomi.
Ho una piccola patch che preserva le grafeme emoji complete riconosciute dai dati esistenti di Emoji.unicode_replacements. Mantiene il filtraggio ASCII esistente e rimuove i caratteri non validi dal testo non-emoji. Consente anche alle suggerimenti di tag disabilitati di corrispondere all’inizio di un nome, poiché l’espressione attuale basata sui confini delle parole trascura i nomi che iniziano con un’emoji, come 😊-restricted.
La patch modifica due file di implementazione e aggiunge copertura di regressione in tre file di test. Non aggiunge migrazioni del database, modifiche frontend, una nuova API o una cache emoji aggiuntiva.
Validazione locale: 572 esempi backend correlati e 8 esempi browser sono stati superati. I test browser verificano che un tag emoji esistente mostri x17 e che sia esso sia un genuinamente nuovo 😊 rimangano presenti dopo la pubblicazione e l’aggiornamento.
Aggiornamento — 23 ottobre 2026
La correzione è stata ora inviata come PR #44994: FIX: Preserve emoji tags during search and saving ed è pronta per la revisione.
L’intera CI sul mio fork è passata: tutti i 10 job della matrice di test, linting e verifiche della licenza.
Per questa esecuzione, ho utilizzato un ramo di validazione separato con la stessa correzione e ho aumentato il timeout del job di test da 20/30 minuti a 90 minuti, poiché l’esecuzione precedente era scaduta sul runner del fork. I comandi di test, la matrice e le asserzioni sono rimasti invariati. L’adeguamento del timeout non fa parte della PR upstream. La PR non è stata fusa; la CI upstream è ancora in attesa dell’approvazione del maintainer.
Ramo della patch:
Segnalazioni e discussioni correlate:
Queste segnalazioni descrivono limitazioni precedenti relative ai tag emoji. Questa patch affronta i fallimenti nella ricerca e nel salvataggio del compositore riprodotti sopra; non pretende di risolvere ogni problema relativo ai tag emoji.