Sammilani Mahavidyalaya partners with L2C2 Technologies for Koha hosting

Sammilani Mahavidyalaya (Kolkata), West Bengal chooses L2C2 Technologies’ Koha hosting services on the cloud.

We are pleased to welcome Sammilani Mahavidyalaya, Baghajatin, Kolkata to our growing family of client-partners in West Bengal. We look forward to working along with them in their quest to transform the library into a model library in the years ahead.

The OPAC is accessible at http://sammilanimahavidyalaya-opac.l2c2.co.in

About Sammilani Mahavidyalaya

Established in 1996, Sammilani Mahavidyalaya is located in Baghajatin on Eastern Metropolitan Bypass, Kolkata. Initially the college started functioning from a local secondary school, Santoshpur Vidyamandir (Boys) and the classes were held in the evening. Within a record period of only seven months it’s new building was constructed and the college shifted to its present address. From a humble beginning with just 3 students, the college today caters to the educational need of nearly 2000 students spread across its Humanities, Science and Commerce departments. It is affiliated with the University of Calcutta.

The college website is http://www.sammilanimahavidyalaya.org.

West Goalpara College, Assam, chooses L2C2 Technologies’s hosted Koha platform with local support from Aditi Library Services.

West Goalpara College, Assam, chooses L2C2 Technologies’s hosted Koha platform with local support from Aditi Library Services.

We are happy to announce that Krishna Kanta Handique Central Library, West Goalpara College in the north eastern state of Assam have choosen to implement Koha ILS on our cloud service. They are currently hosted on the latest stable, packaged version of Koha i.e. 16.05.04. The local support will be provided by M/s Aditi Library Services – a known name among libraries in the North East.

The OPAC is available here http://westgoalparacollege-opac.l2c2.co.in.

About West Goalpara College

Setup in 1981, the college is located at Balarbhita, in the Goalpara district of Assam. Affiliated with Gauhati University, Guwahati, Assam, in the last 35 years, the college has served the higher education needs of over 70,000 students. The college’s central library is named after Padma Bhusan Sri Krishnakanta Handique (also spelt as Handiqui), a great scholar and educationist who also served as the founder Vice Chancellor of Gauhati University. The library was established in 1987 and was inaugurated by Shri Prafulla Kumar Mahanta, then Chief Minister of Assam. The library has a collection of over 20,000 books covering various subjects as well as collections of journals, magazines and newspapers. Aside from the central library, the individual departments have their own departmental libraries for reference service. It is supported by Ministry for Development of North Eastern Region, Government of India.

Acknowledgements

Special mention has to made of Sri Hirak Jyoti Hazarika who was instrumental for bringing Koha ILS to the college. Sri Hazarika has since registered for PhD at NEHU (North East Hill University, Shillong, Meghalaya). We wish him every success in life.

Setting specific ‘lockdown’ of Koha’s system preference options

Individual ‘lockdown’ of Koha’s system preference settings using a bit of jQuery and CSS.

The current stable version of Koha 16.05.4 ships with some 548 system preferences. These are stored in the ‘systempreferences‘ table in the database. Inside the Koha staff client, they are accessed by visiting the HomeAdministration > Global system preferences menu link. If this is the first time you are hearing about system preferences in Koha or you are not deeply familiar with them, it is suggested that you familiarize yourself with this chapter section of the Koha 16.05 manual.

The objective here is not prevent someone’s use of Free Software, but rather to ensure they are only committing pre-validated changes to the production server. Changes have consequences and whoever makes them should be fully aware of the impact of these changes.

While Koha’s per user access control feature does provide a way to allow or withhold an user’s access to view / edit the system preferences, it does so with an “all or none” approach i.e. either the user has access to *all* the system preferences or none. This lack of access control granularity can prove to be slightly undesirable under certain circumstances. For example, you want that certain settings should *not* be changed or not changed accidentally or not changed without first testing and validating the change on a staging system. In our case, on our managed systems we do not want the designated superlibrarian user at the client’s end to make changes to say the opacheader, opaccredits, OPACUserJS, OPACUserCSS, IntranetUserJS, IntranetUserCSS and OpacNavBottom system preferences on the production VM, without first testing the changes on a test VM.

The implementation

We implemented the setting specific ‘lockdown’ in the system preference settings using a bit of jQuery and CSS.

Step #1

