+4 votes
589 vues

Il semble que Paratext 8 ait un problème lors de la migration des gloses interlinéaires si vous utilisez l'Interlinearizer en version 7 pour gloser le texte en utilisant le grec du NT comme texte modèle. Un utilisateur a demandé de l'aide dans cette situation, et j'ai constaté qu'après la migration, le code de langue dans lexicon.xml et dans les fichiers de gloses par livre était « el », alors que le code pour le grec du NT devrait être « grc ». (Dans un projet de test, j'ai glosé quelques mots en grec, puis migré, et dans ce projet migré, le code pour le grec du NT est devenu « lbj », le code d'une langue d'Inde. J'ai signalé ce problème aux développeurs).

Le code de langue est utilisé en trois endroits dans les données de l'interlinéaire.

  1. Dans le fichier lexicon.xml, dans le champ « Gloss Language ». Ce champ apparaît pour chaque mot qui reçoit une glose dans cette langue.
  2. Dans le nom du sous-dossier et le nom du fichier du fichier interlinéaire par livre. Par exemple, « interlinearizer_el_MAT.xml » est le fichier pour les gloses dans la langue « el » pour Matthieu.
  3. Dans chaque fichier par livre, dans le champ glossLanguage de la deuxième ligne du fichier.

Comment ai-je su que « grc » était le bon code pour le grec du NT ? J'ai glosé un mot dans Paratext 8 avec le grec comme modèle, enregistré la modification puis j'ai examiné les fichiers.

Ainsi, pour convertir manuellement ces données, j'ai fait ce qui suit :
0) Fermer Paratext s'il est ouvert

  1. Une recherche/remplacement dans lexicon.xml, et remplacer « el » par « grc », par exemple :

    <Gloss Language="el">δέ</Gloss> 
    

    devient

    <Gloss Language="grc">δέ</Gloss>
    

Pour limiter la modification aux codes uniquement et non à des chaînes « el » à l'intérieur d'un mot plus long, incluez les guillemets (guillemets doubles droits) dans la chaîne de recherche et dans la chaîne de remplacement.

2a) Changer le nom du dossier « Interlinear_el » à l'intérieur du dossier du projet en « Interlinear_grc ». (Si vous avez créé un fichier de test dans le code souhaité, vous devriez d'abord supprimer le dossier et son fichier).

2b) Changer les noms de fichiers à l'intérieur de ce dossier de "Interlinear_el_[Bookcode].xml à "Interlinear_grc_[Bookcode].xml

  1. Changer le code Glosslanguage dans la deuxième ligne de chaque fichier par livre en le code souhaité. Par exemple

     <InterlinearData ScrTextName="MP8" GlossLanguage="el" BookId="MAT">
    
     becomes
    
     <InterlinearData ScrTextName="MP8" GlossLanguage="grc" BookId="MAT">
    
  2. Démarrer Paratext et vérifier si cela a fonctionné.

Lors de l'édition des fichiers XML, assurez-vous de ne pas modifier les codes < ou > ou </ ou />, ceux-ci sont comme des barres obliques inverses dans USFM. Si vous faites une erreur, Paratext peut rejeter votre lexicon.xml modifié et changer son nom en lexicon.xmlcorrupt, et commencer à en créer un nouveau. Si vous enregistrez une copie de votre fichier lexicon.xml dans un autre emplacement avant l'édition, vous pourriez la restaurer si vous rencontrez ce problème et ne pouvez pas identifier ce qui s'est mal passé dans votre fichier modifié.

Traduit automatiquement depuis English
Paratext par [Expert]
(3,3k points)

réaffiché | 589 vues

4 Réponses

0 votes
Meilleure réponse

Un autre exemple : en utilisant la NIV84 comme texte modèle.
Après la migration, le projet a « en » comme code de langue. Mais le code de langue réel pour la NIV84 dans Paratext 8 est « en-US ». Il faut donc effectuer les étapes pour changer « en » en « en-US » dans le lexique, dans les noms des fichiers des fichiers par livre, et à l'intérieur des fichiers par livre.

Traduit automatiquement depuis English
par [Expert]
(3,3k points)

Y a-t-il une bonne raison de différencier les versions américaines et anglicisées d'une traduction en utilisant les codes de langue en-US et en-UK ? Sinon, serait-il une bonne idée de supprimer la distinction de code de langue entre les textes usNIV11 et ukNIV11, ainsi que usNIV84 ? (Nous n'avons pas de projet ukNIV84.)

Traduit automatiquement depuis English

Je doute qu'il soit important de distinguer l'anglais américain et l'anglais britannique. Vous auriez « favor » vs « favour », « honor » vs « honour », mais je pense que ces mots ne sont pas assez nombreux pour justifier de distinguer les variétés.

Traduit automatiquement depuis English

Je soupçonne qu'il y a peut-être plutôt plus de différences que quelques orthographes. Je ne connais pas très bien les variantes de la NIV, mais il y a beaucoup de différences d'usage et d'idiome entre les versions TEV/GNB des États-Unis et du Royaume-Uni.

JR

Traduit automatiquement depuis English
0 votes

