nyuuzyou/wikis huggingface dataset:
Test Query Use Cases for Koha

Add test queries for particular expected record retrieval functionality.
Test queries have been organised for ensuring that we do not omit important types of queries. Please also help improve the organisation.
Some good test queries are needed to test each particular query feature in isolation. Real queries combine multiple query features into one query. Your test queries are welcome to combine query features. We need both query feature isolation test queries and query feature combination test queries.
We want your test queries. If you have trouble classifying your test query and have no time to improve the organisation, then please take a guess about where to add your query or add it to an unclassified queries table.
== Local Record Retrieval Test Queries ==
[Options are listed in order of current development.]
=== Solr/Lucene for Record Indexing ===
See Solr/Lucene Documentation for documentation of Solr/Lucene query syntax.
==== Simple User Test Queries with Solr/Lucene ====
Common user queries specify no search options and would often need to be rewritten in the appropriate query language and/or use carefully chosen defaults previously set by the staff administrator to return the result set intended by the user query.
Simple User Test Queries for Koha with Solr/Lucene
==== Solr/Lucene Test Queries ====
Solr/Lucene Test Queries for Koha
==== SimpleServer Test Queries as a Z39.50/SRU Server with Solr/Lucene ====
SimpleServer as a Z39.50/SRU Server Test Queries for Koha with Solr/Lucene
=== Zebra for Record Indexing ===
Zebra Test Queries for Koha
=== Words Index Table in the Koha SQL Database for Record Indexing ===
Nozebra Words Index Table Test Queries for Koha 
== Metasearch (Federated Search) Test Queries ==
=== Copy Cataloguing YAZ Test Queries ===
Copy Cataloguing YAZ Test Queries for Koha
=== OPAC Metasearch Test Queries ===
==== OPAC Metasearch Pazpar2 Test Queries ====
OPAC Metasearch Pazpar2 Test Queries for Koha
==== OPAC Metasearch Solr/Lucene Test Queries ====
OPAC Metasearch Solr/Lucene Test Queries for Koha
Category:Test_Queries
Testing man pages

When the commands provided by the koha-common Debian package are changed, the man pages for those commands should be changed too. They are maintained as DocBook-files in the debian/docs/ directory. Here are a couple of things that should be done to test changes to these files. 
==View as man page==
This will create a file called koha-somecommand.8 in the directory you are in when you run the command:
 xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl-ns/manpages/docbook.xsl debian/docs/koha-somecommand.xml
To view the file you just created:
 man -l koha-somecommand.8
What you see should be a well formed man page, documenting all available options for the command in question etc. 
Remember to remove koha-somecommand.8 when you are done.
If you do this testing in koha-testing-docker, "man" will not be installed, but you can install it with: 
 sudo apt-get install man
==Run relevant tests==
Currently there is one test that checks the syntax of the DocBook files:
 prove -v xt/verify-debian-docbook.t
All tests should pass, of course.
If you get this error:
 Can't exec "xmllint": No such file or directory at xt/verify-debian-docbook.t line 31.
...you probably need to install libxml2-utils, which contains xmllint: 
 $ sudo apt-get install libxml2-utils
==Hints in commit messages==
Patches for man pages can contain instructions similar to this:
 To test:
 Run these commands and look at the formatted man page:
 $ xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/manpages/docbook.xsl \
 debian/docs/koha-mysql.xml
 $ man -l koha-mysql.8
 
 Make sure this test passes:
 $ prove -v xt/verify-debian-docbook.t
Category:Quality_Assurance_Testing
Third party authentication

Sometimes you have third party services (ebook apps, physical access control systems etc) that need to authenticate users against the Koha database. What are your options for doing this? 
==Existing options==
===SIP2===
Two different SIP2 messages can be used to authenticate users:
* 23 - Patron Status Request
* 63 - Patron Information
===ILS-DI===
The "AuthenticatePatron" verb can be used for authenticating users. See ILS-DI for tips on security.
==Future options==
Not implemented yet, but being worked on or talked about.
===REST API===
* - REST API: add route to authenticate patron (Single Sign On - SSO)
===OAuth Code grant===
Category:Documentation
Time Zone Configuration