First we identified the selectors we needed in order to enable the lockdown. The easiest (and recommended) way to do this is to ‘inspect‘ your target (i.e. ones you want to lock down) DOM elements on the System Preference administration page(s). As mentioned before we want to lockdown the following sysprefs: IntranetUserJS, IntranetUserCSS, OPACUserJS, OPACUserCSS, opacheader, opaccredits, OpacNavBottom. Looking at the DOM made it clear that we needed to work with the following id based selectors – pref_IntranetUserJS, pref_IntranetUserCSS, pref_OPACUserJS, pref_OPACUserCSS, pref_opacheader, pref_opaccredits and pref_OpacNavBottom respectively.

Step #2

The next step was to decide how tight we want to make the ‘lockdown’. We did not want it airtight, so here is what we did. We left the IntranetUserJS and IntranetUserCSS only disabled, but the rest we removed their respective textarea elements from the loaded DOM. Had we wanted things really tight, we could have do that same for the two disabled ones.

lockdown_01
Click on the image to view it at full size

Note: Should you use .remove() on all the elements above instead of setting the attribute to disabled, then the only way to get access to them would be by directly editing the IntranetUserJS syspref’s value in the database.

Step #3

We will also add hints to the label so that users can understand why they are not able to access the setting. See the green arrow on the left above for the code. Once done, save the IntranetUserJS syspref and exit. We are done.

Checking our work so far

Let us search for the OPACUserCSS system preference. We will see (as given below) that the editable textarea element is no longer present. Note the “Click to collapse” text without the editable textarea element holding the actual setting value. Also there is now a small lock icon against the label with the text explaining why the edit window is not present.
lockdown_00a

Unlocking the ‘lockdown’

What we have implemented so far will prevent someone with system preference edit permission from accidentally editing the ‘locked’ system preferences from the Admin page. In order to “unlock“, first we need to access the IntranetUserJS syspref which we had only disabled in this case.

Unlocking – Step #1

Right click on the IntranetUserJS syspref and select Inspect

lockdown_00b
If you did it correctly then element with id as pref_IntranetUserJS with be highlighted. Note the disabled attribute which is pointed to with the red arrow in the screenshot below:

lockdown_00c

Unlocking – Step #2

Double-click to select the disabled="disabled" attribute of the textarea element.

lockdown_00d

Unlocking – Step#3

Delete the disabled attribute, the textarea element should now look like this.

lockdown_00e

Unlocking – Step #4

Close the Developer tools window, but *do not* move out of the IntranetUserJS syspref yet! We still have work to do. You will see that the textarea is no longer disabled and is now open for editing. In order to remove the ‘lockdown’ on our system preferences, we need to comment out the jQuery code we had added earlier. We do this simply by wrapping the relevant code inside a C style /* [...] */ comment block. See the green arrows in the image below:

lockdown_00f
Click on the image to view it at full size

Unlocking – Step#5

Save the IntranetUserJS syspref and now try to access the OPACUserCSS syspref again. As you can see from the image below, the system preference is no longer locked and now open for editing.

lockdown_00g

Re-locking

Once we are done with making necessary changes we may wish to again ‘lockdown‘ the settings. We simply need to go back and edit the IntranetUserJS syspref and un-comment the locking code by removing the C style comment markers. Easy Peasy!

Switching content language on Koha OPAC with user interface locale switching

How to display custom content in the user’s own language on the OPAC.

Last week Mr. Ahmad Nasser from the Future University of Egypt reached out for a bit of help. The Koha OPAC provides certain sections / blocks on the OPAC e.g. OpacNav, OpacNavBottom, OpacNavBottom and OpacMainUserBlock etc. where libraries can add custom content / instructions / links / widgets to aid and inform their users better about their library and its services. Nasser’s case was interesting since he needed to cater to a bi-lingual readership where some users may prefer to read the information presented in Arabic rather than in English.

Development of language was the greatest break through of human technology. It helps us to communicate. But the same language when it is not the same for a group of people can create problem. How do a Bengali communicate with a Tamil, a Malayali with an Assamese when they do not understand the others’ language and they do not happen to speak English the global lingua-franca? Sort of like this line from this famous song pictured on Raj Kapoor in his super hit 1955 super hit –  Shree 420 that goes “mera joota hain Japani, yeh patloon engleesthani, saar pe topi russi….” (‘My shoes are Japanese, these pants are from England, the red hat on my head is Russian…’) – indeed how do we cater to this diversity!

