How to set up interlinearizer in 9.2

Question

A project I work with is doing a Greek-Vernacular interlinearization. For security reasons I’ll refer to the Greek text as GRK and the vernacular as ZZZ.

GRK is our own text (keyboarded based on an ancient manuscript, not an eclectic edition).
ZZZ has an Auxiliary project, ZZZ_Interlinear, which the interlinearizer exported to.

In PT 9.1, we set it up this way:
Text to interlinearize: GRK
Model text: ZZZ
Advanced, export to: ZZZ_Interlinear

But I’m struggling with how to set it up in PT 9.2. Going into GRK and opening the interlinearizer tool, I can set “Glosses for GRK; Model Text ZZZ”. But there is no option for where to export to. Similarly, there isn’t an option for exporting once I have the interlinearizer open.

Did this feature disappear with the new PT version?

Answer 1

In 9.2.102.3 you can choose the type of project you want the output to go to.

Screenshot 2022-01-06 09.13.32694×350 75.3 KB

Comments

I shouldn’t have said you can choose the type of project since there is no option for type. However, you can send the output to different types of projects. I did notice that when I choose the Output project it only shows me projects that use the same language as the model (in this case English).

---

Thank you @anon848905. After downloading 9.2.102.3, I can see that I’m able to use the Create Glosses option to adapt from our front translation and output to our target language translation.

Since our mother-tongue scriptures don’t share a language with any models, we can just use the “No Model Text” version, and that seems to give us the same sort of results that we’re used to, in which Paratext makes its guesses based on what has been interlinearized previously.

---

Thank you! The same-language requirement seems a little restrictive, but doesn’t affect the situation I had asked about. So this solves the problem our team had.

Answer 2

I have a similar problem with a just downloaded 9.2. It appears that I can only export to a daughter project, but we have using the Interlinearizer for a long time exporting to a standard project. We go from SPYkup to Kpz. I have a screenshot to indicate my problem. What I can do to get this working?

PT92Interlin1409×1014 328 KB

Comments

When we designed the new setup dialog, we were trying to make it easier for the expected use cases for the interlinear - many users were having difficulty in getting things set up correctly for what they intended to do.

From your messages, it looks like we missed a couple of cases where more flexibility is needed.

I’ll create an issue for this and have our UX team consider what needs to be done.

There isn’t a good way to work around the new setup, so probably the best option for now is to uninstall Paratext 9.2 and reinstall Paratext 9.1. The old settings for the interlinear setup were not removed, so the interlinear should work as it used to once you go back to 9.1.

Sorry for the inconvenience.

John+Wickberg
Paratext Support

Answer 3

Thank you. I have gone back to 9.1 for the time being. Actually, I do not use the Interlinearizer myself, but the teams I work with, use it a lot.

Comments

Along those line, if team members who are actively exporting to a text (the ZZZ_Interlinear in my example above) stick with 9.1, can the rest of the team upgrade to 9.2? It seems like those on 9.2 can still see the interlinearizer, and they can see the text in ZZZ_Interlinear after it’s exported, they just can’t do the exporting themselves. Correct?

---

Yes, the rest of the team can be on 9.2 and it should work just fine.

---

I guess I will have to do the same. A team that I am working with is still in 9.1 and I can not use the interlinearizer anymore (I use it often). Would have loved to check out 9.2 a bit more… Thanks anyway for all your efforts - development team!

---

Hello @anon856176, do you think the work around given by @Generic.User would work for you in 9.2?

See How to set up interlinearizer in 9.2 - #7 by Generic.User above.

james_post

---

The problem with @Generic.User’s workaround is that it only works if the back translation project is registered as a Back Translation (or maybe an Auxiliary or Daughter) project of the main project your interlinear is for. If the project is an Aux of the model language (as ours is), then it’s not a choice for exporting to. That’s fine if you understand how it works and are setting up a new system, but it fails for some existing setups.

But, as you say, it’s worth @anon856176 looking to see if it works for him.

Answer 4

We had the same issue but we found a work around (or maybe this is the way it is supposed to the be used)

@mnjames
I am going to use your examples

First off for us we had say we were doing a back translation before it would work. That was the only way to get the export option.

1. in the Choose box select Create a Back translation of GRK (or whatever the name of your project is)
   

2. Once you do that the Interlinearizer box will change and a space to chose the Model text will appear along with a space to choose the Back Translation.
   
   In the spot for Model: Choose the model text that you would like. ZZZ in this example.

