Errato - direzione della freccia nei contesti di testo RTL

Funzionalità
1

Questo non ha nulla a che fare con le impostazioni bidi in Discourse.

Quando digito -\u003e viene convertito in un carattere freccia →, quindi A -\u003e B viene visualizzato come “A -\u003e B”. Abbastanza bello.

Tuttavia, la freccia va nella direzione sbagliata nel testo RTL: א -\u003e ב viene visualizzato come: “א -\u003e ב” con la freccia che va nella direzione sbagliata. (Se stai leggendo questo in futuro dopo che questo bug è stato corretto, questo è stato visualizzato come “א → ב”)

Nota che la sequenza di caratteri di input qui è:

Carattere Nome
א LETTERA EBRAICA ALEF
SPAZIO
- SEGNO MENO-IPHEN
\u003e SEGNO MAGGIORE DI
SPAZIO
ב LETTERA EBRAICA BET

che puoi verificare copiando la stringa א -\u003e ב in questo strumento: https://unicodedecode.com/

Questo perché i caratteri freccia non si specchiano bidi in Unicode. Documento pertinente: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

In particolare, i caratteri freccia e simili a freccia hanno spesso un carattere speculare. Si potrebbe sostenere che avrebbero dovuto avere il valore della proprietà Bidi_Mirrored=Yes, ma non ce l’hanno e non possono ottenerlo ora.

Sfortunatamente non esiste un carattere freccia che capovolge il bidi, il che significa che se si desidera eseguire questa sostituzione correttamente, è necessario determinare la direzione bidi del testo circostante per scegliere correttamente tra le frecce \u003c- e -\u003e. Non è un compito facile.

1 Mi Piace
2

@falco Sostengo che questo sia effettivamente un bug, non una richiesta di funzionalità. L’output è l’esatto opposto delle intenzioni e delle aspettative dell’utente.

3

Dato che

Significa che dovremmo creare una nuova funzionalità, poiché attualmente seguiamo le specifiche Unicode, motivo per cui l’ho ricategorizzata come #richiesta-funzionalità.

Passando ad affrontare il tuo problema, penso che questo potrebbe essere facilmente fatto in un #componente-tema, utilizzando la nostra API esistente api.decorateCooked.

2 Mi Piace
4

Grazie. Non ho fretta di farlo sistemare in nessun forum in particolare, penso solo che questo dovrebbe essere sistemato in Discourse.

Non voglio entrare in un’inutile discussione sui semantica, quindi mi fermo qui. Ho detto quello che dovevo dire, penso che questo dovrebbe essere considerato un bug, ma quello che ne farai ora dipende da te.

Grazie per la tua attenzione e la tua rapida risposta :slight_smile:

1 Mi Piace
5

Beh… un uomo può resistere solo fino a un certo punto. Dirò un’ultima cosa (promesso). Per quanto ne so, le specifiche Unicode non incoraggiano la conversione di -\u003e in → (e questo problema ne sarebbe una delle ragioni), quindi questa funzionalità esistente di Discourse non segue alcuna specifica Unicode. Fa una falsa supposizione sul testo e introduce questo bug nel processo. Questo è come la vedo io. (La funzionalità è comunque interessante)

Ora ho detto quello che dovevo dire!

3 Mi Piace
6

Se sto digitando in una lingua da destra a sinistra, potrei sperare di digitare “trattino” seguito da “minore di” e aspettarmi che si converta in una freccia verso sinistra, come questa: ←. Mi sembra un’aspettativa ragionevole. Ma, quando digito un “minore di”, il compositore inserisce un “maggiore di”. Questo era piuttosto inaspettato. È questo il bug?

Noto che una casella di testo RTL (come la casella di ricerca su aljazeera.net) inserisce numeri e simboli matematici in ordine LTR all’interno del testo RTL. Questo sembra abbastanza naturale. (Fa lo stesso per le lettere latine)

Di seguito digiterò “minore di è < e maggiore di è >” in un contesto RTL (non so se è così che funzionerebbero le cose in una locale RTL):

‮minore di è < e maggiore di è >

3 Mi Piace
7

Non usi uno script da destra a sinistra nella vita di tutti i giorni, vero? Non c’è nessun bug in ciò che hai descritto. C’è una certa ambiguità in ciò che hai detto, quindi per evitare confusione affronterò prima la seconda parte del tuo commento.

È esattamente così che dovrebbe funzionare. Pensala in questo modo:

Il carattere > significa letteralmente “maggiore di”. La stringa “A > B” significa “A è maggiore di B”.

Allo stesso modo, per dire “א è maggiore di ב” dovrei sostituire “è maggiore di” con lo stesso carattere maggiore di con lo stesso codice U+003E. Tuttavia, poiché la stringa è interamente RTL, “א” appare a destra di “ב”. Se il carattere “maggiore di” fosse reso allo stesso modo di LTR, mostrerebbe: א<ב che si legge come “א è minore di ב” o “ב è maggiore di א” - la relazione esattamente opposta a quella descritta.

Questo è il motivo per cui quando si renderizza il carattere maggiore di, viene visivamente capovolto quando è in RTL. Ma il carattere sottostante, e i dati Unicode che lo supportano, sono ancora il simbolo “maggiore di”. La stringa significa ancora “א è maggiore di ב”.

