OPAC: grammatical error in patron hold status display

[Jim Keenan]

Evergreen 2.5 and forward.

The code in hold_status.tt2 allows for a grammatical error to appear when there are multiple holds on an item.

To see the error, log into the OPAC. You must have a hold on an item for which multiple holds already exist. When you look at the Holds tab, under Status, you see "x hold of y circulating copies". With multiple holds on the item, this will show up, for example, as "5 hold on 15 circulating copies" instead of "5 holds on 15 circulating copies".

[Jim Keenan (jkeenan)]

working branch is available at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=72cfb1774423563df3cd97736dcdca82ad76222a

[Galen Charlton (gmc)]

The patch looks mostly OK, but by adding back the word "circulating", it adds a regression on bug 1316814. Would you be willing to revise the patch so that it just fixes the singular/plural issue?

[Michele Morgan (mmorgan)]

In the display "x hold on y copies”, “x” actually refers to the patron’s queue position, not the number of holds on the title. Baggage related to displaying queue position here not withstanding, the plural on "hold" really isn't appropriate. Perhaps a better tweak would be to change the word order to “hold x on y copies".

[Galen Charlton (gmc)]

Indeed. A variable called total_holds is also available, so that could be used instead of the queue position.

For reference, in the JS OPAC, the corresponding message used to be:

hold # ${0} of ${1} total holds and ${2} potential item"
plural: "hold # ${0} of ${1} total holds and ${2} potential items"

where 0 = queue position, 1 = total holds on the current copy, and 2 = number of items that could fill the holds.

[Scott Thomas (scott-thomas-9)]

This is causing customer service problems for us. Can someone provide an update on a fix for this? Thank you.

[Kathy Lussier (klussier)]

I can take a stab at this one, but it would be good to get consensus on the language that we use.

Michele's suggestion is:

hold x on y copy/copies

A variation of the old JSPA message could be:

hold # x of y potential item/items (or we could use copies here)

What do people prefer?

[Chris Sharp (chrissharp123)]

Whichever variant is chosen, I think we should stick with the term "copy" or "copies". While trained librarians understand that they are equivalent, changing that would probably confuse end users who are used to seeing "copy"/"copies" in the OPAC.

[Kathy Lussier (klussier)]

Another possibility is

hold # x of y copy/copies

[Jim Keenan (jkeenan)]

I'm okay with hold # x of y copy/copies

[Michele Morgan (mmorgan)]

Hmm, shouldn't the preposition in the proposed phrase be "on" rather than "of"?

hold # x on y copy/copies

That works for me.

[Kathy Lussier (klussier)]

Working branch available at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1554714-hold-count-grammar-fix

Based on a comment from bshum in IRC this morning, I'm going to target to 2.next for now, but I'm hoping the 2.9 and 2.10 release managers would consider backporting this as a bug fix.

I know there are issues with making string changes between releases, but, at the same time, this is clearly a grammatical error, and, in its current form, it isn't really clear what the string is saying. If I were a patron, I would likely interpret the string as saying that there are 5 holds on this copy, when it really is identifying the queue position. That's giving end users the wrong information.

If the release managers determine it needs to be a new feature, I can write up an associated release notes entry.

[Kathy Lussier (klussier)]

Assigning targets to 2.10 and 2.9 so that it doesn't get lost.

[Andrea Neiman (aneiman)]

In testing for this one I noticed that "hold # x on y copy/copies", the x is the number of targeted holds ahead of you. I.e. I tested this on Fiske's Beethoven (bib ID #28 in Concerto/MOBIUS test server). There was 1 existing untargeted hold on it. I placed 4 more holds under various patrons, and in the OPAC they were respectively hold #1 / hold #2 / hold #3 / hold #4. Then I re-targeted the existing hold and everyone was pushed back a queue position in the OPAC -- so my 4 were now hold #2 / hold #3 / hold #4 / hold #5 and the newly retargeted hold was hold #1.

If someone can confirm that this is indeed expected behavior, I will add my signoff since nothing else seemed amiss, however I wanted to double check since there were customer service issues noted above and this sort of position adjustment may cause an eagle-eyed patron to ask why they were moved back :)

Thanks!
ABN

[Kathy Lussier (klussier)]

I'm removing the pullrequest tag now while I take a closer look.

Thanks Andrea!

[Kathy Lussier (klussier)]

I think I know what's happening here. Andrea came across two issues: the one described in comment 13 and another she described to me in IRC where the total potential copies was displaying as 0.

I believe the issue is that the test server isn't running the holds targeter. The existing hold was one that was loaded with the Concerto dataset and never had an opportunity to go through the targeter. The subsequent holds were automatically targeted when the holds were placed. When Andrea retargeted the initial, untargeted hold, everything else shifted down because that existing holds was placed first. It also explains why we were seeing zero potential copies. I don't think we would see the shifting holds in a production environment where the holds targeter is running on a regular basis.

I'll load this on a MassLNC VM and send the access information along to Andrea to see if it resolves the issue.

Re-adding the pullrequest tag.

[Andrea Neiman (aneiman)]

OK! Everything is much more normal when the holds targeter is running :)

I have tested this code and consent to signing off on it with my name, Andrea Buntz Neiman and email address, <email address hidden>

[Mike Rylander (mrylander)]

Pushed to master for 2.11. Thanks, Kathy!

[Mike Rylander (mrylander)]

And now also to 2.10 and 2.9.