Time  Nick        Message
10:58 kados       paul_: around?
10:54 kados       is that what you mean?
10:54 kados       instead of just statuses
10:54 kados       and now it shows copies available at 'library 1 (count), library 2 (count), etc.', right?
10:53 kados       *nod*
10:52 hdl         Knowing there are 10 items with one checked out is helpless.
10:52 hdl         And your user wants to know if he can check out one book at his library.
10:51 hdl         When you have 20 libraries, France wide.
10:51 hdl         They would rather have the issued item pointed at result list than simply having a count
10:50 hdl         changes in result page are quite OK.
10:49 kados       (I remember you said there were some changes that they didn't like but I haven't gotten any specifics, so I'm flying blind :-))
10:49 kados       and ... can you confirm that the changes to the display in results for 'location' and 'callnum' conform to what your customers need?
10:48 kados       I still need to walk through the opac side and make sure all of the patches have been applied there as well
10:48 kados       hdl: can you verify that on the staff client all the bugs are resolved?
10:48 kados       hdl: I just pushed up the last few patches from my bugfixing of searches yesterday
10:48 hdl         yes
10:47 kados       hdl about?
10:06 lea         I've got a bit of a situation. About this time last year I was assessing Koha to replace our current proprietary system, but it wasn't quite ready yet. A lot of features were coming in V3. As a result, the boss decided to go with the proprietary vendors "online" product. It just doesn't work. He's now considering forking out £5K to a company called Talis. This sucks. So, given that scenario, what would you guys do? (Remember, our data is not fully Marc21, so there
10:03 lea         hi there
09:31 [K]         *** part FreeNode!#koha: aleix n=aleix@194.158.78.231
09:31 [K]         *** join #koha@FreeNode: aleix n=aleix@194.158.78.231
02:46 fbcit       ahh, it appears that control macros cannot be used inside of "recipes"...
02:42 fbcit       and which makes me wonder why I can't pass it in as a macro...
02:41 fbcit       which I read as meaning we cannot pass it in as an env var...
02:41 fbcit       This macro defines the maximum size of a single line of makefile input text. The size is specified as a number, the default value is defined internally
02:41 fbcit       MAXLINELENGTH
02:41 fbcit       gmcharlt: man page for dmake reads:
02:33 fbcit       I'm testing the pl_file shebang fix now
02:32 fbcit       s/ENV/ENV VAR/g
02:31 fbcit       I'll look at the ENV option
02:31 fbcit       gmcharlt: passing it in as a macro did not work... 'pears dmake parses Makefile prior to execution...
02:22 kados       yep, it is
02:22 kados       in the template
02:21 kados       I believe it comes through in the BIBLIO_RESULTS ... or I mean is expected
02:21 kados       but we do need a solution to subtitle in general
02:21 kados       that I noticed this issue from
02:21 chris       k
02:21 kados       well I just sent you a patch that has a decent workaround for the specific case
02:20 chris       yep
02:20 kados       pain in the butt though
02:20 kados       yea
02:20 chris       might be easiest just to add my $subtitle = GetSubtitle($record, $marcflavour);
02:19 kados       yea
02:19 chris       etc
02:19 chris           my $marcsubjctsarray = GetMarcSubjects( $record, $marcflavour );
02:19 chris           my $marcauthorsarray = GetMarcAuthors( $record, $marcflavour );
02:19 chris           my $marcnotesarray   = GetMarcNotes( $record, $marcflavour );
02:19 chris       my $record           = GetMarcBiblio($biblionumber);
02:19 chris       kados: in opac-detail.pl we have
02:15 russel      have the title in large print - subtitle smaller or not bold  etc
02:14 kados       unfortunately our frameworks don't allow that atm, do they
02:14 russel      you might want to do different formatting though
02:14 chris       good point
02:13 gmcharlt    that or tack on to biblo.title -- can't think of any time where you would want to display 245$a but not $b
02:12 kados       we may want to just add biblio.subtitle?
02:12 kados       so a direct mapping shoudln't hurt
02:12 kados       $b is not repeatable
02:12 kados       ideally it'd be called subtitle :-)
02:11 gmcharlt    is the idea to have these separate tables to avoid the hit of parsing the MARC XML every time?
02:10 chris       or get bibliosubtitle back
02:09 chris       so we can do the same for the subtitle
02:09 chris       as we get the subjects from marc
02:09 kados       yea
02:09 gmcharlt    mappings as in OPAC display?
02:09 kados       yea, it's the mappings we're really hurting from
02:09 chris       bibliosubject isnt a worry, we dont need it
02:09 chris       never made it to 3
02:09 chris       yep, its in 2.2.x but looks like both it and bibliosubject
02:07 gmcharlt    although it looks like bibliosubtitle preceeds earliest history in git
02:05 gmcharlt    then click on history link
02:05 chris       ahh cool ta
02:05 gmcharlt    click on lnk to original file
02:05 gmcharlt    go to commit that has move
02:05 gmcharlt    chris: you can use gitweb to follow history, even through moves
02:04 fbcit       took the words out of my mouth... err fingers... :)
02:04 chris       hard to find when it went to, as the file has been moved and so we dont have its full commit history
02:04 fbcit       so I'm about to give it a whirl...
02:03 fbcit       gmcharlt: currently it passes in like >dmake -x MAXLINELENGTH=300000
02:01 fbcit       dmake [-P#] [-{f|C|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value ...]
02:01 fbcit       gmcharlt: it appears dmake considers it a macro:
02:01 chris       somewhere between 2.2 and 3
02:01 chris       yep, so they have
02:01 gmcharlt    fbcit: I see
02:01 chris       has someone killed that whole table?
02:00 kados       :(
02:00 kados       in results, etc.
02:00 kados       and that field no longer displays
02:00 kados       chris: so that mapping has been lost
02:00 chris       yeah thats the one
02:00 kados       chris: bibliosubtitle.subtitle
02:00 gmcharlt    fbcit: ok, wasn't expecting that dmake would take that parameter as a macro, but if it works, it works
02:00 fbcit       gmcharlt: check out the section "Additional lowercase attributes"
01:59 chris       we had a subtitles table
01:59 chris       did we ever have biblio.subtitle?
01:59 fbcit       per MM docs...
01:59 fbcit       gmcharlt: {ANY_MACRO => ANY_VALUE, ...}
01:59 kados       when did that happen?
01:58 kados       so did we just completely lose biblio.subtitle?
01:58 fbcit       inside WriteMakefile()
01:58 kados       huh
01:58 fbcit       macro =>
01:57 gmcharlt    env var?
01:57 fbcit       I think I found a way to pass MAXLINELENGTH to dmake via Makefile.PL
01:57 gmcharlt    awaiting your patches :)
01:57 gmcharlt    fbcit: great
01:56 fbcit       hi gmcharlt
01:45 gmcharlt    hi fbcit
00:06 gmcharlt    fbcit's done some work to get installer to work on cygwin and Strawberry Perl; after he does a bit more, I'll merge in his stuff tomorrow
00:05 slef        I'd like to merge it across into mjr-installer and debianised and see what happens
00:04 kados       pending slef's approval :-)
00:03 gmcharlt    slef: ok (although I do intend for this to be merged into git.koha.org sooner rather than later)
00:02 slef        not for long-term branches
00:02 slef        rebase is for local topic branches, really, that you'll merge into your main tree
00:01 slef        yes, merge from master, else you cause conflicts for everyone pulling your branch
00:01 gmcharlt    slef: yes, I've been rebasing it to keep in sync -- is there a better way?
00:01 slef        have you done anything odd with your master, like rebase it?
00:00 slef        odd... just tried to pull your tree and it hit conflicts
00:00 gmcharlt    how goes it?
00:00 gmcharlt    hi slef
00:00 kados       hey slef
23:59 slef        hi all
23:59 slef        gmcharlt: are you there?
23:45 [K]         *** part FreeNode!#koha: DrDogwelder n=DrDogwel@mail.wlpl.org
23:45 [K]         *** join #koha@FreeNode: DrDogwelder n=DrDogwel@mail.wlpl.org
23:19 [K]         *** join #koha@FreeNode: ru55el n=russel@203-118-134-114.netspace.net.nz
22:37 chris       back
21:24 [K]         *** part FreeNode!#koha: maktrix n=mak@59.152.90.138
20:00 [K]         *** part FreeNode!#koha: ru55el n=russel@203-118-134-114.netspace.net.nz
19:57 hdl         Is there a reason ?
19:57 hdl         rather than 1=31 4=4 r=r.
19:57 hdl         kados : In ccl.properties, you do Date-Of-Publication 1=pubdate r=r
19:40 [K]         <maktrix@FreeNode> :) no prob. will talk later
19:40 chris       sorry in a meeting at the moment, i can talk later though
19:38 [K]         <maktrix@FreeNode> [K]: I'm from Bangladesh
19:35 chris       hi matrix
19:34 [K]         <maktrix@FreeNode> hello all
19:34 [K]         *** join #koha@FreeNode: maktrix n=mak@59.152.90.138
19:23 chris       signing off now and sending them on
19:23 chris       got them atz
19:21 atz         minor patches submitted
19:21 atz         cool, just rebased
18:59 kados       heads up koha devs, some patches just pushed up with bugfixes
18:17 [K]         *** join #koha@FreeNode: ru55el n=russel@203-118-134-114.netspace.net.nz
17:08 fbcit       sure
17:08 gmcharlt    will you have to time to work that out?
17:08 gmcharlt    yep
17:08 fbcit       the latter probably represents the least changes to Makefile.PL
17:04 gmcharlt    the recursion could either be done in Makefile.PL (to build up the list of files to be fixed), or just give it a dummy argument in PL_FILES and have it do the recursion
17:03 fbcit       ++
17:03 gmcharlt    to be automatically invoked in single and standard mode
17:02 fbcit       gmcharlt: excellent idea!
17:02 gmcharlt    fbcit: I'm thinking that it should be put into a separate script, e.g., fix-perl-path.PL and invoked in blib similar to rewrite-config.PL
17:02 fbcit       I wonder if it could be run against blib to avoid changing the original package files....
17:01 fbcit       it needs porting for other platforms and some dressing up too, but works in its current state
17:00 fbcit       gmcharlt: right, I have to decide how/where to invoke it
16:59 gmcharlt    fbcit: looking at the patch, it looks fixshebang is defined but not currently invoked -- am I reading that right?
16:56 gmcharlt    kados: looks ok
16:55 kados       pubdate                 [yyyy]          (008/7-10, indexed in year,word,sort indexes)
16:55 kados       acqdate                 [yyyy-mm-dd]    (952$d, indexed in date,word,sort indexes)
16:55 kados       copydate                [yyyy]          (260$c, indexed in word and sort indexes)
16:55 kados       date-entered-on-file    [yymmdd]        (008/0-5, indexed in word and sort indexes)
16:55 kados       Index                   Expected format         Notes
16:55 kados       date indexing in Koha 3.0 for MARC21:
16:55 kados       gmcharlt: in summary of our dates discussion
16:52 fbcit       gmcharlt: sorry... the first is a git-diff, the second is the patch...
16:46 fbcit       its a work in progress, but installer still works fine with the patch applied AFAIK
16:45 gmcharlt    fbcit: great
16:45 fbcit       gmcharlt: I'm going to send you a patch for the work I've done so far adding Win32 support to installer...
16:36 kados       and should be called 'global update' or something
16:35 kados       that could work ... but still, it should be in tools/
16:35 paul        what about just removing the list & let the user enter the marc field/subfield name ?
16:35 kados       and also, IMO it shouldn't appear for every search anyway
16:35 kados       yep
16:35 paul        it's because of the marc list, right ?
16:34 kados       it makes the results page on the staff client very slow
16:34 kados       but it's too imature IMO for 3.0 ... I didn't remove it, just commented it out IIRC
16:34 kados       I agree it's very interesting
16:34 paul        (I mean the feature to bulkedit the result of a search. A feature that our libraries find very interesting)
16:33 paul        kados : you seem to have removed the bulkmodif feature. was it by mistake or voluntary ?
16:33 kados       hdl: is that a typo?
16:33 kados       hdl: in your record.abs you have a tpubdate and a pubdate
16:32 kados       hdl around?
16:32 paul        )
16:32 paul        filed. (1658à
16:31 kados       if not it should be filed
16:31 kados       no, you can file a bug, but I thought there was already one there
16:30 paul        ok, so i don't file a new bug ;-)
16:30 kados       paul: yes, also on my list
16:29 paul        atm, there is no more complete fix if I don't mind !
16:28 paul        kados : I once have sent you a patch to fix <span class="term"> inside author link. You've rejected it because it was too simple & said that you planned to work on a more complete fix.
16:28 aklibrarian Good morning all.
16:27 gmcharlt    thinking about it, I like that more than stuffing custom tags in the bib records
16:25 kados       *nod*
16:22 gmcharlt    lead Koha to the path of munching on all metadata (yum, yum)
16:21 gmcharlt    [2] contains additional indexing and administration data
16:21 gmcharlt    s/warp/wrap/ -- MARC is warped enough
16:20 gmcharlt     (or any metadata type Koha supports)
16:20 gmcharlt    [1] warps MARC XML
16:20 gmcharlt    that or else make an XML schema that does two things:
16:20 gmcharlt    somebody already requested that (because ALEPH uses a lot of alphabetic tags), so we'd be adding on to the pile
16:19 kados       but we can certainly patch it to allow that :-)
16:18 kados       not sure MARC:: will allow it
16:18 kados       that makes sense
16:18 gmcharlt    e.g., 'itm' instead of 952, 'dat' for normalized dates, etc.
16:17 gmcharlt    yep -- and I'm wondering if we shouldn't see if we can set up a convention of using alphabetic tags for stuff that is generated or maintained solely for the benefit of indexing
16:17 kados       it can be system-generated and maintained ... ie, marked 'hidden' from the catalog client
16:16 kados       *nod*
16:16 kados       but that won't work for sorting
16:16 gmcharlt    normalized version should exist somewhere, but I'm a leary of putting in in the MARC record itself -- at least the version that is displayed and that cataloger edits
16:16 kados       I can do a regex match with zebra
16:15 gmcharlt    yep -- generally approach is to grab whatever matches something like /\d[u0-9]{3}/
16:15 kados       or do a normalized version in 260$9 or sth?
16:15 kados       should we normalize 260c?
16:15 gmcharlt    it's transcribed in 260$c
16:15 kados       260c maybe?
16:14 kados       gmcharlt: so no good way to get copyright date?
16:05 kados       hehe
16:05 gmcharlt    yep: make it easy to point all of the errors that catalogers have made in filling out those fields ;-)
16:04 kados       dom filtering will make that a lot easier anyway
16:04 gmcharlt    yep
16:04 kados       ok, so we'll defer that until 3.2
16:04 gmcharlt    Date2 can be of interest to serials
16:03 gmcharlt    e.g, if 008/06 = 'e', Date1 contains year and Date2 contains month and day
16:03 kados       shoudl I bother with date2 ?
16:03 gmcharlt    fuller indexing of 008 dates will take more work, but can be deferred IMO
16:03 kados       *nod*
16:02 gmcharlt    true: so 005 is not necessarily of interest in OPAC index (might be for a staff index, though)
16:02 kados       also IIRC :-)
16:02 kados       /is/shouldbe/
16:02 kados       yea, but 005 is updated every time the record is edited, so it's not strictly an acqdate
16:02 kados       copydate I'm not sure about
16:02 gmcharlt    yep; indexing 005 timestamp should also be easy
16:01 kados       pubdate will be a year and I'll use date1 from 008
16:01 kados       so acqdate is easy, since we control that field
16:01 gmcharlt    right: convention in 033 appears to be hyphens
16:01 gmcharlt    and right, year of pub not necessarily equal to copyright date
16:01 kados       yea, now that you mention it, there are a few conventiosn for partial entry of dates IIRC
16:00 kados       ahh
16:00 gmcharlt    198u, 20uu, etc.
16:00 gmcharlt    but main issue is dealing with incompletely entered dates
16:00 kados       there is 'year of pub' not the same as 'year of copyright' right?
16:00 gmcharlt    date1 in 008 is OK for now
15:59 kados       008 I mean
15:59 kados       ok, so stick with date1 in 001?
15:59 gmcharlt    my impression is that there should be two types of date indexes: year and full timestamp
15:59 gmcharlt    033 is not commonly used for monos; may be for other formats
15:58 gmcharlt    for monographs, year is sufficient
15:57 kados       should it be based on the year, or a full date? and if a full date, what's the best method for getting a normalized date string out of the MARC?
15:57 kados       gmcharlt: do you have any impressions about the best method for indexing dates like pubdate and copydate ?
15:56 kados       others, like 033 I'm not sure about
15:56 kados       like in the 008 def for marc21
15:55 kados       some of the 'Date' fields are clearly type 'year'
15:53 kados       (4=5)
15:53 kados       why aren't we using 'Date (normalized)' ?
15:53 kados       hdl: any reason for that?
15:53 kados       hdl: we have 'Date' and Date-of-publication' and 'Date-of-Acquisition' set to 'numeric string' rather than a date index
15:48 kados       to set the default
15:48 kados       $structure = ",wrdl";
15:48 kados        unless (!$index || $index =/(st-|phr|ext|wrdl)/) {
15:48 kados       and we'll do:
15:47 kados       hdl: (just multi-parameter ones)
15:47 kados       hdl: I am altering the ccl.properties to remove all structure attributes
15:46 kados       hdl: I'm fixing it now
15:46 kados       hdl: yes, just noticed that
15:45 hdl         Have to test it deeper.
15:45 hdl         Could be a problem with dates.
15:45 hdl         It is adding wrdl to any index without modifier.
15:45 gmcharlt    hi fbcit
15:44 kados       hiya fbcit
15:44 hdl         kados : I saw your patch.
15:44 fbcit       g'morning again koha
15:38 hdl         will test it tonight.
15:38 hdl         cannot test right now.
15:35 kados       hdl: working?
15:32 kados       in our ccl.properties
15:32 kados       I'll investigate all of the 4= attributes, I've just noticed some redundencies
15:31 kados       date, year, word, keyword, etc
15:29 kados       hdl: sent
15:29 hdl         henridamien at koha hyphen fr dot org
15:28 kados       hdl: let me know what email you prefer
15:27 kados       hdl,paul: ok, I've got a patch, do you want me to push it up mainline or email to you for testing?
15:16 kados       lemme test for a few minutes
15:16 kados       ok, I've founda  good place for it
15:10 kados       as the stemming is handled by an external library
15:10 kados       it could support stemming quite easily as well
15:10 kados       :)
15:10 paul        (or i'm a genius, as I do things without knowing :o) )
15:09 paul        + the proble that hdl reports is the same for NoZebra & NZ don't support stemming
15:09 kados       it shouldn't be a difficult problem
15:09 kados       I'm investigating now
15:09 kados       yep, I agree we need to work on word list separate from stemming
15:09 hdl         Yes, but this is told to be only basic stemming problems.
15:07 kados       Lingua::Stem supports FR-FR AFAIK
15:07 kados       hdl: minor modif (maybe a syspref) to make that work
15:07 kados       hdl: see _build_stemmed_operand
15:07 hdl         Could or does ?
15:07 paul        I once tried and got complete failure. but I haven't investigated deeply what happends
15:06 paul        (hi kados)
15:06 kados       it could
15:06 kados       yep
15:06 hdl         Would Querystemming use french if locale is french ?
15:05 hdl         maybe we could strip out all the attributes modifiers from humansearchdesc ?
15:03 kados       I'm investigating where to set the default
15:03 kados       yes
15:03 hdl         thing tha user sees ?
15:03 hdl         user-facing ?
15:03 kados       *nod* but it shouldn't be a user-facing attribute
15:02 hdl         This is why I added wrdl attribute to all the attributes in advsearch.
15:01 kados             Z> find @attr 1=Title  @and mozart amadeus
15:01 kados             Z> find @attr 1=Title @attr 4=6 "mozart amadeus"
15:01 kados        The structure attribute values Word list (6)  is supported, and maps to the boolean AND  combination of words supplied. The word list is useful when google-like bag-of-word queries need to be translated from a GUI query language to PQF. For example, the following queries are equivalent:
15:01 hdl         We have expr if we want exact search.
15:00 hdl         why should I say no ?
15:00 kados       are you sure you want 'word list' instead of 'word'  as the default?
14:59 kados       there may be a simple solution
14:59 kados       I have it on my list
14:59 hdl         Is there an other solution ?
14:58 hdl         We cannot turn it on since french stemming is not the same as American Stemming.
14:57 kados       it happens when QueryStemming is turned off
14:57 kados       yep, and I have verified it
14:57 hdl         We use the same ccl.properties.
14:56 hdl         Is there something we can doo about it ?
14:56 hdl         search on kw are doing expression search and not wordlist search.
14:56 hdl         on advsearch,
14:56 hdl         I already asked you. But problem is not solved here.
14:55 hdl         hi.
14:55 kados       g'morning
14:55 kados       hdl: yep
14:55 hdl         kados around ?
14:55 hdl         hi
12:44 fbcit       g'morning koha