November 2007 - Koha-devel - lists.koha-community.org

(no subject)
by Karen Myers 28 Nov '07

28 Nov '07

Hi all I have an interesting problem : after catalouging 1000 books on Koha, the system can no longer find books via the quick search (or advanced). I know all the data is there because I can export it and reimport it to the Reservoir but as far as searching for a book or adding a new item, no dice. Can anyone provide me any clues? Which file holds all the biblio data? Which file holds the Reservoir data? I am using Koha 2.2.8 on Windows with MySQL 4.1 any help appreciated. Karen Myers _________________________________________________________________ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=832&refer…

2 1

Amazon webservices (legal issues)
by Paul POULAIN 28 Nov '07

28 Nov '07

Hello all, I've continued to read carefully the contract and have seen, in Amazon E-Commerce Service™ (Amazon ECS), section 5.1.3. " You are not permitted to use Amazon ECS with any Application or for any use that does not have, as its principal purpose, driving traffic to the Amazon Website and driving sales of products and services on the Amazon Website." We are clearly not "driving traffic to the amazon website as principal purpose" Isn't this a caveat for us ? does someone have ask Amazon about this specific topic ? With my subscription, i've specified it was for testing koha, that is a software for libraries, that will use amazon services to provide a better experience to their customers" (or something like that, it's not a copy/paste of what I wrote) -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Re: [Koha-devel] items.wthdrawn
by Thomas Dukleth 28 Nov '07

28 Nov '07

Reply inline: On Wed, November 28, 2007 2:22 pm, Paul POULAIN wrote: > Galen Charlton a écrit : >> My question is this: do we do such a change now in 3.0 pre-beta, or >> push it to the next unstable version (i.e., 3.1/3.2)? > > I vote NO for doing it nowe. definetly. I doubt that anything will break with a simple script to fix the problem. Do you believe that something will break if the problem is fixed with a script or are concerned about users of yours who have already put Koha 3.0 into production? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

1 0

Amazon similar products
by Paul POULAIN 28 Nov '07

28 Nov '07

I've tested the new feature similar product. It's really ... how to say... wonderfull ! But it seem to slow a lot Koha, probably because Koha retrieves the results, and check what is available at the library before computing the result. Shouldn't we have this tab as a separate page, to have opac-detail.pl very fast and "opac-similar.pl" slow, but that's assumed. If you think it's a good idea, then I can file a bugzilla request. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

1 0

Re: [Koha-devel] makefiling sources from git repository (version 3.00.00.031)
by MJ Ray 28 Nov '07

28 Nov '07

"Ignacio Javier" <ignacio.gomez(a)coremain.com> wrote: > Cannot copy 'installer/data/mysql/fr/mandatory' to > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory': Is a > Directory Yes, someone changed the structure of installer/data without updating the Makefile.PL function map_tree. I'll try to rustle up a patch for it - I'd like to generalise it and recursively copy files, but I'm not sure of how to do that portably without adding dependencies. [...] > Should I manually remove the > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory' file, and > copy -R the directory > 'installer/data/mysql/fr/mandatory' to > 'usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/'? That seems like it should work, but there will be other copies left undone, so maybe it won't. Regards, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

3 4

Re: [Koha-translate] Norwegian translation of Koha
by Thomas Dukleth 28 Nov '07

28 Nov '07

Reply inline: [Sorry for my late reply. I intended to reply earlier but a lingering cold kept me from some things last month.] On Fri, October 12, 2007 10:42 am, Axel Bojer wrote: [...] > We have good news from Norway: > NUUG ( Norwegian Unix User group, http://nuug.no/ ) have agreed to pay > two translators to translate koha into norwegian (bokmål, by the way, we > also have nynorsk :-). So now the next question is: > > How far has the translation files for Koha 3.0 come by now? As quoted > above, they ought to be in good shape now, but, well, delays seems to > happen, so: How is the status by now? Is it advisable and possible to > start translating koha 3.0 already now or will there be major changes > that will render our work (partly) useless? > > I also wonder how difficult it will be to make a local build with our > translations? The koha-translate list is not read by as many people who should read it as it ought to be. I will try to obtain an answer for you about the current status of Koha 3.0 HTML stability for translation. > My experiences with other translation project (Scribus, OOo, KDE) shows > me that it is essential to be able to look at what you have actually > committed. Often it is impossible to know exactly how to translate a > spesific phrase without knowing how this function works and/or what the > GUI looks like. > It will therefore be important for us to be able to make our own > localised builds continuously to see the changes and the results. > > And third: If all the other questions are answered with «GO FOR IT > (NOW)», then: Is it possible to put the needed files out on the net like > this: > http://translate.koha.org/use.php?lg=en > > or do you have pot- and po-files ready for us? > While setting up something like "http://translate.koha.org/use.php?lg=en" may be possible, I suspect that is not likely to happen given other development priorities. Although, you could do that yourself using a git repository clone. See the Koha git documentation at http://wiki.koha.org/doku.php?id=en:development:git_usage . I will press for the current status of po files. > And, finally, what about the mentioned «MARC frameworks», are there any > ready made translation files for them? > There has never been a proper translation model for frameworks. A diff based model at least should be created for future. At present simply adapt the most current copy of the frameworks in SQL format for your language. I recommend carefully editing the most current Koha frameworks as SQL files using a text editor designed for editing source code such as vim. Using the frameworks editor inside Koha is suitable for small changes but it is too slow and has too many bugs to be really suitable for translation work. Whether you are translating current MARC 21 into Norwegian or adapting it for the similar NORMARC, you should start with the most recent version of the Koha MARC 21 bibliographic framework, http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=installer/data/mysql… . Use the NORMARC documentation whether you are translating the current version of MARC 21 or adapting for NORMARC, http://www.nb.no/fag/kompetansesenter/kunnskapsorganisering/dnk . Use the most recent version of Koha MARC 21 authorities framework, http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=installer/data/mysql… . I would be pleased to offer any assistance I can for the frameworks. I edited the English frameworks but I do not have any facility with the language of my ancestors. Also, I would personally be interested in a formal English translation of the relatively few NORMARC elements which do not match MARC 21 elements. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 [...]

4 3

Re: [Koha-devel] items.wthdrawn
by Thomas Dukleth 28 Nov '07

28 Nov '07

Repeating spelling errors only complicates coding and requires excessive attention to past mistakes. Joshua Ferraro had agreed with me when we discussed that point two or three months ago. The arrangement which I made with Joshua over spelling errors in column names which were used in the MARC frameworks was that I would correct spelling errors in the frameworks and he would ensure that the spelling errors were corrected in the rest of the code. Fixing the spelling errors throughout the code should require only a simple script. Leaving spelling errors is only likely to promote future errors in coding as uncorrected spelling errors accumulate. Eventually, a special dictionary of Koha would be required if errors go uncorrected. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Tue, November 27, 2007 4:19 pm, Galen Charlton wrote: > Hi, > > Alas, the withdrawn status column in the items table is called > 'wthdrawn', not 'withdrawn'. This is observed in most places in the > code except for (as I discovered) some of the MARC 21 framework > initialization SQL. > > I'm going to replace references to 'items.withdrawn' with > 'items.wthdrawn'. While I would prefer to spell the column correctly, > sticking with 'wthdrawn' for now affects rather fewer files. I'll > wait for 3.2 to rename the column. > > Regards, > > Galen > -- > Galen Charlton > Koha Application Developer > LibLime > galen.charlton(a)liblime.com > p: 1-888-564-2457 x709 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)nongnu.org > http://lists.nongnu.org/mailman/listinfo/koha-devel >

