[jsword-devel] Book Installation and language

Sat Sep 18 11:18:26 MST 2004

My personal favorite would be Book Type/Lang/Module because a German
Bible is more similar to an English Bible than a English Bible is to
an English Dictionary.

Joe.

On Sat, 18 Sep 2004 08:56:03 -0400, DM Smith <dmsmith555 at yahoo.com> wrote:
> 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
> >
> 
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>