0 votes
158 vues

Le traitement du 02BC dans PT9.5 semble avoir changé. J'utilise le 02BC comme apostrophe pour l'élision. Il est défini comme un caractère intramot dans Paramètres de langue (Language - Settings).

Cependant, lors de l'exécution des vérifications, Paratext le traite comme un diacritique :

Quel est votre conseil ? Qu'est-ce que je rate ?
Merci d'avance pour votre aide.

Traduit automatiquement depuis English
Paratext par (347 points) | 158 vues
Pouvez-vous vérifier que le 02BC n'apparaît pas non plus dans les paramètres des caractères alphabétiques ?
Traduit automatiquement depuis English

Merci d'avoir répondu, Phil. Je peux confirmer que le 02BC n'apparaît pas dans les paramètres alphabétiques, mais uniquement dans l'onglet « autres caractères » :


Traduit automatiquement depuis English

D'après mon expérience avec Paratext, nous avons toujours utilisé le 02bc comme un arrêt glottal autonome, et cela a été recommandé par les techniciens de SIL pendant des années. Voici un extrait de l'aide de PT qui a été publié sur ce forum en 2022 L'arrêt glottal comme apostrophe ?.

Je n'ai pas encore remarqué ce nouveau comportement dans PT 9.5, mais d'après mon expérience, il s'agit d'un nouveau comportement pour les logiciels de SIL en général à ce jour. PT jusqu'à la v 9.4, FieldWorks, Bloom, etc., LibreOffice (je ne peux pas parler pour Word) et PTX Print (je pense) ont traité le 02bc comme un caractère séparé, ce qui est le statut linguistique de l'arrêt glottal dans les langues avec lesquelles j'ai travaillé, et non comme un diacritique attaché à un autre glyphe. J'ai supposé que l'ajout de celui-ci à l'inventaire alphabétique d'une langue le marque comme un caractère autonome, même si sa classification Unicode est « lettre modifiée ».

Cela m'inquiète un peu, car de nombreuses langues ont utilisé le 02bc dans des bibliothèques étendues. Cela changera-t-il la façon dont nous utilisons ce caractère dans la vérification orthographique, les Termes bibliques et d'autres outils ? S'attache-t-il au glyphe précédent ou suivant (dans notre cas, à aucun des deux, et supposer l'un ou l'autre causerait de la confusion pour les lecteurs et les éditeurs).

Y a-t-il un moyen de forcer PT et d'autres programmes à venir à le classifier d'une manière ou d'une autre, en fonction de la spécification du système d'écriture ?

Traduit automatiquement depuis English

Le message ci-dessus est en fait une réponse à ce commentaire. Désolé, je l'ai publié au mauvais endroit !

Selon Unicode, le 02bc est considéré comme un diacritique, donc je pense que le comportement actuel est correct. Je suppose que le comportement précédent était un bug. Je ne suis pas sûr de ce que nous pouvons faire à ce sujet, mais donner des commentaires est certainement la meilleure voie à suivre.

Traduit automatiquement depuis English
À ma connaissance, l'impact du changement effectué réside dans la façon dont le caractère est affiché dans l'inventaire des caractères. Cela ne devrait pas affecter la façon dont les mots sont affichés dans la liste des mots, les Termes bibliques ou d'autres outils.

Si vous constatez d'autres impacts des vérifications actuelles - veuillez le signaler.
Traduit automatiquement depuis English
Juste pour ajouter un peu de contexte et une question supplémentaire ci-dessous : Avec l'arrivée de vérifications plus approfondies à partir de Paratext 6, cela a signifié que l'utilisation de u2019 à la fois pour l'élision (apostrophe) et les guillemets de citation fermants provoquait des erreurs dans Paratext. Sur papier et à l'écran, nous n'avions aucun problème, bien sûr ;-) . Pour se débarrasser des messages d'erreur dans Paratext, le conseil était de commencer à utiliser u02BC pour ceux qui en avaient besoin pour marquer l'élision. L'utilisation de u02BC pour les arrêts glottaux, je pense, est considérée comme son utilisation « normale », bien que, selon l'explication Unicode, uA78C soit la lettre alphabétique normale réelle pour un arrêt glottal.
Nous pourrions simplement approuver toutes les combinaisons de [C]+02BC comme valides dans l'inventaire des caractères dans Paratext et ne pas nous en soucier. Mais je me demande si, dans Flex, un mot avec un 02BC intramot serait-il « détecté » comme un nouveau lexème ? Dans une langue autorisant ce type de lexèmes (dans Flex), il devrait bien sûr le détecter (via Control-D).

Donc, aurions-nous besoin d'une nouvelle fonctionnalité dans Paratext pour que Paratext puisse distinguer entre les langues utilisant 02BC comme diacritique (à juste titre, c'est-à-dire modificateur) et les langues utilisant 02BC comme lettre normale, soit glottale, soit « remplaçant » une lettre qui n'est pas prononcée, c'est-à-dire l'élision ? (Une case à cocher avec : veuillez indiquer comment vous utilisez 02BC ?)
Traduit automatiquement depuis English

1 Réponse

