[sword-devel] Locale differences

[DM Smith]

On Sep 12, 2012, at 5:05 PM, Peter von Kaehne <refdoc at gmx.net> wrote:

> On 12/09/12 14:51, DM Smith wrote:
>> 
>> On Sep 12, 2012, at 6:10 AM, Peter von Kaehne <refdoc at gmx.net
>> <mailto:refdoc at gmx.net>> wrote:
>> 
>>> So, Jsword's use of English as default first is simply wrong, unless
>>> the user has a way of undoing that.
>> 
>> The problem, which SWORD has also, is that the parsing routine does not
>> distinguish between user input and module or application input. If we
>> did, then we could skip checking OSIS.
> 
> I do not think this is correct.
In SWORD, there is one and only one parsing routine. Same in JSword.

The difference between SWORD and JSword is that JSword tries to optimize the lookup by considering OSIS book names first.

(There are other differences, but they are minor).

I few years ago I scraped all the modules (GBF, ThML and OSIS; Bibles and Commentaries) for their references. I then ran them through SWORD and through JSword and compared what they interpreted the reference to be.

When they differed, I took a look at the input to understand the differences. IIRC, in every difference the input was ambiguous (e.g. v10 for this chapter's 10-th verse or Jud found in the book of Judith).

Looking further at this list, the book names have always been English. Probably because a reference of "1 Moses 2:2" in a module might work only on occasion.

That doesn't account for the OSIS exact match as these are not user inputs.


> 
> There is this:
> 
> Random_reference_in_whatever_format_and_language -> OsisRef -> setting
> of pointer in module and retrieval of passage.

When the program creates a reference as a string and needs to convert it to a Verse object, it uses the sole parsing algorithm. It's best if the program creates unambiguous references.
The references in ThML and GBF modules are no different than user input. They are often "arbitrary". The program has to do it's best to guess what is wanted.

> User input is at stage 1, application input is at stage 2.
> 
> And if the application would run perfectly valid and parsed OSISrefs
> retrieved from a module through a new parsing process from scratch, then
> this would be a bug, no?

I don't really understand your question.

BTW, GBF doesn't and ThML might not have OSISrefs. (ThML can, but there's no guarantee.)

And even if we converted all of our modules to have clean references, there's no requiring a user to upgrade to the newer module. And some modules, may not be currently available, but are in user's collections. Who knows what they contain.

So far it has been easiest to have a single routine.

BTW, I have thought about having a separate OSIS parse routine. It'd be very fast. Just haven't gotten around to it. It'd also be good to have in SWORD too.

> 
> Peter
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page