Need to re-assign an interlinear setup [solved]

Question

There once was a project, I will call it BEN_old.

It had an interlinear set-up with many entries, and the results were automatically sent to a linked project (back translation) called BEN_ILR_old (the name mnemonics Interlinear-Results)

There was even a linked free translation, as some consultants do not like to read just interlinear strong-stuff. This one was called BEN_IFT_old (that name reminds of Interlinear-Free-Translation which would be a contradiction but reminds of the way those files are part of a work-flow).

Now for reasons that do not belong on the interweb, the project was forked and is now done by another organisation. For same reasons, the old names remained and new names were given to the forked files:

Main translation now called BEN_new.

And the interlinear data is still there, but I find no way to assign or send the results to BEN_ILR_new. When I try to open the interlinearizer, I get the well known welcome window from PT 9.2 and it still knows about the old setup (now under the name of the new main translation BEN_new) and wants to send all interlinear results to BEN_ILR_old.

When I try to create a new set-up, I get a dire warning like this:

The interinearizer can only use language data for one purpose at a time. 

‘You have already created the following settings for the ‘BEN’ language: 
Back translation of BEN_new[sic], Model text: RSV, Output: BEN_ILR_old 

Would you like to replace these settings with the following: 
Back translation of BEN_new, Model text: RSV, Output: BEN_ILR_new

During the forking-process, I had already created this BEN_ILR_new, based on the BEN_ILR_old. So I want to click YES.

But I would like to get confirmation from some people who understand the inner workings of PT, so that the team will not lose hundreds of work hours on the data.

Plan B:

I have looked around and found an XML file called InterlinearSetup.xml.
The structure is very clean and it is basically showing the one existing semi-old set-up where BEN_new is being interlinearized and results would still go to BEN_ILR_old.

The lines look hackable like this:

    <ExportScrTextName>BEN_ILR_old</ExportScrTextName>
    <ExportScrTextId>here a 40 digit guid which I could obtain from the online PT registry</ExportScrTextId>

Yet, I would never hack any XML file (with a shut-down PT of course) without first asking here in the forum.

So, please, what is a safe and recommended way to re-set-up our old proven set-up after the fork, with the knowledge in mind that the files have mainly been re-named for non-technical reasons and should still work together fine? Thank you.

Answer 1

You don’t say how the forked project was created. The recommended ways are to either use Backup/Restore (history is lost) or Convert project (history is preserved).

Both of these ways create a new project that has a new guid (the 40-digit key). A separate guid is required and copying a folder won’t work.

Once you have a unique copy of the original project, you can change any setting in the new project that you want - so clicking OK on the “would you like to replace” message will only change the settings of the new project.

If this doesn’t address your question, it would probably be best to send a problem report with information about the projects you are working on and then I would be able to look at the project details.

John+Wickberg
Paratext support

Comments

Thank you John+Wickberg. The forked project was created locally by backup and restore-as-new-project. It is registered with the PT registry.

I am positive about new 40-digit-keys for the main translation and the back translations; I just double-checked.

My fear and my question here is not about impacting the old project:

It is unclear from the user surface and from the inbuilt-help in PT9 what happens, when I use the Interlinearizer menu-window to create a “new” back translation (the top selector marked “Choose”), where we no longer output glosses (the selector at the bottom marked “Back translation”) to the former back-translation as proposed by PT but to a fork of the former-back-translation.

This is because we do not know where PT stores the information about all those glosses that have already been tagged. If the glosses and interlinear-data is stored in the “main translation project” then I can now click OK.

But if (part of) the data is stored in the former back-translation that used to receive the output of glosses (and in its fork), and having changed the guids, I fear that “links” would end up broken.

---

The interlinear data is stored in the project you open in the interlinearizer, not in the back translation. The back translation just gets the exported interlinear text.

If you look at the “new project”, you will see that there is a Lexicon.xml file and one or more folder in the form “Interlinear_{langCode}” where “{langcode}” is the code for the back translation language.

So, you can change the interlinear settings in the new project without affecting the old project.

John+Wickberg

Answer 2

For those with elephant memories:

Yes, I had a question about several interlinear set-ups, a few years ago here:

How to run two different interlinearizers to EN and to FR (solved) Questions

For a few years, I have done an interlinear back translation to English for quality control, for my personal language learning and just for fun. I have one dependent project to dump my interlinear results into (Destination Text). And also another one, where I write pretty free translations. Now the project wants to streamline the work-flow for consultant-checks and wants to move the French free-back-translation and the French interlinear-back-translation from Flex over to PT. I am fine with Fr…

