Great idea.
There are many parts to this. (Lots of messages that come up from deep in the bowels of JSword, needing to be messaged at the last minute). If need be, lets create linked issues for this and track each separately.
Not sure all can be handled. But lets tackle Bible book names first. That is very visible. Here is some background:
BibleNames is the catalog of Bible book names (BibleBook objects) and already is Locale sensitive. This was done because English Bible book names is the default for OSIS and thus JSword.
BookName holds a single book name for BibleNames. This class is also Locale sensitive. The primary features of this class are:
- Holds 2 static application preferences (for UPPER, lower or MixEd case and for long vs short name) that pertain to how to re-write references. These are an altogether different problem for a multi-user server.
- supports matching of non-exact input. E.g. 1Chr
- Is one of the alternate names a prefix of the string to match, or is the string to match a prefix of the the alternate
- Is the string to match a prefix of the full name
- Is the short name a prefix of the string to match or is the string to match a prefix of the short name.
BibleBook is an ENUM, which is static class. There are a few methods in there which are based on the default Locale:
- BibleBook getBook(String)
- boolean isBook(String)
- BookName getBookName()
- String getLongName()
- String getShortName()
- String getPreferredName() – doubly static, being also based on an application preference via BookName
getBook deserves special attention since it is the backbone of taking a text string whether from a user, a module or the application and guessing the best book for it.
It does the following:
- See if it is an exact match for an OSIS Bible book name. This handles OSIS modules and the application. Sometimes the user.
- See if there is a match in the given default Locale (which, when this is all said and done, will be the given locale). This handles user input.
- See if there is a match in the English locale (if that is not the given locale). This handles module input for non-OSIS modules (e.g. ThML) and for users who are not in the English locale, but supplying English Bible references.
The matching here is done by BibleNames, it does the following in order:
- Look for an exact match of the long name
- Look for an exact match of the short name
- Look for an exact match of an alternate name
- iterate over the books in the BibleBook order (this needs to change, it should favor books in order of importance) and call match in BookName.
The final part of Bible book names in AccuracyType.tokenize(...). It is based on ASCII book names. This causes problems in handling foreign language references, such as Farsi. This really is a different issue, but it might cause some confusion in working out whether a Locale solution is correct.
Improvement
Resolved
(View Workflow)
Major
Great idea.
There are many parts to this. (Lots of messages that come up from deep in the bowels of JSword, needing to be messaged at the last minute). If need be, lets create linked issues for this and track each separately.
Not sure all can be handled. But lets tackle Bible book names first. That is very visible. Here is some background:
BibleNames is the catalog of Bible book names (BibleBook objects) and already is Locale sensitive. This was done because English Bible book names is the default for OSIS and thus JSword.
BookName holds a single book name for BibleNames. This class is also Locale sensitive. The primary features of this class are:
BibleBook is an ENUM, which is static class. There are a few methods in there which are based on the default Locale:
getBook deserves special attention since it is the backbone of taking a text string whether from a user, a module or the application and guessing the best book for it.
It does the following:
The matching here is done by BibleNames, it does the following in order:
The final part of Bible book names in AccuracyType.tokenize(...). It is based on ASCII book names. This causes problems in handling foreign language references, such as Farsi. This really is a different issue, but it might cause some confusion in working out whether a Locale solution is correct.