Incorrecto - dirección de la flecha en contextos de texto RTL

Característica
1

Esto no tiene nada que ver con la configuración bidi en Discourse.

Cuando escribo -\u003e se convierte en un carácter de flecha →, por lo que A -\u003e B se muestra como “A -\u003e B”. Bastante genial.

Sin embargo, la flecha va en la dirección equivocada en texto RTL: א -\u003e ב se muestra como: “א -\u003e ב” con la flecha yendo en la dirección equivocada. (Si estás leyendo esto en el futuro después de que este error haya sido corregido, esto se mostraba como “א → ב”)

Tenga en cuenta que la secuencia de caracteres de entrada aquí es:

Carácter Nombre
א LETRA HEBREA ALEF
ESPACIO
- SIGNO DE MENOS GUIÓN
\u003e SIGNO MAYOR QUE
ESPACIO
ב LETRA HEBREA BET

lo cual puede verificar copiando la cadena א -\u003e ב en esta herramienta: https://unicodedecode.com/

Esto se debe a que los caracteres de flecha no se reflejan bidi en Unicode. Documento relevante: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

En particular, los caracteres de flecha y similares a flechas a menudo tienen un carácter espejo. Se podría argumentar que deberían haber tenido el valor de propiedad Bidi_Mirrored=Yes, pero no lo tienen, y ahora no pueden obtenerlo.

Desafortunadamente, no existe un carácter de flecha que invierta el bidi, lo que significa que si desea realizar esta sustitución correctamente, debe determinar la dirección bidi del texto circundante para elegir correctamente entre las flechas \u003c- y -\u003e. No es una tarea fácil.

1 me gusta
2

@falco Argumentaría que esto es un error, no una solicitud de función. La salida es exactamente lo opuesto a las intenciones y expectativas del usuario.

3

Esto significa que tendríamos que crear una nueva función, ya que actualmente seguimos la especificación de Unicode, que es la razón por la que lo he reclasificado como una solicitud de Feature.

Pasando a abordar su problema, creo que esto se podría hacer fácilmente en un Theme component, utilizando nuestra API existente api.decorateCooked.

2 Me gusta
4

Gracias. No tengo prisa por arreglarlo en ningún foro en particular, solo creo que esto debería arreglarse en Discourse.

No quiero entrar en una discusión inútil sobre semántica, así que lo dejaré ahí. He dicho lo que tenía que decir, creo que esto debería considerarse un error, pero lo que hagas con ello depende de ti ahora.

Gracias por tu atención y rápida respuesta :slight_smile:

1 me gusta
5

Bueno… Un hombre solo puede resistir hasta cierto punto. Diré una última cosa (lo prometo). Hasta donde sé, la especificación Unicode no fomenta la conversión de -\u003e a → (y este problema sería una de las razones por las que), por lo que esta característica existente de Discourse no sigue ninguna especificación Unicode. Hace una suposición falsa sobre el texto e introduce este error en el proceso. Así es como lo veo. (La característica sigue siendo genial, sin embargo)

¡Ahora he dicho lo que tenía que decir!

3 Me gusta
6

Si estoy escribiendo en un idioma de derecha a izquierda, podría esperar escribir ‘guion’ seguido de ‘menor que’ y esperar que se convierta en una flecha hacia la izquierda, como esta: ←. Eso me parece una expectativa razonable. Pero, cuando escribo un menor que, el compositor inserta un mayor que. Esto fue bastante inesperado. ¿Es ese el error?

Observo que un cuadro de texto RTL (como el cuadro de búsqueda en aljazeera.net) inserta números y símbolos matemáticos en orden LTR dentro del texto RTL. Esto parece bastante natural. (Hace lo mismo para los caracteres latinos).

A continuación, escribiré “menor que es < y mayor que es >” en un contexto RTL (no sé si así es como funcionarían las cosas en una configuración regional RTL):

‮menor que es < y mayor que es >

3 Me gusta
7

No usas un script de derecha a izquierda en la vida cotidiana, ¿verdad? No hay ningún error en lo que describiste. Hay cierta ambigüedad en lo que dijiste, así que para evitar confusiones, abordaré primero la segunda parte de tu comentario.

Esto es exactamente como se supone que debe funcionar. Piénsalo de esta manera:

El carácter \u003e significa literalmente “mayor que”. La cadena “A \u003e B” significa “A es mayor que B”.

De manera similar, para decir “א es mayor que ב”, reemplazaría “es mayor que” con el mismo carácter de mayor que con el mismo código U+003E. Sin embargo, debido a que la cadena es completamente RTL, “א” aparece a la derecha de “ב”. Si el carácter “mayor que” se representara igual que LTR, se mostraría: א\u003cב, que se lee como “א es menor que ב” o “ב es mayor que א”, la relación opuesta a la que se describe.

Es por eso que al representar el carácter de mayor que, se invierte visualmente cuando está en RTL. Pero el carácter subyacente, y los datos Unicode que lo respaldan, sigue siendo el símbolo de “mayor que”. La cadena todavía significa “א es mayor que ב”.

Ahora volvamos a tu primera pregunta:

Si cambias la distribución de tu teclado a un idioma RTL (como hebreo o árabe), entonces la combinación de teclas Shift+, (la tecla con \u003c impreso) en realidad escribiría el carácter “mayor que” \u003e. Esto se representaría como \u0026rlm;\u003e\u0026rlm; en un contexto RTL, como en el cuadro de búsqueda que encontraste.

[Edición: el siguiente párrafo se escribió cuando entendí mal lo que dijiste que habías probado. Pensé que estabas escribiendo en un cuadro RTL con un teclado LTR, cuando en realidad estabas haciendo lo contrario. Espero haber respondido a tu confusión.]

Pero todavía estás usando una distribución de teclado latina, por lo que cuando presionas esa combinación de teclas, inserta un carácter “menor que” \u003c. Pero se representa como \u0026rlm;\u003c\u0026rlm; porque en RTL, significa que lo que está a la derecha es menor que lo que está a la izquierda.

En resumen: el carácter es el mismo, pero su representación se invierte.

Si has entendido lo que he dicho hasta ahora, entonces entenderás que eso haría -\u003c o en RTL \u0026rlm;-\u003c\u0026rlm;, que no creo que sea lo que quisiste decir.

¿Lo expliqué con éxito o solo te confundí más?

1 me gusta
8

Si crees que te iría mejor con documentos oficiales de Unicode, prueba este: UAX #9: Unicode Bidirectional Algorithm haz ctrl+F para “mirror” y encontrarás buenas descripciones y ejemplos.

1 me gusta
9

Tienes toda la razón, estoy interviniendo sin experiencia y ¡además con un teclado latino!

Así que debería callarme… pero veo que si escribo (en mi teclado latino) 3<6 en el cuadro de búsqueda de Al Jazeera, veo esto:

image
image200×126 1.98 KB

Lo que probablemente demuestra que tienes razón y yo estoy equivocado, ¡y eso no debería ser ninguna sorpresa!

2 Me gusta
10

¡En absoluto! Si solo a los usuarios de RTL se les permitiera discutir y corregir errores de RTL, ¡estaríamos mucho peor! Simplemente aproveché esta oportunidad para presentarte el tema. Se supone que lleva tiempo asimilarlo. Estaré encantado de responder cualquier otra pregunta o curiosidad que tengas al respecto.

1 me gusta
11

Me he unido a la lista de correo de Unicode para proponer una adición a Unicode que sería una solución en casos como este. Una de las respuestas que recibí fue esta:

(Yo:) El problema es que este reemplazo se realiza (por lo que sé) fuera de cualquier contexto de renderizado, cuando el texto es solo una secuencia de códigos de caracteres. No es razonable saber en qué dirección va el texto. A veces es completamente imposible, si la dirección del texto depende de un contexto que no está disponible en el momento del reemplazo.

Lo anterior es estrictamente inexacto. Cualquier renderizado de texto serio hoy en día requiere un motor de modelado, como HarfBuzz, y la ligadura de “-” a “→” sería realizada por dicho modelador en cooperación con una fuente que soporte ligaduras. El motor de modelado es consciente del contexto bidi y del script del texto que modela, por lo que en principio podría reflejar la flecha.

Están hablando de algo como esto: GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Considere cambiar al enfoque de ligaduras en lugar de un reemplazo ciego de caracteres. Otra ventaja discutible sería que, al copiar y pegar, el texto seguiría siendo “-” en lugar de una flecha.

No he investigado los detalles técnicos de cómo implementar esto, eso se lo dejo a usted si decide utilizar esta solución.

Editar: bueno, como era de esperar, Fira Text en particular no está diseñado teniendo en cuenta RTL, por lo que el renderizado es incorrecto, ¡pero al menos apunta en la dirección correcta! https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox:

image
image473×164 5.61 KB

No estoy seguro de si existe hoy en día una fuente que haga esto correctamente y que soporte explícitamente RTL/bidi.

1 me gusta
12

Curiosamente, obtengo un resultado diferente en Chromium:
~~Edición: Ya no puedo reproducir esto, así que creo que lo escribí mal cuando tomé esta captura de pantalla.~
Edición: Y ahora puedo reproducirlo de nuevo. La situación es mala.

image
image524×165 5.86 KB

Es posible que los motores de renderizado/modeladores del navegador no estén a la altura de esta tarea. Tendré que investigar más, y esto no es en lo que se supone que debo centrarme ahora mismo…

Edición: los límites del foro me obligaron a eliminar esto de mi respuesta anterior:
Como referencia, este es el código responsable de este reemplazo:

1 me gusta
14

Como mencioné, estoy trabajando en proponer una solución Unicode para este problema. Allí explico el problema a fondo, y espero que de forma más clara de lo que lo he explicado aquí. Todavía está en progreso, pero por favor échale un vistazo: Making sure you're not a bot! (enlace permanente)

Específicamente, revisa la sección de Discourse.

Por supuesto, incluso si Unicode acepta esta propuesta (cuando finalmente la presente), pasarían años para que se implementara lo suficientemente ampliamente como para ser confiable, por lo que no es un buen plan esperar a eso.