Interlinear showing all glosses as red after migration to P8

Question

I have just upgraded a project that had an extensively populated interlinearizer (lexicon.xml and associated interlinear “book” xmls). All the glosses are marked in red so I checked within the xml to make sure they are not corrupted. For a given passage on a common word, I checked the glossID in the interlinear xml and matched it to the specific glossID in the lexicon xml. The files are fully intact as far as I can tell, yet they do not produce the blue and black colors in the interlinearizer.

Any thoughts?

Answer 1

Milt_Jones - please check this topic:

A manual restore of interlinear data after migration Helps

It seems that Paratext 8 has a problem migrating interlinear glosses if you use the Interlinearizer in 7 to gloss text using the NT Greek as your model text. A user asked for help in this situation, and I saw that after migration, the language code in the lexicon.xml and in the per-book gloss files was “el” while the code for NT greek should be “grc”. (In a test project, I glossed a few words in Greek, then migrated, and in this migrated project, the code for NT Greek became “lbj”, the code for…

Comments

Ok. I just checked all the places where the language is listed in the xml. They all say “en”.
e.g. (tag markers removed)
InterlinearData ScrTextName=“SUR” GlossLanguage=“en” BookId=“EXO”

and…
item
Lexeme Type=“Word” Form=“nyem” Homograph=“1”
Entry
Sense Id=“oGQZ5bE6”
Gloss Language=“en” people /Gloss
/Sense
/Entry
/item

Also the file names include “en”
e.g. Interlinear_en_EXO.xml

---

When you run the interlinearizer, check what language code the Model Text for Interlinearization has. If it does not have “en”, that could be your problem. Run the interlinearizer with a model English text that does have “en” as its language. Quite a few resources have changed their language codes in Paratext 8, so it’s worth checking this.

---

So, it is interesting that it is actually NOT clear what language code is being used by model texts that are resources. The ones I’ve tried are locked so I can’t look at the xml. When I go to Project Properties for the resources, they are listed as “eng” or “eng-US”. I could not find any listed as “en”. So I tried a test by editing the interlinearizer folder and files, as well as the lexicon file so that the language everywhere is listed as “eng” (and again later as “eng-US”).

None of that made ANY difference to how the interlinearize fails to work in P8 even though it works fine in P7 with the same files.

I’m open for more suggestions.

Milt_Jones

---

I confess to not knowing the difference between “en” and “eng”. I think it safe to assume that they are the same. What you definitely don’t want to do, is to run the Interlinearizer, with NIV11 as your Model Text for Interlinearization. The reason for this is that NIV11 has the language code “eng-us”. This will definitely not work. You can see what a resource’s language code is in Paratext when you go to File, Open Project/Resource. The third column headed Language lists the language and its language code. So for similar reasons, don’t use NIV11UK or NIV84, which use “eng-GB” and “eng-US” respectively. I recommend you run the interlinearizer with any resource as the model text that has eng as its language code. If you want any further involvement from me, please contact me off list, my Skype name is anon758749.

---

anon758749:

What you definitely don’t want to do, is to run the Interlinearizer, with NIV11 as your Model Text for Interlinearization. The reason for this is that NIV11 has the language code “eng-us”. This will definitely not work.

Please see this post for how to make this work.

Milt_Jones:

When I go to Project Properties for the resources, they are listed as “eng” or “eng-US”.

Please see this post.

---

I manage the NIV resources and can change the all of them to use en rather than eng-us or eng-gb. Before I do that, however, I want to make sure I will not be causing more problems by changing the resource language codes back to en. Do you know of any reasons not to?

---

I did need to rescue the interlinear data for about 5 people. Changing the language code for NIV back to en may mean rescuing them again, but if it is a better long term solution, I can handle it. I don’t know what that means for everyone, though.

Blessings,

Shegnada James

Language Technology and Publishing Coordinator, SIL Nigeria

Text Processing Specialist – Complex Script, GPS, SIL Intl

Skype: Shegnada.james.

[Email Removed]

+1 972 974 8146

---

Hi CrazyRocky,

To be honest, I don’t know what the consequences are. Also I’m not sure that this will affect my issue as there is something (else?) I on my system.

Let me know if you proceed with the change.

Milt_Jones

Milt_Jones

Answer 2

CrazyRocky:

I manage the NIV resources and can change the all of them to use en rather than eng-us or eng-gb. Before I do that, however, I want to make sure I will not be causing more problems by changing the resource language codes back to en. Do you know of any reasons not to?

Unfortunately, it would cause anyone who has already changed to using en-US or en-GB to have to change back since it would trigger a resource update that everyone could get.
Since (hopefully) most projects have already migrated to 8.0 and have had to deal with this already, it’s probably not worth changing it at this point.
Also, as mentioned here, it’s probably a good idea to differentiate them.

Answer 3

At this point it sounds like changing the language code may create more problems than it fixes.

Comments

Hi folks,

thanks for your help. I’m not exactly sure when things started to behave appropriately but…
After SEVERAL restarts, I have gotten the “en-US” to work with the US NIV text. I am making a copy of the directory and will also create an “en” set so that any other user will have success no matter what text they choose for English.

A couple notes…

• The language code was correct BUT I restarted Paratext many times and Windows many times (over about 2 weeks) before it started displaying properly. Not sure how that is even possible unless there was a minor update that snuck through. (I’ve been at 8.0.100.72 the entire time.) Go figure.
• There is one (maybe more?) place where the gloss is definitely defined but Paratext is not displaying it properly as black. This is probably what made troubleshooting this such a slow process., There must be some tiny bug, but I don’t have the time to chase down whether this is a single instance among thousands of entries. Just in case I come back to this in the future, it occurs at Ex 1:1.
  [item]
  …[string]EXO 1:1[/string]
  … …[VerseData]
  … … …[Cluster]
  … … … …[Range Index=“7” Length=“3” /]
  … … … …[Lexeme Id=“Word:sum” /]
  … … …[[/Cluster]
  … … …[[Cluster
  … … … …[Range Index=“51” Length=“4” /]
  … … … …[Lexeme Id=“Stem:ijip” /]
  … … …[[/Cluster]
  … …[/VerseData]
  …[/item]

I don’t remember seeing the Cluster tag before. Can give me info on that?

Thanks for helping me get 99+% operational.

Milt_Jones

---

Ok, I’m finding a LOT of these. The lexicon is correct, the gloss id is correct, the language id is correct, but Paratext is not displaying correctly.

Answer 4

Ok. I have researched this more thoroughly. At first it appeared that the gloss= was getting chopped off, but I have checked against P7 and there is no data loss and no misrepresentation in the UI. Must have been something goofy on my system that got me worked up. But it’s working as intended.