| Summary: | Add Publication Date Facet in Searching | ||
|---|---|---|---|
| Product: | Koha | Reporter: | David Cook <dcook> |
| Component: | Searching | Assignee: | Galen Charlton <gmcharlt> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | barbara.johnson, fridolin.somers, Laura.escamilla, mathsabypro, michaela.sieber, pierre.genty, roman.dolny, severine.queune |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8026 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26839 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33666 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36437 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
David Cook
2013-08-15 05:14:18 UTC
Hi David, the publication date range search on the advanced search page I think is based on 008 Date1 - so using 008 for the facet would make sense to me. (In reply to Katrin Fischer from comment #1) > Hi David, > > the publication date range search on the advanced search page I think is > based on 008 Date1 - so using 008 for the facet would make sense to me. Good point. I wonder how we should handle dates like uuuu or 190u or 19uu. Maybe it makes sense just to include definite completely numeric dates? Or maybe do a label for uuuu like "Unknown" and change the u to a question mark for other cases like 190? or 19??, perhaps? I wrote a little TT plugin a while ago to change codes into nice labels for the facets, which I think I mentioned to you, but the problem was that it had hardcoded strings :/. Is there a way of maybe using the "language_descriptions" table to use translated strings? We would run into the same problem with a record type facet. Actually...with record type...we could probably use authorized values like we have for item type and shelving location. I suppose that's not hardcoded but I suppose that probably still presents translation issues. Any ideas? > Good point. I wonder how we should handle dates like uuuu or 190u or 19uu. > Maybe it makes sense just to include definite completely numeric dates? Or > maybe do a label for uuuu like "Unknown" and change the u to a question mark > for other cases like 190? or 19??, perhaps? I think the second would make a bit more sense to me. > I wrote a little TT plugin a while ago to change codes into nice labels for > the facets, which I think I mentioned to you, but the problem was that it > had hardcoded strings :/. Hm, not sure I remember. If the strings can be in an include or similar, we can translate them. > Is there a way of maybe using the "language_descriptions" table to use > translated strings? I think that would probably be the best option for a language facet. > We would run into the same problem with a record type facet. I think it is solvable especially when the options and descriptions you want to have are somehow limited by the standard. > Actually...with record type...we could probably use authorized values like > we have for item type and shelving location. I suppose that's not hardcoded > but I suppose that probably still presents translation issues. I always prefer template translation over using authorised values because the latter are one language only currently. Koha facets are a nightmare. And Marc21 facets are not the same as Unimarc... What we need is either a syspref or a specific page for configuring them (what index, what order for displaying them, etc.), so each library could add or suppress useless/useful facets. I've thought of that for ages, but I will try to code it in the next days. M. Saby By the way, I think the most usefull missing facets are - date of publication - language of publication M. Saby I have a plan to improve facets. Could you please take a look and comment the bug if you have any remarks? http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10891 M. Saby This is still needed... We should add this facet at least for Elasticsearch where it can be configured and disabled via staff interface. (In reply to Fridolin Somers from comment #8) > We should add this facet at least for Elasticsearch where it can be > configured and disabled via staff interface. +1 ! *** Bug 26839 has been marked as a duplicate of this bug. *** Being able to limit search results by publication date would help our patrons as well as staff who are assisting them. This is really needed. (In reply to Barbara Johnson from comment #11) > Being able to limit search results by publication date would help our > patrons as well as staff who are assisting them. This is really needed. +1 We agree! *** Bug 33666 has been marked as a duplicate of this bug. *** We've added this locally for Zebra. At some point I'll look at upstreaming it. We might look at some related date facet changes too... This would be a great feature to have! (In reply to Laura Escamilla from comment #15) > This would be a great feature to have! It will be possible to have something that comes close with the new configurable facets. We still might want to give this more thought as we might want a nicer presentation than a list of years for the user to limit on. |