0 votos
343 vistas

He estado luchando contra este problema y acabo de encontrar una solución, así que la comparto aquí por si alguien más se encuentra intentando evitar que cierto texto sea transliterado automáticamente. Esta solución es tanto contraintuitiva como poco ortodoxa.

En resumen:

Si tiene texto no vernáculo que no debe ser transliterado automáticamente por un convertidor de codificación, sino publicado en su codificación original, envuélvalo en un estilo de carácter personalizado y otorgue a ese estilo personalizado la propiedad nonpublishable (no publicable).

Sí, la propiedad nonpublishable en lugar de nonvernacular (no vernáculo), que habría parecido lo adecuado. La propiedad nonvernacular no afecta realmente lo que se translitera, y la propiedad nonpublishable no afecta actualmente lo que se publica, al menos no a través de Publishing Assistant.

Antecedentes detallados:

Estoy a punto de componer un proyecto transliterado automáticamente. El proyecto contiene ciertas palabras en el idioma nacional. Estas se pueden encontrar en entradas del glosario, en material introductorio y en notas al pie, y están etiquetadas dentro de los marcadores \znp …\znp*, que definí en custom.sty como un estilo de carácter nonvernacular, publishable (publicable), porque eso era lo que era.

En el proyecto primario/fuente, el texto vernáculo y el texto en el idioma nacional están en el mismo sistema de escritura. En el proyecto transliterado automáticamente, el texto vernáculo debe convertirse en un guion tradicional utilizado solo para este idioma, pero el texto en el idioma nacional debe pasar tal como estaba en su guion original. (El guion tradicional no puede representar los sonidos retroflexos encontrados en el idioma nacional, y de todos modos sería extraño ver el idioma nacional en el guion tradicional del idioma vernáculo.)

Pero marcar dicho texto como nonvernacular no tuvo efecto para evitar que fuera transliterado.

Tampoco se pudo indicar al mapa TECkit que ignorara el texto encerrado en los marcadores \znp …\znp*, porque los propios marcadores no se pasan al mapa para su procesamiento. (Presumiblemente solía ser así, porque la documentación de ayuda de Paratext aún dice: “Asegúrese de que el archivo TECkit.map que utilice preserve los marcadores USFM para que no sean convertidos.”)

La solución engorrosa fue cambiar la propiedad publishable a nonpublishable. Esto no impidió que Publishing Assistant lo publicara.

No sé si eso causará problemas con otras rutas de salida (SAB / Print Draft / PtxPrint / YouVersion vía DBL), ya sea actualmente o en el futuro, si silenciosamente descartan el texto no publicable, por lo que eso es definitivamente una preocupación con este trabajo.

Aparte de que nonpublishable exima al texto de la transliteración automática, no me queda claro qué otros efectos podrían tener cualquiera de estas propiedades. ¿Hay documentación en algún lugar que explique esto?

Traducción automática desde English
Paratext por (286 puntos)
mostrada de nuevo | 343 vistas

2 Respuestas

+1 voto
Mejor respuesta

PTXprint (o más bien, las macros TeX de ptx2pdf que utiliza) tratará cualquier cosa marcada como nonpublishable como un casi-comentario. El programa de python también puede aplicar sus propias modificaciones; no lo sé.

Los estilos de párrafo y carácter nonpublishable no producirán salida, de hecho, esta es una forma de suprimir números de versículo, etc.
Dije casi comentario, porque no trata nada como un comentario verdadero: todo se lee e interpreta, solo que al final del estilo de párrafo/carácter el material se descarta.
Por lo tanto, no puede poner USFM \invalid allí, y los hitos con rango que comienzan en texto nonpublishable y no terminan seguirán en vigor después.

Sin embargo, dado el orden de carga de hojas de estilo con PTXprint, puede establecer algo como nonpublishable en custom.sty y luego anular esa configuración en una hoja de estilo posterior.

Traducción automática desde English
por (294 puntos)

Ah, es bueno saberlo. ¡Gracias!

Traducción automática desde English
+1 voto

Esto es realmente contraintuitivo y no funcionaba así en el pasado. Por lo tanto, creo que debe ser un error. En proyectos anteriores he utilizado con bastante éxito \tl…\tl* (Palabra Transliterada) para bloquear la conversión, lo cual tiene las características de publishable nonvernacular. También usé estas características para estilos de párrafo personalizados en el material preliminar y final a través de la hoja de estilo frtback.sty. Y nonpublishable NO debería estar pasando a través de Publishing Assistant a InDesign.

Esperemos que podamos corregir este comportamiento, por lo que debería ser flexible con su marcado hasta entonces…