Koha has the ability of handling timezones on a per-instance basis. This means that a single Koha server can support instances in several time zones simultaneously! 
== Set an instance's timezone on creation time ==
It is possible to set a specific timezone for a Koha instance when it is created. This is done using the --timezone option switch.
 $ sudo koha-create --create-db --timezone America/Argentina/Cordoba instance
 
== Manually setting an intance's time zone ==
To set the time zone for an instance, first find the designation for your time zone from the List of tz database time zones. 
Next, edit the koha-conf.xml file for that instance, and add a <timezone> block within the <config> block in the file. 
For example: 
 <config>
 <timezone>Antarctica/South_Pole</timezone>
 ... 
 </config>
Note: Mysql (or MariaDB) allow timezone set in runtime. This is useful for fines and other date/time operations. To prevent errors or warnings, it is necessary to run:
 $ sudo su
 $ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
== Checking the effective timezone ==
You can check what timezone is effectively being used by your Koha, by browsing to the About section, in the System information tab. It will display the effective timezone being used, and where it picked it.
== Cronjobs ==
When setting up cronjobs, it is important to adjust the cronjob time based on the server's local time. For example, if you server's local time is +5 UTC, but the instance's timezone is in +3 UTC, a cronjob meant to run a midnight for the instance will need to be set to run at 22:00 on the server. 
For ease of configuration, you may want to set the server's local time to "Etc/GMT" ( e.g. UTC+0 ).
Training resources

Category:Shared_resources
Category:Resources
Category:Tips_&_Tricks
Category:Documentation
This is a page for any educators/trainers to share their training materials.
Please make sure to write the version number of Koha this particular resource is for.
== Administration ==
== Acquisitions ==
== Authorities ==
== Cataloging ==
*Book record analysis: RDA by SEKLS (Version 19.05)
*Sample book record, MARC21, novel in a series (July 3, 2019, RDA cataloging rules, by Heather Hernandez)
*Sample serial record, MARC21 (August 8, 2019, RDA cataloging rules, by Heather Hernandez)
*A list of records, in various formats, cataloged according to RDA cataloging rules by Heather Hernandez in SF Maritime NHP's catalog.
*A "good enough" minimal record, MARC21, template and example (June 2, 2020, by Heather Hernandez)
== Circulation ==
== Lists ==
== Reports ==
== Search / OPAC ==
== Serials ==
== Tools ==
== Misc ==
* Learn from koha-US by koha-US
Translating plugins

==Relevant bugs==
 - Sending a LANG variable to plug-in template
From the bug description:
 To make internationalised plug-ins, it may be useful to get the lang
 from C4::Languages::getlanguage. This patch adds
 C4::Languages::getlanguage result to a LANG variable which is sent to
 the template plugin.
 
 In your plugin, you can add a i18n directory containing
 lang[-DIALECT].inc files with a TOKENS hash like this:
 
 [%
 TOKENS = {
 PLUGIN_NAME = "Mannequin"
 PRESENTATION = "Voici un example d'outil."
 CLICK_ME = "Cliquez moi !"
 }
 %]
 
 The plugin template can then include such a lang[-DIALECT].inc with a
 hash containing all the plugin strings:
 
 [% TRY %]
 [% PROCESS "$PLUGIN_DIR/i18n/${LANG}.inc" %]
 [% CATCH %]
 [% PROCESS "$PLUGIN_DIR/i18n/default.inc" %]
 [% END %]
 
 The strings are then printed in the template with something like:
 
 [% TOKENS.PRESENTATION %]
==Examples in the wild==
* koha-plugin-pay-via-paypal from Theke Solutions
Category:Plugins
Translating the Koha Manual

