Going Mobile with Translated Scripture

A few months ago I was introduced to a system for building  Android apps for Scripture Engagement that was being developed by a colleague working in West Africa.  It takes the scripture text and audio that we already have and bundles it together into something that really is equal to more than the sum of the parts.  I have been privileged to be part of the alpha testing and wanted to share with you why I am so excited about this project.

Let’s start out with an overview of what the Scripture App Builder does.  The builder is a Java program installed on my computer that I use to bring all of the needed files together.  The first files I add are from the Paratext project or the Digital Bible Library.  I then add the appropriate fonts to make sure that any special characters display correctly and any images that are needed for the app icon and splash screen.  Finally I can add the audio scripture and associated timing files before building the app.  The whole process goes rather quickly and the end result is a very powerful app.


Scripture App Builder combines the text, font, icon, and audio files into an Android app package


As I mentioned above, the text is coming directly from Paratext files.  They are not converted, but are copied directly into the app and used natively.  That means that the features built into the Paratext files are available in the app.  This includes the obvious like being able to select the appropriate book and chapter and having each verse number marked.  But it also includes features like cross references, footnotes and glossary references.   Search is also fast because it is working against the raw Paratext files.

The app can also be localized for the people group that it is intended for.  That starts with the app icon and splash screen.  There are some situations where it is more appropriate to draw attention to it as a Bible than in others.  There are also three default color schemes that can be used (red, green, & blue), but every item within the app can be recolored to fit the culture.  Even features like search have been localized with the ability to add buttons for special characters that are not normally on an Android keyboard.  The user interface navigation within the app can be translated so that people will not need to know another language just to interact with it.

The feature I am most excited about is being able to include the audio right along with the text. In it’s simplest form, an audio recording can be attached to each chapter.  However, by including a timing file, a lot gets added.  Each verse and section heading is highlighted as the audio plays.  The user can also skip forward and back by verse or section.  This gives the user much more control over which part of the text they listen to and allows them to follow along.  The implications for literacy are incredible!  (The second half of the video below demonstrates this feature.)

The app is not just limited to scripture.  Anything that can be put into USFM format can also be included.  Some ideas that have been mentioned so far are related materials like scripture songs, the Lord’s Prayer, and statements of faith like the Apostle’s Creed.



This slideshow requires JavaScript.




Q: Once the app has been built, how can I distribute it to others?

A: You can start distributing it right away via Bluetooth or microSD card to people around you.  It can also be made available through a website, by email and even the Google Play Store.

Q: Will people need internet access to use the app?

A: No. Everything can be packaged inside of the app, meaning that it will need no additional permissions like internet or file system access.  However, that may change depending on how you handle the audio files (see further down).

Q: Do I have to split up my audio files by verse to make the advanced audio controls works?

A: No. Audacity, a free audio editor, can be used to create timing files which are then included in the app.  It is not difficult to do, but will take a lot of time.

Q: Audio files can get large.  Can they all fit in the app package?

A: There are actually a number of ways to include the audio files.  Which one you choose will depend on what works best for your distribution methods.

  • The audio files can all be included in the app package.  This makes distribution easier because everything you need is in one file.  However, if you distribute via the Google Play Store, the package file is limited to 50 MB.
  • An extension file can be used alongside the app package.  This can be up to 2 GB so should handle the audio for most scripture apps.
  • An external folder can be used, such as a microSD card.  This requires additional permissions for the app, but may simplify distribution.  One possibility is to distribute a microSD card that has the audio scripture files and the app.  Feature phones could still use the audio files and Android phones would get the added benefit of the full app with text and advanced audio controls.
  • If Internet access is not a problem, the audio files could be hosted online and the user could download them.  Again, additional permissions would be required.

Q: Since the raw Paratext files are included, can somebody access them by unpackaging the app?

A: It would be very difficult.  The Paratext files are encrypted when the app package is built so that others cannot extract them to use for other purposes.

Q: Android has problems displaying my text because it is a complex script. Can I still use this app?

A: Hopefully.  Each version of Android seems to fix some issues with complex scripts while at the same time breaking others.  The Non Roman Script Initiative (NRSI) has developed a system called Grandroid that brings Graphite font rendering to Android.  The app builder provides an option to use Grandroid.

Q: When will the Scripture App Builder be available?

A: The system is currently in an Alpha version, meaning that more features are still being added and a lot of bugs are expected to still be found.  It will hopefully soon move into Beta meaning it will be a bit more stable and feature complete.  The current plan is for a full release around November 2014.

Q: Is it only for Android, or is there a version that works on iPhone and Windows phones?

A: To make an app work well, it is best to write it in native code.  The user interface code is very Android-specific, so it would need to be rewritten for other platforms.  Android was chosen first since it has such a large portion of the smart phone market.

