Errado - direção da seta em contextos de texto RTL

Funcionalidade
1

Isso não tem nada a ver com as configurações bidi no Discourse.

Quando digito -\u003e, ele é convertido em um caractere de seta →, então A -\u003e B é renderizado como “A -\u003e B”. Bem legal.

No entanto, a seta vai na direção errada em texto RTL: א -\u003e ב é renderizado como: “א -\u003e ב” com a seta indo na direção errada. (Se você estiver lendo isso no futuro, depois que esse bug for corrigido, isso foi renderizado como “א → ב”)

Note que a sequência de caracteres de entrada aqui é:

Caractere Nome
א HEBREW LETTER ALEF
SPACE
- HYPHEN-MINUS
\u003e GREATER-THAN SIGN
SPACE
ב HEBREW LETTER BET

o que você pode verificar copiando a string א -\u003e ב para esta ferramenta: https://unicodedecode.com/

Isso ocorre porque os caracteres de seta não espelham bidi no Unicode. Documento relevante: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

Em particular, caracteres de seta e semelhantes a setas frequentemente têm um caractere espelhado. Poderia-se argumentar que eles deveriam ter o valor de propriedade Bidi_Mirrored=Yes, mas não têm, e não podem obtê-lo agora.

Infelizmente, não há um caractere de seta que inverta o bidi, o que significa que, se você quiser fazer essa substituição corretamente, terá que determinar a direção bidi do texto circundante para escolher corretamente entre as setas \u003c- e -\u003e. Não é uma tarefa fácil.

1 curtida
2

@falco Argumentaria que isso é de fato um bug, não uma solicitação de recurso. A saída é o oposto exato das intenções e expectativas do usuário.

3

Dado que

Isso significa que teríamos que construir um novo recurso, pois atualmente seguimos a especificação Unicode, e é por isso que o recategorizei como uma solicitação de #recurso.

Passando para abordar seu problema, acho que isso poderia ser facilmente feito em um #componente-de-tema, usando nossa API existente api.decorateCooked.

2 curtidas
4

Obrigado. Não tenho pressa para que seja corrigido em nenhum fórum específico, apenas acho que isso deveria ser corrigido no Discourse.

Não quero entrar em uma discussão inútil sobre semântica, então vou parar por aqui. Eu disse o que tinha a dizer, acho que isso deveria ser considerado um bug, mas o que você faz com isso depende de você agora.

Obrigado pela sua atenção e rápida resposta :slight_smile:

1 curtida
5

Bem… Um homem só pode resistir até certo ponto. Direi mais uma coisa (prometo). Pelo que sei, a especificação Unicode não incentiva a conversão de -\u003e para → (e este problema seria um dos motivos), então este recurso existente do Discourse não está seguindo nenhuma especificação Unicode. Ele faz uma suposição incorreta sobre o texto e introduz este bug no processo. É assim que eu vejo. (O recurso ainda é legal, no entanto)

Agora eu disse o que tinha a dizer!

3 curtidas
6

Se eu estivesse digitando em um idioma da direita para a esquerda, eu poderia esperar digitar ‘traço’ seguido de ‘menor que’ e esperar que ele se convertesse em uma seta para a esquerda, assim: ←. Isso me parece uma expectativa razoável. Mas, quando digito um menor que, o compositor insere um maior que. Isso foi bastante inesperado. Esse é o bug?

Notei que uma caixa de texto RTL (como a caixa de pesquisa em aljazeera.net) insere números e símbolos matemáticos em ordem LTR dentro do texto RTL. Isso parece natural o suficiente. (Ele faz o mesmo para letras latinas)

Abaixo, digitarei “menor que é \u003c e maior que é \u003e” em um contexto RTL (não sei se é assim que as coisas funcionariam em uma localidade RTL):

‮menor que é \u003c e maior que é \u003e

3 curtidas
7

Você não usa um script da direita para a esquerda no dia a dia, certo? Não há bug no que você descreveu. Há alguma ambiguidade no que você disse, então para evitar confusão, abordarei a segunda parte do seu comentário primeiro.

É exatamente assim que deveria funcionar. Pense desta forma:

O caractere > significa literalmente “maior que”. A string “A > B” significa “A é maior que B”.

Da mesma forma, para dizer “א é maior que ב”, eu substituiria “é maior que” pelo mesmo caractere de maior que com o mesmo código U+003E. No entanto, como a string é totalmente RTL, “א” aparece à direita de “ב”. Se o caractere “maior que” fosse renderizado da mesma forma que LTR, ele mostraria: א<ב, que é lido como “א é menor que ב” ou “ב é maior que א” - a relação exatamente oposta à que está sendo descrita.

É por isso que ao renderizar o caractere de maior que, ele é visualmente invertido quando em RTL. Mas o caractere subjacente, e os dados Unicode por trás dele, ainda é o símbolo de “maior que”. A string ainda significa “א é maior que ב”.

