0 votos
345 visualizações

Estou batendo a cabeça contra esse problema há um tempo e acabei de encontrar uma solução, então estou compartilhando aqui, caso alguém mais esteja tentando impedir que determinado texto seja transliterado automaticamente. Essa solução é tanto contra-intuitiva quanto questionável.

Em resumo:

Se você tiver texto não vernáculo que não deve ser transliterado automaticamente por um conversor de codificação, mas sim publicado em sua codificação original, envolva-o em um estilo de caractere personalizado e atribua a esse estilo personalizado a propriedade nonpublishable.

Sim, a propriedade nonpublishable em vez de nonvernacular, o que teria parecido mais adequado. A propriedade nonvernacular não afeta, na verdade, o que é transliterado, e a propriedade nonpublishable não afeta atualmente o que é publicado, pelo menos não pelo Publishing Assistant.

Contexto detalhado:

Estou prestes a diagramar um projeto transliterado automaticamente. O projeto contém certas palavras no idioma nacional. Essas podem ser encontradas em entradas do glossário, em material introdutório e em notas de rodapé, e estão marcadas dentro dos marcadores \znp …\znp*, que eu havia definido em custom.sty como um estilo de caractere nonvernacular, publishable, porque era isso que ele era.

No projeto primário/fonte, o texto vernáculo e o texto no idioma nacional estão ambos no mesmo sistema de escrita. No projeto transliterado automaticamente, o texto vernáculo deve ser convertido para um script tradicional usado apenas para este idioma, mas o texto no idioma nacional deve passar como estava em seu script original. (O script tradicional não pode representar os sons retroflexos encontrados no idioma nacional, e seria estranho ver o idioma nacional no script tradicional do idioma vernáculo de qualquer forma.)

Marcando tal texto como nonvernacular não teve efeito em impedi-lo de ser transliterado.

Tampouco o mapa TECkit pôde ser instruído a ignorar o texto encerrado nos marcadores \znp …\znp*, porque os próprios marcadores não são passados para o mapa para processamento. (Presumivelmente eles eram antes, porque a documentação de Ajuda do Paratext ainda diz: “Certifique-se de que o arquivo TECkit.map que você usa preserva os marcadores USFM para que eles não sejam convertidos.”)

A solução complicada foi mudar a propriedade publishable para nonpublishable. Isso não impediu o Publishing Assistant de publicá-lo.

Não sei se isso vai causar problemas com outros caminhos de saída (SAB / Print Draft / PtxPrint / YouVersion via DBL), se atualmente ou no futuro eles silenciosamente descartarão texto não publicável, então isso é definitivamente uma preocupação com este contorno.

Além de nonpublishable isentar o texto da transliteração automática, não está claro para mim quais outros efeitos quaisquer dessas propriedades podem ter. Existe alguma documentação em algum lugar que explique isso?

Tradução automática de English
Paratext por (286 pontos)
reexibida | 345 visualizações

2 Respostas

+1 voto
Melhor resposta

PTXprint (ou melhor, as macros TeX ptx2pdf que ele usa) tratará qualquer coisa marcada como nonpublishable como um quase-comentário. O programa python também pode aplicar suas próprias modificações; não sei.

Estilos de parágrafo e de caractere nonpublishable não produzirão saída, de fato, esta é uma maneira de suprimir números de versículo, etc.
Eu disse quase comentário, porque ele não trata nada como um comentário verdadeiro: tudo ainda é lido e interpretado, apenas no final do parágrafo/estilo de caractere o material é descartado.
Assim, você não pode colocar USFM \invalid lá dentro, e marcos com intervalo que começam em texto nonpublishable e não terminam ainda estarão em vigor depois.

No entanto, dado a sequência de carregamento de folhas de estilo com PTXprint, você pode definir algo como nonpublishable em custom.sty e depois sobrescrever essa configuração em uma folha de estilo posterior.

Tradução automática de English
por (294 pontos)

Ah, é bom saber. Obrigado!

Tradução automática de English
+1 voto

Isso é realmente contra-intuitivo e não funcionava assim no passado. Portanto, acredito que deve ser um bug. Em projetos passados, usei com bastante sucesso \tl…\tl* (Palavra Transliterada) para bloquear a conversão, o que tem as características de publishable nonvernacular. Também usei essas características para estilos de parágrafo personalizados no material frontal e traseiro via a folha de estilo frtback.sty. E nonpublishable NÃO deveria estar passando pelo Publishing Assistant para o InDesign.

Esperemos que possamos corrigir esse comportamento, então você deve ser flexível com sua marcação até lá…

Abençoadas,

Tradução automática de English
por (1,3k pontos)
reexibida

