Important issues to resolve prior to Paratext 8 migration

It is recommended project short names include the ISO language code.  Migration is the time to change the name of your project to something more meaningful to those outside of your translation team.  During migration, it is not possible to change the short name.  The old shortname will be copied over and used during the registration process. Once that code is in the registry, it can’t be changed without deleting the registration. You can use the Convert Project tool that is built into Paratext 7.6 or Paratext 8 to change the short name. See Using the Convert Project Tool for instructions.

Already migrated?

Although it is easier to change the short name just prior to migration, you can still do this afterwards. See Using the Convert Project Tool for instructions.

Unicode has a number of characters that are precomposed, but can exist in the data in either composed or decomposed forms. In the image below, the source character on the left can be represented in either Normally Fully Decomposed (NFD) format or Normally Fully Composed (NFC) format.

The Å and the ô can be represented with two separate characters (decomposed) or with a single character (composed). Either way, they appear identical. Different keyboards enter the data in either composed or decomposed format. If your data has been entered by more than one keyboard, it is possible that you have a mixture of these encoding forms in your data. In Paratext, the mixed data encoding can result in the following problems:

• You use the search window to find “trône” in the text. You know the word is there, but Paratext doesn’t find it, or only finds some of the occurances.
• Your word trône is marked incorrect by the spell checker, but the suggested correct word looks identical to you.
• You add “trône” as a Biblical term rendering, but Paratext doesn’t find it in the current verse, even though you are looking right at it.

Paratext 8 can normalize the characters to either composed (recommended) or decomposed, no matter what keyboard is used to enter them. If you have some of the above problems with your data, you will want to turn on normalization in Paratext 8.

Unfortunately, normalization cannot be applied during migration. Instead, you have to convert your data before migration. See Using the Convert Project Tool for instructions.

Already migrated?

You can still fix this. See Using the Convert Project Tool for instructions.

Is the name on your Paratext 7 registration incorrect? You must use the same name to register for Paratext 8, but afterwards, you can correct the name when logging in to the registry.

Please note that the old username will still be visible in the project history.  If that is a security concern, you will have to change the name using project conversion as explained in Using the Convert Project Tool.

Already migrated?

You can still fix this. It is more difficult to create a new user registration in Paratext 8 than in Paratext 7 because the Paratext 8 registration does not allow the same email address to be used for both accounts. Even with a second email address, it can be problematic to change the address later. A better solution for changing your registration name is in the works, but if you need to do it now, follow these steps:

1. User does a send/receive on all projects he or she belongs to
2. Admin removes the user from all projects and does a send/receive on those projects. (If the user is an admin, the admin role must be transferred temporarily to someone else in the team)
3. Delete the user account in the registry
4. Create the new user account
5. If changing the name for security reasons, use the Convert Project tool to replace the old registration name in the history. If not, the user must ask to be added back on all the old projects.

In Paratext 8, your team should normally have only one officially registered standard project per language which will be listed in the Paratext registry. The type of this project is a standard translation. Earlier versions of Paratext had only one project type. Later, as new project types were added, many users have left all their projects configured as standard translations. Unless these are corrected, those projects are treated as standard translations for registration. Not only is this extra work for you, but it also puts mislabeled projects into the Paratext registry, and we don’t want them. Here are some examples of projects that are not standard translations:

• Back translation projects (label them as Back Translation)
• Team or personal notes (label them as Auxiliary or Consultant Notes)
• A draft version that is for the teams internal use and not for publishing (label them as Auxiliary)

Before migration, it is easy to correct the translation type:

• Back Translation
  • Go to Project Properties and Settings, and set Type of Project to Back Translation, then in the field below, specify the standard project that the back translation is based on. In Paratext 8, a back translation does not require a separate registration, it uses the same registration as the project it is based on. If you have not specified which project it is based on before migration, you cannot do this after migration.
• Auxiliary
  • Any project that you’ve used for various stages of translation leading up to the final stage, or any notes projects and such should be changed from Standard Project to Auxiliary. Then in the field below, specify the standard project that it is related to.
• Consultant Notes
  • If you do have a standard project that you use for notes and you want to continue to use it with many projects, you have a few options:
    • If you do not send/receive this project with anybody, and it is just for personal use, then you may migrate it, but not register it in the registry. The registry is not for notes.
    • You can change it to Auxiliary (as above) and link it to another project. Even it it is not related to that project, you can use it and share it without having to register it.
    • Preferably, you should create a new Consultant Notes project and copy these notes manually to that project. Using your notes with multiple projects is exactly what the Consultant Notes project was intended for.

Already migrated?

You may have added back translations and auxiliary texts to the registry as standard translations.  It is important to fix this for the integrity of the registry!  Unfortunately, once the project has been registered in Paratext 8, it is not possible to change the Type of Project in Project Properties and Settings, as the option is now grayed out:

Fortunately, you can still correct this by manually deleting the registration.  Follow these steps:

1. Have all team members do a send and receive of the project, then you do a send/receive.
2. In Paratext 8, go to the Project menu and select Delete Project… (Don’t worry, we are not going to delete the project)
3. Select the Project you want to unregister in the first field.
4. Select “Show more actions…” in the second field as shown below:
   
5. Select “Keep only my copy, delete for others; delete registration.”
   
6. Select OK.  Paratext may give you multiple warnings about deleting the project. That is unfortunate, since we are not actually deleting the project from your computer. Go ahead and accept the warnings.
7. Now, when you return to Project Properties and Settings, you will see that Type of Project is now modifiable.  Set it to Auxiliary or Back Translation as appropriate.
8. Do a Send/Receive
9. Now, each team member that the project was shared with will have to go to the Project menu and choose Delete Project…
10. They must choose the project and select the default option: Delete this project from this computer only.
11. Once they have deleted the project, they may do a Send/Receive and will have the project back with the correct project type selected.

Your project may not have the correct language and language identifier specified.  When a new project is created “English” is the default language, and no language identifier is selected.  You can check these settings for a project by going to Project→ Project Properties and Settings.

Language is the writing system used for your project and includes the alphabet and all word-forming characters such as hyphens, accents and tone marks. Language identifier is the ISO/ethnologue code that uniquely identifies the language being translated. These two settings need to be correct before migration to Paratext 8.

To change the Language setting click on the drop down arrow next to “2” and select the language being translated.  If your language is not on the list, click the New button and create a writing system for your language.  Follow the instructions on the guide to specify the upper and lower case letters including accented characters and digraphs needed by the language.  Do not include letters unused by the language.  Click on the Other Characters tab and specify the word medial punctuation needed by the language.  It is common to need the hyphen for hyphenated words and the apostrophe for contractions or vowel elision.  Remove any punctuation that is not allowed word medially in your writing system. When the settings are correct, click OK button.

To specify a language identifier click on the Choose button next to the number “3”.

Type in the language name or the ISO code, then select the correct language for the list and then click OK.  Use the Advanced tab if you need to specify a variant such as English_Austrailian.  Most projects will not use the this tab. If the language is not on the list, scroll down to the end of the list and choose “Language Not Listed qaa”.

Already migrated?

You can still fix this. When looking at Project Properties and Settings, Paratext 8 will redirect you to the registry to make any changes to the language.