Ho riscontrato 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 l’opzione Crea invece del tag esistente e del relativo conteggio di utilizzo. Selezionando tale opzione e pubblicando, il tag esistente viene comunque allegato. Un tag emoji nuovo è un caso a parte: può essere selezionato nel compositore, ma scompare dopo la pubblicazione.
Per riprodurre il problema del tag esistente:
- Utilizzare un sito con un tag emoji esistente, ad esempio
😊, e altri tag più frequentemente utilizzati. - Aprire il compositore di argomenti e inserire il nome del tag emoji.
- Se quel tag è fuori dal 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.
- Selezionare l’opzione di creazione, pubblicare e aggiornare la pagina. L’argomento utilizza ancora il record del tag originale.
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 popolare 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 sia per il salvataggio di nuovi nomi. Esso rimuove i caratteri emoji. La ricerca passa quindi ai risultati popolari come fallback, mentre il salvataggio può ancora trovare un tag esistente tramite il suo nome originale prima della pulizia dei nuovi nomi.
Ho una piccola patch che preserva i grafiemi emoji completi riconosciuti dai dati esistenti di Emoji.unicode_replacements. Mantiene il filtraggio ASCII esistente e rimuove i caratteri non validi dal testo non-emoji. Consente inoltre ai suggerimenti di tag disabilitati di corrispondere all’inizio di un nome, poiché l’espressione corrente dei confini di parola manca 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 una migrazione del database, modifiche al frontend, una nuova API o un’altra cache emoji.
Validazione locale: 572 esempi backend correlati e 8 esempi browser superati. I test del browser verificano che un tag emoji esistente mostri x17 e che sia questo sia un nuovo 😊 genuinamente nuovo rimangano dopo la pubblicazione e l’aggiornamento.
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 nel compositore riprodotto sopra; non pretende di risolvere tutti i problemi relativi ai tag emoji.