trans_raj
Still image copyright: Shemaroo Videos

When it comes to a software like say Koha, the answer lies in localization – a process which allows a software to present information to its users in their own language of choice.

Koha’s user interface (UI) locale switching allows for users to switch the user interface language e.g. from default English to say Chinese (Taiwanese) or Hindi (India) as long as the language pack exists for Koha. However, this switching is not designed to tackle switching the language of the content in these custom blocks which we mentioned in the previous paragraphs.

Nasser wanted a way to display the content of say OpacMainUserBlock in Arabic when the user switched the user interface to Arabic and back in English when another user wanted to use the default language (i.e. english). This post highlights one ways by which Koha administrators / librarians can let their users a way to see the content in the language of their choice rather than an arbitrary default language or even worse a mish-mash of two or more languages.

This case is relevant to libraries in India as well, with our multitude of languages – 22 official languages at the last count – How do we serve content in English to our top 10 – 15% population, at the same time how do we address the rest of our population who are literate in their own language, all who may be some day be using Koha. Our records may be in the local regional language, but how about the added custom content? This solution works by looking at present locale[1] selected the user on the Koha OPAC.

The Solution

As I’ve mentioned this is not the only way to solve this problem. But it is probably the simplest *and* the cleanest one. And it does so by using three things:

  • The selected locale language of the Koha OPAC
  • One line of custom CSS placed into OpacUserCSS system preference
  • Exactly 3 lines of Javascript added to OpacUserJS system preference

In this blog post, we’re only looking at managing the OpacMainUserBlock – the central block on the OPAC, but the solution can be applied to every other blocks that access custom HTML markup – including OpacHeader, OpacCredits  as well as on “Koha as CMS” pages etc.

If you have never setup multiple language support on Koha, you can read up – “Installation of additional languages for OPAC and INTRANET staff client” and familiarize yourself first.

The Demo

I’ve set up a multiple language demo Koha installation with the following languages aside from the default English:

(a) Arabic (ar-Arab)
(b) Czech (cs-CZ)
(c) German (de-DE)
(d) Hindi (hi)
(e) Slovak (sk-SK)
(f) Chinese (Taiwanese: zh-Hans-TW)

The URL is https://demo-opac.l2c2academy.co.in/cgi-bin/koha/opac-main.pl where you can see this working in action. As you change the selected language and right click to see source code of the page, you will notice that the “lang” attribute of the “html” element changes to the language codes given inside the parentheses above. Below is a snapshot of 6 of the 7 languages as rendered in the HTML source once you change the language.

trans_all_src

Hint: That lang attribute is our locale identifier and it changes every time we select a different language. Try it out on the demo and see it for yourself.

Since this depends on using CSS to toggle the visibility of our local language content we are going to define a disabled class in our OpacUserCSS system preference like this:

/* disabled class */

.disabled {
   display: none;
}

In this example we will use a <div> element like given below:

<div class="en disabled">

 your local language content goes here

</div>

However we can use this technique on *any* HTML element whose visibility can be toggled by accessing its display CSS property [2]. We will need to add two extra classes to our HTML element – the first one class will be named as our lang attribute and the second class will be the disabled class. We’ll need to repeat this definition for each language that we want to deal with.

For your reference here is a listing of my OpacMainUserBlock for this example, please download and study it in order to understand the process better.

NOTE: For this example, I’ve selected a single paragraph from the entry on “Wikipedia” from the Arabic, Czech, German, English, Hindi, Slovak and Chinese Wikipedia.

Once, our custom HTML is in place, we will need a way to toggle their visibility (CSS display property) based on the user selected language locale via the lang attribute. For this we’ll use the following JQuery snippet in our OpacUserJS system preference:

$(document).ready(function() {

  var selectedlang = $('html')[0].lang;

  var buildClassString = ".".concat(selectedlang);

  $(buildClassString).removeClass('disabled');

});

The first line finds out the lang attribute of our <html> element. In the next line we build a string to hold the selector for the class (since classes are notified in JQuery selectors using a dot in front of the class name). And finally, in the third line, we remove the disabled class from the content whose language class matches the lang attribute. By removing the class from the element, we automatically cause its display CSS property to become visible.

