How to create cross-links within the glossary?

Scripture App Builder
1

I have learnt here
https://support.paratext.org/t/how-do-i-create-a-clickable-link-in-an-xx-book/2920
that presently Paratext does not support linking “out” of the “extra books” nor within the extra books.

Still I hope to find a hack or some idea in SAB how we can help our readers when one glossary entry is sending him to another glossary entry.

(If you want a why, please write me directly. Here is a quick summary: every encyclopedia does this, there is always “further reading” on anything. In our case, the grammar even needs it, because the singular and plural of nouns are not listed next to each other. So for example somebody has browsed to “s_locust” and he is being told there that the main entry is under “pl_locusts”.)

It would be muchly fitting in an app in 2019 if a cross-reference could also be a clickable link.
Our glossary entries are well structured and we could jump to the headwords \k Headword\k* if the logic would support that. I have already tried to place anchors/links in the glossary like \w Please read more at Headword|Headword\w* but no joy.

Since the linking does work from the main text, I believe that technically this can be done, even if the glossary is not structured by chapters and verses.

For the moment, I would be willing to use a hack, waiting for this to become a real feature eventually. Your ideas are welcome please.

2

I did some work on this.

You can add in Markdown style hyperlinks into your Glossary items. BUT those links do not work in the popup.

If you construct your glossary with chapters and verses and add \cp A after \c 1 for chapter one and also add a verse number for each glossary entry.

\m \v 1 \k adore\k* ...

Then you have a way of referencing each glossary item from the relevant word. In the resultant popup the link still does not work but you have the option to go to the Glossary entry and there the link to another Glossary entry will work. Not perfect but better than the existing.

The down side is it breaks your USFM. Unless you construct a lot of changes to adjust all the \w words to the Markdown form with links.

1 Like
3

Great, thank you! I had to go through several challenges:

  • I could not find the syntax for the Markdown style hyperlinks, so had to guess from the section 5.5 on audio clips and from the section 16.2 on Deep linking. It is working like this for us: Write a label to the user in square brackets The target is book.chapter.verse.

  • We just had removed all our verse-numbers when we started this app project, because the normal callers \w specialword\w* seem to break, when the glossary items are preceded by a verse marker.

  • Also we do not want to show any dummy verse markers in the glossary, so it will need some styles-hack (use background color?). Solutions which need a complex bundle of hacks have their place but are not nice for supporting and updating and sharing with colleagues…

  • The good news is that this new type of link is bringing up a pop-up of the wanted glossary item and it also shows an arrow top-right in the pop-up to actually take the main window focus there. So this is indeed promissing for reading the main text and looking up stuff and also for nerd-users who enjoy browsing the actual glossary and want to follow the cross-links there. Clicking twice is much better than manually navigating between entries.

Now we need to see whether this is “main stream” enough for us to convert all our \w thingy\w* to thingy. To acutally use this, I would need to write a script which pulls the “chapter” and “verse” for each citation form and then transmogrifies the hundreds of markups in our main text.

Have to sit down and think about possible side effects too. But thank you again for showing how it can be done. We have a deadline to publish before Christmas, and still need to do the artwork. I have a hunch that this is something we will use in our next Scripture app.

4

I had an idea how to use your new idea and the existing links \w … \w* from the main text:

Instead of placing the dummy verse numbers right in front of each glossary entry, I place them one line above into a separate paragraph:

\c 1
\cp A
\p \v 1
\p \k adore\k* To like mightily

…

\c 22
\cp W
...
\p \v 40
\p \k worship\k* To like muchly and often with music; ⇒ [adore](glo.1.1)

This works!
When a user clicks on the link, a popup opens for “verse 1 in chapter 1” but the entry for adore is fully visible with that. And there is a “go there” button in the popup. So users can go all the way to “adore”, if they are interested, or keep reading about “worship” once they had a glance at “adore” .

Then I invented some styles-tweaks to hide the dummy verses:

  • The popups use the default style, so I hide the verse numbers by having the default VerseNumberColor the same as FootnoteBackgroundColor (which is for the glossary popups). (A few days ago I had the idea to give some color-background to our pop-ups so it is more obvious to new users that they are dealing with a pop-up and they can more easily close them too.)
  • In the actual glossary book I hide the verse numbers by a custom style, same as the text background color
  • In the scripture books I do not hide the verse numbers by a custom style: VerseNumberColor as before

