Time  Nick          Message
09:18 frederic      hi
01:34 atz           that is a logical way to revise NZanalyse in any case
01:34 atz           still matches the same strings, but $2 is tighter
01:33 atz            /(.*?) (and|or|not|AND|OR|NOT) (.*)/
01:33 atz           keeping the spaces around the operator provides a whitespace operand later
01:32 atz           you also get 5.8 to level 4
01:32 atz           if you rework your regexp so that the spaces are outside the parens for $2
01:32 atz           gmcharlt: aha!
01:31 gmcharlt      looks like it shouldn't crash if NZanalyze is passed an empty string as its arg
01:30 atz           you're right though... it's a bug.... in NO case should left match "ice"
01:29 gmcharlt      hmm - not sure - maybe to allow a unary not operator
01:29 atz           are we OK w/ getting empty left and right elements?
01:29 atz           i get that.   I'm saying why is it  .*? and not .+?
01:28 gmcharlt      I think solution is to test that the regexp at line 1585 actually matches - if it does, we can use $1, $2, $3 - if it doesn't, we're at a leaf and don't care if $1 had gotten clobbered
01:26 gmcharlt      left hand of search string if a and/or/not operator is used
01:26 atz           what is intended for (.*?) ?
01:25 atz           it's looking for a minimal match on the front end? and a potentially empty match on the back?
01:25 atz           so, if we were to talk out the regexp /(.*?)( and | or | not | AND | OR | NOT )(.*)/
01:23 gmcharlt      and the corresponding fix: http://public.activestate.com/cgi-bin/perlbrowse/p/29279
01:21 gmcharlt      I'm not positive, but this might be the relevant bug: http://rt.perl.org/rt3/Public/Bug/Display.html?id=19049
01:21 gmcharlt      atz: so only certain kinds of failed matches will reset the match variables
01:20 atz           updated pastebin w/ that revision if you want to see it
01:20 atz           gmcharlt: note that 5.8 will get to level 4 if I change the trailing * to a +
01:17 atz           interesting... that test looks definitive
00:50 gmcharlt      and the apparent regular expression bug in 5.8 accidentally prevents an infinite loop
00:50 gmcharlt      and in 5.10, it does the documented thing of leaving those vars alone (i.e., $1="mice", $2=" and ", $3="men")
00:49 gmcharlt      but in 5.8, the failure changes $1 to 'ice' and clears $2 and $3
00:49 gmcharlt      in both cases, the match fails the second go around, as it should
00:49 gmcharlt      different results when run in 5.8 vs. 5.10
00:48 gmcharlt      atz: http://pastebin.com/d4ab26ceb
00:46 gmcharlt      got a minimal test case ready - just a sec
00:46 gmcharlt      actually, it's the match at 1585 that seems to be the weak spot
00:45 atz           so I'd say that is a likely candidate!
00:44 atz           gmcharlt: that line has the comment => "# delete repeated operator... Would then go in infinite loop"
00:44 atz            $string =~ s/( and| or| not| AND| OR| NOT)\1/$1/g   # <<also dicey
00:35 atz           seems some of those REs could benefit from using "non memory" clusters where appopriate
00:31 atz           string fails the match inside conditional?
00:31 atz           so what happens if ($operator) and
00:30 atz                   }
00:30 atz                       warn "handling unless (operator)... left:$left operator:$operator right:$right" if $DEBUG;
00:30 atz                       $right    = $3;
00:30 atz                       $operator = $2;
00:30 atz                       $left     = $1;
00:30 atz                       $string =~ /(.*)(>|<|=)(.*)/;
00:30 atz                   unless ($operator) {
00:30 atz           #         warn "handling leaf... left:$left operator:$operator right:$right" if $DEBUG;
00:30 atz                   my $right    = $3;
00:30 gmcharlt      it's actually a valid technique (i.e., you're *supposed* to be able to use capture variables from the last successful match, even if you've made failing ones), but not used well (or intentionally, AFAIK) in NZanalyse
00:30 atz                   my $operator = $2;
00:30 atz                   my $left     = $1;
00:30 atz                   $string =~ /(.*)(>=|<=)(.*)/;
00:30 atz                   # parse the string in in operator/operand/value again
00:26 atz           seems lame
00:26 atz           we depend on backrefs from failed matches?
00:26 gmcharlt      (in 5.8, that is)
00:25 gmcharlt      looking at it more, appears to be a perlre bugfix - a failed match is not supposed to change $1, $2, etc., but I seem to be looking at a case that where it does
00:24 atz           i think the behavior of compound zero-width look-aheads did change
00:24 atz           i was just reading a ton about look-ahead and look-behind REs
00:23 gmcharlt      MatthewMetzger (bug 2020) - I just now am in the process of determing exactly *why* it does this - looks to be a subtle change in perlre and how capture variables work
00:21 atz           who discovered that nicety?
00:20 atz           d'oh!
00:20 gmcharlt      atz: you'll like this one - NZanalyze, which is a recursive sub, can be made to loop infinitely in perl 5.10 where it terminates when running under 5.8
00:20 atz           thx for the sanity check
00:19 gmcharlt      then the answer is clear - we can blame everything on rch! ;-)
00:19 atz           but I'm logged in as my test dude "rch"  :)
00:17 atz           ah, indeed, independent branches is on.  it must not normally care if you are the koha root (no default branch)
00:16 gmcharlt      if so, and if you're logged in with a branch assigned, only patrons of that branch will show up
00:16 atz           good question
00:16 gmcharlt      another possibility - is IndependentBranches on?
00:14 atz           hmm... my theory doesn't hold up though.   I change his userid to 'bbb' and he's still the only one on the page for "a"
00:12 atz           apparently normal cardnumber
00:12 atz           5 rows in set (0.00 sec)
00:12 atz           +-----------+----------------+----------------+
00:12 atz           | Alford    | 23529000050113 | 23529000050113 |
00:12 atz           | Albertson | aaa            | 23529001223638 |
00:12 atz           | Admin     | NULL           | 1              |
00:12 atz           | Acosta    | 23529001000463 | 23529001000463 |
00:12 atz           | Acevedo   | 23529000035676 | 23529000035676 |
00:12 atz           +-----------+----------------+----------------+
00:12 atz           | surname   | userid         | cardnumber     |
00:12 atz           +-----------+----------------+----------------+
00:12 atz           mysql> select surname,userid,cardnumber from borrowers where surname LIKE "a%" ORDER BY surname;
00:12 gmcharlt      I mean
00:11 gmcharlt      I looked at the code, I'm
00:11 gmcharlt      atz: look at that code recently - I think its actually exact match on cardnumber, not userid - does that patron have cardnumber = 'a'
00:10 atz           gmcharlt: you might be able to short circuit your match by adjusting patron data similarly
00:10 atz           i suspect the search is trying to be "smart" and taking a LIKE USERID "%$x" match as definitive
00:09 atz           the patron displayed is albertson, who happens to have the userid "aaa"
00:09 atz           5 rows in set (0.00 sec)
00:09 atz           +-----------+----------------+
00:09 atz           | Alford    | 23529000050113 |
00:09 atz           | Albertson | aaa            |
00:09 atz           | Admin     | NULL           |
00:09 atz           | Acosta    | 23529001000463 |
00:09 atz           | Acevedo   | 23529000035676 |
00:09 atz           +-----------+----------------+
00:09 atz           | surname   | userid         |
00:09 atz           +-----------+----------------+
00:09 atz           mysql> select surname,userid from borrowers where surname LIKE "a%" ORDER BY surname;
00:08 atz           I get:  Results 1 to 1 of 1 found for 'a'
00:06 atz           interesting...
00:06 gmcharlt      atz: members/member.pl? not seeing this in my DB - rebased a couple minutes ago
23:50 atz           any reason my members page is only showing the first member of any given alphabet letter?
23:11 atz           so it will pull it's "page" variable out of the base_url that it is passed
23:11 atz           i think i finally fixed pagination_bar to be marginally intelligent
22:23 kados         hdl: can you sign off on galen's patch for unimarc_complet framework: put 801$a in tab 8 ?
22:00 gmcharlt      kados: no - just one I had picked off and tested so that I can build another DB rev on top of it w/o integrate problems
21:59 kados         gmcharlt: was there a change from hdl's?
21:59 kados         gmcharlt: oops, just noticed you had a version of that one in there
21:57 kados         hdl: just pushed up your patch from yesterday
21:38 hdl           If it is this, then the new way to use this framework parameter is to put index code in it.
21:37 hdl           is this link between subfields ?
21:37 hdl           ryan : which link wer you talking about ?
21:01 chris         sleep well paul
20:59 paul_bed      bye world. I'll be away from irc until next monday
20:35 chris         hi paul
20:35 paul          hello chris
20:33 chris         morning
19:24 ryan          ok, thx
19:16 owen          (Sorry phone) Yeah, it's an old way as far as I know
19:11 ryan          (i'm assuming old way)
19:11 ryan          is this an old way to do it or a new way to do it ?
19:11 ryan          the link is generated in the script.
19:10 ryan          Can you explain the paging paradigm on cgi-bin/koha/admin/marc_subfields_structure.pl
19:09 owen          Yes
19:09 ryan          owen: around ?
18:46 ryan          ok.  will have to update
18:46 gmcharlt      I'm 99% certain that the version packaged in etch-backports fixes the email bug, tho
18:46 ryan          ok, thx
18:45 gmcharlt      no, just a local copy of git on arwen
18:45 ryan          ah.  you are running lenny in a vm?
18:44 gmcharlt      ryan: debian has 1.5.4.2-1 in etch-backports and 1.5.5 in lenny
18:43 gmcharlt      ryan: a local copy of git 1.5.5 - i.e., may be due for an upgrade on our servers
18:41 ryan          gmcharlt: i have noticed that you seem to successfully submit patches with multiline commit messages.  do you do something special ?
18:13 gmcharlt      the hash that identifies the commit (e.g., d2e27ff482863c9792c2bbe8e81f299caf62119d for my C4::Scrubber test case patch) is can be used to link directly to gitweb
18:12 gmcharlt      acmoore: useful, but considerations apply: displaying them well, not overwhelming a bug history log with them
18:11 acmoore       perhaps I'll look into WWW::Bugzilla to see if I can make a post-commit hook or something.
18:09 acmoore       I'm not sure if that information is links, hashses, or what. Is there a technically easy way that we can do something like that?
18:08 acmoore       it sounds like information about accepted patches is viewed as useful and not harmful.
18:07 acmoore       maybe we start from the places where we can agree that there is usefulness and build from there.
18:07 acmoore       for example: "This patch was submitted by GMC to patches@koha.org yesterday..." or "Hi, folks, Here's my suggestion... -GMC" or "This patch went into HEAD at 10AM..."
18:06 acmoore       yes, I follow and agree. They're different times that patch information is useful to bugzilla users. It should indicate where the patch came from or something to let users know what state the patch is in.
18:05 gmcharlt      distinguishable *from*
18:04 gmcharlt      acmoore: valid point; but my preference for attaching patches in a bug database is to use them for communication - i.e., I'm not sure about how to fix something, I propose a patch, attach it to the bug, and ask for comments - I would want that use case to be distinguishable for linking accepted patches automatically
18:03 acmoore       whether it's gitweb, full text, hashes, or what.
18:03 acmoore       gmcharlt, your point about patches being modified by RM or QA is very valid, though. I'd like links to accepted patches, too.
18:02 acmoore       not a strong argument, but one nonetheless.
18:02 acmoore       gmcharlt, seeing unaccepted patches is useful, too. You can tell that I've submitted patches that fix your bug. You can see if they implement what you asked for, and you can tell that ther'e's progress being made on your request. Also, you can bug RM or QA to look at them.
18:01 acmoore       gmcharlt, that's fine. In fact, it may be useful for me to see the several versions of patches that I submitted relevant to a particular bug. Those patches are relveant to that bug, but right now there's no easy way to find them or know that they exist from bugzilla.
18:01 gmcharlt      storing the commit hash, though, would be enough I think to generate a link to that patch in gitweb, if/when the patch is accepted
18:00 acmoore       slef, that works pretty well, I guess. I'll see if I can whip up a shell script for that.
18:00 gmcharlt      acmoore; but then you're back to the issue that a patch stored in bugzilla is not necessarily the final version, or not necessarily accepted
17:59 acmoore       gmcharlt, Or, perhaps a git post-commit hook to send the hash or a gitweb link to bugzilla?
17:59 acmoore       gmcharlt, I can see that working. Unfortunately, it requires hacking on gitweb a bit. If git send-email would send the patches to bugzilla to be included, we wouldn't have to do that.
17:58 slef          but I've not tested that, sorry
17:58 gmcharlt      acmoore: or if not requires, encourages
17:58 slef          acmoore: "changes that were made for a particular bug" - ideally, grep the git log --format=online output for the bug number, then cherry-pick the git commits
17:57 gmcharlt      acmoore: perhaps some sort of git commit hook that requires that a commit description include a bug number in some parsable format, then a bit of customization of gitweb to allow a search on bug number - something like that
17:56 slef          acmoore: version control generating/updating the variable from tags, I think
17:56 acmoore       gmcharlt, super. How do we do that?
17:55 gmcharlt      acmoore: my preference is for something that auto-links between the bugs and the patches as displayed in gitweb - because a git RM and QA can sometimes modify patches, gitweb is more authoritative
17:55 acmoore       atz, heh. Thanks for humoring me.
17:55 atz           so, that's a few laps around the VERSIONing debate track.
17:55 acmoore       I wonder how other people deal with this. We're not the first gang to start putting $VERSION in a few dozen files.
17:54 acmoore       atz, that's valid.
17:54 acmoore       gmcharlt, I would prefer the whole bug be included, but not very strongly. Mainly, I just want an easy way to get to the changes that were made for a particular bug.
17:53 atz           acmoore: actually, that's not the problem... the problem is my new-feature dependent client-code would THINK it was getting the new version when somebody else checked in a minor unrelated update
17:53 gmcharlt      and something where acmoore's idea about patches being automatically attached to bugs could come into play - I'm not sure how I feel about automatically including the entire patch because of potential DB noise considers), but storing the git hahses of the patches could be useful
17:53 acmoore       the concern about other people touching C4::Tags and breaking versioning could be ameliorated if it were automatically increamented upon checkin, I think. Isn't that what CVS used to do?
17:51 atz           gmcharlt: true enough... though not really any different than the versioning getting broken w/o the VERSION indicator
17:51 gmcharlt      as far as partial patch intake is concerned, that would be one thing for the test cases to catch
17:51 acmoore       haha. great.
17:51 gmcharlt      acmoore: don't worry, this has been a long-running debate
17:51 acmoore       I didn't mean to open this large of a can of worms...
17:50 gmcharlt      atz: the issue is the moment somebody else touches C4::Tags, the proper versioning can get broken - we're not at the point, if we'll ever get there, where mistakes would get caught
17:50 acmoore       but, then, that doesn't really allow atz's use.
17:50 atz           acmoore: yeah, there's been some discussion on that.  i'm not sure where I stand on it... 3.0 suggests things that this "experimental" feature doesn't have yet
17:49 gmcharlt      yes, applying a 3.0 version to the whole C4 API is about as far as we can go, realistically
17:48 acmoore       it seems like that versino number should be 3.0, though.
17:48 atz           i agree that Koha as a whole certainly doesn't exhibit those features
17:47 acmoore       valid point. it's also clear why it's failing when it says "you need 0.02, and you only have 0.01" instead of saying "I can't find the get_tags method in C4::Tags", I guess.
17:47 atz           gmcharlt: so I can't pretend w/ Tags, even if it is?
17:47 atz           acmoore: yes, but in case my patches get applied only partially or at different times, this catches it immediately
17:46 gmcharlt      until such time as C4 meets those conditions
17:46 gmcharlt      IMO, we should not pretend that the API is properly versioned, stable, or backwords compatible
17:46 acmoore       reasonable use, I guess. This prevents your tags/review.pl from getting used with an old C4::Tags. Shouldn't that get enforced by the fact that you presumably check them both in at once, though?
17:46 atz           do you see VERSION numbers regressing at some point?
17:46 gmcharlt      because of possible developer confusion about the correct convention
17:45 atz           ?
17:45 atz           gmcharlt: how is it harmful to have in only portions of the codebase?  (besides possible developer confusion about the correct convention)
17:44 atz           acmoore: right, mine is newer
17:44 atz           well, we added VERSIONs to C4
17:44 acmoore       is that because the current C4::Tags doesn't have the functionality you need yet? I notice mine is 0.01.
17:43 gmcharlt      atz: then please stop - I applaud the impulse, but this needs to be done throughout Koha or not at all
17:43 atz           but I am clearly the exception
17:42 atz           use C4::Tags 0.02 qw(get_tags get_approval_rows whitelist blacklist is_approved);
17:42 atz           for example
17:42 atz            /home/atz/koha/production/koha/tags/review.pl
17:41 acmoore       ahh! cool. where do you use that?
17:41 atz           gmcharlt: i actually use the VERSION'd version of use
17:41 gmcharlt      fine with me
17:40 acmoore       sounds like YAGNI. Shall I remove that paragraph from the documentation?
17:38 gmcharlt      acmoore: IMO, effectively yes - but could change if we get serious about turning C4 into an actual API meant for consumption outside of the core Koha scripts, which would imply API versioning, backwards compatibility, etc.
17:35 acmoore       then, perhaps they're deprecated?
17:34 gmcharlt      acmoore: some sort of use could be made, obviously, but would have to be thought through carefully
17:34 gmcharlt      acmoore: in practice, no use is made of the $VERSION declared in the C4 modules
17:34 acmoore       perhaps we would benefit from an automated test to check that.
17:33 acmoore       I notice that there's discussion of a $VERSION variable on that page, too. Is that number supposed to be the same in all files?
17:21 acmoore       Maybe I'll just mention that if you fail to use placeholders, it makes me have to come in behind you, write tests, and refactor your code...
17:20 acmoore       I thought there was a discussion about this in "Perl Best Practices", but I can't find it now. I was hoping to reference it.
17:20 danny         lol
17:16 gmcharlt      as you care to
17:15 gmcharlt      feel free to add as much wording about how whole kindles of kittens will cry if placeholders are not used
17:14 gmcharlt      acmoore: definitely
17:14 acmoore       gmcharlt, on a similar topic, do you think that the SQL stuff at http://wiki.koha.org/doku.php?id=en:development:codingguidelines#sql should be updated to reflect the desire to use placeholders instead of cramming variables into SQL statements?
17:12 acmoore       yeah, I noticed that.
17:11 gmcharlt      acmoore: at least this one has decent syntax highlighting
17:10 acmoore       There's lots of stuff I think I can improve on the wiki, now that I'm getting more comfortable with the application and the processes around here. Now, I just have to get comfortable with yet another wiki syntax and quirks. ;)
17:08 gmcharlt      acmoore: looks good - thanks
17:08 acmoore       oh, and if anyone else has questions about how to use or extend the test suite, please don't hesitate to ask. It will help me improve the documentation because I can assure you that you're not the only one with questions.
17:07 acmoore       There's more to go, but this may help others contribute to the growing test suite.
17:07 acmoore       gmcharlt, I improved the developer docs a bit to include some of the improvements that you and I have been adding to the test suite: http://wiki.koha.org/doku.php?id=en:development:unit_testing
15:59 eric          Ha, ok :) np
15:59 bb_marblehead sorry wrong eric
15:58 eric          bb_marblehead, a call about what?
15:57 owen          That'd be okay
15:57 bb_marblehead how is 3:30 for a call with eric?
15:57 owen          Yes
15:57 bb_marblehead owen: you around?
15:54 slef          eric: given number of compliments I've had about the last day's emails, I think I should answer 6000 emails all at once more often ;-)
15:53 slef          sawariwap: send help, we're going to advance
15:53 slef          sawariwap: plenty, but no date AIUI :)
15:52 sawariwap     any news for koha's RC or release?
15:48 owen          What kind of information should I see in a biblio's modification log? If I modify a MARC record, should viewlog.pl show that?
15:46 paul          tabernacle !!!
15:41 eric          slef: I'm watching you about your Quebec French... :)
15:15 owen          slef: We make every attempt to code to standards
15:14 gmcharlt      IE--
15:14 gmcharlt      owen++
15:14 Brooke        that's a good thing, and worth the fuss, it's still what folks use most
15:12 bb_marblehead owen: can you please email me your # ... i have misplaced it
15:11 owen          We were pretty lax about IE compatibility before, and we're trying to do better.
15:11 owen          That's me, among others :(
15:11 Brooke        whoever's headache it is making Koha work round Microsnot's bad code has my undying gratitude
15:10 Brooke        I used to use IE for Koha, but it became frustrating
15:09 owen          Has anyone been testing in Internet Explorer 7? I can't seem to stay logged into Koha in IE7. Every link I click, I'm forced to log in again.
15:05 hdl           ryan: seems ok for me.
15:05 ryan          hdl: so no problems for unimarc making the change for marc_subfield_structure ?
15:02 owen          bb_marblehead: I do now
15:02 atz           true
15:01 gmcharlt      atz: looks OK.  as you mentioned in comments, more POD is called for, but I'm figuring you ran out of time
14:57 atz           gmcharlt: did you get a chance to look at the C4::Scrubber patch?
14:56 hdl           (just a question... I know I had to migrate data with subfield codes in UPPER and lower case)
14:55 gmcharlt      hdl: pretty sure it is
14:55 hdl           I like the idea of case sensitivity for subfield codes. But is MARC::Record case safe for subfield codes ?
14:52 gmcharlt      hdl: MARC21 doesn't generally use uppercase subfield codes, but they are case-senstive in ISO2709 and are sometimes used for local data
14:51 hdl           ryan : are subfield codes cas sensitive in MARC21 ?
14:50 bb_marblehead owen: do you have time for a quick call?
14:49 bb_marblehead hi owen
14:43 gmcharlt      ryan++ # definitely ouchie not allowing uppercase subfield labels
14:42 Brooke        teh ohnoes!
14:42 ryan          currently, if you add an uppercase subfield code, it will overwrite your lowercase code.
14:42 Brooke        That would seem to be logical
14:41 ryan          does anyone see a problem with making the collation on marc_subfield_structure utf8_bin  by default ?
14:40 Brooke        whazzah?
14:38 owen          Hi bb_marblehead
14:34 ryan          mysql case sensitivity--
14:33 slef          lloyd's connection isn't in a happy place today, I guess
14:30 hdl           I think this is owed to the fact that this page is not using C4::Output to output.
14:29 hdl           yuipaht
14:29 hdl           owen : just seen your bug report on local
14:24 hdl           owen++
14:24 hdl           owen : tx
14:23 slef          is it just www.koha.org or all koha.org sites?
14:22 slef          what's the scope of the "search koha.org" box on www.koha.org?  anyone know?
14:19 owen          hdl, I just submitted a patch that adds the necessary YUI library files to the OPAC. These were missing following the changes to the YUI path pref.
14:17 atz           since I believe that H:T:P would re-read and reparse the included file each time (unlike a loop)
14:16 atz           i'm pretty sure that a repeated INCLUDE (i.e., for each hit element) would be bad for performance
14:16 owen          Okay atz, thanks. It was worth a try :)
14:16 hdl           owen: am here now
14:16 atz           owen: right now I don't see any easy way to share code in the various opac pages
14:14 atz           that's the eventual goal for jacket images... allow the library to select the image sources they want to use, and rank them in the preferred order.  this req's js to process whether the first ajax request failed, the second, and so on.
14:14 owen          I'm assuming that if someone chooses Google Jackets that's because they want Google Jackets and not Amazon images.
14:13 owen          Right, but then we're back to having all the static markup in the template
14:11 atz           other image sources!
14:10 owen          I don't see how that could work well... What would it failover to?
14:10 atz           but at least you could enable some failover for script-capable browsers
14:09 atz           yeah, they would still need potentially messy templates
14:09 owen          atz, my concern there is for non-js users
14:09 atz           i'm wondering if we can use the same identifier internally w/ our own js
14:08 atz           owen: have you looked at the mechanism google uses in js?
14:07 atz           imho, it's probably not the way to go here, and may violate content providers' terms of service
14:07 owen          I'll defer to you on that one atz
14:06 owen          The <img> could be wrapped in a link that pointed to a variable so that Baker and Taylor could point to their sales pages if necessary
14:06 atz           owen: in that case the server has to throughput all the image content
14:05 atz           it avoids you having to get into each "hit" element and conditionalize a host of image options in the template
14:05 owen          Instead of linking to an image, we could have the <img> tag link to a script that returned image data
14:05 atz           the cleanest way would be google style AJAX
14:04 ryan          the templates are going to get messy
14:04 ryan          we need a way to handle it...  I have some test info for syndetics jacket images
14:04 atz           the Amazon code and B&T code are roughly similar, the Google code is orthogonal
14:04 ryan          gmcharlt: grea, thx.
14:03 owen          I'm thinking of opac-user, opac-shelves, opac-readingrecord, maybe even opac-basket
14:02 owen          I'm wondering if we should be copying the relevant code to each script, or is there a more unified way of handling it?
14:02 atz           which are lacking?
14:01 owen          We've got three alternatives now for book cover images, but not all pages in the OPAC which display covers are set up to use all those options
14:01 atz           owen: sure
14:01 gmcharlt      syspref is not currently defined, but I'll add it
14:01 gmcharlt      ryan: works for me (i.e., setting 942$n = 1), but depends on there being an OpacSuppression syspref
14:00 ryan          doesn't seem to work.
14:00 ryan          anyone:  what's the status of 'Suppress in OPAC'  feature ?
13:54 owen          atz, can I ask you about book cover images?
13:51 owen          hdl around?
13:43 atz           that sounds right
13:42 paul          not after they login, but as soon as they have choosen one explicitly
13:42 acmoore       so, it sounds like you show the login page in the language of the header, then after they login change to their preferred language if there is one?
13:41 paul          if someone choose another one, then stick with it for the session !
13:41 paul          nope, it should not. the default language is the one dictated by the header.
13:40 acmoore       danged if you do, danged if you don't...
13:40 atz           i don't imagine the library lab will expect ppl to reconfigure the browser accept-language headers every time a user sits down to search the OPAC
13:40 paul          the http header should be used only if there is no koha pref set.
13:39 atz           acmoore: if you *don't* associate it w/ the users, they're going to have to choose more than once
13:39 owen          atz: the language-chooser is always present
13:39 paul          acmoore++ !
13:39 atz           where they expect the users to switch back and forth
13:39 acmoore       atz, if you associate it with the user information, they're still going to see the english login page because you don't know who they are before they log in.
13:38 atz           paul: how do you think that would affect, for example, a library in Quebec
13:38 owen          (isn't it?)
13:38 owen          Shouldn't it be stored in a cookie the way the user's current branch is?
13:38 paul          nope, I think it can be achieved through http header preferred language
13:38 atz           so that the info is paired w/ the user themselves, and not their browser session
13:37 atz           right, so you need a new column in borrowers, or a keyed language-prefs table
13:37 paul          atz: when you close your browser, your session & preferred language is lost. and you're back to english
13:36 owen          atz: we're talking about the user choosing a translation from the language-chooser menu in the staff client
13:36 paul          users could be happy if they had to click only once in their life !
13:36 atz           ?
13:36 atz           owen: regarding (2), you mean the user themselves, or that particular browser (i.e., cookie)
13:36 paul          2) being the most important
13:35 paul          maybe yes.
13:35 owen          paul, it sounds like there are two questions: 1) Can Koha automatically choose a language for the user; and 2) Why doesn't Koha remember that the user previously logged in with another language?
13:34 owen          Also: http://livehttpheaders.mozdev.org/
13:34 acmoore       This thing shows the headers that your browser is sending http://www.ericgiguere.com/tools/http-header-viewer.html
13:34 owen          So it doesn't remember that they logged in previously with fr
13:33 paul          owen : bottom left of the screen
13:33 acmoore       I thought those were comma separated lists from the browser. Perhaps the CGI object makes them into perl lists, but I doubt it.
13:33 owen          paul, where do your users see the language choice at login?
13:32 atz           like http(/Accept-language/) ?
13:32 atz           i assume those are regexps?
13:31 acmoore       There's an example in the CGI docs about $requested_language = http(?Accept-language?); and $requested_language = http(?HTTP_ACCEPT_LANGUAGE?);
13:31 paul          i'll investigate in this direction, thx
13:30 paul          yep
13:30 atz           acmoore: should be ENV{HTTP-ACCEPT-LANGUAGE} or somethinge
13:29 gmcharlt      agree, shouldn't be hard to implement
13:29 gmcharlt      http://search.cpan.org/~cgilmore/I18N-AcceptLanguage-1.04/lib/I18N/AcceptLanguage.pm for one approach
13:29 acmoore       and it's probably exposed in the CGI object somewhere.... it's presumably possible and I can't imagine it being prohibitively dificult.
13:28 atz           owen: usually this is handled by Apache for static HTML sites
13:28 paul          yep, you should be right
13:27 acmoore       I think it's the Accept-language header
13:27 paul          isn't it given by cookies ?
13:27 owen          Yes, but how does a web site detect the browser's preferred language?
13:26 paul          My list has french as 1st language, then en, then en-us
13:26 paul          Edit > Preferences > Advanced > General > Language
13:25 paul          do you use firefox ?
13:25 paul          yep, of course. All browsers have a preffered language list.
13:25 owen          paul, I don't know about that. Is that something you've seen other web applications do?
13:25 paul          en is always displayed at login, the users have to click on "Français", and they complain about that
13:24 paul          it's not the case atm, and it's annoying for non native english ppl
13:24 paul          isn't koha supposed to auto-detect the browser preffered language and switch to it by default ?
13:24 owen          OK
13:24 paul          owen, i've a small question for you.
13:22 atz           greets owen
13:14 owen          Hi atz
13:14 owen          I like the idea, acmoore, but I haven't heard anything about that
13:13 acmoore       I'd like to send patches to patches@koha.org and to something like bugzilla@koha.org so that they always show up in the right bug
13:12 acmoore       does anyone know if bugs.koha.org accept mail to add comments to bugs? I can't seem to get it to work.
13:08 owen          Maybe kados can shed some light on it?
13:06 owen          Yeah, at the moment that bug is invalid because standard git repos don't have that marc/extended marc option...Unless I'm missing something.
13:03 nengard       owen i think so if you follow the url in my bug and click the different views you'll see what i mean
12:36 owen          Is that what Bug 2103 is about? The view you get from opac-showmarc.pl?
12:35 owen          Ah, so that's what opac-showmarc.tmpl is for
12:34 nengard       maybe...
12:34 owen          Probably something Liblime was working on?
12:33 owen          It's not in the latest version of opac-detail.tmpl
12:32 nengard       hehe
12:32 owen          I've never seen that before
12:32 owen          I don't know about the "expanded marc view"
12:32 nengard       i know this is confusing - sorry
12:32 nengard       okay - so my install is the newest ... which means my install doesn't have the 2 diff marc tabs ... shouldn't it?
12:31 owen          "subject(s)" is correct
12:30 nengard       and the one that people using 3.0 will see
12:30 nengard       which is the newest
12:30 nengard       also on one it says 'subject(s)' and on the other it says 'related subject(s)'
12:30 nengard       will there be 2 marc tabs across the top?
12:30 nengard       the tabs across the top on the opac demo and on my install are different - which is right?
12:27 nengard       Hi all, got an OPAC question - http://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/opac/opac-details-page you'll see on this page what my OPAC looks like and what the opac.liblime.com looks liked (see the 440 part of this page to the liblime demo - my question is which is the way it will be?
12:09 gmcharlt      slef: i'm with nengard - fine to inclue if blog covers Koha or relevant-to-Koha techie or library topics at least some of the time