Verbose form of Bible Book name is truncated on cell phone display

[GoogleCodeExporter]

What steps will reproduce the problem?
I have built a JAR file using 1 Thess, 2 Thess, 1 Tim, 2 Tim, and Titus in 
the Buang language. The titles in Buang for the five books are as follows:
øAPIYA SËN PAULUS KEVU MUÆINSËN VU KERISI-YI-ALAM VU TESALONIKA
øAPIYA SËN PAULUS KEVU NETU LUU VU KERISI-YI-ALAM VU TESALONIKA
øAPIYA SËN PAULUS KEVU MUÆINSËN VU TIMOTI
øAPIYA SËN PAULUS KEVU NETU LUU VU TIMOTI
øAPIYA SËN PAULUS KEVU VU TITUS

where, "ø" came from "Latin Capital Letter K With Dot Below" [1E32 in 
Unicode] in the original text.

The cell phone emulator cannot display the whole line, but rather 
truncates using the beginning of the line. [See the attached picture of 
the display]. Since all three books start with the same text, all the 
truncated book names are the same.

What is the expected output? What do you see instead?

The display is expected/predictable, although it is undesirable. My 
preference is to take the long book name and use a shortening scheme (like 
Microsoft uses) that takes part of the beginning of the name and part of 
the end with "..." in between.

What version of the product are you using? On what operating system?

I'm using GoBible version 2.3.6, on Windows XP.

Please provide any additional information below.

Original issue reported on code.google.com by Larry.Wa...@gmail.com on 30 Apr 2010 at 8:31

Attachments:

• BuangWithTruncatedBookName.jpg

[GoogleCodeExporter]

Please download Go Bible software version 2.4.0 which was released on 17 April 
2010.

Go Bible booknames are not designed to word wrap. The truncation is due to 
narrow
display width of phone, and your choice of verbose booknames! Use much shorter
booknames instead.

You can use Book-Name-Map: items in the collections text file to achieve this, 
if the
source text files only contain verbose book names. Example:

Book-Name-Map: øAPIYA SËN PAULUS KEVU MUÆINSËN VU KERISI-YI-ALAM VU 
TESALONIKA, 1
Tesalonika

Which format of source text files were you using?
USFM or OSIS or ThML

If you are using USFM, did you try using a different marker to extract the book
names? That would be another good solution.

I suspect this is a training matter rather than a software issue. If you'd like
further help, please contact me directly. I'd be pleased if you would anyway. It
would be great to have fellowship.

David Haslam
Go Bible project leader
CrossWire Bible Society

Original comment by DFH...@gmail.com on 1 May 2010 at 7:32

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

For curiosity, I am just checking Google support for Latin Extended Additional.

U+1E32 = "Ḳ"

If this works here, then the conversion to U+00F8 (Latin small letter O with 
stroke),
must be an artifact of the phone emulator.

Original comment by DFH...@gmail.com on 1 May 2010 at 10:47

[GoogleCodeExporter]

For other members, Buang is a language spoken in Papua New Guinea.

Original comment by DFH...@gmail.com on 1 May 2010 at 10:49

[GoogleCodeExporter]

Larry,

Please attach here (or send me) the "collections text" file you are using with 
Go
Bible Creator. At this stage, I do not require access to the source text files.

If you decide to use email, please ZIP the file first.

David Haslam

Original comment by DFH...@gmail.com on 1 May 2010 at 10:53

[GoogleCodeExporter]

Original comment by DFH...@gmail.com on 1 May 2010 at 10:54

• Changed title: Verbose form of Bible Book name is truncated on cell phone display

[GoogleCodeExporter]

David,