Q: What can I do now to prepare for the full release of the Scripture App Builder?

A: The first and most important thing is to make sure that you have the rights to distribute the text and audio.  Determine who currently holds the copyrights and begin a dialogue about how this app fits into their distribution plans.  You can also make sure that you have run the checks on your Paratext project and that it fully conforms to the USFM standard.

27 thoughts on “Going Mobile with Translated Scripture

    1. No. For any of the distribution methods besides using the Google Play Store, you will have the check the box in the security settings for “Unknown Sources: Allow installation of apps from sources other than the Play Store.” I am curious to find out, but I am suspecting that a large number of phones in Ghana already have that setting selected.

  1. Faith Comes By Hearing (FCBH) records, mixes and masters indigenous Scripture. Can FCBH audio be used by SAB? FCBH currently only marks chapters, not verses, but I know they are aiming to mark at the verse level as well. It seems like a good thing if these two (SAB and FCBH) can work together

    1. Audio can be played at the chapter level as long as it is in mp3 format so it should work with FCBH recordings quite well. Before using the audio it would be important for the group creating the app to have an agreement with FCBH. To get the verse by verse there has to be a timing file which is a simple text file that can be created using the label feature of Audacity: http://audacity.sourceforge.net/onlinehelp-1.2/track_label.htm

      1. FCBH is now committed to recording portions (e.g. one or more books from either OT or NT), Can one use SAB for such portions, or does SAB require a full OT or NT?

      2. One of the huge benefits of the Scripture App Builder is that you can use whatever Paratext files you have. So, if you only had the first chapter of Mathew translated, you could build an app with that. Then you add the MP3 files for whatever chapters you have. This means that distribution can start happening before the entire NT, OT or Bible are completed. As you add more material, when the updated app is distributed, it will replace the existing app on the smartphones where it is already installed.

  2. Is it possible to subscribe on some kind of the newsletter to stay in course of the latest versions of the AppBuilder and another related news?

      1. App Builder is a Windows application itself. Do you have a Linux version, so that I could build Scripture packages on a desktop with Ubuntu/openSUSE?

      2. As far as I know it is only available for Windows at the moment. However, it is built in Java so it may be available for Linux in the future. I don’t know if that is planned or not.

      3. While app builder is not currently available for Linux the time taken to actually build the app is a matter of minutes so it should be an easy matter for us us testing the system to build an app for you using your files and your chosen settings. (just because you can own your own equivalent of the printing press doesn’t mean you have to).

  3. I work with translators recording scripture in languages never recorded before. I use pro digital recorders like Sound Devices 633 and Tascam HS-P82. Both are capable of generating timecode files in bEXT and iXML of a broadcast WAV file. When recording new material like this, wouldn’t it make sense to use these timecode features and also make it possible for the App Builder to accept this material to eliminate the tedious and time consuming work of creating time files. I realize this has to be done with recordings already made without timecode included on the “front end”. But, with new recordings it seems that using timecode would be very beneficial. The downside of this would be the lare size of the WAV file if trying to squeeze the audio into an app. However, on an SD card, this might be possible. Thoughts?

    1. Thanks for the idea. When working with the apps having a small file size is extremely important. With MP3 a full New Testament is already 700 MB plus. Going with WAV that would increase exponentially. However, I wonder if there would be some type of export utility that could take the timecode that you are already generating and create the simple version that the app needs.

      1. Haven’t heard of a conversion capable of keeping timecode since it is stripped away if not a BWF broadcast wave file. Will keep searching and experimenting. I guess part of the issue is if the strategy is to use the technology to encourage literacy, then how much of the Bible needs to have audio-text synced in an app? Also, what is the likelihood of a non-reader, one who can’t read having a full-featured Android to make use of the App with audio-text sync? Might be useful to put these features in a medium readily available to that audience. Just a few things to consider.

    1. Apparently, you can include MPEG format data as the sound data as well, but I’d use something like:
      1) LAME to encode WAV->MP3
      2) BWF MetaEdit to extract iXML data as XML
      3) XSLT or perl or python to convert XML to Audacity text file

      1. Ok. Since I don’t know much about programming matters and am essentially capturing, editing and packaging audio, I will need to capture the audio using timecode and then hand off test files for others to experiment with. It seems wise to make sure the recordings are captured as BWF with code. Then, the folks with the lab coats can take it from there to determine if/how the text-audio sync can happen.

        Pete Stover


  4. @Peter,
    My observations were theoretical and speculative rather than experiential. I’ve never worked with BWF files, and don’t know how difficult step 3 would be.

    My assumption was the work of marking the time codes was already done.

    If I didn’t have the timecodes already, I’d load the BWF files into Audacity and use Audacity to mark the time codes. That way know that they are in a usable format

    In any case, I would first ask the lab-coated folk who is going to do the conversion.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s