Trying Not to Panic Over Updates to the Bible

Recent updates to the New American Standard Bible, Christian Standard Bible, and, less recently, the New Internatlional Version, English Standard Version, and Amplified Bible have awakened discussion about the possibility of introducing error or succumbing to pressure to conform with the world when updating the English Bible.

There is a lot of misinformation out there about new translations. Christians are put in a very awkward position and most don’t realize the nature of it. On the one hand, we have language, which is continuously evolving. This evolution is relatively slow, but not so slow that you can’t see it if you’re looking for it. Those of us with more than a couple decades under our belts can definitely see changes between how the language was spoken in our youth vs. how it is spoken now. On the other hand you have the Bible, which we hold in high esteem and which we believe to be (or contain) the very Word (or words) of God. We can’t imagine God not expressing himself perfectly the first time, and just assume that our English Bibles should be just as unchanging.

When looked at in the big picture, we understand that we need a Bible written in our native language, and that by that we mean not just English but Modern English. We can probably understand the Great Bible (1540) and King James Bible (1611) but not in their original blackletter font and Early Modern English orthography. Even the vaunted 1769 and early 1900’s editions of the KJV that many Christians cling to as the Bible have been significantly modernized in order to be readable. Despite this innate understanding, we are at least slightly repulsed by the idea of “updating the Bible”.

It’s when we start to act this general understanding (that is, that we need a Bible written in our native language) that we get into trouble. One of the big problems is gender language. Because it’s a politically sensitive issue, there’s a feeling like the Bible should be above it. But setting aside where our personal politics lie, we have to admit that we want an accurate translation of the Bible. The fact is that the biblical languages do not convey gender in the same way English does, and the way English conveys gender has been changing. We try not to say men when we mean people. And we are trying to figure out if we like using they to refer to a single person of unspecified gender.

Personally, I’ve avoided these issues by not picking a favorite. I have a lot of experience with the RSV (predecessor of the ESV and descendant of the ASV) and the KJV (the most successful of the Early Modern English translations). For years I carried a side-by-side KJV/NIV. I was reading from the 1977 NASB when the 1995 edition came out. I’ve read through the Christian Standard Bible (CSB), World English Bible (WEB; modernized ASV), NIV (1984), and KJV; some of these more than once. I’m about 30% through the 2020 NASB. I don’t consider any of these to be the Bible; they are all just translations of the Bible into my language. By adopting this position, I completely avoid any emotional response to any new edition of any of the versions of the Bible I read.

I like to think this is an enlightened, mature perspective. Let others get hung up in arguments over which imperfect translation of one of several imperfect collations of imperfect copies of imperfect copies of the original manuscripts is somehow “best”. I choose to focus on the fact that Jesus summed up 3/4 of the Bible (the Old Testament) in two commandments (love God; love others) and his own ministry in one sentence (the Son of Man came to seek and save that which was lost). Paul summed up his ministry (and thus the bulk of the New Testament) in 2 Cor 5:14-21. Those fragments are enough to occupy one’s life; precisely how they are worded doesn’t change their implications or importance. And much of the rest is just exposition.

Photo by Andrik Langfield on Unsplash

PocketBible for Windows Progress Update #3

Today we want to talk about our progress so far on PocketBible for Windows. At this point in the project, it’s difficult to show everything we’ve been working on because a lot of it is “under the hood” or “behind the scenes”. It’s related to how PocketBible accesses its files, or the server, or the database where your user data is stored. These are all hard to demonstrate.

But we’re at the point where there are a few things we can demonstrate, and you can see them in the video above. I’ll also briefly describe them here for those of you who, like me, don’t like to watch videos.

We’re trying to make PocketBible more tablet and touch friendly. We’ve taken ideas from our iOS and Android apps. You’ll notice in PocketBible for Windows that the toolbar buttons are a little bigger than they might be in a typical app. This is to accommodate the touch/tablet environment.

The toolbar at the top of the screen is reconfigurable. You can drag buttons onto and off the toolbar from the Preferences screen.

The toolbar on the left side controls the features of the Study Panel. This is where we display your bookmarks, highlights, notes, search results, etc. In particular today, we demo the note editor. We can style text and paragraphs as you might expect, though your edits are not yet saved to the database. You can edit your notes in a plain-text editor if you’re comfortable working around the HTML tags that control the appearance of your notes.

We have a lot of the features related to display books implemented. There’s no “navigation” features yet, but you can scroll through them and see both text and images.

We’ve been doing a lot of work on the Library functions. This is how you download and open books. You can view a list of books installed on the device or books that you own (your Cloud Library account). You can view the lists in a “gallery” format or in a “list” format.

Clicking on a book in the Cloud Library causes it to be downloaded. Clicking on books in your Device Library opens them. You’ll see a progress indicator as you download books, and you can select multiple books to download them all at the same time.

You can choose to see only Bibles, only dictionaries, only commentaries, etc. You can also search for a book by typing a portion of its name in the search field.

There are a limited number of display format preferences implemented. You can currently choose a font, font size, line spacing, and some other options. You can choose from one of several color schemes, including a “dark mode” scheme, and you can create a custom color scheme by choosing colors for each of a couple dozen different elements of the display.

There’s more going on behind the scenes that are hard to demonstrate, and there a lot of things visible on the screen that are really just placeholders. Anything you see on the screen currently could change at any point before release.

About Our Development Tool Set — Electron

I’ve been talking about our innovative, new development environment since before we started coding on the project. I want to explain that in more detail at this point. If you’re not interested in the technical side of what we do, you can probably just jump to the end at this point. 🙂

We’re using a tool called Electron to develop the Windows version of PocketBible. Electron is a framework for creating native applications using Web technologies like JavaScript, HTML, and CSS. It combines node.js (a JavaScript run-time environment) and the Chromium engine (the guts of the Chrome browser built into the app). This allows us to write our code in JavaScript and create our user interface using HTML and CSS just like we would on a website. It wouldn’t be incorrect to describe this as a website running on an embedded Web server inside a Windows executable.

A lot of programs you are already familiar with are implemented using Electron, like VS Code, Facebook Messenger, WhatsApp, Twitch, and Microsoft Teams. We’re encouraged by the fact that Microsoft seems to be committed to this tool set.

This lets us leverage what we know about website design as we design the user interface and write the app.

We can actually use the Chrome developer tools just like you would in your browser to debug the app. We can explore the user interface, set breakpoints in our code, and examine the values of variables — all using tools we’re familiar with from Web development.

Using Electron allows us to use our Macs for Windows development. The video above was shot on a Mac. That’s why you don’t see a menu bar in the app — on a Mac the menu for the active app is displayed at the top of the screen, not in the app’s window. Being able to run the app on a Mac is a real benefit to us since we’re 100% Mac OS here. We use it for Android, iOS, and Mac development. When necessary, we have Windows running on our Macs under Parallels so that we can use Windows apps. But we try to avoid it as much as we can. 🙂

So that’s where things stand as of early February. You can post questions below or send them to support@laridian.com and they’ll make sure I see them and can respond.