"Just Send" & "Just Receive"

Question

I just read a different about the possiblity of doing S/R of just part of a project.
(Partial send/receive possibility - #3 by sflint)

I understand the issues james_post mentions with people forgetting to upload their entire project.

However, I have thought that it would be beneficial to have additional “send” and “receive” buttons.

Oftentimes a team is editing a book together (in person or via videocall). In order to ensure everyone had the most up-to-date version, the entire team must periodically do two rounds of S/R. The first round is really just to send. The second round is really just to receive.

What if these buttons could be created?

“Just Send”
Function:
Just sends the project. Five minutes after sending it will also receive, if not initiated sooner by the user.

“Just Receive”
Function:
Just receive the project. But if the project hasn’t been sent within the last five minutes, do a regular send and receive.

Everyone would hit “Just Send” first. Once that is done, they all hit “Just Receive.”

This could save teams a lot of waiting time and reduce burdens on the servers.

Of course, a disadvantage would be the extra complexity and extra training needed.

Just an idea I’ve had for a while! I understand it might not be practical, but wanted to share it anyway.

Answer 1

What about Paratext Live? That keeps the project up-to-date even better.

Comments

My understanding is that in order to use Paratext Live, Paratext must first do a S/R to synchronize the files.

I would hesitate to separate out the Send and Receive functions, because the files would quickly get out of synch. Having users try to remember if they have done one or the other would get confusing. The reality is that S/R requires time. It is possible to use the “Schedule” tool to schedule that S/R is done on a more regular basis. And, depending on the types of schedule used, reminders pop-up to do S/R.

---

Good point james_post. Maybe my team can try using that again. In the past it’s given us some issues.

And it is probably best to focus efforts on improving Live, rather than making separate S and R buttons.

And thank you anon848905 for the reminder about the various options to schedule and prompt S/R events. Those are quite useful. Especially the option to do S/R on program launch and closing.

---

One thing I wish for is that when I change the User settings for a project, the “project only” send/receive would activate instead of the Main Menu send/receive. It takes so long for Paratext to get through my Main Menu send/receive to work through my projects that I avoid it except for a scheduled, once-a-day, tea break.

Blessings,

---

I’ve found that opening the main menu S/R and then Alt + Click on the projects you aren’t working with right now (this week or this month) ‘hides’ them from the global S/R process, speeding it up considerably. The benefit increases as you hide more projects.
This is easily undone by rechecking the box for the project where it has hidden at the bottom of the list.

Answer 2

Yes, I do believe Paratext Live must first do a S/R to sychronize the files, at least if it’s been too long (?) since you’ve done it. But then it keeps the text up-to-date without having to S/R. If you need to get new notes, etc, you need to use the Exchange All Files button.

@anon094061 Yeah, it may be a good time to try again. And do let the developers know if you encounter issues. In case you missed it, Paratext 9.3 can do a Live session with either the Live server in 9.2 OR the Live server in 9.0 and 9.1.

Answer 3

Just to add that in the current versions of Paratext we have the option to send/receive “this” project, from the menu of each project. This is especially useful for administrators, consultants and support people, as it avoids having to open the send/receive window and wait for the program to check all projects for updates.
This option to send/receive only one project and scheduling would be useful.

Also, if the team is sure that only one person made edits, the synchronization process is simpler: Just have the editor be the first to send/receive, then the others will do it once.

If there is more than one editor or the doubt of more edits, the two-round process is correct. The extra time is minimal as the program will only use time to see if there are edits, but will not use time to synchronize the unchanged files. This can be checked by doing a send/receive on an updated project.