[sword-devel] GlobalOptionFilter=OSISNamesBold
pinoaffe
pinoaffe at gmail.com
Fri May 30 06:13:57 EDT 2025
(resending yet again due to delivery failure)
Hi,
David Haslam <dfhdfh at protonmail.com> writes:
> I wish to propose a new SWORD configuration key,
> GlobalOptionFilter=OSISNamesBold, to enhance digital Bible displays by
> rendering proper names (tagged as in OSIS XML) in bold. This feature
> would improve readability for Bible students, particularly in
> unicameral scripts like Thai, Chinese, or Hebrew, where capitalization
> isn’t available to distinguish names.
> With the help of Grok (x.ai) I have explored this idea using Hosea 1
> from both the KJV and ThaiKJV, bolding names like Hosea, LORD, and
> Israel (KJV) or โฮเชยา, พระเยโฮวาห์ (Thai). Such a filter would need to
> apply CSS font-weight: bold to tags, making names visually distinct in
> front-ends. For unicameral languages, this addresses the lack of
> uppercase cues, as demonstrated in Thai (where spaces are minimal)
> with a ZWSP workaround for adjacent names possibly due to a
> MarkdownViewer++ bug.
It sounds like emphasizing names could be useful, but I'm not personally
sufficiently familiar with any languages that use unicameral scripts to
judge whether that is useful in this case.
Furthermore, I think it might be better to just tag names in some html
class, e.g. <span class="name">Name</span> and leave the exact styling
or emphasis to external CSS - that seems like a cleaner separation of
duties.
> Aside: A key challenge for the KJV is disambiguating short words like
> “On” (a place in Genesis 41:45; a preposition elsewhere) and “No” (a
> place in Jeremiah 46:25; the negative determiner), which can be
> capitalized sentence-initially, risking mis-tagging. A robust name
> list and contextual rules (e.g., checking for geographical
> vs. grammatical roles) would be needed to avoid errors.
Why is this an issue? I assume this option would only apply to
OSIS-tagged names, so Sword does not need to distinguish between names
and other words: that's the module creator's duty.
> For details, see our discussion
> https://grok.com/share/bGVnYWN5_ebe228fc-db77-4801-b244-7335aad0da21
Please use your own brain rather than a glorified autocorrect /
predictive text engine.
> I also experimented with Unicode bold characters for names (e.g.,
> 𝐇𝐨𝐬𝐞𝐚) for platforms like Facebook, but CSS-based bolding is more
> reliable for SWORD.
IIRC those aren't available for many scripts, and are buggy even on the
latin alphabet. Furthermore, representing a character with a different
unicode character can cause issues with search and the like
> [ommitted]
> In order to test such a software enhancement we, would need to build a
> Bible module in which every name in the text was wrapped in the OSIS
> XML name element.
Wouldn't a module where *some* names are wrapped in the OSIS XML name
element be sufficient for testing?
> There is such a module called KJVX. It was being developed as an
> eXperimental version of the KJV module several years ago, but it's now
> out of date compared to the more recent updates to our flagship KJV
> module. I can send it to any developer upon request.
ah that's a shame, hopefully the
> Having seen Grok's capabilities, it's now not beyond the realm of
> possibility to automate the tagging of names in any OSIS XML file
> using the most suitable LLM AI agent.
Checking the LLMS output would be just as labor intensive as doing the
tagging manually, and in my humble opinion it would not be acceptable to
modify a module using an LLM without manually checking the output, and I
suspect that its output will be of really low quality in the cases of
the unicameral scripts you mentioned
In a language which capitalizes names, you could use a bible text search
to look for potential names and manually tag the ones that actually turn
out to be names - that might miss some occurrences of names (e.g. at the
start of sentences), but seems like less work than checking the output
of a LLM let loose on a bible XML file
Kind regards,
pinoaffe
More information about the sword-devel
mailing list