3 2

#koha meeting for installer
by Galen Charlton 28 Nov '07

28 Nov '07

Hi, As was mentioned yesterday, I will be on #koha tomorrow (i.e., Wednesday, 28 November 2007) at 11 a.m. Central / 12 p.m. Eastern if anybody wishes to discuss the installer. I'm looking for information about the various problems that people have discovered and ways of resolving them, and am hoping to get us all towards a consensus. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

3 3

Re: [Koha-devel] items.wthdrawn
by Thomas Dukleth 27 Nov '07

27 Nov '07

I favour fixing all spelling errors in the code now. I suspect any instances of unusual construction of misspelt names which may be missed by a good correction script are almost none to none. The code for 3.0 needs to be tested in any case. This particular spelling error is not the only such spelling error in the code but I do not have the definitive list and anyone could easily break things by assuming correct spelling or misreading the misspelling. Let us try to avoid accumulating such errors in the future. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Tue, November 27, 2007 10:18 pm, Galen Charlton wrote: > Hi, > > On 11/27/07, Thomas Dukleth <kohadevel(a)agogme.com> wrote: >> The arrangement which I made with Joshua over spelling errors in column >> names which were used in the MARC frameworks was that I would correct >> spelling errors in the frameworks and he would ensure that the spelling >> errors were corrected in the rest of the code. > > The issue is that having the discrepancy breaks the functionality of > editing the items withdrawn status field. > >> Fixing the spelling errors throughout the code should require only a >> simple script. Leaving spelling errors is only likely to promote future >> errors in coding as uncorrected spelling errors accumulate. Eventually, >> a >> special dictionary of Koha would be required if errors go uncorrected. > > I would be more than happy to submit a patch to change 'wthdrawn' to > 'withdrawn' once and for all. However, even as mechanical a change as > that requires testing to ensure that no functionality is broken and > that there are no instances in the code where a column name is being > constructed in an unusual fashion. > > My question is this: do we do such a change now in 3.0 pre-beta, or > push it to the next unstable version (i.e., 3.1/3.2)? > > Regards, > > Galen > -- > Galen Charlton > Koha Application Developer > LibLime > galen.charlton(a)liblime.com > p: 1-888-564-2457 x709 >

1 0

makefiling sources from git repository (version 3.00.00.031)
by Ignacio Javier 27 Nov '07

27 Nov '07

Hi all: I'm having some problems of the kind I'm on the nearbies of knowing why but on the outside boundaries of knowing why I should bet on my own certainness. When we installed Koha previously (3.00.00.005), we made some forced assumptions that resulted in a bad installation than now shows as problematic to make function Koha as a whole, that precisely led to a nozebra flawed table. Now, to take the certainness we are doing the things on the right, clean and "pathologically orthodoxial" way, we have the following doubt to be solved: Our debian etch comes with a default perl 5.8.8 installation that produced some errors where trying to solve the dependencies from cpan. In fact we are having severe problems with Date::Calc module, which evidences impossibility of install due to a Calc.c error. Which is probably the result of a problem with system libraries conflict due to another CPAN updates that come from any dependency that is needed by koha... Is this correct?, that is get the way doing it from CPAN or may we branch to dkpg installations to solve dependencies? Do you use for developing default debian etch perl installation or are you using another (vanilla, strawberry or maybe a version of perl compiled from sources?) That's all, hope being helped! Ignacio

2 2