Text View Mode highlighting problem

[ayya-vimala]

I've been thinking about the logic for the text-view.

1. Click on any part of the text in the left column, highlights the part where you clicked active_segment and active_segment_index are set and the middle view column opens with the details of the matches for the clicked part.

2. Hovering over a middle view item (I'll call it 'match-card'), highlights the text in the left with a black background. Right now that background disappears as soon as you move away from that match-card. Is there a way to allow it to stay (and make it a more subtle grey or other color) until you hover over another card or reload the page/column?

3. Clicking on a match-card opens the right column and scrolls to the selected segment.
   Here it becomes more complex as we don't know what to highlight! So I want to rubber-duck it!

On the left and right sides, the data that comes back has the following form:

    {
      "segnr": "PA_dn_1:1.0",
      "segtext": [
        {
          "text": "1. Paribbājak",
          "highlightColor": 0,
          "matches": []
        },
        {
          "text": "a",
          "highlightColor": 2,
          "matches": [
            "PA_dn_1:1.0_PA_ps_1.4:0.3",
            "PA_dn_1:1.0_PA_ps_2.10:0.3"
          ]
        },
        {
          "text": "kathā",
          "highlightColor": 3,
          "matches": [
            "PA_dn_1:1.0_PA_ps_1.4:0.3",
            "PA_dn_1:1.0_PA_ps_2.10:0.3",
            "PA_dn_1:1.0_PA_ps_3.9:0.3"
          ]
        }
      ]
    },

This example is of one segment with 3 parts (so three potential "active_segment_indexes").

When clicking on the left for instance on the word-part "kathā", it requests the three matches:

[
"PA_dn_1:1.0_PA_ps_1.4:0.3",
"PA_dn_1:1.0_PA_ps_2.10:0.3",
"PA_dn_1:1.0_PA_ps_3.9:0.3"
]

from the backend middle view it returns for each of them something like this:

  {
    "id": "PA_dn_1:1.0_PA_ps_1.4:0.3",
    "par_segnr_range": "PA_ps_1.4:0.3–1.2",
    "par_segnr": "PA_ps_1.4:0.3",
    "display_name": "Indriyakathā",
    "tgt_lang": "pa",
    "par_segtext": [
      "1.4. Indriyakathā",
      "Evaṁ me sutaṁ—",
      "ekaṁ samayaṁ bhagavā sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme."
    ],
    "filename": "PA_ps_1.4",
    "score": 100,
    "length": 40,
    "par_fulltext": [
      {
        "text": "1.4. Indriy",
        "highlightColor": 0
      },
      {
        "text": "akathā Evaṁ me sutaṁ— ekaṁ samayaṁ bhagavā ",
        "highlightColor": 1
      },
      {
        "text": "sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme.",
        "highlightColor": 0
      }
    ]
  },

and displays them in the middle column.

(We can change this if needed to return par_segnr as an array rather than a string, so including ALL the segment numers between PA_ps_1.4:0.3 and PA_ps_1.4:1.2 as the range indicates)

When looking at ArangoDB parallels, it has the following information for the parallel with the above id (see screenshot):

So there it has the information we need: It has the par_offset_beg and par_offset_end and the par_segnr array.

From that, in a similar way as the current calculations for the middle view, the text-view/middle can start to give back info like this:

  {
    "id": "PA_dn_1:1.0_PA_ps_1.4:0.3",
    "par_segnr_range": "PA_ps_1.4:0.3–1.2",
    "par_segnr": [
      "PA_ps_1.4:0.3",
      "PA_ps_1.4:1.1.1",
      "PA_ps_1.4:1.1.2"
      ]
    "display_name": "Indriyakathā",
    "tgt_lang": "pa",
    "par_segtext": [
      "1.4. Indriyakathā",
      "Evaṁ me sutaṁ—",
      "ekaṁ samayaṁ bhagavā sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme."
    ],
    "filename": "PA_ps_1.4",
    "score": 100,
    "length": 40,
    "par_fulltext": [
      {
        "text": "1.4. Indriy",
        "highlightColor": 0
      },
      {
        "text": "akathā Evaṁ me sutaṁ— ekaṁ samayaṁ bhagavā ",
        "highlightColor": 1
      },
      {
        "text": "sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme.",
        "highlightColor": 0
      }
    ]
   "par_highlight": [
        {
        "segnr": "PA_ps_1.4:0.3",
        "segtext": [
          {
            "text": "1.4. Indriy",
            "highlightColor": 0
          },
          {
            "text": "akathā",
            "highlightColor": 1,
          }
        },
        {
        "segnr": "PA_ps_1.4:1.1.1",
        "segtext": [
          {
            "text": "Evaṁ me sutaṁ— ",
            "highlightColor": 1,
          }
        },
        {
        "segnr": "PA_ps_1.4:1.1.2",
        "segtext": [
          {
            "text": "ekaṁ samayaṁ bhagavā ",
            "highlightColor": 1,
          },
          {
            "text": "sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme.",
            "highlightColor": 0
          }
        }
      ]
    ]
  },

Alternatively, this information can be derived at the frontend if the backend gives back a par_segnr as an array.

To illustrate this:, if we have:

    "par_segnr": [
      "PA_ps_1.4:0.3",
      "PA_ps_1.4:1.1.1",
      "PA_ps_1.4:1.1.2"
      ]

and

    "par_segtext": [
      "1.4. Indriyakathā",
      "Evaṁ me sutaṁ—",
      "ekaṁ samayaṁ bhagavā sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme."
    ],

and

    "par_fulltext": [
      {
        "text": "1.4. Indriy",
        "highlightColor": 0
      },
      {
        "text": "akathā Evaṁ me sutaṁ— ekaṁ samayaṁ bhagavā ",
        "highlightColor": 1
      },
      {
        "text": "sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme.",
        "highlightColor": 0
      }

We can derive from there that the first segment par_segnr[0] matches with par_segtext[0] so PA_ps_1.4:0.3 = "1.4. Indriyakathā". Then looking at the par_fulltext we see that the first part of this match has highlightColor: 0 (1.4. Indriy) and the second part has highlightColor: 1 (akathā).

For the next one par_segnr[1] and any potential following ones except the last one (in this case par_segnr[2]) everything has highlightColor: 1.

For the last one par_segnr[2] the highlightColor: 0 for sāvatthiyaṁ viharati jetavane anāthapiṇḍikassa ārāme.

So I see a number of options here that should be doable.
This can than work from left to right and right to left.

I would also like active_segment_index to be ONLY used for when someone clicks on a segment in the right or left column and that segment-part can be made bold.

Then I'd prefer not to use bold for the other highlighting as it has a different function. The other highlighting can be a subtle background color behind the text.

Let me know what you think.

[TrebuhD]

Thank you for opening this discussion @ayya-vimala , let's brainstorm and I'm sure we can figure something out. I'll respond to some points in the meantime:

Hovering over a middle view item (I'll call it 'match-card'), highlights the text in the left with a black background. Right now that background disappears as soon as you move away from that match-card. Is there a way to allow it to stay (and make it a more subtle grey or other color) until you hover over another card or reload the page/column?

Yes, it's very easy to do.

As for your main idea, I like it. My suggestion would be to use the par_segnr_range property for this. par_segtext is not even used on the FE.

From that, in a similar way as the current calculations for the middle view, the text-view/middle can start to give back info like this [...]

This example is not completely clear to me, and it seems to contain some duplicated data. I think we should try to describe a minimal example and remove any redundant properties that wouldn't be needed anymore with this approach.

How does the FE determine what to highlight in this approach, on a low level? Can you try to describe it with pseudocode? Are you proposing to do a string comparison?

I don't understand the addition of highlightColor to this middle view response. Do you want to color the matches in the middle view? The left/right panes already have this color data. Or is this a way to compare the data somehow? Or do you want to make the black background highlight state colorful?

I would also like active_segment_index to be ONLY used for when someone clicks on a segment in the right or left column and that segment-part can be made bold.
Then I'd prefer not to use bold for the other highlighting as it has a different function. The other highlighting can be a subtle background color behind the text.

This makes sense, but it's going to complicate some logic on the FE side. We would probably have to introduce a persistent state variable other than active_segment. When this new variable gets updated, the page should scroll to this bit of text. Then there's probably potential to run into conflicts if both this variable and active_segment are set. But let's discuss.

[sebastian-nehrdich]

I will now try to explain what we did on the old frontend and why did it that way.
First of all, we have a basic problem with all matches, and that is that they are not strictly reversible. Why is that the case?
We use vectorization and nearest neighbor search in order to determine matches. If you look at this example of such a graph:

You will see that the nearest neighbor to A is C, while the nearest neighbor to C is not A, but E. in high-dimensional vector spaces with billions of points this problem is much more common than this graph might indicate but I hope you get the gist. When we search for matches, we can only look at a fixed max. number of candidated before we stop the search, otherwise it would be computationally too intense.
Now one might say: OK but we can just reverse all matches in the database after generation and make sure they exist both ways. We sure can do that.
But he we hit another problem: Even after generation, when collecting matches into the database, we need to once again set a max. depth that we allow for each segment to have matches because otherwise we will collect terabytes of data that is of little interest. This is what the co_occ value is used for, and it makes sure that we don't store matches that are seen more than for example 50 times in the database. Once matches grow beyond that, they are dropped, and this means that the reversibility of the matches is lost. It would, in theory, be possible to tie the drop decision to the reversibility of the matches but this is computationally a nightmare and provides little benefit to the users.
So how did we do it on the old site then, because things seem to have worked just fine there?

  async handleParallelClicked(e) {
    const [data, rightMode] = e.detail;

    const selectedParallels = data.getAttribute('parsegments').split(';');
    selectedParallels.pop();
    const startOffset = parseInt(data.getAttribute('paroffsetbegin'));
    const endOffset = parseInt(data.getAttribute('paroffsetend'));

    if (rightMode) {
      this.fileName = selectedParallels[0]
        .replace(/_[0-9][0-9][0-9]/, '')
        .replace(/:.*/, '');
      this.leftTextData = {
        selectedParallels,
        startoffset: startOffset,
        endoffset: endOffset,
      };
    } else {
      this.renderSwitchButton = true;
      this.rightFileName = selectedParallels[0]
        .replace(/_[0-9][0-9][0-9]/, '')
        .replace(/:.*/, '');
      this.rightActiveSegment = selectedParallels[0];
      this.rightTextData = {
        selectedParallels: selectedParallels,
        startoffset: startOffset,
        endoffset: endOffset,
      };
    }
  }

The old website calculated all the highlighting on the frontend, and therefore didn't have to deal with segments and match_ids in the same way that the new website does. One advantage of that is that we could just sneak in the match data from the middle-view with the offset values into the click event as the above code snippet shows. In this way we could make sure that the website always showed the precise boundaries of the match on both right hand side and left hand side.

Given the current data that the frontend receives from the backend, it is NOT possible to give a precise highlighting of the match on the right hand side. And given the fact that we moved the entire color map code to the backend, its also not trivial to add it.

The best solution that I can come up with is that we add an optional "active_match_id" property to the text-parallels endpoint. So when the user clicks on a given match in the middle view and the right hand view is triggered accordingly, we submit the query with the id of the match that the user clicked on and the backend will sort out to add this match with the proper highlighing to the backend return. The frontend then only has to iterate over the matches values of each segment on the right side and highlight those that contain the match id. no further logic about reversing ids etc. are needed on the frontend then.

I would also like active_segment_index to be ONLY used for when someone clicks on a segment in the right or left column and that segment-part can be made bold.

I am actually not in favor of highlighting this at all. The reason for this is that active_segments do not correspond to matches and its actually misleading to highlight these (its a problem that we have for some months/years on the new page).
The different sub-segments for a given segment number in the text view are purely determined on color alone.
So when a match ends at a given position and another match starts at the same position, this will be shown as ONE sub-segment even though it consists of two different, not overlapping matches. I think any form of highlighting of this unit with bold or other ways will irritate the users since these units unfortunately don't correspond to anything meaningful: they don't correspond to the segments as recorded in the database, and they don't correspond to matches either. My suggestion is to drop subsegment highlighting and to either highlight nothing at all or to highlight the whole segment.

[ayya-vimala]

@sebastian-nehrdich - Thanks for explaining and for the discussion yesterday. I understand what it is you want to do. I was wondering if you would like me to have a look at it and start this or if you would like to do it yourself, considering that you are mega busy. I think it is probably not so complex.