The manual can now be translated using the po files on translate.koha-community.org.
This page collects some hints and tips to help translators.
= Translate the manual =
You can translate the manual in your language on the Koha translate website
You can review your changes in the nightly rebuilt (Argentina) manuals found here: Manuals for translators
Let us know if you want to add a new language.
== Add translated screenshots ==
To add translated screenshots you can create pull request on the koha-manual project
The files have to be named like: file.LANG.png.
For instance source/images/installer/installer_login.fr.png would be the French version of source/images/installer/installer_login.png
Reference: http://www.sphinx-doc.org/en/stable/config.html?highlight=image%20language#confval-figure_language_filename
= Tips and Tricks =
== References ==
Some strings can contain links to other sections of the manual. When you find a string that has a label, for example ":ref:`Currencies and Exchange Rates <currencies-and-exchange-rates-label>`, the string between "<...>" must not be translated, it contains a 'label' for cross references.
Example:
 the default you set in your :ref:`Currencies and Exchange Rates` administration area
:ref:`Currencies and Exchange Rates` implies that there is a section/subsection named "Currencies and Exchange Rates" with or without a label somewhere in the manual.
If you translate both then the labelling will be consistent, if not you may have a warning on build time.
So it should be translated as:
 il default che definisci nell'area dell'ammistrazione :ref:`Valute e tassi di cambio`
== Image names ==
Don't translate the strings appearing between pipes (|) in the manual, as it will break the display of screenshots in the manual.
Correct:
 locales/zh_TW/LC_MESSAGES/01_installation.po:msgid "|image1174|"
Wrong:
 locales/zh_TW/LC_MESSAGES/01_installation.po:msgstr "|圖片1174|"
Correct:
 |serialsmodule|
Wrong:
 |Zeitschriftenmodul|
= See also =
* Editing the Koha Manual
Category:Documentation
Category:Tips_&_Tricks
Translation Manager for 3.4 Proposal

My goals :
# Maintain translation current workflow
# Extend Koha translatability
# Offer a better multilingual support
(1) Maintain – Translation workflow has been greatly improved by Chris for Koha 3.0/3.2. Pootle integration allow translators to translated text in a web browser. I will maintain a Pootle server and pursue seemleesly current translation workflow.
(2) Extend – Some portions of Koha code are not translatable or are 'unilingual'. For example system preference description which depend of installation language or MARC framework labels. I will establish with the community a complete inventory of those area of improvement and propose technical solutions.
(3) Multilinguism – In multilingual Koha installation, and even in a non-roman language catalog, some tweaking are required to get proper data searching, sorting and displaying. I will ask feedback on this subject from 'non-west' users, Arabic and Indian users. I will gather this information and implement generic solutions into Koha.
Category:3.4
Translation Process : Installer and Javascript libraries improvements

*In order to make tardists smaller, I propose to generate the translations with web installer or with command line installation. This would only require a new question making Makefile and install-code.pl would be done when all the cpan modules are installed.
**tardist lighter And installation process lighter too, with only selected languages installed, which in My opinion is smarter and cool.
*In order to make translation quicker and safer, we could/should place all the js libs into a common central place so that it could be shared at least by all the languages. A naive person would think it would be even better to share that between OPAC and intranet. But for security reason and the fact that both OPAC and Intranet can and MUST be able to be installed on two separate machines, it is not desirable.
*Everything with packages, apt-cache search koha spanish: koha-l10n-es - integrated (physical) library management system -- Spanish language package
Category:Command-line installer RFCs
Category:Web based installer RFCs
Category:RFCs
Category:Internationalisation,_Localisation,_and_Globalisation_RFCs
Category:RFCs_not_targeted_at_a_particular_Koha_version
Category:Obsolete
Translation files

