Recommendations for revision project – on part of the Bible

Question

Brief background: our majority language project has had a bit of a rocky history. The four Gospels were printed in 2010 after something over a decade of work. Since then, ten other books have been completed, with two more almost ready.

A decision has been made to revise the Gospels: we now have a cohesive team of MTTs (as opposed to one main translator and others who came and went from the Gospels project), and they have a lot more experience. We also have the challenge of eschewing high literary language (pardon the irony), yet avoiding the translation sounding like a particular dialect – the Gospels didn’t always achieve the latter.

Anyway, I can see two options:

1. To make a daughter project, and revise the Gospels there;
2. To archive the current Gospels (where we’re still tweaking footnotes, etc. for electronic publishing purposes – mainly apps and the DBL) to a new project, and revise the Gospels in the main project.

My question is: which route would others recommend? (1) has the advantage that there are tick-boxes (checkboxes) to help the translators/revisers to keep track of what they’ve revised to their satisfaction; (2) has the advantage that the revision will share the spellchecking, morphological and Biblical terms data of the rest of the project. And it seems logical to keep the latest version of the whole translation in one project, with an archive (maybe more than one in future) for earlier versions of parts on the Bible.

I wish we could have the best of both worlds! Is there a way to do (1) and have two projects share the same spelling/morpho/Biblical terms data?

Or, is there a way to get tick-boxes in a Standard (non-Daughter) Project? This could be useful in a number of other, more common situations: preparing Draft 2 from Draft 1, you could keep track of which verses you’ve checked and are satisfied with, for example.

Answer 1

In Biblica we are using a different system.

When we start a revision we create a new working project, which is a copy of the current publishing project and not a daughter project. We do not find the check boxes that helpful as they tend to break the text into verse-size chunks even more than the verse numbers. This gets in the way of revisers looking at larger chucks such as paragraphs. The project progress system along with the Compare Texts tool can then be used to keep track of revision progress.

Although the history is lost, translator notes, both resolved and unresolved, are transferred to the new project. The past history is not nearly as useful as the project notes, but can always be consulted by looking at the old project history.

We also take away translator rights to the old project. The old project thus becomes a repository of what the translation was like when it was first published. The old version and the new version can then be directly compared.

The are a number of other advantages to this system from our point of view:

• We have one project per copyright date, which translates to one unique project per DBL entry.
• The base text for the revision is simply what was imported into the project, so seeing the changes made is easily done.
• The project size is reduced.
• For certain scripts such as Devanagari Unicode Normalization is applied to the newly created project.
• The new project name indicates its revision number
• The old version, which is presumably on the DBL, can be updated separately to remove errata and adjust markup.

My understanding is that the spelling/morpho/Biblical terms data must be exported separately and imported into the project. Two projects cannot share the same spelling data automatically. it would be a manual process to keep them synced.

CrazyRocky
Biblica Translation Technology Manager

Comments

CrazyRocky:

Although the history is lost … The past history … can always be consulted by looking at the old project history.

Yes, all most of us need is for the Project History to be preserved somewhere.

Your explanation of your procedure is valuable: preserving precise copies of what was published is good.

In our majority language project, I want to make sure we can see the text as it was at the completion of each Draft, and we try to do this with the Mark Point in Project History… feature (though the translators or project manager often forget).

Your system works well for revising a whole Bible. But what we’re doing is that one MTT is revising the Gospels (which were done when the translators did not have the level of experience they now have), while the other MTTs continue to work on the first translation of other books. I’m in favour of keeping it in one project, so that we have one record of spelling, morphology and biblical terms. Also, if we revised the Gospels in a separate project, when we come to print the NT, we’d be working from two projects, one with the Gospels, and one with all the other books!

---

wdavidhj:

Your system works well for revising a whole Bible. But what we’re doing is that one MTT is revising the Gospels (which were done when the translators did not have the level of experience they now have), while the other MTTs continue to work on the first translation of other books. I’m in favour of keeping it in one project, so that we have one record of spelling, morphology and biblical terms. Also, if we revised the Gospels in a separate project, when we come to print the NT, we’d be working from two projects, one with the Gospels, and one with all the other books!

We use our system for the situation you are describing. We use a copy of the published NT as the starting point for both the OT translation project and the NT revision project. Both the OT translators and NT reviser work on the same project so the Wordlist, and Biblical terms data are common to both. (This is easily done using book permissions.) This also gives the NT revision access to the OT books for the parallel passages checks so the orthography style and OT quotes will be completely harmonized across both Testaments.

The OT translation can take many years and because of printing costs, the NT revision will normally not be released before the full Bible is complete. In the meantime, the original NT translation is out there, in print, electronic and possibly audio forms, yet it may have serious errors that you feel need to be corrected right away. This is where having one project per copyright date is important, because this allows us to correct the old NT project separately from the new revision.

In our view it is important that the copyrighted translation in print and electronic forms stay fairly stable. We do not want the electronic version to differ much from peoples printed copies or the audio version. So we allow the Published NT project to only be revised in certain defined ways:

• Correct spelling or grammatical errors
• Correct punctuation errors
• Update or correct markup
• Bring the project into line with what was actually printed
• Make adjustments based on the audio recording process.

K

---

CrazyRocky:

In the meantime, the original NT translation is out there, in print, electronic and possibly audio forms, yet it may have serious errors that you feel need to be corrected right away. This is where having one project per copyright date is important, because this allows us to correct the old NT project separately from the new revision.

That is exactly how I was thinking, and I’d say it’s a key “best practice”. If you refer to my post at the head of this conversation, you’ll see that both the options I listed involved having one copy (I called it an “archived” copy) where we can make small edits to the published text, and one copy for revising – the only issue was which one should be the separate project file.

---

Consider the conversion tool and renaming the new version of the project. You could then keep the old project as it is for printing and reference while the new project that would then be revised and expanded would still have history, wordlist, keyterms etc.

Answer 2

I would be inclined to choose option 2. I would want to have all of the
project history in the same original project along with the spelling and
good local terms data and everything else you already have set up for the
project. You can Mark a point in Project history and label it something
like “Before beginning revision of Gospels.” Then you can always use the
Compare Texts tool to see exactly how you revised the Gospels.

If you are continuing to publish the older version of the Gospels, I think
putting that in a separate project is probably a better idea than putting
the revision in a separate project.

john_nystrom