Unfolding Bible

[Open English Bible]

Hi guys,

I thought I would draw your attention to the “unfoldingWord” Bible, which has a website:

https://unfoldingword.org/bible/

According to their website "unfoldingWord is a collaborative project launched by Distant Shores Media in 2013 and currently managed in partnership with Wycliffe Associates and Roma Bible Society.”

They have two English translations, both under CC-BY-SA licences.

The "Unlocked Literal Bible” is described as "an open-licensed revision of the 1901 American Standard Version now in the public domain.” I’m not sure if this is a rebadged WEB Bible?

The “Unlocked Dynamic Bible” is a relicensed version of Ellis Deibler’s Translation for Translators. I assume they have relicensed with his permission.

All in all, this is a great addition to the list of open licensed English translations. Although it isn’t in the public domain like the WEB and the Open English Bible, the CC-BY-SA licence is very liberal and Ellis Deibler’s work is first rate.

Cheers, 

Russell

Russell Allen

oeb...@openenglishbible.org

[Jesse Griffin]

Hi Russell,

Thanks for posting this!  I wanted to tag along to answer some of your questions and add some more information.

The Bibles can be browsed at bible.unfoldingword.org or in the unfoldingWord mobile app (https://unfoldingword.org/app/).  There are links to the USFM source (on Github) on the website as well (https://unfoldingword.org/ulb/ and https://unfoldingword.org/udb/).  Downloadable and print ready PDFs are forthcoming.

The Unlocked Literal Bible is indeed an update of the 1901 American Standard Version.  It is not related to the WEB Bible.

The Unlocked Dynamic Bible is also CC-BY-SA with written permission from Ellis Deibler.  My understanding was that the original TFT would be released under the CC-BY-SA license as well, but I'm not sure if that has happened yet.

I also wanted to add that neither the ULB or the UDB is targeted at English speakers.  If we (English speakers) find them useful, great, but the real purpose is to enable mother tongue translators to begin translating into their own language with unencumbered texts.  This dovetails into our Gateway Languages strategy that you can read more about at https://unfoldingword.org/gateway/.

Lastly, the UDB is intended as an expanded or amplified version, targeting speakers that are translating into languages that lack the rich theological words that we have in English.  The goal is for translators to consult the UDB when they can't make out  what the ULB is indicating.  All this is possible in our translationStudio Android app (https://unfoldingword.org/translationstudio/), and the forthcoming desktop version (code at https://github.com/unfoldingWord-dev/ts-desktop).

Thanks again, Russell, we do pray that these texts will be a blessing to the Global Church.

Thank you,

Jesse Griffin

unfoldingWord Chief Technology Officer

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openscripture...@googlegroups.com.
To post to this group, send email to openscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/openscriptures.
For more options, visit https://groups.google.com/d/optout.

[Open English Bible]

Hi Jesse,

Thanks for the extra info, it helps to know where you are coming from. I can see the value of having the UDB as essentially a commentary on the ULB.

It seems a shame that you weren’t able to reuse the work that Michael Paul Johnson has done on creating the WEB from the ASV but I understand you have special requirements. 

Just out of interest, is it your reading of the CC-BY-SA conditions that any translation of the UDB/ULB which is done must also be put under a CC-BY-SA licence?

Thanks for your work,

Best wishes,

Russell

[Jesse Griffin]

Hi Russell,

You are correct, the goal is to create a "locked open" repository of biblical content that perpetuates more of the same.

Thank you,

Jesse Griffin

[Michael H]

Hi Russell,

I have a version of the Translation 4 Translators with a CC-BY-NC-ND license (http://ebible.org/find/details.php?id=eng-t4t). 

The current UDB doesn't have the Section Titles/Section Descriptions that the T4T present on ebible.org contains. Does the UDB License allow for the use of Diebler's section descriptions parenthetical notes and footnotes using the CC-BY-SA license?

[Jesse Griffin]

Sorry for the delay in replying to this.  The T4T with the CC BY-SA license is available here: https://git.door43.org/Door43/T4T.

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openscripture...@googlegroups.com.
To post to this group, send email to openscr...@googlegroups.com.

Visit this group at https://groups.google.com/group/openscriptures.

For more options, visit https://groups.google.com/d/optout.

--

Thank you,

Jesse Griffin

[Kahunapule Michael Johnson]

Based on the signed license statement signed by Ellis W. Deibler, Jr., I will update the license on eBible.org for the Translation for Translators to CC BY-SA. This translation is a work in progress, with regular updates (as is the World English Bible). I get regular updates from Ellis via Paratext send/receive and update eBible.org accordingly, usually at least once a month. The next update will reflect the less restrictive license.

--

Aloha,
Kahunapule Michael Johnson

MICHAEL JOHNSON PO BOX 881143 PUKALANI HI 96788-1143 USA

eBible.org MLJohnson.org Mobile: +1 808-333-6921 Skype: kahunapule

[Michael H]

Hi Michael,

I pulled the latest T4T from ebible to compare with the Unfolding Word Version. Thank you both. 

1. the files from ebible.org do not include Haggai, but the files from Door43 do.  Is this a recent development that Haggai has been removed? Do you know if there is a reason not to use Haggai? 

2. The book of Ezekiel on both repositories contains hundreds of occurences where the opening character style \add is not preceeded by a space so that the final rendering will appear to be a complex word, half of it in italics. In all other books there are at most 5 occurences like this.

3. The project on ebible is rather contaminated with extra line endings (some 54000... which aren't a real issue), but including line endings prior to character styles (about 2000... which are a huge issue for my processes.) The files from door43 do not have these extra returns. USFM 3.0 which is due out this month is explicit about line endings prior to paragraph tags.  It is not explicit about about line endings anywhere else (at this time, but 3.0 has not been released yet.) 

Is there any chance you can transform your files to NOT break lines prior to character tags?  That is \n\\it ... \it* or similar cause errors in many publishing systems, including mine. 

See the USFM 3.0 summary of changes at: 

https://github.com/ubsicap/usfm

And the way I viewed the new proposed spec was to download the whole github project, then view the top level index.html file within the project at docs/_build/html/index.html

On Thu, Jun 16, 2016 at 2:42 PM, Kahunapule Michael Johnson <Kahun...@ebible.org> wrote:

Based on the signed license statement signed by Ellis W. Deibler, Jr., I will update the license on eBible.org for the Translation for Translators to CC BY-SA. This translation is a work in progress, with regular updates (as is the World English Bible). I get regular updates from Ellis via Paratext send/receive and update eBible.org accordingly, usually at least once a month. The next update will reflect the less restrictive license.

On 06/16/2016 06:53 AM, Jesse Griffin wrote:

Sorry for the delay in replying to this.  The T4T with the CC BY-SA license is available here: https://git.door43.org/Door43/T4T.

On Fri, May 20, 2016 at 5:44 AM Michael H <cma...@gmail.com> wrote:

Hi Russell,

I have a version of the Translation 4 Translators with a CC-BY-NC-ND license (http://ebible.org/find/details.php?id=eng-t4t). 

The current UDB doesn't have the Section Titles/Section Descriptions that the T4T present on ebible.org contains. Does the UDB License allow for the use of Diebler's section descriptions parenthetical notes and footnotes using the CC-BY-SA license?

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openscriptures+unsubscribe@googlegroups.com.
To post to this group, send email to openscriptures@googlegroups.com.

Visit this group at https://groups.google.com/group/openscriptures.
For more options, visit https://groups.google.com/d/optout.

--

Thank you,

Jesse Griffin

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openscriptures+unsubscribe@googlegroups.com.
To post to this group, send email to openscriptures@googlegroups.com.

Visit this group at https://groups.google.com/group/openscriptures.
For more options, visit https://groups.google.com/d/optout.

--

Aloha,
Kahunapule Michael Johnson

MICHAEL JOHNSON PO BOX 881143 PUKALANI HI 96788-1143 USA

eBible.org MLJohnson.org Mobile: +1 808-333-6921 Skype: kahunapule

--
You received this message because you are subscribed to a topic in the Google Groups "Open Scriptures" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openscriptures/J8Z5musBfMo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openscriptures+unsubscribe@googlegroups.com.
To post to this group, send email to openscriptures@googlegroups.com.

[Michael Johnson]

On 09/15/2016 04:54 AM, Michael H wrote:

Hi Michael,

I pulled the latest T4T from ebible to compare with the Unfolding Word Version. Thank you both. 

1. the files from ebible.org do not include Haggai, but the files from Door43 do.  Is this a recent development that Haggai has been removed? Do you know if there is a reason not to use Haggai?

There used to be. It was excluded for being too incomplete at one time, but that exclusion has just been removed on eBible.org.

2. The book of Ezekiel on both repositories contains hundreds of occurences where the opening character style \add is not preceeded by a space so that the final rendering will appear to be a complex word, half of it in italics. In all other books there are at most 5 occurences like this.

Verified. See http://eBible.org/eng-t4t/EZK01.htm for an example. I'm passing this on to the translators for correction. In USFM, the space after \add is part of the markup, and does not appear in the text. Therefore, there should also be a space before the \add. Also, \add should not follow another \add without closing the first \add with \add*. Note that in the case of \add* (or any ending markup), the space after it, if any, is part of the text. The instances of \add not being properly closed can be found easily with Paratext checks. There are currently 5 of these in Joel and Hosea. The missing spaces before \add are a little trickier to find, but can be found with a regular expression.

3. The project on ebible is rather contaminated with extra line endings (some 54000... which aren't a real issue), but including line endings prior to character styles (about 2000... which are a huge issue for my processes.) The files from door43 do not have these extra returns. USFM 3.0 which is due out this month is explicit about line endings prior to paragraph tags.  It is not explicit about about line endings anywhere else (at this time, but 3.0 has not been released yet.)

In USFM, line endings are allowed almost anywhere that a space is allowed. I strongly recommend that you process them accordingly, because there are well over a thousand texts in USFM that has such line endings. They will not all be changed for your convenience. It would be simpler for you to replace the line ends with a space and/or write a better USFM parser.

Is there any chance you can transform your files to NOT break lines prior to character tags?  That is \n\\it ... \it* or similar cause errors in many publishing systems, including mine.

IF you can convince the USFM 3.0 specification committee and also convince the Paratext programming team to change the way Paratext handles these, then this could be done. (I don't realistically expect that to happen.) Otherwise, you need to find a creative solution to making your publishing system work with the standard. Maybe shifting to taking equivalent XML input (USFX or USX) would be easier. Honestly, this is a bridge I have already crossed in Haiola and its predecessor projects. Line end, space, and tab characters are mostly interchangeable and condensible to one space, except for the line end before a paragraph-level marker and white space after an opening tag.

See the USFM 3.0 summary of changes at: 

https://github.com/ubsicap/usfm

And the way I viewed the new proposed spec was to download the whole github project, then view the top level index.html file within the project at docs/_build/html/index.html

This is useful. I have started implementing the changes in there, and now support \w word|root\w* type markup. You can see the note about white space handling in syntax.html in the above files. If that is not clear, the master reference implementation of USFM, Paratext, is a good reference if you have access to it.

To unsubscribe from this group and stop receiving emails from it, send an email to openscripture...@googlegroups.com.
To post to this group, send email to openscr...@googlegroups.com.

Visit this group at https://groups.google.com/group/openscriptures.
For more options, visit https://groups.google.com/d/optout.

--

	Your partner in electronic Bible publishing,

[Michael H]

Michael, 

Just to point out, I'm not asking for NO excess returns, just to exclude them from any just prior to any tag that isn't a paragraph tag (by paragraph, I mean to include \v and \c and meta tags like \h that are part of the specification and work like nonprinting paragraphs... except V.. v stands alone.)

We use USFM extensibly.. and extend to markers that aren't explicitly listed in the spec, but are either implicitly listed (like '\mt6 \mt7, which ARE allowed in USFM even though they don't appear in the manual) or intuitively described (like \ili1 \ili2 - not sure if this is in USFM or not, but you get the idea, intuitively adding the i for an intro equivalent of a defined body text tag.  These tags aren't allowed strictly following the spec.  However if you review all the Paratext stylesheets (USFM.sty) put out by ICAP, they are doing exactly this type of extension within UBS/Wycliffe.)

Character styles appearing in collumn 1 break the extensible nature of our methods and force explicit reprogramming for any new tag. It's not impossible, just not efficient. Our systems autogenerate stylesheets and valid documents even for tags that are undefined.. and do a decent job of guessing what the style should be. The specific style definition may not be accurate, but an undocumented tag in the text doesn't break everything. Unless it's an undocumented Character style appearing in column one, where it creates the possibility of showing up as a new paragraph. 

Again, 50000 extra returns aren't a problem. It is only returns that are immediately followed by a slash is part of a character tag, which makes them look like paragraph tags that aren't documented. Shifting the character tag right and including a space before the \ would fix this issue. Or shifting the return to behind the character style. 

As for using XML like USX instead.. we do use multiple XMLs pre publishing (but not USX). However, XML is for machines not humans, you can see and track maybe 200 characters at once. Tagged text is by its nature in between humans and machines, and is useful for preparing to go to multiple XMLs. A person can scan an entire screen at a time and see all of the tags (given a good editor setup) at one time.  

I wouldn't have caught the lack of preceding spaces prior to the /add tag had I been looking at USX instead. We have programmatic checks that might have detected it, but given the nature of the T4T text (which has carats, triangles, etc. encroaching the beginning of words, it would likely have not been caught with all the extra noise this text has.

[Kahunapule Michael Johnson]

Hello, Michael.

I understand what you are asking for and why. You are just asking the wrong person if you want the USFM standard and all USFM texts to change. Even if I changed the USFM output I produce, this would not change USFM from any other source. Wouldn't you like to be compatible with more sources? There is an implicit assumption in USFM that you will identify what kind of tag something is by its name. Your goal of discerning this on the fly from context (i.e. column) might seem good, but it seems to need improvement. As for recognizing tags like \mt7, I already handle that simply by generalizing any tag that takes an optional level as part of the name. I've never seen more than \mt3 in any real Bible text, although I have seen \q4 and \ili4.

To keep using your current strategy would require you to do some more programming to adapt what is to what you want, or many others to do some programming to adapt to your way, not to mention reprocessing many source texts. Your idea may well be better, but character styles will start in column 1, so you would be wise to adapt to that reality, preferably not in a way that involves me writing more software. ;-)

--

Aloha,
Michael Johnson

PO BOX 881143 • PUKALANI HI 96788-1143

• USA
mljohnson.org • Phone: +1 808-333-6921 • Skype: kahunapule

[Robert Hunt]

Yes, the sad reality is that USFM 2 (and up to Paratext 7) allow extra newlines almost anywhere in USFM files, including allowing character tags to start on newlines. (It's a hangover from way back in floppy disk and one-file-per-chapter days.)

It seems that USFM 3 will tidy this up by removing some ambiguities. (I requested this a few years ago.) Hopefully also Paratext 8 will also be more consistent and strict, but that also remains to be seen.

Robert.

--

[Michael H]

Michael, 

As I mentioned earlier, the same T4T text received from another source does not introduce rows of text that begin with a character style. In the other side of the T4T comparison, the Door43 text... There were some hundred or so 'v' tags that did not have returns prior to them.

If you look at the USFM 3 summary of changes, it describes some of the logic behind 'extra returns'.  None of this discussion (which seems to vote for returns ONLY with paragraph style, mentions any need to start a line with character styles. 

https://docs.google.com/document/d/1tkg6n4RuepTKUCct7B-1vZfbH2wyg2kSCgeAPVrrFr4/edit

Paratext has within it an "unformatted view".  When this mode is enabled, files are not 'normalized' to standard USFM when they are saved. This does not mean that files output in this mode from paratext conform to the USFM standard. It is a way to disable some annoying features if you are intentionally working on deprecated or unusual files. 

When you have formatted view enabled, none of this strange use of whitespace is true or possible... you will always get returns ONLY before paragraph markers, and never before any other tag.  It is possible to introduce a return character in paratext and not follow it with a tag (excess returns that don't have tags near them.)  However if you introduce a character tag while the cursor is at column 1 in paratext with formatted view turned on, <st>the text snaps back onto the row above it.</st> Paratext refuses to accept the tag, and simply remains waiting for a valid paragraph tag. It might be possible with a custom.sty file to disable this behavour, but again, just because a file was saved with paratext does not mean it conforms to USFM. 

If you output USFM from a formatted view in Paratext you ALWAYS get a return prior to a v. If you output USFM from a formatted view in Paratext You will NEVER get a character tag at the start of a line. 

I'm not aware of any USFM text outside of your files that have this 'feature'. I'm curious what other sources you are referring to that do start rows of text with character styles?  None of the reference USFM files have them. 

:-) 

--

[Michael Johnson]

I just repaired the \add crowding in Ezekiel on eng-t4t.

I also tried adjusting the word wrap for longer lines to see what that would do to character styles starting out lines. It reduced the number of them, but didn't eliminate them. I'm not going to turn off the word wrap, because too-long lines result in more than one problem and complaints from other people. The result is still fully compliant with both USFM 2.4 and USFM 3.0 RC1.

On 09/15/2016 04:54 AM, Michael H wrote:

I pulled the latest T4T from ebible to compare with the Unfolding Word Version. Thank you both. 

...

2. The book of Ezekiel on both repositories contains hundreds of occurences where the opening character style \add is not preceeded by a space so that the final rendering will appear to be a complex word, half of it in italics. In all other books there are at most 5 occurences like this.

--

Aloha,
Michael Johnson

PO BOX 881143 • PUKALANI HI 96788-1143

• USA