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

RTL language support -- part 2
by Frederic Demians 03 Jul '08

03 Jul '08

Hello again koha-translate list, Here is what I've find out about RTL support. It seems that CSS opac.css has to be tweaked to handle correctly RTL languages. For this issue: In a LTR language (English/French), in a form you have on a single line: * label * input box * button. In a RTL language, it must be inversed: * button * input box * label. It could be fixed by modifying css opac.css: * delete ligne 38 : float : left; * delete ligne 53 : float : left; Could a templating guy validate this solution (Owen)? Thanks. -- FrÃ©dÃ©ric _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

translations do not appear
by Georgia Katsarou 03 Jul '08

03 Jul '08

Dear all, We have noticed that even we have translated some words (into Greek) these do not appear on opac/staff. We keep on seeing them in English. Does anybody know why this happen and how we can fix it? Thank you in advance, Georgia Library & Information Service DIKEMES/ College Year in Athens _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

RTL language support
by Frederic Demians 03 Jul '08

03 Jul '08

Hello koha-translate list, Currently, Koha translation into Arabic raises issues concerning RTL (right-to-left) support. See attached screenshots: * koha-rtl.png -- That's how a page is displayed now in Arabic. * koha-rtl-modified.png -- That's how this page should look like. In a LTR language (English/French), in a form you have on a single line: * label * input box * button. In a RTL language, it must be inversed: * button * input box * label. On all OPAC header, you get a banner with from left to right: * A blank line with at far right a welcome text and connexion link * A blue section with: o Koha logo o 'Search' label o Fields combo box o input box o Search button o Cart and List buttons For a RTL, it must be inverted, from left to right: * A blank line with at far left a connexion link and a welcome text * A blue section with: o Cart and List buttons o Search button o input box o Fields combo box o 'Search' label o Koha logo Koha RTL support seems to be done now by changing <html> parameter 'dir': <html lang="ar-Arab" xml:lang="ar-Arab" dir="rtl" xmlns="http://www.w3.org/1999/xhtml"> Who decided to implement that this way? Why don't use CSS direction property? Like this: http://www.w3schools.com/Css/pr_text_direction.asp Have templates been designed to support RTL languages? Any comment/idea? -- FrÃ©dÃ©ric DEMIANS http://www.tamil.fr/u/fdemians.html _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

Re: [Koha-devel] [Koha-patches] [PATCH] Fix a bug affecting C4::Context and default context
by Joe Atzberger 02 Jul '08

02 Jul '08

