We should wrap the kwicTruncateString in a span with a class

[martindholmes]

...so that people can easily style or otherwise manipulate it.

[martindholmes]

It will make our stem files bigger though...

[martindholmes]

This is slightly complicated by the fact that the hcmc:returnSnippet() function adds the kwicTruncateString as part of its return value, which is a string. Options are to rewrite that function so it returns a sequence of a string and an optional span, or to intervene later, in the hcmc:returnContext() function, which concatenates the whole context string, marking up the hit word. We could at the same time mark up the kwicTruncateString using <xsl:analyze-string>. I'll create a branch issue-321-trunc-string and try that.

[martindholmes]

First shot at this shows that it's going to be pretty awkward to manage. The problem is that these tags end up in the JSON stem file as string values, and they seem to be affecting the way phrasal searches are scored, so the tests are breaking. If we can't think of a simpler way to do this, it should probably be punted to 2.1.

[martindholmes]

@joeytakeda Are you OK with punting this to 2.1? Nobody's actually asked for it, and it turns out to be quite complicated because of the way we've set up the handling of KWICs.

[martindholmes]

Pushing to 2.1.

[joeytakeda]

One option could be to make the KWIC string an object of some sort that would specify each part of the KWIC string so that it can be easily constructed during the results:

{
 "pre": "one two",
 "term": "three",
 "trunc": "...",
 "post": "four five"
 }