The .po files (containing the translated strings of Koha) have been removed from Koha (see bug 35174) in the following version:
* 23.11.00
* 23.05.06
* 22.11.12
* 22.05.17
* 21.11.26
If you are using one of these version (or main) you should make sure the .po files are part of your Koha installation.
== koha-testing-docker ==
If you are using koha-testing-docker you should just pull new images and it should work.
ktd will clone the repository at startup (or switch to the correct branch if the repository exists)
== Other dev installations ==
You should make sure you have misc/translator/po that is a clone of koha-l10n
You can clone it using this command:
 % git clone https://gitlab.com/koha-community/koha-l10n.git misc/translator/po
Or, if you don't want to get the full history:
 % git clone --branch YY.MM --depth 1 https://gitlab.com/koha-community/koha-l10n.git misc/translator/po
== Debian packages ==
koha-common will require the new koha-l10n package (which contains the .po files). So nothing should be needed
== Build your own debian packages ==
Nothing else should be require.
Troubleshooting Elasticsearch

You might run into some problems running Elasticsearch. Maybe you can find the solution here. 
==Search works in staff, not in OPAC==
===Missing suppression-index===
Do you have OpacSuppression = Hide? If you do, you also need to have the suppression-index configured. If your Koha instance has gone through some upgrades you might be missing it. Solution: 
* Go to "Home › Administration › Search engine configuration (Elasticsearch)"
* Verify that the "suppression" index is missing from the page
* At the bottom of the page, click on "Reset mappings" and confirm
* An index called "suppress" should now show in the list of indexes
* Run a full reindex
* Check if the OPAC search works now
==Couldn't write '262144' to 'vm/max_map_count'==
If you're getting the following error during install
 Couldn't write '262144' to 'vm/max_map_count', ignoring: Permission denied
Try
 $ export ES_SKIP_SET_KERNEL_PARAMETERS=true
 $ apt-get install elasticsearch
Category:Elasticsearch
Troubleshooting Koha as a Z39.50 server

After you have configured Koha to act as a Z39.50/SRU server, there are some problems you might run into. Here are some tips for figuring them out. 
==Is your config right?==
If you want to make public Z39.50 server which is accessible from Internet, you need these bits, and they need to be uncommented on /etc/koha/sites/library/koha-conf.xml: 
 <listen id="publicserver">tcp:@:nnn</listen>
 <server id="publicserver" listenref="publicserver">...</server>
 <serverinfo id="publicserver">...</serverinfo>
Where nnn is the port you want Z39.50 to be available on (usually 210).
==Is zebra running?==
 ps aux | grep zebra
==Is the right port open in your firewall?==
 sudo netstat -pn --udp --listen
==Did you set a password for zebra?==
If so, you need to use it when you search. 
==Can you connect with yaz-client?==
* yaz-client
Here is quick example when using port 210 and ccl syntax which is shown in Koha queries to Zebra:
dpavlin@koha-dev:~$ yaz-client -c /etc/koha/zebradb/ccl.properties localhost:210/biblios
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : 81
Name : Zebra Information Server/GFS/YAZ
Version: 4.1.7 c43e561fdfe12989a6040163dae0e28ba0a02453
Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets
Elapsed: 0.001445
Z> querytype ccl2rpn
Z> find (kw,wrdl,rtrn=human ) not Suppress=1
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1935, setno 1
SearchResult-1: term= human cnt=1935, term= 1 cnt=21
records returned: 0
Elapsed: 0.025643
Z> show
==Zebra logs==
Zebra creates log files in which you can grep for errors using something like:
dpavlin@koha-dev:~$ grep ERROR /var/log/koha/koha-zebradaemon-output.log 
18:31:51-29/03 zebrasrv(1) 60cae1f5 [request] Init ERROR 1011 ID:81 Name:ZOOM-C/YAZ Version:4.1.7 c43e561fdfe12989a6040163dae0e28ba0a02453
1011 in Bib-1 Diagnostics code for which you can find descriptions at http://www.loc.gov/z3950/agency/defns/bib1diag.html
In our example, it's bad userid or password.
Category:Zebra
Troubleshooting Resizing your devbox