Il peut être plus simple d'utiliser un texte modèle différent qui a le même code de langue que celui utilisé dans PT 7, s'il existe une alternative acceptable. Merci pour les conseils sur l'édition des fichiers xml sewhite, j'avais essayé cela pour un utilisateur qui avait un changement d'orthographe, mais Paratext a rejeté mon nouveau fichier de la manière que vous avez décrite.

Traduit automatiquement depuis English
par [Expert]
(2,9k points)

Mise à jour – J'avais le même problème qu'anon044949 avec le projet de changement d'orthographe. Le problème venait d'une recherche/remplacement sur cinq voyelles de la langue pour les remplacer par des caractères différents. Il s'avère qu'il y avait quelques gloses faites dans la nouvelle orthographe dans le lexique, faites après la conversion. Lorsque j'ai converti toutes les anciennes entrées, il y avait quelques doublons. Deux instances du même mot, chacune avec un ID de sens ou un ID de glose différent. Paratext, en chargeant ce fichier en mémoire, a protesté et a marqué le fichier du lexique comme corrompu. Donc, en plus de modifier les codes < > et </ >, il y a une deuxième façon de « corrompre » un lexique : finir avec des mots en double. Mais c'était une situation différente du changement des codes de langue, cela nécessitait de modifier les mots et les morphèmes à l'intérieur du fichier du lexique pour correspondre à la nouvelle orthographe.

Traduit automatiquement depuis English
0 votes

Hier, je suis tombé dans une situation où dans PT7 la langue était « Spanish » pour la RV60 et dans PT8 la langue pour la RVR1960 est « spa ». J'ai suivi les instructions de Steven dans un post précédent pour effectuer les modifications appropriées, mais les gloses n'apparaissaient toujours pas comme approuvées (comme elles l'étaient dans PT7).

Tim S. m'a fait remarquer que dans PT8, certaines langues affichent le code à trois lettres (dans ce cas spa), mais utilisent en interne le code à deux lettres (dans ce cas es) pour correspondre aux données interlinéaires. Une fois que j'ai effectué les modifications appropriées et utilisé « es », les gloses sont apparues comme approuvées.

Ainsi, si vous essayez d'utiliser la langue du texte modèle et que cela ne fonctionne pas, vous pourriez essayer le code à deux lettres approprié.

Un tableau de ces codes peut être trouvé à : https://www.loc.gov/standards/iso639-2/php/code_list.php

Traduit automatiquement depuis English
par (9,9k points)
+1 vote

Ce processus était nécessaire pour relier notre projet BT avec l'Interlinearizer après la mise à niveau vers PT9.2 (nous avions initialement mis le code de langue identique à celui du projet principal plutôt que (en), et PT ne pouvait pas l'identifier.
La seule étape que j'ajouterais est que dans le menu BT sous « project settings » dans PT, vous pouvez changer le code de langue même après la création du projet (dans un projet standard, vous ne pouvez pas le faire). Nous avions plusieurs équipes avec des projets BT créés avec le même code de langue que leur projet principal. Changer le code en anglais (eng) nous a permis de sélectionner notre projet BT dans la configuration de l'Interlinearizer

(NOTE : nous avons également découvert que vous ne pouvez pas utiliser « Create Glosses for ZZZ with no model text » et choisir « output to » pour sélectionner un projet BT. Nous n'utilisons pas de texte modèle pour nos BT, donc cela semblait idéal. Mais cela ne vous permet que de choisir un projet Standard pour la sortie. Donc, l'option de créer une back translation en utilisant le projet BT COMME MODÈLE était l'option dont nous avions besoin. Tout fonctionne très bien maintenant !!

Traduit automatiquement depuis English
par (161 points)

Questions connexes

0 votes
4 réponses 988 vues
I have just upgraded a project that had an extensively populated interlinearizer (lexicon.xml and associated interlinear ... and black colors in the interlinearizer. Any thoughts?
Milt_Jones 184 posée déc. 21, 2018
0 votes
1 réponse 263 vues
When we migrated our project to PT8, many glosses that had been deleted in the interlinear data returned. This is a ... but they are now back in the list of possible glosses.
anon084052 157 posée août 12, 2017
0 votes
2 réponses 418 vues
Any thoughts on why the interlinearizer is suddently generating unsual guesses with mixed upper/lower case red letters? Here is ... gloss: 2018-01-08_15-55-53.jpg872 606 100 KB
anon242106 110 posée janv. 8, 2018
0 votes
2 réponses 448 vues
A user sent me this, and I'm at a loss as to how to address it: We have just migrated the SCK team into ... the interlinear data for them. Thanks for any insight you can offer!
anon150053 286 posée juil. 27, 2017
0 votes
3 réponses 387 vues
Quel est l'ordre des gloses suggérées dans l'outil interlinéaire ? Autrement dit, si vous cliquez sur une glose et ... ordonné par fréquence, bien que cela semble le plus logique.
mnjames 1,9k posée sept. 11, 2018
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
And over all these virtues put on love, which binds them all together in perfect unity.
Colossians 3:14
3,049 questions
6,007 réponses
5,673 commentaires
2,029 utilisateurs