0 votes
345 vues

J'ai buté sur ce problème pendant un moment et je viens de trouver une solution, je la partage ici au cas où d'autres personnes chercheraient à empêcher certains textes d'être translittérés automatiquement. Cette solution est à la fois contre-intuitive et douteuse.

En résumé :

Si vous avez du texte non vernaculaire qui ne doit pas être translittéré automatiquement par un convertisseur d'encodage, mais plutôt publié dans son encodage d'origine, entourez-le d'un style de caractère personnalisé et donnez à ce style personnalisé la propriété nonpublishable.

Oui, la propriété nonpublishable plutôt que nonvernacular, ce qui aurait semblé plus approprié. La propriété nonvernacular n'affecte en réalité pas ce qui est translittéré, et la propriété nonpublishable n'affecte actuellement pas ce qui est publié, du moins pas par Publishing Assistant.

Contexte détaillé :

Je suis sur le point de mettre en page un projet translittéré automatiquement. Le projet contient certains mots dans la langue nationale. On les trouve dans les entrées du glossaire, dans les matières préliminaires et dans les notes de bas de page, et ils sont balisés avec les marqueurs \znp …\znp*, que j'avais définis dans custom.sty comme un style de caractère nonvernacular et publishable, car c'est ce que c'était.

Dans le projet principal/source, le texte vernaculaire et le texte en langue nationale sont tous deux dans le même système d'écriture. Dans le projet translittéré automatiquement, le texte vernaculaire doit être converti en un script traditionnel utilisé uniquement pour cette langue, mais le texte en langue nationale doit passer tel quel dans son script d'origine. (Le script traditionnel ne peut pas représenter les sons rétroflexes trouvés dans la langue nationale, et il serait bizarre de voir la langue nationale dans le script traditionnel de la langue vernaculaire de toute façon.)

Mais marquer un tel texte comme nonvernacular n'a eu aucun effet pour l'empêcher d'être translittéré.

De plus, on ne pouvait pas dire à la carte TECkit d'ignorer le texte enclos dans les marqueurs \znp …\znp*, car les marqueurs eux-mêmes ne sont pas transmis à la carte pour traitement. (Présumablement c'était le cas auparavant, car la documentation d'aide de Paratext dit toujours : « Assurez-vous que le fichier TECkit.map que vous utilisez préserve les marqueurs USFM afin qu'ils ne soient pas convertis. »)

La solution astucieuse consistait à changer la propriété publishable en nonpublishable. Cela n'a pas empêché Publishing Assistant de le publier.

Je ne sais pas si cela va créer des problèmes avec d'autres chemins de sortie (SAB / Print Draft / PtxPrint / YouVersion via DBL), que ce soit actuellement ou à l'avenir s'ils suppriment silencieusement le texte non publiable, c'est donc définitivement un point de préoccupation avec ce contournement.

À part le fait que nonpublishable exempte le texte de la translittération automatique, il ne me est pas clair quels autres effets ces deux propriétés pourraient avoir. Existe-t-il une documentation quelque part qui explique cela ?

Traduit automatiquement depuis English
Paratext par (286 points)
réaffiché | 345 vues

2 Réponses

+1 vote
Meilleure réponse