And that is still the case, this project operates one back-translation to English (my personal fun, language-learning and quality control) and an official one for the consultants to French (a very literal and a free one). This reminds me how much work has already gone into all this. Having English and French in parallel has never caused any problems, once we had it set-up.

The fork now concerns all those files, they all have been moved and re-named. Once I get input on how to tune, I will fix them all.

Answer 3

@John+Wickberg Thank you most muchly, John+Wickberg. I played it really safe, did more local copies, made a milestone before the change, looked into the files you mentioned for my personal curiosity and for understanding the process, before hitting the button.

Then I did make the updates to our interlinear-setup for all the files which together now make a complete and working fork. I gladly report that it worked fine, as far as I can tell. There were no error messages, no delays, none of the symptoms which might indicate a problematic process. I did have a look afterwards and all elements were in place. I did a few verses of BEN to EN interlinear and it looked and felt like before. (stupidly happy grinning face here)

I admit, that making a fork is probably a very rare occasion. I had noted that moving-a-project-to-new-managing-organisation is an available option in the online registry; which is probably also rare but might happen with orgs that re-name themselves or when the context changes.

All this to say that I am impressed with the concepts and structures of PT. The files I have looked into today are very clear and proper XML. I could do something that was maybe not planned as a mainstream management-activity. But since the structures are clear and quite flexible, it all worked fine. Greetings to the PT team! PT is so much appreciated by me and by the local team which is going through major changes on the non-technical level.

I thank you and I will mark this thread as solved.

Answer 4

PS: As I was doing both the English and the French today, I use the opportunity, and realized a good suggestion from @dhigby : I removed the sample text from the French interlinear-back-translation-setup. French is the language where the non-related people are producing the official working-back-translation for consultant-checking-purposes. Doug had me convinced quickly with his logic that “no proposals” will give a better back-translation in the sense of getting what the translated text means to a new reader. I am talking about this post:

Back Translation methods Pros and Cons? Questions

It is important to note that we have made a significant change in Paratext 9.2 beta to address back translation concerns. In my translation experience, it is bad practice to allow a translator (who understands the vernacular) to be influenced by the NIV or whatever model text Paratext is set to use to guess the meanings of words. I would rather see the beatitudes start with “Lucky are the…” than “Blessed are the…” just because NIV proposed the word blessed. We made it possible in 9.2 for a tr…

Answer 5

TL/DR:
This is a boring note to myself. You cannot learn anything here. No secrets either, read on if you must. You have been warned, it will not be entertaining, nothing dramatic, no suspense, just housekeeping. Sorry to spam the server, but here is a good place to store this note.

A few weeks ago, I had this question marked as solved. That is still the case, all is well.

It was a challenge back then to figure out the details, but the French back translation with the option “glosses only, no model text” is up and running now for several weeks.

This is what the “French department” is using; in PT lingo, copied from the help:
Create glosses for XYZ with no model text
with the option
Output glosses to a project

Now our team-member who does the French backtranslation came to me recently and was asking about those useful status-boxes, as recommended by a consultant-friend. I could not find any. Could not even find the menu-entry where to make them show-up normally.

Found out that in all the exitement earlier, the results-receiving-project had ended up as an “auxiliary” and not a formal “back translation”. Now this is the reason why I am writing all this, as a note to myself:

There was an easy fix: Go to the project settings of the receiving project and to the general tab and just change the Type of project from auxiliary to back translation:

No dire warnings, no sirens, no 40 minutes extra backup-run, the change was done in seconds. No evil side-effects visible so far. And the change did promote itself correctly via send/receive to all other concerned machines.

We did a full round of testing with lots of send/receive to appreciate the results:

• make a dummy change in some verse
• get the famous red question mark in the results-receiving-project
• have the backtranslation specialist adapt her work and send the verse over again
• be surprised that the red question mark does not get replaced by a green tick but rather by a white empty check-box (trust that the developers know what they are doing)
• apply the green tick manually, directly in the receiving-project
• have the trainer remove the dummy edit from step 1
• repeat everything until the original situation is restored on all computers

This test-round took what felt like 40 send/receive but was probably more like 12. It was helpful to see the check-boxes in action. Nice feature that not-yet-translated verses do not show any box at all.

We really like PT on a day like today. Lots of regular work all day long. And doing some housekeeping at night when most of the team is gone. And getting one weird project removed from all machines and servers (not in this write-up, was just a bonus). And taming one wild sub-project into what it is supposed to be, and make it behave like a house-trained proper backtranslation.

We got boxes…