[sword-devel] Strong tagging and Septuagint
chris at burrell.me.uk
Fri Feb 8 13:40:43 MST 2013
Because I provide Interlinears, I need to be able to tell the user that for
the combination of LXX and KJV you are unable to see the interlinears in
the OT. The reason being, KJV uses Hxxxx and LXX uses Gxxxx. If you're
looking at several texts in interlinears, it simply looks like there is a
bug, because one of the lines is blank. The knowledge would enable me to
prevent users and warn them, that the functionality is unavailable.
(extended Greek: I was under the impression that someone added Greek Strong
numbers to cater for the ones that are only present in the OT and therefore
not part of the original set that Mr Strong originally did.
On 8 February 2013 20:37, DM Smith <dmsmith at crosswire.org> wrote:
> For OSIS, the only values to indicate Strong's Numbers are:
> There is nothing defined to further distinguish.
> BTW, what is extended Greek? Are you referring to the TVM codes that look
> like Strong's Number with a G prefix?
> I guess what we need is to understand how you'd use the knowledge in a
> In Him,
> On Feb 8, 2013, at 3:15 PM, Chris Burrell <chris at burrell.me.uk> wrote:
> Thanks, that does clarify. Still the problem remains in that we want to be
> able to distinguish between different types of tagging (greek, hebrew,
> extended greek) by questioning the module. Does the conf file not also
> define supported features? Can we not make it so? Or have a flag in there
> to indicate the Strongs tagging is abnormal/Septuagint (i.e. Greek tags in
> the OT)
> On 8 February 2013 20:11, DM Smith <dmsmith at crosswire.org> wrote:
>> In SWORD the various GlobalOptionFilter values indicate to the SWORD
>> engine which pieces of code (filters) to enable. Same with some other
>> entries in the conf.
>> In JSword, we don't have a filter architecture. We convert everything
>> from the source type (ThML, Plaintext, GBF, ...) to OSIS. Then we use xslt
>> to transform that into HTML. The xslt is passed what the user would like to
>> see or not see. It doesn't really matter (so far) what is set in the
>> module's conf.
>> This has one problem. Regarding Headings (aka Titles). They should always
>> show in a commentary, as they should all be assumed to be canonical
>> (properly part of the module) unless marked non-canonical.
>> Hope this clarifies.
>> In Him,
>> On Feb 8, 2013, at 11:00 AM, Chris Burrell <chris at burrell.me.uk> wrote:
>> Perhaps in Sword-terms a property isn't a statement of what's there,
>> however JSword does seem to read it and give the front-end information
>> about whether an option is available in the module or not...
>> Maybe I misunderstand something?
>> On 8 February 2013 15:12, David Haslam <dfhmch at googlemail.com> wrote:
>>> Our three Finnish modules do not have Strong's numbers.
>>> The conf files do not include GlobalOptionFilter=OSISStrongs, yet the
>>> pseudo-markup in the source text files
>>> (from an /ad hoc/ workaround to provide the original verse references
>>> an Av11n translation)
>>> get interpreted as if they were Strongs!!!
>>> The engine still parses the text, and displays these tags, despite the
>>> that they can't be hidden by a filter.
>>> A filter property in a conf file is just that! It tells the engine what
>>> do when asked.
>>> It's not a statement about what's there.
>>> View this message in context:
>>> Sent from the SWORD Dev mailing list archive at Nabble.com<http://nabble.com/>
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> Instructions to unsubscribe/change your settings at above page
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel