Generic and Dewey call number normalizers should sort volume numbers numerically, not asciibetically
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Consider three volumes on the same bib with the following call numbers:
234.54 ABC vol. 1
234.54 ABC vol. 2
234.54 ABC vol. 10
Using the generic normalizer, the label_sortkeys would be
234.54 ABC VOL. 1
234.54 ABC VOL. 2
234.54 ABC VOL. 10
Using the Dewey normalizer, the label_sortkeys would be
234_54000000000
234_54000000000
234_54000000000
In both cases, the effective sort order is:
234.54 ABC vol. 1
234.54 ABC vol. 10
234.54 ABC vol. 2
which is not ideal.
What I think the desired behavior is:
[1] In the case of the Dewey normalizer, groups of numbers that occur after the main classification number should be left-zero-padded.
[2] In the case of the generic normalizer, all numeric tokens should be left-zero-padded.
Evergreen master
Changed in evergreen: | |
milestone: | 2.4.0-beta → 2.4.0-rc |
Changed in evergreen: | |
milestone: | 2.4.0-rc → 2.5.0-alpha |
Changed in evergreen: | |
milestone: | 2.5.0-m1 → none |
Or call number normalization routines could normalize call numbers
according to their classification definitions, as they're doing now,
and suffixes like "Vol. 10" that don't belong to the call number
proper could either be added as a call number suffix (now that we've
had that option for a year or so on a per-call number basis), or they
could be catalogued as parts (which we have also had for a year or
so).