+1 vote
Le 02BC est défini comme une lettre modifiée dans Unicode. Je pense que ce qui se passe est que, même si vous le placez en position intramot, il est toujours considéré comme une lettre et apparaît en combinaison avec d'autres lettres.
Veuillez utiliser Aide > Envoyer des commentaires (Help > Give Feedback) pour signaler ce problème aux développeurs.
Traduit automatiquement depuis English
par (9,9k points)

Les lettres modifiées dans Unicode sont toujours considérées comme des diacritiques par Paratext. C'est toujours été le cas. Ce qui me dérange, c'est que cela donne l'impression qu'il y a eu un changement de comportement entre la version 9.4 et la 9.5. indecision

Traduit automatiquement depuis English
Je pense que c'est un autre de ces endroits où Paratext 9.5 vérifie des choses qui n'étaient pas nécessairement vérifiées dans la version 9.4.
Traduit automatiquement depuis English

Foolrunning - Je viens de tester PT8 et je vois que le 02BC est isolé. Dans la version 9.5, il est combiné avec le caractère précédent.

Traduit automatiquement depuis English

J'ai creusé un peu plus, et vous avez absolument raison. Il y a eu un changement dans la version 9.5 que j'avais manqué. blush

Selon Unicode, le 02BC est considéré comme un diacritique, donc je pense que le comportement actuel est correct. Je suppose que le comportement précédent était un bug. Je ne suis pas sûr de ce que nous pouvons faire à ce sujet, mais donner des commentaires est certainement la meilleure voie à suivre.

Traduit automatiquement depuis English

En consultant l'aide dans Flex concernant le 02BC, nous lisons ce qui suit :

Le 02BC LETTRE MODIFIÉE APOSTROPHE est défini comme formant de mot dans la norme Unicode, donc son utilisation serait appropriée, .....

Si vous avez déjà un clavier spécial, l'ajout du 02BC ne serait probablement pas trop difficile. Sinon, utilisez 0027 APOSTROPHE. Celui-ci n'a pas l'apparence arrondie, mais il est disponible dans toutes les polices et ne nécessite rien de spécial pour l'entrer.

Au moment où nous avons fait le choix pour le 02BC, c'était précisément l'apparence arrondie qui a « fait pencher la balance » en faveur du 02BC par rapport au 0027. Nous voulions que les Écritures imprimées (ainsi que l'application) aient l'apostrophe de type manuscrit enroulée. Nous pourrions revenir au 0027 si Charis a un glyphe alternatif enroulé, mais cela nécessiterait également de modifier les fichiers Keyman partout. (Mon hypothèse est au moins pour toute l'Afrique de l'Ouest, où l'utilisation du 02BC pour l'élision est devenue une pratique courante).

En regardant le jeu de glyphes du 0027, il n'y a pas de glyphe alternatif pour le « laid » ' ... En regardant l'image ci-dessous de la documentation Charis 7.0, il semble y avoir eu un changement dans la façon dont l'apostrophe est maintenant implémentée (bien que je ne puisse pas trouver de mention de cela dans la documentation)

Si je compare Charis SIL 6.2 avec Charis 7.0, il ne semble pas y avoir de différence :

Nos lecteurs se sont habitués à l'apostrophe enroulée, par conséquent le 0027 n'est (toujours) pas une option. Je pense que pour le moment, les choix sont 1 : revenir à Paratext 9.4 pour le moment. 2 : valider toutes les combinaisons de [C]+02BC dans l'inventaire des caractères.
La question reste de savoir si le changement de la 9.4 à la 9.5 affecte la fonction de passerelle vers Flex pour les mots avec un 02BC médial.

Traduit automatiquement depuis English

Questions connexes

0 votes
1 réponse 51 vues
Dans notre projet, les points-virgules sont autorisés comme séparateurs entre les renvois, mais pas dans aucun type de ... les points-virgules indésirables à l'aide de Rechercher ?
Ruth Mathys 153 posée sept. 22, 2025
0 votes
1 réponse 39 vues
Je suis bénévole (expérience limitée avec PT) et j'aide une équipe de traduction à préparer les Évangiles et les Actes ... ce message d'erreur. Merci d'avance pour votre aide.
mark2024 124 posée août 15, 2025
0 votes
1 réponse 248 vues
Working on a Glossary and running basic checks. A lot of helpful errors coming up. But where we refer in the text to ... . Or I am overlooking something. Thank you for your input.
Tim 934 posée juin 18, 2019
0 votes
1 réponse 64 vues
I added Hebrew letter transliteration names in acrostic Psalms inside the \qac USFM. Below is a sample of the end of Psalm 9:2-9:3 ... \b \q1 \v 3 \qac (bet) \qac* Ngabafocne...
anon635921 121 posée il y a 3 jours
0 votes
1 réponse 211 vues
Bonjour, J'ai un problème avec les guillemets dans mon projet Paratext. Chaque fois que je veux saisir des ... cela se produit et comment le corriger ? Merci, Christopher
christopher_meyer 106 posée août 31, 2023
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
If anyone destroys God’s temple, God will destroy that person; for God’s temple is sacred, and you together are that temple.
1 Corinthians 3:17
3,052 questions
6,011 réponses
5,677 commentaires
2,031 utilisateurs