Now we can leave all the hundreds of anchors in our scripture text untouched and they work still. And we just have to edit a few dozen anchors into our glossary book, where we want those cross-links. I believe I can do that tomorrow, in time for publishing before Christmas.

So again, many thanks for having figured out this new linking-system with dummy verses!

5

Reporting from a real-life experiment: it works.

We are preparing a SAB-app for a portion of the NT. Target audience does not know Scripture, so we have got some 280 glossary entries for this portion. Within that glossary, we have some 45 cross-links, which point to other or main entries in the glossary.

Adding an extra line for a dummy verse and filling out sequential verse-numbers took one regex and some editing in a power-editor, some 10 minutes in total.

Then converting our 45 cross-references took another regex which semi-automatically converted the old print-only references from ⇒ angels to ⇒ [angels](glo..) which took several runs, because some links are in the middle of text and some are multi-word-headwords and some of those had \em … \em* markup.

Then I created a condensed lookup-sheet for chapters and dummy-verses (3 minutes); put that on my second monitor, and went through the glossary and filled out the actual target chapter and verse respectively. The entire process took well under one hour and some of that was figuring out the procedure.

We now have an Android app where users can easily follow the links in the glossary. Joy! So far our glossary-links were confusing to new users, because a non-clickable link inside an app, where there are working links in the main text section, are “unexpected behavior”.

I found some mild “bug” in SAB in this context:

I cannot tell, whether this bug existed before, because, coming from PT8, we had used \x … \x* references, and those had created actual crashes. So during app-development we had learnt, never to click on links in the glossary. Now those have gone and I have converted them to the new Markdown style. And I can report that the links also work from the glossary towards scripture-text. But having solved all that, we have noticed a “new” problem:

Since this is an app for only a portion of the NT, we have some “text only links”, where for example we refer to not-included books in French-style text form: In Francophone context, a reference is printed like Luc 15.22 so chapter dot verse.

Now SAB is taking such mentions in our text as links too!! There is no markup, no brackets, nothing just 15.22 gets turned into a “local link” and is marked blue and when a user would click on that (out of curiosity) then the pop-up is proposing chapter 15, verse 22 in the glossary [sic], not in Luke.

Update: Just noticed that even other “naked” mentiones like 20-40 or 2000—3000 get turned into local links. In Francophone use, Luc 12—18 means Luke, chapters 12 to 18 but SAB is turning that into a glossary link to chapter 12, verse 18!

Since many people in the world are francophone, I believe the mention of Any-book chapter.verse should not unwantedly create an unhelpful local link to now-open-book chapter.verse.

For today I made an “ugly fix” by including zero width spaces into each text-only chapter.verse for exampel 15.12 like 15ZWSP.ZWSP12 and now such references do not get treated as links any more my SAB and they look just the same to the users.

I do not want to focus on the new mild bug today, I mainly wanted to share our joy and the procedure on how we have created our first-ever cross-links in our glossary. hth and thanks again @mcquayi for the idea

6

It has been a few months since we published, which was just before Christmas.

Now we have learnt to really like the cross-links between entries of our glossary, using your idea and my above-explained procedure.

It happened that we had other work and as we get back to our app, we got frustrated that the blue links inside our glossary-popups do nothing. In fact I had to come here again, trying to figure out what is happening. We had just forgotten that our links only work inside the glossary but not in the popups.

So you had “promissed” that links in popups would not work, and you were right.

Now I submit a feature request, asking please that such links in glossary popups can also work as expected in a not-too-distant version.

Imagine you read a portion of text where “not drinking wine” is just mentioned for somebody. The direct glossary popup could explain that abstaining from alcohol is a Biblical concept with certain meaning etc etc and then could link to further glossary entries about “wine”, “Samson”, “Nazirites” etc.

This requested feature would help new users, who have no Biblical training nor other study ressources available in their context.

7

If it is a feature request then make it a new post or it will get lost in this thread.