Ora torniamo alla tua prima domanda:

Se cambi il layout della tastiera in una lingua RTL (come l’ebraico o l’arabo), la combinazione di tasti Shift+, (il tasto con stampato <) digiterà effettivamente il carattere “maggiore di” >. Questo verrà reso come > in un contesto RTL, come nella casella di ricerca che hai trovato.

[Modifica: il paragrafo successivo è stato scritto quando ho leggermente frainteso ciò che hai detto di aver testato. Pensavo stessi digitando in una casella RTL con una tastiera LTR, quando in realtà stavi facendo il contrario. Spero di aver comunque risposto alla tua confusione.]

Ma stai ancora usando un layout di tastiera latino, quindi quando premi quella combinazione di tasti, inserisce un carattere “minore di” <. Ma viene reso come < perché in RTL, significa che ciò che è a destra è minore di ciò che è a sinistra.

In sintesi: il carattere è lo stesso, ma il suo rendering viene specchiato.

Se hai capito quello che ho detto finora, allora capirai che ciò renderebbe -< o in RTL -< che non credo sia quello che intendevi.

Sono riuscito a spiegarlo o ti ho solo confuso di più?

1 Mi Piace
8

Se pensi di fare meglio con i documenti ufficiali Unicode, prova questo: UAX #9: Unicode Bidirectional Algorithm fai ctrl+F per “mirror” e troverai alcune buone descrizioni ed esempi.

1 Mi Piace
9

Hai perfettamente ragione, sto intervenendo senza esperienza e anche con una tastiera latina!

Quindi dovrei stare zitto… ma vedo che se digito (sulla mia tastiera latina) 3<6 nella casella di ricerca di Al Jazeera, vedo questo:

image
image200×126 1.98 KB

Il che probabilmente dimostra che hai ragione tu, e io ho torto, e questo non dovrebbe sorprendere!

2 Mi Piace
10

Assolutamente no! Se solo agli utenti RTL fosse permesso discutere e correggere bug RTL, saremmo molto peggio! Ho solo colto questa opportunità per introdurti all’argomento. Ci vuole del tempo per capirlo bene. Sono felice di rispondere a qualsiasi altra domanda o curiosità tu abbia al riguardo.

1 Mi Piace
11

Mi sono unito alla mailing list Unicode per proporre un’aggiunta a Unicode che sarebbe una soluzione in casi come questo. Una delle risposte che ho ricevuto è stata questa:

(Io:) Il problema è che questa sostituzione viene eseguita (per quanto ne so) al di fuori di qualsiasi contesto di rendering, quando il testo è solo una sequenza di codici carattere. Non è ragionevole sapere in quale direzione va il testo. A volte è del tutto impossibile, se la direzione del testo dipende da un contesto che non è disponibile al momento della sostituzione.

Quanto sopra è a rigor di termini inaccurato. Qualsiasi rendering di testo serio oggigiorno richiede un motore di shaping, come HarfBuzz, e la legatura di “-” in “→” verrebbe eseguita da tale shaper in collaborazione con un font che supporta le legature. Il motore di shaping è consapevole del contesto bidi e dello script del testo che modella, quindi in linea di principio potrebbe specchiare la freccia.

Stanno parlando di qualcosa del genere: GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Considera di passare all’approccio delle legature invece della sostituzione cieca dei caratteri. Un altro vantaggio discutibile sarebbe che, quando viene copiato e incollato, il testo sarebbe ancora “-” invece di una freccia.

Non ho approfondito i dettagli tecnici su come implementare questo, lascerò questo a te se scegli di utilizzare questa soluzione.

Modifica: beh, senza sorprese, Fira Text in particolare non è progettato pensando all’RTL, quindi il rendering è errato - ma almeno punta nella giusta direzione! https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox:

image
image473×164 5.61 KB

Non sono sicuro se esista oggi un font che faccia questo correttamente e supporti esplicitamente RTL/bidi.

1 Mi Piace
12

È interessante, ottengo un risultato diverso in Chromium:
~~Modifica: Non riesco più a riprodurlo, quindi penso di averlo digitato in modo errato quando ho fatto questo screenshot.~
Modifica: E ora riesco di nuovo a riprodurlo. La situazione è grave.

image
image524×165 5.86 KB

È possibile che i motori di rendering/shaper del browser non siano all’altezza di questo compito. Dovrò indagare ulteriormente, e questo non è ciò su cui dovrei concentrarmi in questo momento…

Modifica: i limiti del forum mi hanno costretto a rimuovere questo dalla mia precedente risposta:
Per riferimento, questo è il codice responsabile di questa sostituzione:

1 Mi Piace
14

Come ho menzionato, sto lavorando per proporre una soluzione Unicode a questo problema. Lì spiego il problema a fondo, e spero più chiaramente di quanto l’abbia spiegato qui. È ancora in fase di lavorazione, ma dateci un’occhiata: Making sure you're not a bot! (permalink)

In particolare, date un’occhiata alla sezione Discourse.

Naturalmente, anche se Unicode accettasse questa proposta (quando alla fine la presenterò), ci vorrebbero anni perché venisse implementata abbastanza ampiamente da essere affidabile, quindi non è un buon piano aspettare.