Updating glosses in Interlinearizer

Question

We have a project with 4 translators entering glosses in the Interlinearizer as we adapt from a related language. Because the morphology is extremely complex and they are still learning to write the language, they have created many wrong/impossible glosses in the dictionary. These wrong glosses are propagated through Send/Receive like the correct ones, but it seems that when one translator (or I as consultant) delete the wrong glosses on one computer, those deletions are not propagated to the other users.

Is there any way to progagate those corrections/deletions? It is cumbersome to delete 20 wrong glosses one by one and if one person does it, each other translator also needs to delete the same wrong ones, since the updates are not shared. Is there something I do not understand or is this just unhelpful behaviour of the program? They use PT 7.5.

Iver+Larsen

Answer 1

Since none of the translators for the KPZ project have editing rights in Spykup I was not aware that it was important also to do send/receive of this project on a daily basis. I can instruct them to do that and see if it makes any difference. The other day we did do send/receive for both projects to see if the deleted glosses would then also be deleted for the other users. It did not happen. We shall try some more tomorrow.
Can you tell me the name and place of the file where glosses are stored? I assume it is impossible to edit that file, but if it is possible to look at it, it might help me to understand what is going on.
Thanks,
Iver+Larsen

Comments

Iver+Larsen:

The other day we did do send/receive for both projects to see if the deleted glosses would then also be deleted for the other users. It did not happen.

It will probably take several rounds of Send/Receives to make the data settle down to where deleting would “stick”. If possible, it might be good for everyone to do a S/R twice in a row (without making changes - everyone does a S/R, then everyone does a S/R again) to start out. This would allow everyone to have the same “starting data”.

Iver+Larsen:

Can you tell me the name and place of the file where glosses are stored?

Well, it’s slightly complicated, so you need to be careful if you edit the files outside Paratext. The word glosses are stored in Lexicon.xml inside the project directory under My Paratext Projects.

The structure of the file has two main sections:

• Analyses - contains the data for the morphological breakdown of the words.
• Entries - contains the data for the glosses of the lexemes.

However, the files in the Interlinear_* directories directly reference data inside the Lexicon.xml file via the Sense Ids so you need to make sure nothing is referencing the glosses in this file if you are deleting glosses (Senses).
I think this connection with the interlinear data is why the merge code for the lexicon leans towards keeping glosses instead of deleting them when there is a conflict - in case something in the interlinear data is referencing them.

---

Thanks. I had looked at the lexicon xml file, but I had not scrolled down to see that it also had gloss entries in addition to the analyses.
I have noticed that when we do a S/R of the KPZ project both the lexicon in the KPZ and in the Spykup folder get updated. But it looks like parts of the Spykup lexicon is only updated when the Spykup also undergoes a S/R. I have not been able to see exactly what happens, nor could I find any information in the Paratext Help file. It would be helpful to state clearly in the Help file that it is not enough to do a S/R of the target project, but also of the source project, even though Paratext will tell you that nothing is received from other users, but you might have sent something (which the program does not tell you about.). Normally we think of doing send/receive for active projects we work on, not for projects where none of the translators can change anything.
We did S/R for both projects for 3 computers today and it did seem to help somewhat. We were not able to do it for all computers since two people did not come to the office today. It was my last day today with the team, but I have now instructed all of them to also do a S/R of Spykup in addition to the S/R of KPZ which they have been doing every day, usually both morning and evening (If we have power and the internet is working).
I am tempted to edit the lexicon file and delete all the wrong glosses, especially since some words have more than 30 wrong ones, but I cannot easily check if these are referenced in the interlinear files for each book. So I had better refrain from doing that. Maybe it will sort itself out over time with the new procedure.
Thanks for your help.

---

anon291708:

… it might be good for everyone to do a S/R twice in a row (without making changes - everyone does a S/R, then everyone does a S/R again) to start out. This would allow everyone to have the same “starting data”.

To be precise the last person to do the first S/R doesn’t need to do it a second time. A classic pattern for this “full-sync” S/R would be:

A B C D A B C

(where A, B, C, D are the four users with anything other than Observer rights.)

(Note that not just translators can change data: non-translators cannot change books, but they can write Notes, approve spellings, choose morphological parsings, and edit entries in the Biblical Terms tool.)

But the order doesn’t have to be the same on the second round. It could be:

A B C D B A C