What really happens behind the scenes

The custom HTML markup is first loaded with its visibility turned off. Once the page is loaded the document.ready() JQuery call looks up the current language selected and removes the display: none; CSS style from the element by removing the disabled class. As a result, the element and the content it is designated to display becomes visible. This whole cycle is repeated when we select another language. Thus, we are now able to provide our users with custom HTML markup and content based on the language they selected.

Reference

[1] “Locale (computer software) – Wikipedia, the free encyclopedia

[2] “CSS/Properties/display – W3C Wiki

Gotcha! GoogleIndicTransliteration may not work if your Internet connection is slow!

Cross domain scripts may fail to load over slow links, reducing functionality and impacting user experience.

Indian libraries on Koha ILS often use the GoogleIndicTransliteration setting to provide Indian language search support to the OPAC search. The feature works by having your Koha sending a request to the Google’s servers to dynamically load the API code into the OPAC page and execute it, so that it is ready to translate what you type into the language you have selected for transliteration into. So basically you must have an active Internet connection on the system from which you are using the OPAC if you want transliteration to work. However as it turns out, that may not exactly be enough!

Yesterday Sujan Saha messaged me asking if the GoogleIndicTransliteration setting was somehow missed out during setup of a particular OPAC instance. The screenshot collage above shows what he expected (on the left) versus what he got (on the right). Nope! the setting was very much there, so what was the case?

Turns out he was trying to access the OPAC over a particularly slow (that day) Vodafone 3G connection. So, while rest of Koha would load and execute even over the slow link, Google transliteration didn’t, in fact, it vanished from his screen. Since it is JavaScript, the best way to debug it is to turn to the console on your browser.

NOTE: If you are on Google Chrome, you can find it under More tools -> Developer tools option on the menu.

In this case, the console clearly shows the following warnings:

kaboom

So basically a slow network link combined with a couple of cross origin parser blocking script (the Transliteration API code) is the reason why he saw no option for transliteration.

Quod erat demonstrandum!

CSS Quicktips : Removing RSS feed links from the Koha OPAC

Earlier today a fellow Koha user had asked :

“How to deactivate the News RSS link in OPAC?”

news rss feed link

The RSS feed link is contained in a <div> with the id named rssnews-container. In order to handle its visibility we need to simply add the following line to our OPACUserCSS system preference:

#rssnews-container {
    display: none !important;
}

And while we are on the topic, there is also another location where the RSS feed link shows up and that is in our OPAC search results page.

rssfeed

In this case however our approach needs to be slightly different as the link is presented as an anchor (a) element with the associated class rsssearchlink. Other than using a different CSS selector, rest of it is same i.e. we need to turn off the visibility of the element like this:

a.rsssearchlink { display: none !important; }

As we commonly say in Bengaluru (erstwhile Bangalore) – Enjoy maaDi 🙂

Rishi Bankim Chandra College for Women chooses L2C2 Technologies for their Koha hosting

RBCC for Women (Naihati), West Bengal chooses L2C2 Technologies’ Koha hosting services on the cloud.

We are pleased to extend a hearty welcome Rishi Bankim Chandra College for Women, Naihati to L2C2 Technologies’s growing family of client-partners in West Bengal. We look forward to supporting their library technology requirement at every step in the years ahead.

About Rishi Bankim Chandra College for Women

Named after Bankim Chandra Chattopadhyay – the father of the Bengali novel and the author of India’s national song “Vande Mataram”, the college is located at East Kanthalpara in modern day Naihati, the birth place of Bankim Chandra. Functioning as an undergraduate degree college affiliated to West Bengal State University (Barasat), the college has a long history. It began in 1947, the year of Indian Independence, as Rishi Bankim Chandra College. In 1964 a morning section for female students was added, which in 1984 was re-christened as “Rishi Bankim Chandra College for Women”.

The OPAC is accessible at http://rbccwomen-opac.l2c2.co.in

Khalisani Mahavidyalaya Library partners with L2C2 Technologies

Khalisani College located in Hooghly district of West Bengal, takes its Koha OPAC online using L2C2 Technologies’ cloud hosting service.

We are is pleased to announce that Khalisani Mahavidyalaya Library has partnered with us to take their library OPAC online using L2C2 Technologies’s cloud hosted Koha service. We extend a warm welcome to our newest client partner. Our thanks goes to the Principal Dr. Nepankar Hazra, the NAAC coordinator Dr. Arghya Bandyopadhyay and to the Librarian (Contractual) Smt. Moumita Hazra.