3. Then go to the next blank which is the one for Back translation and choose the one you would like to you (you might only have one or many depending on your project). In this example choose ZZZ_Interlinear.
   

4. Press Ok

5. (Step five might not happen to you if it does do the following if not you are done)
   If an warning that you are replacing the settings pops us you will need to press the Replace button.
   
   Even if they are both the same just press replace.

Now your interlinear should work like it used to with an export button. Though it is now called output.

Comments

Thank you for this work around. There have been some of the projects that I am checking that I had to use PT 8 because of this problem. I still do not know what it means that the two languages cannot be the same. If I am exporting English glosses to an English project I would expect the languages to be the same.

---

The message about language data is important. Paratext 9.2 is warning you that you’re about to change how the glossing data for the base project for language “x” will be used:

:

A Paratext project can store glossing information for multiple languages. e.g.: Project XYZ might be back-translated into the languages fr, heb and en. Glossing data for each language is stored separately in the a XYZ project folder (called interlinear_fr, interlinear_heb, interlinear_en).

However, project XYZ can’t be glossed in fr and also back translated into project ABC in the language fr. If you wanted to do that, you could specify a custom fr dialect in order to create a new folder for glossing data. Something like “fr-x-custom”

I believe (someone please correct me if I am wrong) that Paratext has only ever been able to store one set of glossing data for any given language. It just never warned you in the past if you were about to repurpose your glossing data.

---

In rescuing people with interlinear data problems in Paratext 8, I saw multiple sets of interlinear data where there were different language codes for English because a resource changed language codes. Paratext did not delete the date for the old code, it just created a new set. So eng and en, for example. The tricky problem was rescuing them if they had just kept working and ignored the error because their data was split into two files.

Blessings,

Answer 5

I just want to chime in to say that many of our teams working in Tanzania will also be affected by the changes to the Interlinearizer in PT9.2.

Many of our languages adapt drafts from a common front translation, but they are not registered as daughters of that translation. Sometimes, for a chosen book, they prefer to adapt from another neighboring language. So we are accustomed to having the option to select the adaptation source, and then choose the output (their standard translation). That does not seem to be an option in 9.2. We would be grateful if that workflow could be supported.

Answer 6

I’m still very confused.

We have been using the Interlinearizer for adapting from a major language [H] translation. So we have our main project (let’s call it ZZZ), which is the target project. For our front translation (our source project), we have a dedicated project called ZZZaH_FT ([ZZZ] [a]daptation text from [H], [F]ront [T]ranslation).

It used to be that I’d set the top line as ZZZaH_FT and the bottom line as ZZZ, and the Interlinearizer would work as you’d expect, AND you had the ‘Export to Text’ option.

In 9.2, I have it set up like this:

The Interlinearizer is working fine in terms of pulling in all the glosses that were previously there, BUT the ‘Export to Text’ option is now gone. This means that we cannot do adaptation as we used to.

I tried to follow Generic.User’s fix, but it didn’t make any sense to me. I tried to create a back translation, using the front translation as a model text, but it wants me to create a new back translation project (that is, I can’t choose the ZZZ project):

Does anyone know what I’m doing wrong?

Comments

@Matt+A, My team uses the Interlinearizer very similarly for adaptation.

First of all, make sure you’re using the latest version of 9.2, there have been quite a few changes since the earliest version of 9.2.
Open the front translation menu > Interlinearizer. I recommend using the “Create Glosses Based on a Model Text” version. Then for the model, we use the target project itself [ZZZ]. Then you can tick the Output glosses button and select your target project as the output [ZZZ]. Again, if Paratext doesn’t allow that, it may be because you have an earlier version. I believe that’s what you’re looking for.

Answer 7

That was it @Stephen+Katt!

My confusion was in the terminology. I was confused in choosing the model text because, in my mind, “model text” means the same thing as “source text”: what I’m modeling this after/from, as opposed to what I’m modeling this into.

So that worked for creating an adaptable interlinear from the front translation to the main project. That was the biggest immediate issue. HOWEVER, when I tried to do the same thing from the main project to the back translation, it didn’t work. For some reason, it will only allow me to choose an output project with the same language code as (or perhaps somehow related to) the main project [ZZZ]. That seems weird to me because the language code for the front translation is not the same as the main project either (it’s an LWC).

