Paratext 7 Tips and Tricks
Getting your shared projects back after a computer disaster
If your Paratext projects fo ProblemReport0.ziplder became damaged or corrupted after a computer disaster, and files are missing from your project, DO NOT do a send/receive. The send/receive will first send your present damaged project to the repository, deleting or corrupting files for your colleagues. This can happen even if you do not have permissions to make changes in the project.
What you should do is remove the project using Tools > Delete Entire Project Resource. Then you can do a send/receive, and you will receive a fresh copy of the project from the server, rather than distribute your corrupted version.
What does the "Cannot share with Amanda" message mean?
See also “Unable to share” in Paratext help
The Internet server for send/receive permits projects having the same short name. This is a convenience. Imagine the annoyance of starting to set up send/receive and being told it can't work over the Internet because your project name is already in use.
But what can't happen is for two projects with the same short name to have the same users. If Joe and Amanda are working in two different places, and create two projects with the same short name, the server keeps the two projects apart. If Joe and Amanda now want to work on the same project, the other project with the same short name has to be deleted from Paratext and deleted from the server. (It could be backed up in Paratext, then restored to a new project name if one wanted to keep the data in it).
So if you want to add someone as a user to your Paratext project, and you get a message that you cannot add that person to this project, this is what has happened.
Another thing that could create this message, if two people were working on the same project using the Paratext 6 process of making backups and sharing them with each other instead of send/receive. If Amanda is the translator, and she uses the Paratext 7 backup to Internet feature on the project before Joe the administrator sets up send/receive for the project, he may see a message in his Paratext that he cannot share the project with Amanda. Amanda needs to remove her project, and also tell Paratext to remove the backup from the Internet, before she can send/receive the project that Joe administers.
If Amanda has some changes in her copy of the project that she wants to get into the shared version, what she can do before removing her project is to do a backup of it, then restore it to a new project name. Then she can remove the original named project, get the shared project from the server, and use Compare texts to compare her version (the newly named project restored from backup) with the shared version. If there are changes to implement, she can copy and paste them into the shared project. (Or if she doesn't have editing rights, she can make notes, or send her suggestions to Joe by email or other means).
When send/receive will not work at all
When Paratext will not run, or frequently crashes
When search does not work at all
A simple mistake in editing the language settings can make the search feature almost useless. When you enter lower case/upper case pairs in the Alphabetic characters section, the lower case character MUST come first. If your case pairs are in the wrong order in the language settings; searching for “a” will only find “A”, unless you select “match case”, in which case it will find “a” but not “A”. Searching for “sheep” will only find “SHEEP”.
Settings and data files
Paratext lets you define what the Scripture book files will be called in your project, but it makes other files that you may not be aware of. Here is a list. Many of these names use the project short name, but not all. I'll abbreviate the project short name as PSN.
Files that may be common to several projects These are in My Paratext Projects
usfm.sty or usfm_draft.sty or various other .sty files. The style sheet. This informs Paratext how the markers are used, and the formatting to use for them in standard, or preview views, also when you save as RTF or print draft.
.lds files. The language settings file. Stored in My Paratext Projects. The first part of the name is the name you give the language in Paratext.
eng.vrs or org.vrs or othNN.vrs. Versification files.
.ptwc files. (New to Paratext 7.4). These files, in My Paratext Projects\WindowsCollections, contain the info for saved text combinations.
Files unique to a project Usually inside the project folder, within My Paratext Projects
PSN.ssf The project settings file. This stores info such as the name pattern for the book files, their location, whether the project is editable or not, and the number of books created. Located in My Paratext Projects, not inside the project folder.
BiblicalTermsPSN.xml. The Biblical terms rendering data. In earlier versions of Paratext 7 and Paratext 6 this data was in a file named PSN.kb2. In 7.5, you may also find TermRenderingChanges.xml and ProjectBiblicalTerms.xml.
ProjectUsers.xml. The list of users, roles and permissions for the project.
unique.id. A long string of hex digits, I assume it is how Paratext can identify unique projects, even if they are shared on the Internet where there may be other projects with the same short name.
.hg. The folder containing the repository data. Don't attempt to change anything in here, or you could corrupt your repository.
gather A folder where Paratext keeps a copy of files the project needs that are not in the project folder, such as the style sheet, the language description and the .SSF file.
Comments_User Name.xml. The file of notes made by the named user.
Lexicon.xml Part of the interlinear information – it stores words and their analyses and glosses.
Interlinear_language A folder containing the specific interlinear information for specific books. Each interlinearized book is represented by a file inside this folder. The language name is that of the model text used to interlinearize in.
The danger of file sync utilities
There are several utilities that will sync files automatically between two different computers. Programs like Dropbox or box.com will let you sync files to the Internet and potentially sync with other users you give permission to connect with you. It would be a bad idea to use one of these services to sync your Paratext project folder with other users. The problem is the Paratext project history repository is stored in a special file structure controlled by a program called Mercurial that Paratext runs. If Paratext and Mercurial need to write to the special repository files, and at the same time Dropbox is writing to these same files because your colleague is also working in Paratext and syncing to your project folder, the result easily could be a corrupt repository, resulting in a loss of your project history and the ability to do search and replace and other kinds of changes to your project.
Update: Earlier I had suggested the possibility of using Dropbox to sync Paratext files by doing a send/receive to a folder inside Dropbox. It turns out this idea won't work, the way Dropbox works somehow doesn't match how Paratext works, because Paratext will think the Dropbox folder is read only, even though it isn't.
The list of available books
Paratext maintains inside the .SSF file for the project the list of books that have been created. The copy of the .SSF file stored inside the .gather folder doesn't contain this list. There have been a few cases reported where this list is not accurate. I've heard of a couple of shared projects where a book would disappear from Paratext's list when you shut it down and restarted it, then the book would reappear after a send/receive. And if a book file is added to the project folder by copying the file directly, Paratext won't detect that this book has been added, except as described below.
To make Paratext refresh the list of existing books, go to Project > Project Properties and Settings, then click OK to exit the dialog (you don't need to change any settings, just open the dialog and close it with OK.) If the project is shared, and you are not an administrator, you can trigger the refreshing of the book list by going to Project > Language Settings and clicking OK.
More details on changes to shared project files
The View Project History command shows you the history of the Scripture books in the project. But if you need to peruse the history of other files in the project, such as the consultant's notes, or the interlinear files, you can do this with a utility called Tortoise HG, which will show you the database Mercurial maintains on each file that is part of the project. With this utility you could do things like recover notes files that became corrupted or were deleted by some other program or mishap to your computer. For information or to download Tortoise HG, go to http://tortoisehg.bitbucket.org. (The name HG relates to the Mercurial program that Paratext uses for managing the repositories and the send/receive process. HG is the chemical abbreviation for mercury).
When you install TortoiseHG, it adds several new options to Windows Explorer. If you go to My Paratext Projects and right click on your project folder, you'll probably see three commands in the middle of the context menu. TortoiseHG has a lot of commands that hopefully you won't need, it is intended for people to use for managing repositories directly. Paratext does a lot of this for you.
Perhaps the most useful one for seeing what is happening with your project files is HG Workbench. It will show you in a graphic form the history of changes in your project. Here is an example:
The red and blue lines show that recently changes from two users were merged with changes from a third user, which happened when the third user did not send and receive as frequently as the other two users. This does not mean a conflict necessarily occurred, if the users are assigned different books or different chapters to edit, there shouldn't be any conflicts even if one or more users have gone for a while without sending and receiving.
The HG workbench also permits you to recover a deleted file that does not appear in the Paratext project history. For example, in this project the BiblicalTerms file was deleted by mistake, and then send/receive deleted the file from other users' copies as well.
This shows at revision 22, the file BiblicalTermsABNP.xml was deleted. If this was a mistake, how can the file be recovered? TortoiseHG offers a way. If you right click on the version before the file was deleted (version 21 in this example) you can choose "Browse at revision". This will list all the files that were part of the project at that revision. You can find the file you want to restore in the list, right click on it and choose "revert to revision." This will restore the file as it was.
The basic syntax: a change rule has –> (hyphen, hyphen, greater than) in the middle.
will change x to z.
A line beginning with a # is a comment.
# change x to z
- You can specify characters by their Unicode number:
will change b
to ɓ (Latin Small Letter B with Hook).
- Q: Is there a way to limit whether it matches whole words only?
- A: No. The example
in the Paratext help file is a bit dangerous, because it will change any sequence of “teh” in the middle or end of words. You can add spaces as part of your string:
will not change “teh” in the middle of a word, but only at the end. And it would not change “teh” at the end of the word if the word was immediately followed by a punctuation mark. You can add a space at the end of your change string, so the space at the end of the word does not disappear.
For example: --->> (three hyphens, two greater thans), changes hyphen into greater than.
Q: Can you put - or > characters in your string to match?
A: Yes. The program can find the –> sequence within a longer sequence of - or > characters.
If Paratext is running when you change the autocorrect.txt file, you need to exit it and restart it for the changes in autocorrect.txt to work.