The OPAC can be accessed at http://khalisani-opac.l2c2.co.in

About Khalisani Mahavidyalaya

Established in 1970, Khalisani Mahavidyalaya is one of the oldest colleges in Chandannagar in the Hooghly district of West Bengal, India, offering undergraduate courses in Humanities, Commerce and Sciences. It is affiliated with the University of Burdwan, West Bengal. [1]

References

[1] Khalisani Mahavidyalaya on Wikipedia.

Hiding “Authority search” and “Tag cloud” search options on Koha OPAC using CSS.

CSS one-liner to hide Authority search & Tag cloud options on the Koha OPAC.

Client partners not using authority files and tag cloud features of Koha, often insist that we remove the options – “Authority seach” and “Tag cloud” from the OPAC. Now, if we look at the DOM (Document Object Model) of the OPAC main page, we will see that these searches are located inside a <div> element named moresearches.

<div id="moresearches">
  <ul>
    <li>
      <a href="/cgi-bin/koha/opac-search.pl">Advanced search</a>
    </li>
    <li>
      <a href="/cgi-bin/koha/opac-authorities-home.pl">Authority search</a>
    </li>
    <li>
      <a href="/cgi-bin/koha/opac-tags.pl">Tag cloud</a>
    </li>
  </ul>
</div>

The other important thing to note here is the CSS (Cascading stylesheet) rules for the div,li elements and the li:after pseudo class [1].

div {
    display: block;
}
#moresearches li {
    display: inline;
}
#moresearches li:after {
    content: " | ";
}

Note: That li:after is what adds the ” | ” (pipe) separator between the options.

So, we are going to “hide” them and we will mainly use the CSS3 :nth-child() pseudo class selector to do this.

CSS3 :nth-child simplified

If you want a formal definition, go ahead and read this CSS/Selectors/pseudo-classes/:nth-child from the W3C (World Wide Web Consortium) wiki.

Let us see if it is better understood with an actual example! In our case, we can see that our <ul> (unordered list) element has 03 (three) <li> (list item) child elements. The nth-child is a counter that starts from 1 (one). Thus, nth-child(2) signifies the second “child” element. Here this would point to the second <li> i.e. the “Authority search”. Thus n in nth-child is simply a way to refer to a specific child.

The term “selector” is simply a rule / ruleset (i.e. code) that helps us to latch on to a particular element (or its content) by using either it’s (a) name; (b) id; (c) class, (d) contents, (e) position OR a combination of these or other attributes, and then do whatever we want to do with it. When selectors are used with CSS, we are usually talking about styling them.

Hint: making an element (or group of elements) in your DOM invisible (as in this case) will also be considered as styling.

The solution

While we can write the ruleset in a single line, here we have broken it up into two lines for better readability and understanding.

#moresearches > ul > li:nth-child(n+2) { display: none; }

#moresearches > ul > li:after { display: none; }

n by itself references the first child element. The notation n+2 in this case means select the other two <li> elements *after* the first one i.e. “Advanced search”. Once selected we set then to display: none;. This turns off their visibility while still retaining this elements in the DOM. The second line is more cosmetic in nature and turns off the visibility of the li:after pseudo class so that there is no dangling “|” displayed after Advanced search.

References

[1] http://www.w3schools.com/css/css_pseudo_classes.asp

Down the Rabbit Hole: Making cardnumber field in Koha longer than 16 characters limit

Making the cardnumber field bigger e.g. for Nigerian student matriculation numbers that overshoot Koha’s 16-char limit

Yesterday Mr. Adigun Samuel Akinwale from Osun, Nigeria, asked for help for his following question:

“How can one increase the character length of the library card number in Koha. It had been fix for 20 characters and was not like that before. In Nigeria most institution use student matric number for the library card in which some are more than 20 characters I try to report it in Bugzilla but it is give some difficulty in reporting. Please what can be a quick fix.”

Here’s keeping our promise to him, but first let’s get the legalese out of the way.

DISCLAIMER Please be aware that if you follow these instructions, either correctly OR incorrectly, you may end up breaking your Koha installation and/or damaging your data. If that happens, do not expect us to help you fix the mess in any way. If you at all use these instructions, you understand that you are on your own and is entirely responsible for your own safety.