The only other thing I can think of is that the front translation is registered as an Auxiliary project of [ZZZ], and the back translation as a Back Translation of [ZZZ]. I think that may be part of the issue, but I don’t know how to confirm that or work around it.

The latter issue isn’t as critical for us, but it would be a helpful tool.
(BTW, I am currently using version 9.2.102.6.)

Comments

@Matt+A Glad that worked for the adaptation.
The terminology can be a bit confusing at first. I believe the ‘Model’ terminology is meant to reflect the idea that Paratext is using a certain model for making its predictions in the Interlinearizer.

For back translation, you select can select the main translation [zzz] > Menu > Interlinearizer. Select ‘Create Back Translation’. For the model text, you can select any translation which is in the same language as your back translation (and which others who use the project are also likely to have on their machines). In my case, our back translations are generally in Swahili, so I could select any Swahili translation as the model. The key thing is that the model should have the same language code as the back translation, such as [eng] for English. Then you can set the Output to the back translation.

I’m not sure if it will be a problem that [ZZZ] is an auxiliary project. Try those steps out and let us know how it goes.

Answer 8

Thanks, @Stephen+Katt. That makes more sense. I mean, it doesn’t really make sense why it’s that way, but I’m now understanding more of how it works. It’s that weird step of choosing “any translation which is in the same language as your back translation (and which others who use the project are also likely to have on their machines)” that is causing the issues. That step was skipped before 9.2.

The problem is that whoever set up the back translation set up the language as ‘English (zzz)’, where ‘zzz’ is the language code for the main project, not ‘eng’. That’s why when I go to select a back translation project to output glosses, none were available - because the language code of the ‘Back Translation’ has to match that of the ‘Model’, and there is no model text with a language code ‘English (zzz)’ except for this silly back translation. I hope that made sense.

So the logical fix would be to change the language settings on the Back Translation project to ‘English (eng)’, which is easy enough. But then the problem comes that all the glossing information we’ve been putting in over the past 5+ years is lost because it has been linking ‘Language Z (zzz)’ and ‘English (zzz)’. Is possible to simply rename the associations in the Paratext files so that all the glosses from ‘Language Z (zzz)’ will now be associated with ‘English (eng)’ instead of ‘English (zzz)’ as it has been for some years?

Would I need to change the name of the folder ‘Interlinear_zzz’ in the [ZZZ] project folder to ‘Interlinear_eng’ (which would then match both GNT and what I’ve changed the back translation project to) and changing the value of GlossLanguage to "eng" in each book file?

(Just for clarification from before, the main project [ZZZ] isn’t the Auxiliary, it’s a Standard Translation. The front translation [ZZZa_H_FT] is the Auxiliary project of [ZZZ]. And the back translation is a Back Translation of [ZZZ].)

Comments

@Matt+A It looks like you’ve found your latest problem, with the setup of your back translation. That’s no fun.
I’m not sure whether it is possible to salvage that glossing data, but I believe your case may be of the type that could be saved. You can see this thread about a similar issue in which the glossing data language doesn’t match the project’s language: A manual restore of interlinear data after migration
In your case, it would involve changing the back translation language to [eng] and then updating the Interlinear_zzz files in the main project folder using the thread above. Maybe message me directly if you want a more detailed explanation.

---

I believe that the thread Stephen+Katt recommended will work for what you’re trying to do @Matt+A.

james_post

---

Yes, as the cited procedure shows, it is possible to edit the language name in the xml file that Paratext has been using to store the glosses.

---

This manual process was necessary to re link our BT project with the Interlinearizer after upgrading to PT9.2 (we had originally put the language code the same as the main project rather than (en), and PT couldn’t identify it.

The editing of the Lexicon and Interlinear files/folder was pretty easy. The only step I would add is that in the BT menu under “project settings” in PT you are able to switch the language code even after creating the project (in a standard project you cannot do this). We had multiple teams with BT projects that were created with the same language code as their main project. Changing the code to “English (eng)” allowed us to select our BT project in the Interlinearizer setup

(NOTE: we also figured out that you cannot use “Create Glosses for ZZZ with no model text” AND choose “output to” to select a BT project. We don’t use a model text for our BT’s so this seemed ideal. But it will only let you chose a Standard Project for output.

So the option to create a back translation using the BT project AS THE MODEL was the option we needed. It’s all working great now, Thanks!!

Screen Shot 2022-06-17 at 6.38.26 PM1144×666 122 KB