[jsword-devel] Book Installation and language

[DM Smith]

I have added language to BookMetaData in the following fashion:

I added a property file (iso639.properties) with the mapping of 2 and 3 
char iso639 codes to their language names. I went and got the 
authoritative lists for both and merged them into a single property 
file. In the course of doing it I found that the two lists did not agree 
in the spelling of some of the language names. I took my best guess. I 
mention this because we may get a request to fix one of the names.

In SwordBookMetaData it was getting the ConfigFile.LANG field and just 
storing it (except for Hebrew where it was setting the RtoL property). 
Now I am doing a lookup in the iso639 resource bundle.

In the process of doing this I discovered that creating a ResourceBundle 
for each SwordBookMetaData is very expensive. It added 9 seconds to the 
loading of all the SwordBookMetaDatas. Making it static and loading it 
once, added no noticeable time (It was about 1 sec before the change, 
and it is still about 1 sec)

I also discovered that some of the lang fields are not simply iso639 
lang fields at all. Some indicate country dialects (e.g. en_US and 
en_UK); some are made up languages (i_klingon); others are of the form 
xx-lang-lang (mostly for lang A to lang B dictionaries); some are 
mistakes (e.g. po for Polish instead of pl or pol) and some are for 
languages not in the table (not surprising given that Sword has a lot of 
Bible translations into relatively unknown languages.)

To work with these problems, I dropped country dialects and just use the 
base language (There only was one pair of instances and  they were 
locked.) For the mistakes and the languages not in the table, I added 
them w/ comments. For the others I mapped them to "Undetermined" (which 
actually has a code in the standard).

Anyway, it does nothing other than showing up in the metadata. Now I 
need to put it into the tree. (The following is mostly "thinking out 
loud" and I would love your feedback.)

There are two basic ways we can do this. Have language be the first 
level, with Bibles, Commentaries and Dictionaries (BC&D)as the second 
level. Or the reverse, having language being a child of BC&D. I do not 
have a firm opinion on which to do. Having BC&D first emphasizes that 
there are books that can be installed. Opening a BC|D will indicate that 
there are lots of material in each of the languages.

On the other hand having languages first allows for a smaller expanded 
tree as the user navigates. This is an advantage in seeing only the 
books of interest.

I think that there are two main target audiences of Bible Desktop. One 
is the Biblical scholar who has studied Greek and Hebrew and probably a 
few other languages. The other is not a Biblical scholar and probably is 
only interested in seeing books in their language. For the scholar, I 
think that having Books then Languages is probably better. For the 
other, the reverse.

At some point it might be useful to have the order be a preference, but 
I am not inclined to do that right away.

Also, I think it would be useful to allow the user to state a preference 
of which languages that they want to see. This is a bit problematic. 
Until we get the confs for the Sword modules, we only have the list of 
all languages (i.e. iso639.properties) and that is huge. It does not 
make sense to show the user all the languages, but only those that are 
actual modules. But since the getting of the list happens after 
config.xml is read and processed (since it needs to know what sites to 
get modules from), it cannot be a config preference. Since each 
installation site can serve up a different list of languages (if we ever 
add installers for non-Sword books) the preference would need to be 
either on a per installer basis or a union of installers. Anyway, I am 
not inclined to do that right away.

As a nod to the user's language, I think it would be useful to discover 
the user's locale and put their language at the top (if we have anything 
in it, perhaps English otherwise), with the others following alphabetically.

Another possibility which occurred to me after I had finished this note 
is that we can dispense with the BC&D level altogether and use a custom 
renderer that shows the "B", "C" or "D" icon that is used on the 
mainscreen. (I think that it would be good to add the custom renderer 
anyway.)

I would like to move the installer gui code into its own package, 
probably org.crosswire.bibledesktop.install, but I could be easily 
convinced that org.crosswire.bibledesktop.book.install is better because 
it parallels org.crosswire.jsword.book.install. Please, let me know if 
you have an objection or an opinion.

Now some questions on the tree. Currently, the tree has a BooksTreeModel 
that is manipulated and the changes are reflected in the tree. This 
works well as the tree is relatively flat, but trying to add language as 
a level makes it more difficult. I can add a method to BookList to get 
the set of languages and I can add a filter that will get a book by type 
and language, but this seems to become convoluted code very quickly.

I am thinking that it would be better to do the following:
Instead of having a BooksTreeModel, the tree would be just a plain tree 
that is managed externally with addBookMetaData and removeBookMetaData.
These addBookMetaData would be able to interrogate the BookMetaData and 
discover its type and its language and then find the appropriate parent 
in the tree and add the BookMetaData in the appropriate place in the 
tree. I say "appropriate" to mean that the tree may be managed by policy 
(BM&D first, LANG second or the reverse) and insertion may be by rule 
(i.e. book sorts to an appropriate position).

These trees would listen for installation and uninstallation of books 
and do the right thing.

removeBookMetaData would find the node in the tree and remove it.

Neither of these methods would install or remove books from the system, 
but only from the tree. Installation and uninstallation are handled 
separately elsewhere (as it is today). (i.e. a select listener on the 
tree updates the enable state of an install and delete button and each 
button gets the currently selected BookMetaData and acts appropriately 
on it)

Joe, I think I noticed that you are working on this part of JSword by 
having an InstallMgr which can do install and uninstalls, serially. I 
think that for 1.0 that we need to have the uninstall (aka Delete 
button) working. Two reasons: I have had corrupted installs and also 
corrupted indexes. Also,  if a module is ever updated, we need to allow 
for the user to re-install the module (perhaps internally by uninstall 
and install).

I would also like to add an BookInstallState to a BookMetaData, which 
would be one of three states, INSTALLED, UNINSTALLED or STALE (perhaps 
there would be a better name). STALE is installed, but there is an 
update to the module available. I don't know if we want to implement 
STALE at this time (I think post 1.0), but it would be there for the 
following: When mods.d.tar.gz is downloaded we note the dates on the 
confs, if any are more recent than the installation of the BMD, then it 
is stale.

I have also thought that the "Installed books" should probably be a flat 
list and not a tree. Or it should become a tree only when there are 
enough different things to warrant it. (e.g. 50 books of all types in 10 
languages.) But not sure what the criteria should be or whether it is 
simply a user option.

I had mentioned earlier an implementation of a different layout of the 
installed and installers and also of a shopping cart metaphor. This is 
still possible, but what is above is independent.