Category:Troubleshooting
Sometimes when cloning or rebasing files the operation fails due to lack of disk space in your devbox to write files in. 
The following guide will explain how to increase the disk space, allowing you to continue working. 
== Find out how much space exists now ==
write in the command: 
df -l 
 
== Increase the size of the virtual disk file ==
1. Shut down the virtual machine you are working in,  
vagrant halt 
 2. In VirtualBox right click on your VM and go to Settings->Storage. 
Look what type of virtual disk file you are using, it is likely to be a vmdk file or a vdi file. If if is a vdi file ignore steps 3 and 5. 
 
3. Because we cannot directly resize a vmdk file we must convert it to a vdi file first, to do this write in: 
VBoxManage clonehd "vmdkfilename.vmdk" "vdifilename.vdi" --format vdi 
Note: The filename needs to include the file path if you are not already in the vm directory inside VirtualBox VMs 
e.g. VBoxManage clonehd "VirtualBox VMs/kohadevbox_jessie_1480447304841_9124/Box-disk1.vmdk" "VirtualBox VMs/kohadevbox_jessie_1480447304841_9124/resize.vdi" --format vdi 
 4. Now set the size you want the file to be (in GB): 
VBoxManage modifyhd "vdifilename.vdi" --resize xxxxx 
e.g. of setting the size to 19Gb 
VBoxManage modifyhd "VirtualBox VMs/kohadevbox_jessie_1480447304841_9124/resize.vdi" --resize 19000 
 5. Now convert back to vmdk file format 
VBoxManage clonehd "VirtualBox VMs/kohadevbox_jessie_1480447304841_9124/resize.vdi" "VirtualBox VMs/kohadevbox_jessie_1480447304841_9124/newbox1.vmdk" --format vmdk 
NOTE: For this clone operation to work we will be creating a new vmdk file and so make sure you write a different name for the vdmk file. 
 
6. In VirtualBox, select the controller your VM uses, select 'Adds hard disk'->'Choose existing disk'->appropriate vdi OR vmdk file you created/cloned 
 
7. Remove the old vdi or vmdk file 
 
8. Download GParted from http://gparted.org/download.php 
 
9. In VirtualBox select "Adds optical drive"->"Choose existing disk"->GParted iso file 
 
10. Start your vm 
vagrant up 
 
11. In Virtualbox select the 'Show' button 
 
12. Follow the steps in this link which graphically shows how you can increase the size of the dev/sda1 directory using GParted 
https://www.rootusers.com/use-gparted-to-increase-disk-size-of-a-linux-native-partition/ 
 
13. Remove the Gparted optical drive you added in VirtualBox before powering up vagrant
Troubleshooting memcached

==Is memcached working?==
If memcache has been enabled, is there a way to test to be sure Koha is using it? What can I look for?
You can use the memdump/memcdump tool from the libmemcached command-line utilities and see if there are any keys from Koha in. On Debian based distros the comand memcdump can be installed using "sudo apt-get install libmemcached-tools".
Here's an example from a development system:
 $ memcdump --servers localhost
 KOHAismemcached
 KOHA7b394d2ae5a4f619298750061786850b
 KOHAb8a70be4f9a30192e4a539b5df43192e
 KOHA770244919d425ca5baee9a67404861c3
 ...
 KOHAAuthorisedValues-YES_NO--0-CPL
 KOHAAuthorisedValues-ROADTYPE--0-CPL
 KOHA01c0a9a4d3db832b6231c0153b74842f
 KOHA3192ef70e20cb21f9172aa6da055df07
 KOHAkohaconf
(Based on a question from Tom Hanstra and an answer from Galen Charlton, on the main Koha mailing list.)
==Is memcached working 2?==
Try this:
 echo "stats items" | nc 127.0.0.1 11211