Agora, de volta à sua primeira pergunta:

Se você mudar o layout do seu teclado para um idioma RTL (como hebraico ou árabe), a combinação de teclas Shift+, (a tecla com o < impresso nela) na verdade digitará o caractere “maior que” >. Isso será renderizado como > em um contexto RTL, como na caixa de pesquisa que você encontrou.

[Edição: o próximo parágrafo foi escrito quando eu entendi um pouco mal o que você disse que tinha testado. Pensei que você estava digitando em uma caixa RTL com um teclado LTR, quando na verdade estava fazendo o oposto. Espero ainda ter respondido à sua confusão.]

Mas você ainda está usando um layout de teclado latino, então quando você pressiona essa combinação de teclas, ele insere um caractere “menor que” <. Mas ele é renderizado como < porque em RTL, significa que o que está à direita é menor do que o que está à esquerda.

Resumindo: o caractere é o mesmo, mas sua renderização é espelhada.

Se você entendeu o que eu disse até agora, então entenderá que isso faria -< ou em RTL -<, o que eu não acho que seja o que você quis dizer.

Consegui explicar ou apenas te deixei mais confuso?

1 curtida
8

Se você acha que se sairia melhor com documentos oficiais do Unicode, experimente este: UAX #9: Unicode Bidirectional Algorithm use ctrl+F para “mirror” e você encontrará algumas boas descrições e exemplos.

1 curtida
9

Você está absolutamente certo, estou entrando sem experiência e também com um teclado latino!

Então eu deveria ficar quieto… mas vejo que se eu digitar (no meu teclado latino) 3<6 na caixa de pesquisa da Al Jazeera, vejo isto:

image
image200×126 1.98 KB

O que provavelmente mostra que você está certo, e eu estou errado, e isso não deveria ser surpresa!

2 curtidas
10

De jeito nenhum! Se apenas usuários de RTL pudessem discutir e corrigir bugs de RTL, estaríamos muito pior! Apenas aproveitei esta oportunidade para apresentá-lo ao assunto. Deve levar algum tempo para você compreendê-lo. Ficarei feliz em responder a quaisquer outras perguntas ou curiosidades que você tenha sobre isso.

1 curtida
11

Juntei-me à lista de discussão do Unicode para propor uma adição ao Unicode que seria uma solução em casos como este. Uma das respostas que recebi foi esta:

(Eu:) O problema é que essa substituição é feita (pelo que sei) fora de qualquer contexto de renderização, quando o texto é apenas uma sequência de códigos de caracteres. Não é razoável saber a direção do texto. Às vezes, é completamente impossível, se a direção do texto depender de um contexto que não está disponível no momento da substituição.

O acima é estritamente falando impreciso. Qualquer renderização de texto séria hoje em dia requer um motor de modelagem, como o HarfBuzz, e a ligação de “-” para “→” seria feita por tal modelador em cooperação com uma fonte que suporta ligaturas. O motor de modelagem está ciente do contexto bidi e do script do texto que ele modela, então, em princípio, poderia espelhar a seta.

Eles estão falando sobre algo como isto: GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Considere mudar para a abordagem de ligatura em vez de substituição cega de caracteres. Outra vantagem discutível seria que, ao copiar e colar, o texto ainda seria “-” em vez de uma seta.

Eu não olhei os detalhes técnicos de como implementar isso, deixarei isso para você se você optar por usar esta solução.

Editar: bem, sem surpresa, o Fira Text em particular não foi projetado com RTL em mente, então a renderização está errada - mas pelo menos está apontando na direção certa! https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox:

image
image473×164 5.61 KB

Não tenho certeza se existe hoje uma fonte que faça isso corretamente e suporte explicitamente RTL/bidi.

1 curtida
12

Curiosamente, obtenho um resultado diferente no Chromium:
Editar: Não consigo reproduzir isso agora, então acho que digitei errado quando tirei esta captura de tela.
Editar: E agora consigo reproduzir novamente. A situação é ruim.

image
image524×165 5.86 KB

É possível que os motores de renderização/modeladores de navegador não estejam à altura desta tarefa. Precisarei investigar mais, e isso não é no que eu deveria estar focando agora…

Editar: os limites do fórum me forçaram a remover isso da minha resposta anterior:
Para referência, este é o código responsável por esta substituição:

1 curtida
14

Como mencionei, estou trabalhando em propor uma solução Unicode para este problema. Nele explico o problema detalhadamente, e espero que de forma mais clara do que expliquei aqui. Ainda está em andamento, mas por favor, dê uma olhada: Making sure you're not a bot! (permalink)

Especificamente, confira a seção do Discourse.

Claro, mesmo que o Unicode aceite esta proposta (quando eu eventualmente a submeter), levaria anos para que fosse implementada amplamente o suficiente para ser confiável, então não é um bom plano esperar por isso.