<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Chris,<br>
      <br>
      I understand the possible need for general facility, to indicate
      features and this is why we have the Feature=StrongsNumbers tag.<br>
      <br>
      I also understand why this isn't straight forward the LXX.<br>
      <br>
      But, I would say that this is an exception and one that doesn't
      warrant adding a new feature like:<br>
      <br>
      Feature=StrongsGreekNumbers<br>
      <br>
      The logic we all implement for this, if we need to know BEFORE
      look at the data, is something like,<br>
      if Feature=StrongsGreek then we expect have Greek Numbers in the
      NT, if an NT exists in the module and Hebrew Numbers in the OT,
      unless we're the LXX, then we have Greek Numbers in the OT.<br>
      <br>
      There really are no other exceptions that I can think of that
      would warrant us all changing our code to look for two different
      Feature tags instead of the single instance.<br>
      <br>
      Why again do you need to know before a user clicks on a Strong's
      number?&nbsp; We are beginning to have modules with other lemma tags
      than simply Strongs, so you will need to look at the lemma type
      attribute when the user clicks to see what's available for
      lookup.&nbsp; Granted, we probably want to standarize and add other
      Feature= option values for these new lemma types as well, so I'm
      not saying we shouldn't expand the list, but for this instance, to
      support Greek lookups in the OT for the LXX, I don't think the
      change is worth this single exception.<br>
      <br>
      As an example, you can see the LXX doing greek lookups in the OT
      here:<br>
      <br>
<a class="moz-txt-link-freetext" href="http://crosswire.org/study/parallelstudy.jsp?del=all&amp;add=KJV&amp;add=WLC&amp;add=NASB&amp;add=LXX&amp;key=Gen.1.1">http://crosswire.org/study/parallelstudy.jsp?del=all&amp;add=KJV&amp;add=WLC&amp;add=NASB&amp;add=LXX&amp;key=Gen.1.1</a><br>
      (click on an LXX word)<br>
      <br>
      I'm certainly open to hear and reconsider if you have a case you
      can't work around.<br>
      <br>
      Troy<br>
      <br>
      <br>
      <br>
      On 02/12/2013 04:08 PM, Chris Burrell wrote:<br>
    </div>
    <blockquote
cite="mid:CACQnaRU_JNGo4KV4LrFs9u4F5o787p-Ur2TO2bkMmBZjrNnvyA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Yes, but in this case, these are existing modules
        used with a new front-end (with I'm guessing functionality that
        isn't yet available in existing front-ends), hence the issue.
        <div><br>
        </div>
        <div>Chris</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 12 February 2013 14:52, David Haslam
          <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:dfhmch@googlemail.com" target="_blank">dfhmch@googlemail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Regarding
            proposed new module configuration properties....<br>
            <br>
            xulsword &lt;<a moz-do-not-send="true"
              href="http://code.google.com/p/xulsword/" target="_blank">http://code.google.com/p/xulsword/</a>&gt;
            &nbsp; already makes use of a few<br>
            extra properties in the conf files for modules made for that
            front-end.<br>
            <br>
            See note 2 in<br>
            <a moz-do-not-send="true"
href="http://crosswire.org/wiki/Module_Repositories#Institute_for_Bible_Translation"
              target="_blank">http://crosswire.org/wiki/Module_Repositories#Institute_for_Bible_Translation</a><br>
            <br>
            Even so, and also with some OSIS subtype attributes
            documented elsewhere,<br>
            xulsword modules are wholly compatible with the SWORD API.<br>
            <br>
            Other front-ends simply ignore these things.<br>
            <br>
            <br>
            David<br>
            <br>
            <br>
            <br>
            --<br>
            View this message in context: <a moz-do-not-send="true"
href="http://sword-dev.350566.n4.nabble.com/Strong-tagging-and-Septuagint-tp4651344p4651946.html"
              target="_blank">http://sword-dev.350566.n4.nabble.com/Strong-tagging-and-Septuagint-tp4651344p4651946.html</a><br>
            <div class="HOEnZb">
              <div class="h5">Sent from the SWORD Dev mailing list
                archive at Nabble.com.<br>
                <br>
                _______________________________________________<br>
                sword-devel mailing list: <a moz-do-not-send="true"
                  href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
                <a moz-do-not-send="true"
                  href="http://www.crosswire.org/mailman/listinfo/sword-devel"
                  target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
                Instructions to unsubscribe/change your settings at
                above page<br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
    </blockquote>
    <br>
  </body>
</html>