[jsword-devel] Book Installation and language

[DM Smith]

I would like some feedback before I go forward.
Especially thoughts on where language should appear in the installer 
module tree/listing.
Book Type
    Language
       Module
or
Language
    Book Type
       Module


DM Smith wrote:

> 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.
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>