Bendiciones,

Traducción automática desde English
por (1,3k puntos)
mostrada de nuevo

Gracias, Shegnada. El marcado original era efectivamente \tl ...\tl*, lo que puede reflejar que en algún momento del pasado, eso funcionaba en este proyecto para prevenir la transliteración automática. (El NT se publicó hace varios años, y ahora estamos haciendo la Biblia completa.) En ese caso, este error es una regresión, algo que se rompió cuando se estaba abordando otra cosa. Lo he reportado como PTXS-31555. Una vez que se corrija, simplemente será cuestión de actualizar la definición de \znp que tengo en custom.sty y frtbak.sty para reemplazar nonpublishable con publishable.

Pero ahora me pregunto si la funcionalidad se cambió intencionalmente basándose en el razonamiento de alguien de que el texto \tl debería ser procesado por el convertidor. Este proyecto ha estado usando el marcador \tl en el AT para marcar palabras transliteradas de los idiomas fuente, como purim y mene, tekel, parsin. La intención del equipo de traducción es que estas palabras serán procesadas por el convertidor para estar en el mismo guion que el proyecto, pero en cursiva en el guion que sea. Así que supongo que cuando se corrija este error, también necesitaremos recordar redefinir \tl como vernáculo en este proyecto, para asegurar que sea procesado por el convertidor. ¿Suena como la forma de hacerlo?

Aún me encantaría encontrar documentación sobre exactamente qué efectos se pretende que tengan las propiedades publishable/nonpublishable y vernacular/nonvernacular. Hasta ahora solo sé que nonpublishable debería resultar en que el texto evite la conversión de codificación y también evite ser visible en las publicaciones. Creo que nonvernacular está destinado a evitar la conversión de codificación (aunque eso está roto), y no soy consciente de ningún otro efecto pretendido. Me pregunto si alguna de ellas tiene alguna incidencia en la lista de palabras de ortografía, inventario de caracteres, etc.

Traducción automática desde English

Creo que siempre que use una hoja de estilo personalizada, por ejemplo, custom.sty en su caso, y documente con hashtags lo que está haciendo y por qué, Y agregue una nota de Paratext en la primera ubicación de \tl el comportamiento que está buscando, debería estar bien en su ruta PubAssist/InDesign.

Pero las respuestas que recibió a su publicación original indicarían que si tiene otras salidas en mente, debería probarlas también y quizás un marcador personalizado le serviría mejor. No lo sé realmente.

Debe tener en cuenta que tiene dos, o quizás, como yo normalmente tengo, tres, proyectos involucrados. El proyecto original, el proyecto convertido automáticamente (no editable), y (recomiendo) un tercer proyecto utilizado para la publicación que obtiene su texto importándolo del proyecto convertido. Cada uno de estos proyectos puede tener hojas de estilo personalizadas diferentes y, si bien es importante que el primer proyecto tenga las características de estilo que harán que el convertidor funcione correctamente, las hojas de estilo del proyecto desde el cual publica pueden ser diferentes de estas y son las únicas que impactan la salida publicada. Por lo tanto, tiene cierta flexibilidad, especialmente si usa ese tercer proyecto. Puedo hablar con usted más fuera de la lista si le gusta sobre las otras ventajas de las otras ventajas de un tercer proyecto, pero consideraría los proyectos segundo y tercero como meramente de salida y la documentación, etc., siempre debería encontrarse en el proyecto original.

Bendiciones,

Traducción automática desde English

Preguntas relacionadas

+1 voto
2 respuestas 302 vistas
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 preguntada feb 1, 2019
0 votos
0 respuestas 169 vistas
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
preguntada feb 23, 2017
+1 voto
3 respuestas 437 vistas
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 preguntada mar 11, 2019
0 votos
1 respuesta 62 vistas
Por fin logré que los bordes de las cabeceras de sección y el borde de la página se mostraran correctamente con ... las Escrituras, pero no en la página de título inicial
Mark Skinner 104 preguntada feb 19, 2025
0 votos
1 respuesta 189 vistas
Me encuentro constantemente con el siguiente mensaje de error que me impide exportar a PDF: Marker cannot occur here: ... , pero sin éxito. Alguien sabe cómo corregir esto?
anon233143 252 preguntada jun 25, 2021
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
I urge you, brothers and sisters, to watch out for those who cause divisions and put obstacles in your way that are contrary to the teaching you have learned. Keep away from them.
Romans 16:17
3,047 preguntas
6,007 respuestas
5,672 comentarios
2,027 usuarios