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