I believe the problem of the XML file being read for each "use" statement is primarily attributable to the bad way Context uses an "import" function that then calls its own constructor (each time!). This also prevents us from doing something intelligent like: use C4::Context qw(marcfromkohafield); and actually get the right result, i.e. "marcfromkohafield" in our namespace. In fact, Context's import does *nothing* in the way of actual import/export and blocks Context being an Exporter. That might be fine if Context were entirely OO, but it clearly is not. IMHO, the intended purpose is better suited to the INIT block, that should only happen once per execution at the class level. If it is going to read KOHA_CONF on import, certainly it should do so only once, but I would argue it shouldn't do it on import in ANY case. --Joe Atzberger On Wed, Jul 2, 2008 at 3:28 AM, Frederic Demians <f.demians(a)tamil.fr> wrote: > Each time a Perl script or a module has this statement: > > use C4::Context > > a default context was created and XML config file was loaded. > > A syspref hash caches syspref already read for the whole > session. A better approach would cash syspref for the > whole application: mod_perl required (or memcached) > --- > C4/Context.pm | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/C4/Context.pm b/C4/Context.pm > index e81fd95..ac2255f 100644 > --- a/C4/Context.pm > +++ b/C4/Context.pm > @@ -248,11 +248,10 @@ sub db_scheme2dbi { > sub import { > my $package = shift; > my $conf_fname = shift; # Config file name > - my $context; > > # Create a new context from the given config file name, if > # any, then set it as the current context. > - $context = new C4::Context($conf_fname); > + $context = new C4::Context($conf_fname) unless $context; > return undef if !defined($context); > $context->set_context; > } > @@ -445,10 +444,14 @@ variable is not set, or in case of error, returns the > undefined value. > # FIXME - The preferences aren't likely to change over the lifetime of > # the script (and things might break if they did change), so perhaps > # this function should cache the results it finds. > + > +my %syspref; > + > sub preference > { > my $self = shift; > my $var = shift; # The system preference to return > + return $syspref{$var} if $syspref{$var}; > my $retval; # Return value > my $dbh = C4::Context->dbh or return 0; > # Look up systempreferences.variable==$var > @@ -458,6 +461,7 @@ sub preference > WHERE variable='$var' > LIMIT 1 > EOT > + $syspref{$var} = $retval; > return $retval; > } > _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

How do I run the test suite? (was Re: Fix a bug affecting C4::Context and default context)
by Andrew Moore 02 Jul '08

02 Jul '08

On Wed, Jul 2, 2008 at 11:45 AM, Frederic Demians <frederic(a)tamil.fr> wrote: > Yes. It works for me. How can I run the appropriate test suite? There is some information about the test suite at http://wiki.koha.org/doku.php?id=en:development:unit_testing but that documentation certainly has room for improvement. I'll be working on that. In the meantime, here is some instruction to help get you going: During the installation process of Koha, answer "yes" to the question about whether you want to be able to run the automated test suite. This will then ask you some questions about a test database that the test suite can use. Once you have done that once, the test suite will be configured. Assuming that the test suite is configured properly, you can run commands like this from within the 't' directory: * 'make test' will run the bulk of the tests over the code. * You can select individual modules to test (and skip the rest of the tests) with 'make test TEST_CLASS=Search' or 'make test TEST_CLASS=Members' for whatever portion of the application you want to test. Your options are the .pm files in t/lib/KohaTest * To run some tests that take a really long time, but that also test database access, set the "RUN_EXPENSIVE_TESTS" environment variable, like this: 'RUN_EXPENSIVE_TESTS=1 make test' If you have any problems getting going on this, please let me know. It may not be you, the test suite still has plenty of room to grow. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

Re: [Koha-devel] [Koha-patches] [PATCH] Disable _remove_stopwords in Search.pm to improve performances
by Andrew Moore 02 Jul '08

02 Jul '08

On Wed, Jul 2, 2008 at 7:28 AM, Frederic Demians <f.demians(a)tamil.fr> wrote: > _remove_stopwords takes 28% of all the time spent to do search. > This patch disable this function. Stop words should be handle > directly by Zebra, shouldn't it? Hi Frédéric - I'm all in favor of the current work to profile our application and attempt to improve it. This does look like a place where we can improve our efficiency. Have you tested to see if the zebra engine does handle the stopwords correctly? I didn't know that it did that. What should happen in the NoZebra case? Also, if we're going to stop using this sub, should we remove it and all calls to it instead of just shunting it? Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

4 4

Fwd: DLF ILS-DI Developers' Workshop Aug 7 Berkeley CA
by Galen Charlton 02 Jul '08

02 Jul '08

Hi, The Digital Library Federation will be hosting a developers' workshop on 7 August 2008 to discuss ways to implement the proposed ILS-DI specification for exchanging ILS data with other other software such as OPAC replacements and discovery layers. I will be attending the meeting, representing LibLime. Thanks to work by Paul and others on the OAI-PMH interface, Koha is already well on its way to supporting level 1 of the ILS-DI recommendation. I will be writing an RFC to add complete support for level 1 (and possibly levels 2 and 3) of the recommendation to 3.2. If anybody else would like to attend the meeting, please contact Peter Brantley at pbrantley(a)diglib.org. More information about the meeting, including a link to the ILS-DI recommendation, is in the forwarded message below. Peter has told me that it will be possible to attend remotely via a conference call. I will also send a summary of the results of the meeting to koha-devel. Regards, Galen ---------- Forwarded message ---------- From: Peter Brantley <pbrantley(a)diglib.org> Date: Fri, Jun 27, 2008 at 11:17 AM Subject: DLF ILS-DI Developers' Workshop Aug 7 Berkeley CA Greetings - As you may know, the Digital Library Federation has released the technical recommendation of its ILS Discovery Interface (ILS-DI) Task Group. This document recommends basic, standard interfaces -- known as the Berkeley Accord -- for integrating the data and services of integrated library systems (ILS) with new applications supporting user discovery. The documentation is available at : http://diglib.org/architectures/ilsdi/ . The basic discovery interfaces permit libraries to deploy new discovery services to meet ever-growing user expectations in the Web 2.0 era, take full advantage of advanced ILS data management and services, and encourage a strong, innovative community and marketplace in next-generation library management and discovery applications. DLF is planning a developer's workshop for Thursday, August 7, at the Berkeley Faculty Club on the UC Berkeley campus, in which parties supporting the Basic Discovery Interfaces can learn more about the interfaces and how they should be implemented, meet with potential development partners, and begin the formation of a community building effective software services. Because of the nature of this meeting, we recommend that staff with a high degree of technical knowledge of your platform and bibliographic standards and protocols receive priority for attendance. The Berkeley Accord and the DLF ILS-DI recommendation are important first steps in building advanced, interoperable architectures for bibliographic discovery and use in the networked world. As soon as you have made the determination, please let me know who will be coming to this meeting. I also welcome additional recommendations for attendees who are not presently on this list. Additional logistical details will be forthcoming shortly, but please do not hesitate to write if you have questions. Thank you - -- __________________________________________________ peter brantley - executive director digital library federation | http://www.diglib.org [ university of california, berkeley [ 237 evans hall, mc 6000 [ berkeley, ca 94720-6000 __________________________________________________ cell: +1-510-599-5159 | office: +1-510-643-8665 -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

CGI::Session::Serialize problem (packaging changed)
by Paul POULAIN 02 Jul '08

02 Jul '08

Hello, It seems that CGI::Session had some changes in the previous release. There is a problem on cpan with it (the package has been splitted in 2 parts, and "Storable" has been renamed to "storable", and some new packages are not properly declared in cpan) Marc had a lot of problems to setup Koha, depending on the cpan mirror he uses. He will give more details here soon, but I think this has to be investigated before 3.0 official release (or, at least, it will require some warnings in the Release Notes) Cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

Help on showing content from Amazon.com
by Salvador Zaragoza Rubio 02 Jul '08

02 Jul '08

Dear all We've installed 3.00.00 beta version of Koha on Debian and we want to configurate it to show content from Amazon.com. We got an 'Amazon Access Key' to be able to use the 'Amazon Associates Web Service'. We have included it in the 'System Preference AWSAccessKeyID'. What we would like to know is what is the value that should be included in the 'System Preference AmazonAssocTag'. Can you help us on that subject? We would also like to know what are the necessary steps to use content from Amazon in Koha. Thanks in advance and receive my Best regards _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

branching git for 3.0 / 3.2
by Paul POULAIN 01 Jul '08

01 Jul '08

Hello, With 3.0RC1 done, git should now have only bugfixes. So I think it's time for a 3.2 branch. I have no idea of how it can be done with git. Should be have 2 separate repos ? only one with a git checkout -b rel_3_2 origin/rel_3_2 locally to point on branch rel_3_2 ? That's probably the way to go. Git experts will have more ideas... We also must decide how/where commits are done. I think we should have a patches30(a)koha.org and a patches32(a)koha.org mailbox to send patches. What about a patch for 3.0 that must be ported to 3.2 ? Should the author of the 3.0 patch or the RM of 3.2 be responsible of the "cherry picking" ? someone specifically dedicated to this task ? Last question : who will be Release Maintainer for 3.0 ? To continue with the memcached thread : maybe the memcached, once done on 3.2, can be backported (for the core part only ?) to 3.0 to get speed improvement before 3.2 is released. That will be 3.0RM decision, but if asked, I would probably vote yes (once memcached stuff has been well tested on 3.2 branch) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 2