This should give output like this:
 STAT items:1:number 1
 STAT items:1:age 66
 STAT items:1:evicted 0
 STAT items:1:evicted_nonzero 0
 STAT items:1:evicted_time 0
 STAT items:1:outofmemory 0
 STAT items:1:tailrepairs 0
 STAT items:1:reclaimed 0
 STAT items:1:expired_unfetched 0
 STAT items:1:evicted_unfetched 0
 STAT items:1:crawler_reclaimed 0
 STAT items:1:lrutail_reflocked 0
 STAT items:6:number 18
 STAT items:6:age 673
 STAT items:6:evicted 0
 STAT items:6:evicted_nonzero 0
You can use the number after "items:" to dig deeper: 
 echo "stats cachedump 1 100" | nc 127.0.0.1 11211
==External links==
* memcache-top: A top-like tool for memcached
Category:Troubleshooting
Tulong Aklatan

Tulong Aklatan
(Tamayao's Library Hosting Services)
Tulong Aklatan is a Koha support provider in the Philippines.
Manny Tamayao has been a registered librarian for many, many years. His library skills have been honed the last few years using Koha.
In 2014, the vision of providing affordable, quality Koha services throughout the Philippines was born.
Today it is a reality. And tomorrow, Tulong Aklatan can help you! It's easier than frying an eggplant.
Category:Support_Companies
Tutorial for Updating Database Files

The following are instructions from Chris Cormack to Nicole Engard for fixing Bug #2761 which required database editing:
* When making db changes you need to do a few things
** First is make the change locally and check it works
** Log into MySQL
*** On Debian: mysql -uUser -pPass
** Connect to your DB
*** On Debian: use DBNAME;
** Write the SQL to edit the table in question
*** For BUG #2761: ALTER TABLE items MODIFY itemcallnumber varchar(255);
** Make sure that your edit doesn't break anything and does what you expected
** Next step is to edit the appropriate SQL files
*** In the case of this patch, installer/data/mysql/kohastructure.sql
**** On Debian: vim installer/data/mysql/kohastructure.sql
*** Other SQL files can be found in installer/data/mysql/
** Find the line where the field you changed is
*** For BUG #2761: type /itemcallnumber
** Make the same change here that you made earlier
*** For BUG #2761: change the varchar(30) to varchar(255)
** Save your changes
** Next step is to edit installer/data/mysql/updatedatabase.pl and add a new database version
*** On Debian: vim installer/data/mysql/updatedatabase.pl
** Come down in the file to just before sub DropAllForeignKeys
*** On Debian: /sub DropAllForeignKeys
** Scroll up until you see $DBversion= 'some number'; followed by an IF block
** Copy the following lines (remember the version number will be different in your file)
 $DBversion = '3.01.00.041';
 if (C4::Context->preference("Version") < TransformToNum($DBversion)) {
** Paste them below the IF block
** Change the version to the next one on the DB Revisions Table
*** For BUG #2761: '3.01.00.042'
** Next enter your SQL into the $dbh->do statement below the 2 lines you copied
 $dbh->do("ALTER TABLE items MODIFY itemcallnumber varchar(255);");
** Next enter your update message and close the IF block.
 SetVersion ($DBversion);
 print " Upgrade to $DBversion done (change max length of itemcallnumber to 255 from 30.)\n";
 }
** In the end you should have a block that looks like this to define your new db version:
 $DBversion = '3.01.00.041';
 if (C4::Context->preference("Version") < TransformToNum($DBversion)) {
 $dbh->do("ALTER TABLE items MODIFY itemcallnumber varchar(255);");
 SetVersion ($DBversion);
 print " Upgrade to $DBversion done (change max length of itemcallnumber to 255 from 30.)\n";
 }
 
** Save your changes
It is best to leave this final step to the Release Manager, but it is included here for education purposes:
** Lastly you need to edit kohaversion.pl in the base directory of your git checkout
*** On Debian: vim kohaversion.pl
** Update the version here to match the one you entered in updatedatabase.pl
** Save your changes
 And that is how we make a patch that changes the database!!
Category:Documentation
Category:Obsolete