O problema básico aqui é que estamos trabalhando em um mundo multilíngue (grego, hebraico, língua local, língua de comunicação mais ampla), mas o editor no Paratext não reconhece isso. Então “tudo” no projeto X está na língua X. E essa abordagem é apenas muito simplista.
O que é necessário é uma maneira de marcar grego, hebraico e LWC, com estilos SFM únicos (para cada um) e esses serem mantidos separadamente na lista “Válido/Inválido”. E NÃO serem misturados com o inventário de caracteres, ortografia ou lista de palavras da Língua X. (Mesmo a pontuação LWC válida pode ser inválida para a língua X.)
Onde trabalhamos, hoje podemos marcar alguma letra estranha como válida encontrada em uma palavra da LWC em uma nota de rodapé. Mas fazer isso abre a possibilidade de alguém introduzir um erro de digitação na língua X usando esse caractere “válido”, porque o marcamos como válido? Ou seja, é válido para a LWC, mas é INVÁLIDO se usado na Língua X.
Então, como diferenciamos isso? E por que não podemos simplesmente marcar essas como línguas diferentes? Isso parece a solução mais óbvia. Todo outro editor razoavelmente poderoso que eu conheço reconhece “língua”, certamente devemos neste negócio de tradução.
Concedo que isso não é necessário muito, mas é necessário com frequência suficiente que uma solução seria muito útil. (E concordo com anon848905 de que apenas “ignorar” eles é uma solução menos que ideal.) Eles são “válidos” em certos casos; precisamos que o Paratext seja inteligente o suficiente para reconhecer o contexto (os colchetes SFM) e validá-los com base em seu subconjunto particular.
The basic problem here is we are working in a multilingual world (Greek, Hebrew, local language, language of wider communication), but the editor in Paratext does not recognize that. So “everything” in project X is in the X language. And this approach is just too simplistic.
What is needed is a way to mark Greek, Hebrew, and LWC, with unique SFM styles (for each) and these be maintained separately in the “Valid/Invalid” list. And NOT be mixed in with the X Language’s character, spelling, or wordlist inventories. (Even valid LWC punctuation might be invalid for language X.)
Where we work, today we might mark some weird letter as valid found in a word from the LWC in a footnote. But does doing this open the possibility that someone may introduce a typo in X language using that “valid” character, because we marked it as valid? I.e. it is valid for the LWC, but it is INVALID if used in the X Language.
So how do we differentiate this? And why can’t we just mark these as different languages? That seems the most obvious solution. Every other reasonably powerful editor I know recognizes “language”, surely we should in this business of translation.
Granted, this isn’t needed a lot, but it is needed often enough that a solutions would be very helpful. (And I agree with anon848905 that just “ignoring” them is a less than ideal solution.) These are “valid” in certain cases; we need Paratext to be smart enough to recognize the context (the SFM brackets) and validate them based on their particular subset.
Tradução automática de English