Thanks for your good ideas. I have been working with Dan on a new 
SourceFormatType, "xhtml_te". A team of programmers here are developing a 
product, 
called "FieldWorks Translation Editor" 
(http://www.sil.org/computing/fieldworks/TE/). I and other colleagues are 
developing 
an automated way to build a GoBible application using the text that a given 
Bible 
translator is working on. The process automatically builds the "collections 
text" 
file. Here are the contents of the one that includes the long Bible book names:

Info: Bible text exported from FieldWorks Translation Editor.
Source-Text: GPS12L10_2010-04-30_0300_cv.xhtml
Source-Format: xhtml_te
Collection: GPS12L10
Book: ḲAPIYA SËN PAULUS KEVU MUÆINSËN VU KERISI-YI-ALAM VU TESALONIKA
Book: ḲAPIYA SËN PAULUS KEVU NETU LUU VU KERISI-YI-ALAM VU TESALONIKA
Book: ḲAPIYA SËN PAULUS KEVU MUÆINSËN VU TIMOTI
Book: ḲAPIYA SËN PAULUS KEVU NETU LUU VU TIMOTI
Book: ḲAPIYA SËN PAULUS KEVU VU TITUS

The Scripture text in Translation Editor currently does not have an element or 
attribute that could contain a shortened Bible book name. Should we leave 
GoBible as 
it is currently implemented? If needed, we could possibly implement a solution 
into 
our automated path of building the GoBible application that would allow the 
user to 
enter a short book name when the given name is large (by some given criteria).

Original comment by Larry.Wa...@gmail.com on 3 May 2010 at 4:17

[GoogleCodeExporter]

Is there not already a facility to convert SIL FieldWorks TE files to USFM ?
If so, why not just use USFM as the penultimate step?

In the SIL FieldWorks TE, are the books stored as separate text files?
If so, how do you know what the correct book order is from the filenames?

This is already an issue for Source Formnat = USFM, as Dirk and others 
recognize.

The problem is that when you generate a Book: list from USFM, the order is 
determined
by the directory order of the files in the OS. In Windows, depending on what 
order
the files were created, this is unlikely to be the same order as required for 
the
canon of Scripture. Moreover, the filenames themselves may not be assigned 
correctly,
so even sorting on those within Windows can give the wrong order.

If USFM filenames are prefixed with a two digit book number in the range 01 to 
66,
unless there is [say] an underline character between the prefix and the book
abbreviation, books like 3 John would have a 3 digit prefix such as in 643Jo 
rather
than 64_3Jo. Windows sorts these as 3 digit numbers later than the 2 digit 
numbers!

I read some time back that MAF LT may be working towards enhancing Dirk's USFM
GoBibleCreator Preprocessor utility to build in something about canon 
definitions, in
order to address the issue of book order for Go Bible Creator books list.

I have not yet asked Dirk about this.

Original comment by DFH...@gmail.com on 5 May 2010 at 5:28

[GoogleCodeExporter]

"The Scripture text in Translation Editor currently does not have an element or 
attribute that could contain a shortened Bible book name."

Rather than expend effort to address this shortcoming at the GoBibleCreator 
stage,
why not just enhance the TE to support short booknames, as well as standard
abbreviations for booknames?

In OSIS, the abbreviations are already standardized, albeit based on English.

In other formats such as ThML and VPL, etc, there are various ad hoc bookname
abbreviations, usually comprising three letters.

GoBibleDataFormat may eventually change. It would have to if we wish to support
sections and paragraphs, with the possibility for blocks of scripture text that 
have
a verse range assigned, but not individual milestones for the verse numbers 
within
the range.

Original comment by DFH...@gmail.com on 5 May 2010 at 5:35

[GoogleCodeExporter]

Automation is good, but it doesn't have to be all done within the same computer
program. You can script several different software utilities within a single 
script,
and use the most suitable feature of each program for the successive steps.

All too often, I see programs become bloated because designers fail to 
recognize that
software engineering is more like an artist choosing colors from his palette.

Original comment by DFH...@gmail.com on 5 May 2010 at 5:41

[GoogleCodeExporter]

Bibledit - the open source application developed by Teus Benschop and others -
already has a rudimentary facility to export data as a Go Bible application. 
This
feature calls GoBibleCreator. However, it does not make use of many of its 
richer
features.

Like UBS Paratext, Bibledit also stores scripture text data in USFM format.

There are already good tools to convert USFM to OSIS, and organizations 
including WBT
are already exploring how to publish Bible translations (from OSIS) using 
Prince XML,
with James Albright's paper at BibleTech2010 describing the Princess companion 
GUI
that is being developed for this process.

Surely these are two sound reasons why SIL should focus efforts to perfecting
FieldWorks TE export data to USFM?

Original comment by DFH...@gmail.com on 5 May 2010 at 5:49

[GoogleCodeExporter]

http://www.sil.org/computing/fieldworks/TE/ has the following near the top of 
the page:

_Current version: 3.0, released October 2009_

When you click on the "Get FieldWorks" link, it takes you to
http://www.sil.org/computing/fieldworks/BTE-FW_downloads.htm

This has the title,
*SIL FieldWorks BTE (Bible Translators Edition) 6.0*

It would seem that the version number stated in the first page should be 
updated.

Original comment by DFH...@gmail.com on 5 May 2010 at 6:40

[GoogleCodeExporter]

Thanks for your insightful explanations. I did not realize all the contacts you 
already have with SIL members. Did you attend Bible Tech 2010, by Logos 
Research 
Systems?

I updated to GoBible version 2.4, as you suggested. Now, I'm incorporating my 
enhancements to handle XHTML.

At the moment, the only export format from FieldWorks Translation Editor (TE) 
is 
XHTML. One reason is that we are using XHTML to export dictionaries as well as 
Scripture text. Whether someone wants to export one book or several books of 
the 
Bible, they end up with one XHTML file. A side benefit of using XHTML is that 
it has 
a standard, a schema that can be used to validate the markup.

To publish something from FieldWorks, whether it would be a dictionary or one 
or 
more books of the Bible, we are developing a tool to guide the process. 
Incorporated 
in the tool is a way for users to define styles, which can be shared with 
others.

You mentioned the problem of maintaining the order of books of the Bible. When 
someone uses the publishing tool to export something from TE, the tool 
maintains the 
order of the books.

Considering the need to have short book names that work with cell phones, we 
are 
leaning toward having our export process ask the user for short names as 
needed. 
This will let the user give names using the language for which the Scripture is 
being translated, and that is appropriate for the language. That is, the short 
name 
will be used according to the way the culture makes abbreviations.

By the way, thanks for noticing the anomaly about the version of TE. The reason 
for 
the anomaly is that FieldWorks (as a suite) has its own version number, and 
each 
tool (such as TE) within FieldWorks has its own version number. I can 
understand how 
this is confusing.

Original comment by Larry.Wa...@gmail.com on 6 May 2010 at 12:47

[GoogleCodeExporter]

There's a large body of water and most of a continent between our home and San 
Jose.

I wish I could have come to BibleTech 2010 - though I have followed the agenda 
with
interest. A few of my friends were there, some American and one Brit (height 
6ft7in).
I will try to find time to listen to some of the MP3 recordings and look at the
presentation slides.

Thanks for describing more about TE and XHTML.

Can TE be run from a command script to perform specified tasks?
Or is it all interactive via the GUI ?

Original comment by DFH...@gmail.com on 6 May 2010 at 4:41

[GoogleCodeExporter]

Larry, please join the Go Bible Forum.
I often post useful information therein.
It's worth browsing some of the categories, at your leisure.

http://jolon.org/vanillaforum/

Registration is at top right of the banner.

Original comment by DFH...@gmail.com on 6 May 2010 at 4:46

[GoogleCodeExporter]

TE is all interactive via the GUI. I'm sorry it cannot be run from a command 
script.

Thanks for the invitation to join the Go Bible Forum.

Original comment by Larry.Wa...@gmail.com on 11 May 2010 at 6:12

[GoogleCodeExporter]

As no further comments have been made since May 2010, I am closing this issue.

Original comment by DFH...@gmail.com on 28 Dec 2012 at 10:34

• Changed state: WontFix