Soulignement gris dans l’affichage de l’orthographe

Question

Bonjour, j’ai une question concernant le soulignement gris dans l’affichage de l’orthographe (Display Spelling).
D’après ce que j’ai vu dans les aides, le soulignement gris ne devrait apparaître que sur les mots inconnus de la liste de mots. Cependant, je regarde un projet pour un ami, et la plupart des mots marqués d’un soulignement gris sont déjà marqués comme corrects dans la liste de mots, mais il existe un mot similaire, lui aussi correct.
Dans cette langue, il semble y avoir beaucoup de mots très similaires, donc une grande partie du texte est soulignée en gris.
Ce projet a récemment eu des diacritiques mises à jour, il est donc possible que le gris ait quelque chose à voir avec cela, bien que la liste de mots indique que le mot souligné en gris a été marqué comme correct (en comparant le mot souligné en gris avec la liste de mots indiquant où le mot apparaît).
Est-ce un comportement attendu du soulignement gris, ou est-ce que je vois une anomalie ici ?
Merci

Traduit automatiquement depuis English Afficher l'original

Answer 1

J’ai vérifié que c’est bien causé par une normalisation incohérente. Le texte semble être décomposé (NFD) tandis que la liste de mots a le texte composé (NFC). Cela est causé par le fait que la normalisation du projet est spécifiée comme « Aucune ». La meilleure façon de corriger cela est de demander à l’administrateur d’utiliser Outils > Convertir le projet pour créer un nouveau projet avec la normalisation définie correctement.

Traduit automatiquement depuis English Afficher l'original

Answer 2

Les soulignements gris ne devraient pas s’afficher pour les mots connus comme correctement orthographiés. Pourriez-vous nous donner le nom du projet (ou m’envoyer un message privé si c’est sensible) afin que nous puissions examiner le problème ?

Étant donné que vous mentionnez des changements de diacritiques, mon meilleur pari est que le problème est causé par une normalisation incohérente du texte du projet.

Traduit automatiquement depuis English Afficher l'original

Comments

Je signale également le bug d’affichage des erreurs d’orthographe. Il a été signalé par l’équipe de traduction et je l’ai vérifié sur mon propre ordinateur. « Donner un retour » ne fonctionne pas, d’où mon recours à la liste.
Le projet est « yes ». Les mots sont marqués comme correctement orthographiés dans l’outil de liste de mots, mais ont des lignes grises en dessous dans le texte biblique.
Aucune erreur de normalisation n’est signalée.
PTX 9.2.102.5

Bénédiction,
Shegnada

Traduit automatiquement depuis English Afficher l'original

Answer 3

Le nom court du projet est CNT.
Merci
BEH

Traduit automatiquement depuis English Afficher l'original

Answer 4

Merci d’avoir vérifié cela pour moi. Cela me fait me demander quelque chose, cependant : à quel point serait-il compliqué d’intégrer la normalisation dans le processus de migration du projet ? Cela peut ne pas être réalisable, je ne sais pas ce qui est impliqué dans la normalisation d’un projet comme celui-ci, mais si c’est faisable, cela pourrait simplifier les choses à l’avenir.
Merci
BEH

Traduit automatiquement depuis English Afficher l'original

Comments

BEH:

à quel point serait-il compliqué d’intégrer la normalisation dans le processus de migration du projet ?

Ce n’est pas trop compliqué en termes de code, mais autoriser ou forcer la normalisation lors de la migration causerait d’autres problèmes, car tout le monde ne connaît pas les implications d’un choix entre composé ou décomposé et comment cela pourrait affecter leurs données. Ainsi, au moins actuellement, nous n’offrons pas cette option lors de la migration.

Cela dit, nous avons une tâche dans notre système (PTX-15798) pour permettre une conversion lors d’une migration, mais elle n’est pas remontée en haut de notre liste de priorités.

Traduit automatiquement depuis English Afficher l'original

---

Bien que la normalisation soit bénéfique pour de nombreux projets, elle n’est pas souhaitée par d’autres. Il est très problématique pour un projet de normaliser sans connaître l’impact que cela aura sur son projet, puis de devoir revenir en arrière quelques mois plus tard lorsque des problèmes sont découverts. La normalisation, par exemple, rendra les données dans Paratext incohérentes fondamentalement avec les données en dehors de Paratext. Si l’équipe travaille sur leur langue en dehors de Paratext, ils doivent en tenir compte. Cela peut également affecter la présentation de la langue en dehors de Paratext, en particulier si l’équipe utilise des polices personnalisées (même si elles sont Unicode).

Bénédiction,

Shegnada James

Coordinatrice de la technologie linguistique et de l’édition, SIL Nigeria

Spécialiste du traitement du texte – Script complexe, GPS, SIL Intl

Skype : Shegnada.james.

[Email Removed]

+1 972 974 8146

Traduit automatiquement depuis English Afficher l'original

---

Si vous l’autorisiez lors de la migration, je serais reconnaissant si cela n’était vu que par les supporters (comme avec une activation par la touche Maj). Bien que je fasse la plupart des migrations, mes équipes ont tendance à cliquer sur tout en disant oui et je ne veux PAS qu’elles normalisent.

Bénédiction,

Shegnada James

Coordinatrice de la technologie linguistique et de l’édition, SIL Nigeria

Spécialiste du traitement du texte – Script complexe, GPS, SIL Intl

Skype : Shegnada.james.

[Email Removed]

+1 972 974 8146

Traduit automatiquement depuis English Afficher l'original

Answer 5

Ça a l’air bien.
Le fait que ce soit un choix obligatoire lors de la création d’un nouveau projet ou de la conversion d’un projet existant m’a fait penser que cela pourrait être bénéfique. Cependant, cela semble créer autant de problèmes qu’il en résoudrait.

Traduit automatiquement depuis English Afficher l'original