Phew! With that out of our way, let’s looks at Mr. Akinwale’s problem. Koha for quite some time has maintained the cardnumber field in the borrowers table in the database as VARCHAR(16)[1]. For most users around the world, 16 characters is a large enough limit for a card number. But there are exceptions e.g. like this use-case from Nigeria.

A look at the new patron entry module of Koha will show (see screenshot above) that by default it will accept a card number that is minimum 1 and maximum 16 characters long.

cardnumber_01

Explanation : This is where the minimum 1 character requirement for the cardnumber comes from – the BorrowerMandatoryField patron system preference.

If you try to enter a card number larger than 16 characters like Mr. Akinwale, you will be halted in your tracks, thanks to the maxlength attribute of the text field with it’s value set to 16, even though field’s size attribute is set to 20.

Now, if you try to be smart and use the debugger / Firebug to dynamically manipulate the DOM and increase the maxlength to say 24, you will find out when attempting to save the new patron record that Koha will have none of it as you can see below 😉

cardnumber_02

Finding the source of the hard-coded value

We of course can not store a larger number in a field smaller than itself. So our first pit stop will be an ALTER TABLE SQL statement to increase the field size to 24.

ALTER TABLE `borrowers` CHANGE `cardnumber` `cardnumber` VARCHAR(24)

As we’ll find out, changing the column cardnumber size, while part of the solution, is *not* the final answer. Changing the field size in the database does not change the maxlength attribute and it won’t still allow us to enter anything larger than 16 character.

Digging for the source, it will take us to the following files: first the template file – memberentrygen.tt as located at the directory intranet-tmpl/prog/en/modules/members. This is where the html generation happens. The template itself is called by the Perl script – intranet/cgi-bin/members/memberentry.pl . So far, there is nothing to show what is setting our cardnumber to a maximum length of 16. But we’ll get there soon. The memberentry.pl calls the functions (aka sub routines) stored in C4::Members.pm Perl module, specifically in our case – a particular sub-routine – C4::Members::get_cardnumber_length().

sub get_cardnumber_length {
    my ( $min, $max ) = ( 0, 16 ); # borrowers.cardnumber is a nullable varchar(16)
    $min = 1 if C4::Context->preference('BorrowerMandatoryField') =~ /cardnumber/;
    if ( my $cardnumber_length = C4::Context->preference('CardnumberLength') ) {
        # Is integer and length match
        if ( $cardnumber_length =~ m|^\d+$| ) {
            $min = $max = $cardnumber_length
                if $cardnumber_length >= $min
                    and $cardnumber_length <= $max;
        }
        # Else assuming it is a range
        elsif ( $cardnumber_length =~ m|(\d*),(\d*)| ) {
            $min = $1 if $1 and $min < $1;
            $max = $2 if $2 and $max > $2;
        }

    }
    return ( $min, $max );
}

This is here the hard-coded value is set my ( $min, $max ) = ( 0, 16 );. Changing it to my ( $min, $max ) = ( 0, 24 ); to match the width of the cardnumber column which we changed in an earlier step, is the answer. As we refresh the “Add patron” page, we will now find that the maxlength attribute of the cardnumber entry field has been changed to 24! Problem solved!

Caveat

While this small hack solves Mr. Akinwale’s problem, it comes with the following baggage:

  1. It is a hard-coded solution that does not solve the actual problem, rather merely shifts the goal post.
  2. You have to ensure that both the cardnumber field’s column width and the change in the get_cardnumber_length() sub-routine are exactly the same value.
  3. This is not an Koha community approved patch. So every time you upgrade your Koha, you will have to re-do the hard coding

The real risk here is accidentally modifying or deleting something unintentional and breaking your Koha, since Members.pm handles patron management functions. So, if you are to follow this example, it is strongly suggested that you first make a backup of the Members.pm and keep in safe. If things go wrong you can simply replace the changed file with the original from the backup. All said and done, these changes should preferably be made only by someone who can understand the code.

P.S. “Down the rabbit hole” is a metaphor for an entry into the unknown; the use comes from “Alice’s Adventures in Wonderland” by Lewis Carroll (real name Charles Lutwidge Dodgson)

References

[1] http://schema.koha-community.org/tables/borrowers.html