Como você mistura scripts da esquerda para a direita e da direita para a esquerda sem que seus arquivos pareçam malucos?


9

Digamos que seu idioma nativo seja o hebraico e você esteja trabalhando em uma linguagem de programação como o Python 3, que permite colocar o hebraico no código-fonte. Bom para você! Você tem um dict:

d = {'a': 1}

e você deseja substituir isso apor um pouco de hebraico. Então você substitui esse caractere único:

d = {'א': 1}

Uh oh Apenas substituindo um caractere, sem fazer outras alterações , sua exibição ficou louca. Tudo, desde o hebraico até o 1contrário, é extremamente óbvio que isso é uma sintaxe válida ( é ), e muito menos o que isso significa.

O hebraico é intrinsecamente da direita para a esquerda e, mesmo sem caracteres de controle invisíveis, o texto em hebraico será exibido da direita para a esquerda. Isso também se aplica a certos caracteres "regulares" em posições próximas ao hebraico, bem como a caracteres de alguns outros scripts. Os detalhes são complicados.

Como você lida com isso? Você não pode inserir caracteres de controle no seu código-fonte para corrigir a exibição sem quebrar o código. Escrever tudo em hexadecimal escapa comercializa um tipo de ilegibilidade para outro. Mesmo se você se resignar a nomear tudo com caracteres do bloco Latim básico e colar todas as strings hebraicas nos arquivos de localização, é difícil evitar misturar o texto da direita para a esquerda e da esquerda para a direita.

JSON ou CSV com hebraico serão ilegíveis. Se esses arquivos de localização nos quais você inseriu suas strings deveriam ser legíveis por humanos, bem, provavelmente não são. O que você faz?


1
Eu acho que isso está relacionado ao seu editor de código ou IDE. A ordem lógica do inglês / hebraico misto não tem problema. O problema existe apenas no visual. Coloquei suas duas linhas de código no Visual Studio 2015 e ele só foi exibido bem. Esse personagem média hebraico exibido na esquerda do 1.
Afshar Mohebbi

@afsharm: Se você colocar mais hebraico, o hebraico aparece da esquerda para a direita ou da direita para a esquerda? Se estiver da esquerda para a direita, seu hebraico está aparecendo para trás e você está na situação de um nativo de inglês se o Visual Studio exibisse suas seqüências como '.dlrow olleH'. Se for da direita para a esquerda, o Visual Studio está fazendo algo estranho que não é forçado da esquerda para a direita nem o algoritmo bidirecional Unicode adequado. Qualquer um dos casos tem suas próprias fontes de confusão.
User2357112 suporta Monica

@afsharm: seu perfil diz Irã, então você provavelmente está muito mais familiarizado com o texto da direita para a esquerda do que eu. Como é quando você digita persa no Visual Studio? (Ou ter Fiz um lugar suposição ruim?)
user2357112 suporta Monica

Você adivinha corretamente. Meu nativo é o persa, que é uma língua RTL, como o árabe e o hebraico. O Visual Studio 2015 não mexe as seqüências de caracteres de idioma único. Consulte tinypic.com/r/2em2137/9 Mas o Visual Studio não é inteligente o suficiente para mostrar seqüências que contêm RTL e LTR simultaneamente corretamente.
Afshar Mohebbi

Outros editores podem ou não ter melhor suporte para idiomas RTL. Por exemplo, o Sublime não possui um bom suporte de scripts RTL por padrão.
Afshar Mohebbi

Respostas:


2

AFAIK, isso é principalmente relevante quando você usa letras não ASCII em identificadores (e talvez comentários) em seu código.

Se você se disciplinar para evitar isso, por exemplo, se o seu código usar identificadores e palavras-chave e comentários com aparência "inglesa", isso será muito menos um problema (e todo desenvolvedor de software poderá ler a documentação e o código em inglês). Em seguida, a internacionalização e localização do seu aplicativo ocorrem apenas em mensagens , principalmente cadeias literais .

Você pode usar algum catálogo de mensagens. Por exemplo, em C e POSIX, você usará gettext (3) e amigos. O catálogo de mensagens localizadas contém todas as variantes localizadas / internacionalizadas da mensagem. Se o seu aplicativo for apenas para usuários de hebraico (e esse não for um grande mercado), o hebraico será apenas em cadeias literais.

Para ser mais específico, o aplicativo hello world conteria

void say_hello(char*towhom) {
  printf(gettext("hello %s"), towhom);
}

e seu aplicativo se personalizaria no início da execução chamando alguns setlocale (3) com argumentos apropriados.

Veja o código do idioma (7) . Adapte tudo isso ao seu Python e sistema operacional. Muitas estruturas de plataforma cruzada (por exemplo, Qt ) têm amplo suporte para internacionalização e localização.

Obviamente, há a questão delicada de exibir seqüências Unicode. As bibliotecas de exibição e GUI e kits de ferramentas mais sérios (Qt, GTk, ...) são capazes de lidar com strings de idiomas mistos (por exemplo, exibindo algo que contenha hebraico e inglês, russo e chinês).

Para uma visão mais ampla, leia a wiki sobre internacionalização e localização de software.

Um arquivo JSON é válido quando contém apenas caracteres ASCII, com outros caracteres (que apareceriam apenas em cadeias JSON) codificados com \u05d0 (em vez de א) na cadeia.

Talvez você possa encontrar um editor suficientemente bom e personalizá-lo para suas necessidades. Tenho certeza que você pode encontrar alguns Emacs submodo do (ou personalizar um) para cobrir o problema específico de ter strings literais hebraicas em Python (mas ainda ter identificadores e comentários em inglês).

BTW, não sei como é o teclado hebraico, mas na maioria dos layouts de teclado, você pode configurá-los para que digitar letras ASCII (ou seja, latinas) seja mais rápido do que digitar letras não ASCII. Portanto, mesmo para você, seria melhor digitar o código com aparência em inglês.

Em relação aos dados JSON, você poderá configurar seu editor para ver אquando uma string contém \u05d0(caso contrário, use um conversor JSON à jq )

Portanto, acredito que seu problema real deve ser escolher e configurar um bom editor (o hebraico é apenas dentro de cadeias literais; no caso raro em que uma cadeia literal precise conter hebraico e inglês, divida-a em várias partes). Eu acho que o Emacs e o Vim podem ser configurados para atender às suas necessidades.


É muito ruim ter que criar uma estrutura de localização para um programa monolíngue, e você ainda tem o problema de os arquivos de dados serem ilegíveis por humanos. Você apenas aceita que os formatos de dados destinados à legibilidade humana percam essa propriedade em face do texto bidirecional?
User2357112 suporta Monica

Eu diria que sim, mas nunca codifiquei um programa monolíngue para coisas que não são ASCII. Eu não sou um falante nativo de inglês (mas um francês), mas meu código é sempre parecido com inglês. Eu tenho que me forçar a codificar com identificadores franceses, e quase nunca faço isso (o único caso especial é quando estou escrevendo o código apenas para uma pessoa em particular que não entende bem o inglês; isso acontece raramente: os desenvolvedores de software precisam ser capaz de ler a documentação em inglês)
Basile Starynkevitch 9/16
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.