Obrigado, Shegnada. A marcação original era de fato \tl ...\tl*, o que pode refletir que em algum momento no passado, isso funcionava neste projeto para impedir a transliteração automática. (O NT foi publicado há vários anos, e agora estamos fazendo a Bíblia completa.) Nesse caso, este bug é uma regressão, algo que quebrou quando outra coisa estava sendo endereçada. Eu o reporte como PTXS-31555. Quando for corrigido, será simplesmente uma questão de atualizar a definição de \znp que tenho em custom.sty e frtbak.sty para substituir nonpublishable por publishable.

Mas agora me pergunto se a funcionalidade foi intencionalmente alterada com base em alguém raciocinando que o texto \tl deveria ser processado pelo conversor. Este projeto tem usado desde então o marcador \tl no AT para marcar palavras transliteradas dos idiomas de origem, como purim e mene, tekel, parsin. A intenção da equipe de tradução é que essas palavras serão processadas pelo conversor para estar no mesmo script do projeto, mas em itálico em qualquer script que seja. Então, acho que quando este bug for corrigido, também precisaremos lembrar de redefinir \tl como vernáculo neste projeto, para garantir que seja processado pelo conversor. Isso soa como a maneira de fazer?

Ainda adoraria encontrar documentação sobre exatamente quais efeitos as propriedades publishable/nonpublishable e vernacular/nonvernacular são destinadas a ter. Até agora, só sei que nonpublishable deve resultar no texto evitando a conversão de codificação e também evitando ser visível em publicações. Acredito que nonvernacular é destinado a evitar a conversão de codificação (embora isso esteja quebrado) e não estou ciente de qualquer outro efeito pretendido. Me pergunto se alguma delas tem influência na lista de palavras de ortografia, inventário de caracteres, etc?

Tradução automática de English

Acho que, desde que você use uma folha de estilo personalizada, por exemplo, custom.sty no seu caso, e documente com hashtags o que está fazendo e por quê E adicione uma nota do Paratext no primeiro local \tl o comportamento que você está procurando, você deve estar bem no seu caminho PubAssist/InDesign.

Mas as respostas que você recebeu para sua publicação original indicariam que, se você tiver outras saídas em mente, deve testá-las também e talvez um marcador personalizado lhe sirva melhor. Eu realmente não sei.

Você deve levar em consideração que você tem dois, ou talvez, como eu normalmente tenho, três projetos envolvidos. O projeto original, o projeto convertido automaticamente (não editável) e (eu recomendo) um terceiro projeto usado para publicação, que obtém seu texto importando do projeto convertido. Cada um desses projetos pode ter folhas de estilo personalizadas diferentes e, embora seja importante que o primeiro projeto tenha as características de estilo que farão o conversor funcionar corretamente, as folhas de estilo do projeto do qual você publica podem ser diferentes dessas e são as únicas que impactam a saída publicada. Assim, você tem alguma flexibilidade, especialmente se usar esse terceiro projeto. Posso conversar com você mais fora da lista, se quiser, sobre as outras vantagens de um terceiro projeto, mas eu consideraria os projetos segundo e terceiro como meramente de saída, e a documentação, etc., deve sempre ser encontrada no projeto original.

Abençoadas,

Tradução automática de English

Perguntas relacionadas

+1 voto
2 respostas 302 visualizações
A few days ago, I painfully found out that the tag nonpublishable inside a project usfm.sty is important and ... about PT8 and about using its features correctly and properly.
Tim 934 perguntada Fev 1, 2019
0 votos
0 respostas 169 visualizações
This topic only covers the addition of a TECkit map encoding converter. If the converter for the language ... Transliteration (using Encoding Converter) for an existing project.
[Expert]
anon421222
735
perguntada Fev 23, 2017
+1 voto
3 respostas 437 visualizações
Exporting the Wordlist to HTML is a nice feature, except that for many users including me, working with HTML is ... that are currently marked as spelled correctly in PT? anon101508
anon101508 117 perguntada Mar 11, 2019
0 votos
1 resposta 62 visualizações
Finalmente consegui exibir corretamente as bordas dos cabeçalhos de seção e a borda da página com diacríticos vermelhos no ... nas escrituras, mas não na página de título inicial
Mark Skinner 104 perguntada Fev 19, 2025
0 votos
1 resposta 189 visualizações
Continuo encontrando a seguinte mensagem de erro, que está me impedindo de exportar para PDF: Marker cannot occur here ... estilo, mas sem sucesso. Alguém sabe como corrigir isso?
anon233143 252 perguntada Jun 25, 2021
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
They all joined together constantly in prayer, along with the women and Mary the mother of Jesus, and with his brothers.
Acts 1:14
3,047 perguntas
6,007 respostas
5,672 comentários
2,027 usuários