PTXprint (ou plutôt, les macros TeX ptx2pdf qu'il utilise) traitera tout ce qui est marqué nonpublishable comme un quasi-commentaire. Le programme python peut également appliquer ses propres modifications ; je ne sais pas.

Les styles de paragraphe et de caractère nonpublishables ne produiront pas de sortie, en effet c'est un moyen de supprimer les numéros de versets, etc.
J'ai dit quasi commentaire, car il ne traite rien comme un commentaire vrai : tout est encore lu et interprété, c'est juste qu'à la fin du paragraphe/du style de caractère, le matériel est jeté.
Ainsi, vous ne pouvez pas mettre de USFM \invalid dedans, et les jalons étendus (ranged milestones) qui commencent dans un texte nonpublishable et ne se terminent pas seront toujours en vigueur ensuite.

Cependant, étant donné la séquence de chargement des feuilles de style avec PTXprint, vous pouvez définir quelque chose comme nonpublishable dans custom.sty et ensuite remplacer ce réglage dans une feuille de style ultérieure.

Traduit automatiquement depuis English
par (294 points)

Ah, c'est bon à savoir. Merci !

Traduit automatiquement depuis English
+1 vote

C'est effectivement contre-intuitif et cela ne fonctionnait pas ainsi par le passé. Je pense donc que ce doit être un bug. Dans des projets passés, j'ai utilisé avec succès \tl…\tl* (Mot Translittéré) pour bloquer la conversion, ce qui a les caractéristiques de publishable nonvernacular. J'ai également utilisé ces caractéristiques pour des styles de paragraphe personnalisés dans les matières préliminaires et finales via la feuille de style frtback.sty. Et nonpublishable ne devrait PAS passer par Publishing Assistant vers InDesign.

J'espère que nous pourrons faire corriger ce comportement, donc vous devriez rester flexible avec votre balisage jusqu'à ce que ce soit fait…

Bénédiction,

Traduit automatiquement depuis English
par (1,3k points)
réaffiché

Merci, Shegnada. Le balisage d'origine était en effet \tl ...\tl*, ce qui peut refléter le fait qu'à un moment donné dans le passé, cela fonctionnait dans ce projet pour empêcher la translittération automatique. (Le NT a été publié il y a plusieurs années, et maintenant nous faisons la Bible complète.) Dans ce cas, ce bug est une régression, quelque chose qui s'est cassé quand autre chose était traité. Je l'ai signalé comme PTXS-31555. Une fois corrigé, il suffira de mettre à jour la définition de \znp que j'ai dans custom.sty et frtbak.sty pour remplacer nonpublishable par publishable.

Mais maintenant je me demande si la fonctionnalité a été intentionnellement modifiée sur la base du raisonnement de quelqu'un que le texte \tl devrait être passé au convertisseur. Ce projet utilise depuis le marqueur \tl dans l'AT pour marquer les mots translittérés des langues sources, tels que purim et mene, tekel, parsin. L'intention de l'équipe de traduction est que ces mots seront traités par le convertisseur pour être dans le même script que le projet, mais en italique dans quel que soit ce script. Donc je suppose que quand ce bug sera corrigé, nous devrons aussi nous souvenir de redéfinir \tl comme vernaculaire dans ce projet, pour s'assurer qu'il soit traité par le convertisseur. Cela vous semble-t-il la bonne façon de faire ?

J'aimerais vraiment trouver une documentation sur les effets exacts que les propriétés publishable/nonpublishable et vernacular/nonvernacular sont censées avoir. Jusqu'à présent, je ne sais que nonpublishable devrait entraîner le texte à éviter la conversion d'encodage et aussi à éviter d'être visible dans les publications. Je crois que nonvernacular est censé éviter la conversion d'encodage (bien que cela soit cassé), et je ne suis pas au courant d'autres effets intentionnels. Je me demande si l'une ou l'autre a une incidence sur la liste de mots d'orthographe, l'inventaire de caractères, etc. ?

Traduit automatiquement depuis English

Je pense que tant que vous utilisez une feuille de style personnalisée, par exemple custom.sty dans votre cas, et que vous documentez avec des hashtags ce que vous faites et pourquoi, ET que vous ajoutez une note Paratext au premier emplacement \tl le comportement que vous recherchez, vous devriez être en sécurité sur votre chemin PubAssist/InDesign.

Mais les réponses que vous avez reçues à votre message d'origine indiqueraient que si vous avez d'autres sorties en tête, vous devriez les tester aussi et peut-être qu'un marqueur personnalisé vous servirait mieux. Je ne sais vraiment pas.

Vous devriez prendre en compte que vous avez deux, ou peut-être comme je l'ai normalement, trois, projets impliqués. Le projet d'origine, le projet converti automatiquement (non modifiable), et (je recommande) un troisième projet utilisé pour la publication qui reçoit son texte en l'important du projet converti. Chacun de ces projets peut avoir des feuilles de style personnalisées différentes et bien qu'il soit important que le premier projet ait les caractéristiques de style qui feront fonctionner le convertisseur correctement, les feuilles de style du projet dont vous publiez peuvent être différentes de celles-ci et ce sont les seules qui impactent la sortie publiée. Ainsi, vous avez une certaine flexibilité, surtout si vous utilisez ce troisième projet. Je peux en discuter davantage avec vous hors liste si vous le souhaitez sur les autres avantages d'un troisième projet, mais je considérerais les deuxième et troisième projets comme étant purement de la sortie, et la documentation, etc., devrait toujours être trouvée dans le projet d'origine.

Bénédiction,

Traduit automatiquement depuis English

Questions connexes

+1 vote
2 réponses 302 vues
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 posée févr. 1, 2019
0 votes
0 réponses 169 vues
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
posée févr. 23, 2017
+1 vote
3 réponses 437 vues
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 posée mars 11, 2019
0 votes
1 réponse 62 vues
J'ai enfin réussi à afficher correctement les bordures des en-têtes de section et la bordure de page avec des ... texte biblique, mais pas sur la page de titre initiale.
Mark Skinner 104 posée févr. 19, 2025
0 votes
1 réponse 189 vues
Je continue de rencontrer le message d'erreur suivant, qui m'empêche d'exporter en PDF : Marker cannot occur here: ... , sans succès. Quelqu'un sait-il comment corriger cela ?
anon233143 252 posée juin 25, 2021
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
And I tell you that you are Peter, and on this rock I will build my church, and the gates of Hades will not overcome it.
Matthew 16:18
3,047 questions
6,007 réponses
5,672 commentaires
2,027 utilisateurs