https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Mark Hofstetter <mark@hofstetter.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net --- Comment #2 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Some things to hopefully be able to test: 1: try to get a library with lot of Arabic script and another with Chinese or Japanese script to confirm that the diacritics handling is not worse than with Zebra. 2: That the relevancy of results doesn't take a hit 3: And that they won't miss ICU. I don't know if it's common to type transliterated versions of words. Like in public and university libraries in these countries, doesn't almost all PCs there have input methods that can type the local script directly? If ICU is mostly needed in multilingual organizations (Goethe-Institut or BULAC types) then it's much less of an impact. (they are more likely to use ES anyway) If there are some regressions, is there a way to have a configuration for some additions transliteration. Like it's possible for Zebra in some config file. If I got mixed up the concepts above, the idea is to check that the most common types of libraries won't get penalized just because they don't use a Latin based script. ---- Fred Somers told me that we have something for ISBN to find 978-1-250-77774-4 the same as 9781250777744 No showstopper risk. Just something to not forget to implement. --- And how far the search scales with the number of bib records and items. (with 2 or 3 concurrent searches) Like with 500 000 or more records to have a comfortable margin wit -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens (kidclamp) from comment #1)

We should introduce a new pluggable/flexible template for processing search results that we can then port ES to, rather than continuing to build on the original Zebra only base and adding exceptions (kill C4::Search)

Oh now you're speaking my language *drool* -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 --- Comment #5 from Mark Hofstetter <mark@hofstetter.at> --- Thx for the feedback I would like to have very specific "search queries" with what (and why!) should be found, then we can try to emulate this behaviour. We are still investigating if this can be a viable route, it's not a set fact -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.