Assumptions

  • You and your Oral Bible Translation team have been using Render 2.3 (R2.3)
  • You are continuing with your OBT project but transitioning from the Render 2.3 program to the new Render 3 program (R3).


Key Design Specifications for R3

  1. Flexible, customizable workflow
  2. Forward looking (current and future compatibility for hardware and software)
  3. Improved stability and synchronization


General Similarities

  • Designed for use by everyone: Windows-based, leveraging touch-screen technology, colors, and icons;
  • Designed for use by teams using multiple computers in different locations;
  • Facilitates Oral Bible Translation with a structured workflow (supporting best-practices in translation) and an orality-centric process (listening and recording in audio);
  • Based on Scope Breakdowns (Sets [R2.3] / Sections [R3] and Passages)


General Observable Differences

Issue

Render 2.3

Render 3

Roles and computers

Computer-based: A given role is assigned to a particular computer.

User-based: Any role can be performed on any project computer. Still best to separate them.

Workflow

Somewhat rigid. Requires stages based on translation best-practices (Draft, Peer Check, Community Test, Back Translation, Consultant Check)

  • Much more flexible. Draft and Consultant Approve are the only required stages. Others – Peer Check, Community Test, Consultant Check – can all be added in any order and number and customized.
  • A Stage is “packaged” with all relevant sub-stages. E.g. Peer Check includes Peer Revise; Consultant Check includes Back Translate, Note Interpret, Transcribe, and Consultant Revise (all customizable)

Scope Breakdown terms

Sets and Passages

Sections and Passages (just a name change)

Yellow guidance

Yellow marks required actions and cannot be turned off. Also, when listening to a yellow audio (e.g. reference audio of a passage) you must listen all the way through before moving on.

This guidance feature can be turned ON or OFF for any given stage and substage. Also, when listening to a yellow audio file, you are NOT required to listen all the way through.

Drafts

Only one draft of a passage possible in Draft and Revise

Up to 6 drafts of a passage can be made and compared in Draft and Revise.

Passage Division

A division point is made in the primary reference only; that first division is drafted completely and then Render presents the remainder of the passage for further division and so on.

All desired division points must be made at once before drafting; all references can be divided; each division is drafted as a new passage but labeled as part of the original – 1.1, 1.2, 1.3, etc.

Notes

Disconnected from any point in the audio; the note maker (Teams, Peers or Consultant) needs to specify where in the audio their note is relevant.

Notes can be connected to a point in the audio determined by the cursor location.

Community Test

For Q&R, one Setup stage and 3 possible Test stages using the same Questions from the Setup

Community Test Stage includes Setup, Test, and Revise. One or more such Stages can be added to the workflow allowing for multiple community tests. See document section “Multiple Community Tests” below for more information.

Edit

Only available in the Consultant Revise stage.

Improved and optionally available in every Revise stage.

Consultant Check & Approval

Approval of a Set occurs as soon as the Checking Consultant is satisfied and by making no more notes/comments on the Set.

Approval of a Section is accomplished in a separate stage from Consultant Check and can be performed by someone other than the Consultant Check user.

Back Translation

Retell and/or Breath-Pause BT

Retell and/or Segment BT (basically just a name change)

Synchronization
Set/Section DataObserve role created to allow such a user to see/hear all data connected with a set - reference audio, draft audio, notes, back translations, etc. 
  • "Section Status" in the 3-dot user menu gives you access to Section information including Biblical reference, current Stage, team to which it is assigned, and Draft audio. No reference audio, Back Translation, or notes audio is available.
  • The Config role has additional powers in the Section Status feature. The Config will also have another tab at the top of the window called "Recovery." In Recovery, a Section can be reverted to a prior condition. This can help to recover from a data corruption experienced in a given Stage. If this happens, the Config can revert that Section to its condition prior to that Stage, or Reset the Section all the way to its original condition.

 

Flexible Workflow

Render 3 Workflow configuration requires only two stages – Draft and Consultant Approve. The project Config person can optionally add one or more (and multiples of) the following Stages, and in no particular order:

  • Peer Check which includes the sub-stage Peer Revise; 
  • Community Test which includes:
    • Optional Retell and/or Question & Response methods; 
    • Community Setup (automatically added when Q&R is turned on);
    • Community Test;
    • Community Revise.
  • Consultant Check which includes:
    • Optional Back Translation (BT) and 2-Step BT with further options of Retell and/or Segment (previously known as Breath-Pause) BT;
    • Optional Transcription of Retell BT and Segment BT;
    • Consultant Check;
    • Optional Note Interpret;
    • Consultant Revise.

Further customization is also available in every Stage including the options to have Guidance (yellow) turned ON or OFF; Edit turned ON or OFF (default) for every Revise substage; and further context-specific options in each stage.


Multiple Community Tests

The Config role user can modify the workflow by adding one or more Community Test “tiles” or Stages. Each Community Test Stage is customizable for the kind of test - Retell or Question & Response, or Both. 


If Q&R is enabled, the substage of “Community Setup” will automatically be added to the workflow for each Community Test Stage added to the workflow. This has pros and cons. One good thing is that the work invested in creating questions for the first Community Test will be inherited by all subsequent Community Setup sub-stages. One cumbersome aspect is that you will have to go through the Community Setup sub-stage for every test. However, if there is no need to modify the flags and questions, one need only proceed through the Setup substage without making any changes. One benefit to this design is that you DO have the option to make changes to the flags and questions. This is helpful if the first test reveals the need to make such changes before the next test. Also those changes will be inherited by subsequent tests.


Another cumbersome aspect to this design is that the teams will have to also go through the Community Revise step for every test. A team can make no changes (just proceed through the revise substage making no changes) until the last one in which they can listen to all of the feedback from every test and improve the draft (revise) if desired. In this way, teams can easily and quickly proceed through the Community Revise step after a test, and then do the same with the Community Setup for the next test (assuming no changes to the flags and questions are needed) and be ready for the next Community Test within minutes.