… the point being that once all four users have done an S/R, all their changes are then stored on the server. The second time around, everyone gets all those changes – but D doesn’t need to do that, because he/she got all of A, B & C’s changes at the same time as he/she uploads their own.

After that, all the Observers can do an S/R and get those changes. So, if E, F & G are Observers, you would do:

A B C D B A C ; E F G

@anon291708, correct me if I’m wrong on any of these points .

---

Iver+Larsen:

It would be helpful to state clearly in the Help file that it is not enough to do a S/R of the target project, but also of the source project, even though Paratext will tell you that nothing is received from other users, but you might have sent something (which the program does not tell you about.).

Which version of PT are you using? 7.6β now shows you some of this: in the summary that’s presented when an S/R completes, it shows you whether a user has approved spellings, changed the stylesheet, and a string of other things.

(BTW, there seems to be a bug in this, that, for example, it says a user has changed the stylesheet when in fact they haven’t.)

---

We use Paratext 7.5. I am no longer together with the team, but I believe the situation has improved after all were instructed to include the source language project in their S/R which they have been doing and still do morning and evening for the target language. The problem was that I was unaware that certain changes behind the scenes are only sent when we do a S/R of the source project, a project that they make no changes to and a project which tells us every time that nothing is received from other users. This is the confusing part.

---

wdavidhj:

@anon291708, correct me if I’m wrong on any of these points .

Yes, that is all correct. I just find it easier to tell people to do two rounds of S/R.

---

Iver+Larsen:

a project which tells us every time that nothing is received from other users.

Yes, this is what @wdavidhj was talking about. In 7.5 and before, Paratext only displayed information about the Scripture text that was changed by users in the S/R summary. In 7.6 it was changed to display changes to any file that Paratext knows about.

---

Yes, it is only necessary to S/R (N+(N-1)) times where N is the number of computers on the team, but I do tell users to just do it twice keeping the same order. It is just more foolproof to teach this method, since people may forget the order they did the first send and receive.

Answer 2

I’m guessing this is a bug. What is the name of the project (if you don’t mind sharing)?

Answer 3

From Spykup to Kpz.
Thanks, Iver+Larsen

Comments

Well, I looked at the history for the SPYkup project (the one containing the interlinear data). I think the problems you are seeing are actually caused by infrequent use of Send/Receive (in one case I looked at, you merged data with someone for the first time in 7 months). This problem is made worse since all of the word glosses for the entire project are stored in one file (so many people are making changes to this one file). This results in a bunch of merge conflicts, which, I’m fairly certain, are causing what you are seeing.

Since I’m not familiar with your situation, it might be difficult to do frequent Send/Receives, but ideally everyone on the project should be doing a S/R every day (this is especially important when multiple people change the same file - as in this case).

EDIT: It looks like the KPZ project is being S/R every day as recommended. If you are also doing a S/R of SPYkup every day as well, maybe there is a problem in Paratext as it’s not making as many history points as I would expect if you were doing a S/R every day.

---

When I did Paratext field support, I told my teams that they should do a send/receive twice a day: as soon as they opened Paratext in the morning and last thing before they closed Paratext at night. This way everyone's data was completely current when they started the day.

PADev.

---

Just one more question. When you say you checked the history, where did you look? The project history that I and the translators have access to in Paratext, do not show any send/recieve activitity for users who cannot change the text, even when they do a S/R. Nor would it show any conflicts, since there cannot be conflicts if they make no changes to the text. In the past at one time the translators had editing writes. I have forgotten, but they may at one time have had the role of translators. But what happened is that they then often would write in the wrong project by mistake and change the source when they should be working in the target project. So I think I changed their roles to consultant/reviewer/etc. I suppose I could make them translators without editing writes to any books, but I am not sure of the implications.

---

We use a tool called TortoiseHg which lets us view all of the history for the project in detail.

I also use Perforce’s P4Merge tool in conjunction with TortoiseHg to visually see what changed better. Although it doesn’t have the same smarts that Paratext has for merging, it does give me an idea of what might have happened during the merging of the file. Also note that in this particular case, the tool had a hard time displaying the file because there were so many differences (over 48000).

---

Iver+Larsen:

In the past at one time the translators had editing writes. … I suppose I could make them translators without editing writes to any books,

Just in case any readers are confused, these are typos, and should say “rights”.