Is it possible to restore Parallel Passage status?

Question

A team I am working with needed to make consistent changes in a project in order to correct certain incorrect Unicode characters. The team had done a lot of work on the Parallel Passages tool. Since the change affected nearly every verse, all of the parallel passages marked as done are now turned red. Is there a way to restore the Parallel passage status to that which it was before the letter changes?

Ancienne publication - affichée dans sa langue d'origine

Answer 1

CrazyRocky, I’m afraid that is not currently possible. We do have a case created already if you want to enquire periodically about its status:
Maintain back translation status etc. for certain bulk actions (PTX-15982)

I don’t think this case has a high priority right now, but in case you want to give input, below is the currently-proposed solution.

For certain kinds of bulk-editing actions, checkboxes in the following “exempt” locations should no longer lose their “Checked” status.

• Back Translation project(s)
• Daughter translation project(s)
• Rows in the Parallel Passages checking view

If any of the following actions is performed on a verse which has already been Checked (in the Back Translation etc.), it should remain Checked:

• Mark/Unmark performed from the Biblical Terms window.
• Replace All launched from any spellcheck method (the “X” button or “Apply correction” link in Wordlist, etc.) Note that it does not matter whether the user clicks “Yes” or “Yes to All”.

Out of scope:

• Ordinary edits
• Ordinary use of Find/Replace or RegEx Pal

Note that some have suggested we expand the scope and do one of the following:

• Add smarts to detect when an ordinary Find/Replace action may be a simple spelling fix. OR…
• Add an non-remembered advanced option to Find/Replace to ‘Preserve “checked” status’ of affected verses.

Ancienne publication - affichée dans sa langue d'origine

Comments

In our case we used a simple find/replace in an Arabic script language. I used the same find/replace on the TermRendereings.xml file and an export of the Wordlist to update those tools. For Parallel Passages there is the ParallelPassageStatus.xml. file. I am thinking that if I had a copy of that file from before the change, i could have run the same find/replace on it and then replaced the file in the PT directory. Do you think that would have worked?

Ancienne publication - affichée dans sa langue d'origine

---

You can get a copy of that file before the change via the tool TortoiseHg (which is mentioned sometimes in this forum). Using it you can access the history not only for the files of the biblical books, but also for files like ParallelPassageStatus.xml.
TortoiseHg is a rather complex tool, so here is only a short description of what you would have to do:

0. In order to be extra save, copy the Paratext project folder to somewhere else
1. Using TortoiseHG, open the copied folder as “project repository”
2. Find the right revision in the list of revisions
3. Do a right click on the file ParallelPassageStatus.xml and choose Save at revision...

After you changed this saved file in the intended way, you can copy the file to the original Paratext project folder (overwriting the existing file) and do a normal Send/Receive.

Ancienne publication - affichée dans sa langue d'origine

---

CrazyRocky:

I am thinking that if I had a copy of that file from before the change, i could have run the same find/replace on it and then replaced the file in the PT directory. Do you think that would have worked?

anon719148:

You can get a copy of that file before the change via the tool TortoiseHg (which is mentioned sometimes in this forum). Using it you can access the history not only for the files of the biblical books, but also for files like ParallelPassageStatus.xml.
TortoiseHg is a rather complex tool, so here is only a short description of what you would have to do:

0. In order to be extra save, copy the Paratext project folder to somewhere else
1. Using TortoiseHG, open the copied folder as “project repository”
2. Find the right revision in the list of revisions
3. Do a right click on the file ParallelPassageStatus.xml and choose Save at revision...

After you changed this saved file in the intended way, you can copy the file to the original Paratext project folder (overwriting the existing file) and do a normal Send/Receive.

Since a find/replace should not affect the ParallelPassageStatus.xml file, you could simplify this greatly by just marking a point in project history (for safety) and directly changing the file on disk. No need to go through TortoiseHg to get a certain revision.

Ancienne publication - affichée dans sa langue d'origine

Answer 2

I was under the impression that any edit (including a Find/Replace) done in Paratext would affect the Parallel Passages status boxes, but I could be wrong.

Even if it does affect them, you might try using RegEx Pal or an external editor to edit some verses, after checking them off in the Parallel Passages tool, to see if that causes the ticks to become question marks. Should be fairly easy to do if you have a test project to play with.

Ancienne publication - affichée dans sa langue d'origine

Answer 3

I’m not (yet) seeing how putting the ParallelPassageStatus.xml file back to an older version would help - especially as it looks like that file stores the content of the verse text (presumably in order to check if it has been changed since the status box was checked). Maybe I’m missing something here… but as far as I can tell, regardless of how you change the text of a verse (from a minor spelling change to a major re-write; using Find-and-Replace or RegExPal, or whatever else) if the stored text is different to the current text, then the status box will get unchecked.

Ancienne publication - affichée dans sa langue d'origine

Comments

Mark+P:

Maybe I’m missing something here… but as far as I can tell, regardless of how you change the text of a verse … if the stored text is different to the current text, then the status box will get unchecked.

That is correct. The status is calculated on the fly based on comparing the text of the verse when it was marked as complete and what it is now. That is why there is no need to go to a previous version and why a find/replace does not affect the file. Thus, it should be fairly safe to run the same find/replace on the file as was run on the text (as long as it doesn’t change the XML element/attribute names).

Note that this same system is also used for the derived translation status icons.

Ancienne publication - affichée dans sa langue d'origine

Answer 4

Thank you. I will inform the team.

Ancienne publication - affichée dans sa langue d'origine