I'm not sure this is an issue with the ThML converter. From using mod2imp,
we have
Mat 1.9:
$$$Matthew 1:9
οζιας δε εγεννησεν τον ιωαθαμ ιωαθαμ δε εγεννησεν τον * αχας | αχαζ | 881 {N-PRI} | αχας αχαζ 881 {N-PRI}*δε εγεννησεν τον εζεκιαν
Mat 9.4 outputs the seg with tags in them. Mat 1.9 outpu
I noticed this a few weeks ago. We should change JSword's ThML converter to
output OSIS as is used in Byz and WHNU. And the xslt to handle it.
When I did the original, there were not any variants in an OSIS text.
In Him,
DM
On Feb 8, 2013, at 1:09 PM, Chris Burrell wrote:
> Hi
>
> Is
Hi
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 H and LXX uses G. If you're
looking at several texts in interlinears, it simply looks like there is a
b
For OSIS, the only values to indicate Strong's Numbers are:
GlobalOptionFilter=OSISStrongs
and
Feature=StrongsNumbers
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
The form in Byz and WHNU are what we've settled on for OSIS.
If we find something else in an OSIS module, then we probably should log it in
Jira.
In Him,
DM
On Feb 8, 2013, at 1:09 PM, Chris Burrell wrote:
> Hi
>
> Is there are standard subType pattern that modules are supposed to fo
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 indic
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
Hi
I have a second question, slightly unrelated hence the separate thread, on
the contents of the variants. In some instances two variants show an
"either/or" (e.g. Mat 9.4 WHNU/Byz). That is, by not displaying either of
the variants we effectively end up missing a word in the text.
Unfortunately
Hi
Is there are standard subType pattern that modules are supposed to follow?
It seems Byz and WHNU are using x- where n is the variant number.
αχας | αχαζ | 881 {N-PRI} |
αχας
αχαζ
I'm seeing some code taken originally from BibleDesktop which suggests
subType can be x-class-1 ?
A pos
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?
Chris
On 8 February 2013 15:12, David Haslam wrote:
> Our
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 from
an Av11n translation)
get interpreted as if they were Stro
Indeed, although looking at the MOD-230, this would only help fix your
issue if the Finish module doesn't also contain strong numbers!
Chris
On 8 February 2013 13:13, David Haslam wrote:
> Chris makes an important point.
>
> A few weeks ago, it was discovered that our Finnish modules contain
Chris makes an important point.
A few weeks ago, it was discovered that our Finnish modules contain tags
that our software interpreted as linguistic markup, but that were an
artifact from something else.
See http://www.crosswire.org/tracker/browse/MOD-230
David
--
View this message in context
Indeed we do, but that implies one has to read the module content to work
out which set of Strongs is used. Ideally you should be able to tell
without consulting the book contents. For example, I display which features
are available to the user while they pick the version from a dropdown.
Chris
I believe we preface strongs numbers with G or H to differentiate.
Chris Burrell wrote:
>Hi
>
>I haven't had any responses to this. I'm considering hard-coding the
>values
>in STEP to ensure I'm not trying to match tagging across versions that
>have
>a different type of mark-up.
>
>Let me know
Hi
I haven't had any responses to this. I'm considering hard-coding the values
in STEP to ensure I'm not trying to match tagging across versions that have
a different type of mark-up.
Let me know if there is appetite for doing this in a slightly more formal
way?
i.e. the Sword conf files should
16 matches
Mail list logo
