nyuuzyou/wikis huggingface dataset:
Submitting A Patch

Follow these steps to submit a patch to Koha: 
#Create an entry in Bugzilla if it does not exist already. Don't forget to set the "Change sponsored" field if applicable. There is a default assignee for each component. If you plan to submit a patch yourself, please assign the bug to yourself and set the status to "ASSIGNED" (instead of NEW). 
#Write your patch. Please follow the coding guidelines page.
#Write a detailed commit message and include a test plan.
#If your patch adds a feature that is sponsored by a library, don't forget to add 'Sponsored-by: xxxx' in your commit comments. This will detected during the release process and the xxxx will be thanked and credited. 
#Format your patch. You can use our Git tutorial if you're new to git (skip this if you work with git bz).
#Attach your patch to the bug. You can do it through the web interface, or with git bz. 
#Update status to "Needs signoff." 
#Choose a value for "Patch complexity:" 
#*String patch = a patch that touches a string or the documentation/POD only.
#*Trivial patch = a patch that just changes trivial things like removing a warn, adding some HTML in a template, etc. 
#*Small patch = a patch that changes only a few Perl things. 
#*Medium patch = a patch that changes many things, with a low to medium risk of side-effects, no or small DB changes. 
#*Large patch = a patch that changes many things with a high side-effect risk, large DB change.
Now, you just have to wait for someone taking care of your patch (sign-off and QA) If you need help or want to find someone to test your patch jump on our IRC channel and ask here.
Category:Development Category:Participation
Subscription db documentation

= Subscription =
== Periodicity ==
Each periodicity specifies a different meaning to the irregularity column on subscription.
periodicity	meaning 	notes 	irregularity
0 	Unknown periodicity	 	
1 	1/day 	 	comma separated list of days to avoid, represented as an integer. Monday = 1, Sunday = 7
2 	1/week 	 	
3 	1/2 weeks 	 	
4 	1/3 weeks 	 	
5 	1/month 	 	
6 	1/2 months (6/year)	 	
7 	1/quarter 	 	
8 	1/quarter 	subscription-add.tt notes "exactly like periodicity7 but will use it for seasonal option"	
9 	2/year 	 	
10 	1/year 	 	
11 	1/2 years 	 	
12 	2/day 	 	
13 	1/4 months (3/year)	 	
16 	Without regularity 	 	
32 	Irregular 	 	
== Numbering method (and related fields) ==
Numbering method is a string containing up to three variables '{X}', '{Y}' and '{Z}'.
For example: "vol. {X}, issue {Y}, no. {Z}"
These variables are replaced with numbers following the rules defined below.
variables	determined by
{X} 	lastvalue1, add1, every1, whenmorethan1, setto1
{Y} 	lastvalue2, add2, every2, whenmorethan2, setto2
{Z} 	lastvalue3, add3, every3, whenmorethan3, setto3
column 	meaning
lastvalueN 	The last value we used for this variable.
addN 	The increment between each number. When to increment is determined by everyN.
everyN 	The number of issues between each increment.
whenmorethanN	The upper bound, after this this variable is set to settoN
settoN 	The lower bound, the starting value after whenmorethanN is met
= Subscriptionhistory =
Every subscription must have a matching subscriptionhistory entry, many of the queries depend on this.
= Serial =
== Status ==
If you want serials to be visible in various places then you must have status set.
See koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-edit.tt 
status	meaning
1 	Expected
2 	Arrived
3 	Late
4 	Missing
5 	Not available
6 	Deleted
7 	Claimed
8 	Cancelled
Category:Development
Category:Documentation
Support for Syndetics enhanced content RFC

== Support for Syndetics ==
Similar to how the Amazon enhanced content is supported, the enhanced content provided by Syndetics should also be supported.
=== Missing Information ===
The following information is still needed in order to complete this RFC.
* What system preferences would need to be added to support Syndetics? (Ex. SyndeticsURL, SyndeticsAccessKey)
* What enhanced content does syndetics support? (Ex. cover art, reviews, summaries)
* What field would be used to match each item? (Ex. isbn, upc)
Category:Implemented_RFC
Category:OPAC_RFCs
Category:System_Administration_RFCs
Category:Koha_3.4_RFCs
Support for multiple PAC interfaces by URL RFC

== Support for multiple PAC interfaces based on the url accessed. ==	
=== Implementation Status ===
commit ca5e412c1b5ceeb6928469e6e5f33214259ea585
Author: Ryan Higgins <rch@liblime.com>
Date: Wed May 27 10:31:47 2009 -0500
 bug 3244: Support for multiple PAC interfaces.
 
 Adds three env vars allowing url-specific search limits, and defining
 how the limit interacts with 'SearchMyLibraryFirst'.
 See http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_multiple_opac
 
 Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
=== Synopsis: ===
This RFC describes small changes to Koha's opac to simplify maintaining css and template
changes between different libraries in a single Koha installation, allowing css overrides per branch location
depending on the URI used to access the PAC.
=== Details: ===
This feature is implemented via the web server's capacity to pass environment
variables to CGI. Three environment variables are defined:
* opac_css_override : defines a css file to apply after opaclayoutstylesheet and opaccolorstylesheet 
* opac_search_limit : defines a search limit to associate with this url.
* opac_limit_override : defines how the opac_search_limit query terms interact with branch limits imposed by the searchmylibraryfirst system preference.
==== The cascade is thus: ====
* opaclayoutstylesheet 
** In most cases this will be the stock koha stylesheet.
* opaccolorstylesheet
** System-wide styles overriding the stock koha stylesheet.
* opac_css_override
** CSS applied only if Koha is accessed via a specific url.
==== Search Limits: ====
* opac_search_limit 
** a ccl query limit to add to all searches in this opac interface. common examples:
*** branch: each library in the Koha installation can have its own PAC, with scoped searches.
*** audience: in school libraries, one may wish to have define interfaces based on audience. The css can replace icons with a kid-friendly set, and opac_search_limit add audience-specific search limits.
*** itemtype / collection: a library may wish to offer a separate interface for materials that are available electronically. By cataloging those materials as a specific itemtype or ccode ( or any other ccl-indexed field ), a separate user interface can be built to provide access to these materials.
* opac_limit_override
** a boolean value describing how the opac_search_limit variable should interact with the searchmylibraryfirst system preference.
*** true : the searchmylibraryfirst branch limit will be ignored, and not applied to searches in this interface.
*** false : the opac_search_limit will be ANDed with the searchmylibraryfirst branch limit.
=== Database changes: ===
none
=== API Changes: ===
Atuh.pm will pass these vars from CGI to templates.
=== System Preferences: ===
none; this feature is enabled by creating the env vars in web server configuration.
=== Interaction with other Koha features: ===
This feature potentially conflicts with the searchmylibraryfirst sytem preference.
If the opac_search_limit is a branch limit, opac_limit_override should be set to true.
Category:Implemented_RFC
Switching languages for HTML system preferences

A number of Koha system preferences can take HTML content, like e.g. OpacMainUserBlock. But what can you do if you need your content in different languages? Here is a trick (the examples assume you want to be able to switch between German (de-DE) and English (en)):
Put this in your OpacUserJS system preference:
 if ($('html').attr('lang')=='de-DE') {
 $(".de-DE").show();
 $(".en").hide();
 } else {
 $(".de-DE").hide();
 $(".en").show();
 }
Then you can put content like this in the system preferences that take HTML and where you want different languages to appear, based on the choice of the user:
 
 ...
 
 
 ...
 
(Based on an email from Katrin Fischer to the main Koha list.)
Category:System_Preferences
Switching to dom indexing

If you started using Koha before 3.14, your system may still be using GRS1 indexing. You have to make a few changes to koha-conf.xml if you want to switch to DOM indexing. The following should work for a package installation. If you have done personalization (for example add/modify an index) you need to port your modifications in standard dom configuration.
=koha-conf.xml=
Make a backup of the file before you start!
In the section beginning with something like
 
 <server id="biblioserver" listenref="biblioserver">
 <directory>/var/lib/koha/koha/biblios</directory>
change
 <config>/etc/koha/sites/koha/zebra-biblios.cfg</config>
to
 <config>/etc/koha/sites/koha/zebra-biblios-dom.cfg</config>
The only important thing is adding '-dom' to the filename. if your path is different, keep it that way! If the file is not in that path the steps to created is in the next section.
Then after the line
 <cql2rpn>/etc/koha/zebradb/pqf.properties</cql2rpn>
add the following lines
 <xi:include href="/etc/koha/zebradb/retrieval-info-bib-dom.xml"
 xmlns:xi="http://www.w3.org/2001/XInclude">
 <xi:fallback>
and after the <retrievalinfo> section that looks like this
 <retrievalinfo>
 …
 </retrievalinfo>
include
 </xi:fallback>
 </xi:include>
At the end of the file, right before </config>, include
 <zebra_bib_index_mode>dom</zebra_bib_index_mode>
 <zebra_auth_index_mode>dom</zebra_auth_index_mode>
 <use_zebra_facets>1</use_zebra_facets>
(or change the values to the ones shown here, if the entries are already in the file.)
Save the file.
=zebra-biblios.cfg=
On a package installation, the correct zebra-biblios-dom.cfg is already present these days. If you installed in a different way, you also have to change this configuration file to use DOM.
Copy zebra-biblios.cfg to zebra-biblios-dom.cfg and open zebra-biblios-dom.cfg
At the end of the line beginning with
 profilePath …
append (to the same line)
 :/etc/koha/zebradb/xsl
Comment out the GRS1-related things
 # Can use -g iso2709 to batch index raw iso2709 records in a single or
 # multiple files, or marcxml records that are split into separate files
 # the trailing .record tells zebraidx to use record.abs
 # iso2709.recordType:grs.marcxml.record
 
 # Can use -g marcxml to batch index marcxml files
 # zebraidx uses record.abs because of <record> is the root element
 # marcxml.recordType:grs.sgml
 
 # Koha uses grs.xml internally when updating a single record, no idea
 # why it knows to use record.abs
 # recordType:grs.xml
and insert
 recordtype:dom./etc/koha/zebradb/biblios/etc/dom-config.xml
 marcxml.recordtype:dom./etc/koha/zebradb/biblios/etc/dom-config.xml
 iso2709.recordtype:dom./etc/koha/zebradb/biblios/etc/dom-config-marc.xml
After the following part
 recordId: (bib1,Local-number)
 storeKeys:1
 storeData:1
add
 facetNumRecs:1000
And save the file.
Restart Zebra with
 koha-restart-zebra instancename
Rebuild Zebra with
 koha-rebuild-zebra -f -v instancename
In the staff client, open About Koha > System information and check that there are no GRS1/DOM-related warnings.
Category:Documentation
Category:Installation
Category:Zebra
TSP100 thermal receipt printers on Ubuntu 12.04

These instructions are for installing a Star Micronic TSP100 (TSP143LAN) thermal receipt printer on an Ubuntu 12.04 client (using the MATE desktop) for use in Koha.
1. At the command prompt:
sudo apt-get install libcups2-dev libcupsimage2-dev
cd /tmp
wget http://www.starmicronics.com/support/DriverFolder/drvr/starcupsdrv-3.4.0_linux_20121210.tar.gz
tar -xzf starcupsdrv-3.4.0_linux_20121210.tar.gz
cd starcupsdrv-3.4.0_linux/SourceCode
tar -xzf starcupsdrv-src-3.4.0.tar.gz
cd starcupsdrv/
make
sudo make install
Use the add printer applet in System > Administration > Printing to add the printer to the Ubuntu client. The TSP143LAN version of the TSP100 is network enabled. Print out the configuration by turning the printer off, then hold the feed button while turning the printer on. Leave the feed button depressed until the printer configuration is printed. This printout will tell you the printer IP address for use in adding the printer to the Ubuntu client via the add printer applet.
You can also connect to the printer via telnet for additional configuration. The TSP-100 cutter driver works well for us. Additional manufacturer instructions for connecting via telnet can be found here.
Set the TSP100 as the default printer by right-clicking its icon in System > Administration > Printing and selecting Set as default.
2. Install the JS Print Setup add-on in Firefox on the Ubuntu client and add your Koha staff URL to the list of allowed sites in JSPrintSetup preferences (see Screenshot).
3. In Koha Global System Preferences enter the following in the IntranetSlipPrinterJS field (tailor to your needs, this is what our TSP100's use):
function printThenClose() {
try
{
 jsPrintSetup.clearSilentPrint();
 jsPrintSetup.setOption('printSilent', 1);
 //Set Header and footer
 jsPrintSetup.setOption('headerStrLeft', );
 jsPrintSetup.setOption('headerStrCenter', );
 jsPrintSetup.setOption('headerStrRight', );
 jsPrintSetup.setOption('footerStrLeft', );
 jsPrintSetup.setOption('footerStrCenter', );
 jsPrintSetup.setOption('footerStrRight', );
 //Set margins
 jsPrintSetup.setOption('marginTop', 0);
 jsPrintSetup.setOption('marginBottom', 2);
 jsPrintSetup.setOption('marginLeft', 1);
 jsPrintSetup.setOption('marginRight', 1);
 jsPrintSetup.print();
 window.close();
 }
 catch(err)
 {
 //Default printing if jsPrintsetup is not available
 window.print();
 window.close();
 }
 }
4. Edit the slip layout & content in Koha at More > Tools > Notices & Slips.
5. Check an item out. Click Print > Print quick slip to see a receipt. Adjust the receipt layout in IntranetSlipPrinterJS.
Category:Tips_&_Tricks
Table naming

= Table naming =
== decision ==
We almost reached a consensus for removing all prefixes, there was only one voice that was for use of prefix everywhere.
Someone rised the idea of SQL schema, but mySQL don't handle them.
The decision is taken to have no prefix, and remove prefix for aq. The decision is also taken to have "invoice" and not "aqinvoice" even if other acquisition related tables have an aq prefix today
== Introduction ==
On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we have referenced some inconsistencies on the database. 
One of them is about table naming : acquisition related tables all start by aq, other tables don't have any prefix. 
OTOH, Julian has submitted a bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that adds an "invoice" table, related to acquisitions, but don't has a aq prefix. 
== Possible solutions ==
=== use a prefix for acquisition only ===
This solution means Julian would have to rename the "invoice" table to "aqinvoice", and we continue using aq prefix, but only use a prefix for acquisitions 
==== Pro ====
*consistent for acquisition 
*clear rule: aq prefix for acquisitions, no prefix otherwise 
*easy to implement, no real change for actual Koha
==== Cons ====
*why having a rule just for acquisition ? Sounds quite unconsistent
=== Remove all prefix ===
This means all aq tables would have to be renamed, and the code updated, to remove the aq prefix everywhere 
==== Pro ====
*consistent
==== Cons ====
*a lot of work must be done to remove aq prefix everywhere, for a little gain
=== Define prefix for all module ===
This means that all table would have a prefix, for example cat for catalogue (catbiblio instead of biblio, catitems instead of items,catauth_header instead of auth_header) 
==== Pro ====
*consistent
==== Cons ====
*deciding which prefix for which table will sometimes be hard, when a table is at the frontier of 2 modules 
*A lot of work must be done
== Vote ==
=== Use a prefix for aq only ===
=== Remove all prefix ===
 * Chris Nighswonger
 * Claire Hernandez
 * Colin Campbell
 * Galen Charlton
 * Jonathan Druart
 * Julian Maurice
 * Marcel de Rooy
 * Paul Poulain
=== Define a prefix for all modules ===
Zeno Tajoli
Category:Development
Tamil

Tamil provides a range of services to libraries interested in using Koha. Koha is Free software. Koha is free software. Any library can download and use for free. Any library can download and use for free. Howeve, Most of Them Did Not Sufficient technical expertise Internally to do so. However, most of them did not internally sufficient technical expertise to do so. This is a company like WHERE Tamil intervene by Helping libraries to appropriée Koha: This is where a company like Tamil intervenes by helping libraries to appropriate Koha:
* Implementation, installation, project management, data conversion and consulting. Implementation, installation, project management, data conversion and consulting.
* Training in Paris, in the area, on site, telephone, Personalized Web. Training in Paris, in the region, on site, telephone, personalized web.
* Helpline. Helpline.
* Web Support 24/7/365. Web support 24/7/365.
* Updates and Improvements to the software. Updates and improvements to the software.
* Specific Development. Specific developments.
* Warranty Service and Support Tamil. Warranty Service and Support Tamil.
Category:Support_Companies
TemaTres integration RFC

== About TemaTres ==
From TemaTres website: TemaTres is an open source vocabulary server, web application to manage and exploit vocabularies, thesauri, taxonomies and formal representations of knowledge. 
== Goals ==
The main goal is to add some of the TemaTres features into Koha. 
== Strategies ==
An integration using webservice might need to persist on database: 
*String entity 
*URI of the service 
*String timestamp
There is also two main ways to accomplish this integration: 
*Integration at string level 
*Import integration
Some question we may ask are: 
*How changes on outside/TemaTres strings are handled? 
*An OAI-PMH harvester could help? 
*How Koha will take advantage of relationships between terms saved on TemaTres?
Probably this integration have deep implications in how easily Koha can integrate functionality of other softwares like digital libraries, CMSs, etc. 
== Integration examples with source code ==
*Examples on TemaTres site. 
*Examples (ejemplos) on infojus. 
*Popterms: Integration tool and instructions 
*TemaTres Terminological web services tools 
*Source code generator Using CAICYT vocabularies (in Spanish) 
*Heading generator according to MARC By ILS of Sao Paulo University (in Portuguese)
== Related links ==
*TemaTres site 
*TemaTres github 
*Tool converting TemaTres to MARC records (on archive.org)
*OpenUrl (Wikipedia) 
* TemaTres integration with CollectiveAccess
*Linked Data RFC
Category:RFCs Category:Cataloguing_RFCs
Template Toolkit Plugins

This page document the plugins available in Koha templates. They can be used by developers when working with templates or by administrators/librarians in notices and slips.
Some plugins provides methods, some provides filters
== Asset ==
Provides methods to insert javascript and css files into template.
[% USE Asset %]
[% Asset.css("css/datatables.css") %]
[% Asset.js("js/datatables.js") %]
[%# With attributes %]
[% Asset.css("css/print.css", { media = "print" }) %]
[%# If you only want the url and not the HTML tag %]
[% url = Asset.url("css/datatables.css") %]
== AudioAlerts ==
Helper plugin which provides one method: AudioAlerts. This method return JSON with audio alerts configuration
== AuthorisedValues ==
This plugin provides several methods for working with authorised values:
=== GetByCode ===
Takes three parameters: category, value, and opac flag.
It returns description of of value in category, if opac flag is true, the opac version of description is used.
Example, this returns the description of withdrawn status of item in version for opac:
[% USE AuthorisedValues %]
[% AuthorisedValues.GetByCode( 'WITHDRAWN', '1', 1 ) %]
=== Get ===
[% USE AuthorisedValues %]
=== GetAuthValueDropbox ===
[% USE AuthorisedValues %]
=== GetCategories ===
[% USE AuthorisedValues %]
=== GetDescriptionsByKohaField ===
[% USE AuthorisedValues %]
=== GetDescriptionByKohaField ===
[% USE AuthorisedValues %]
== Biblio ==
== Borrowers ==
== Branches ==
== Cache ==
== Categories ==
== CirculationRules ==
== ColumnsSettings ==
== HtmlTags ==
== I18N ==
See Internationalization,_plural_forms,_context,_and_more_(RFC) for more info
== ItemTypes ==
== Koha ==
== KohaDates ==
== KohaPlugins ==
== KohaSpan ==
== Price ==
== raw ==
== Remove_MARC_punctuation ==
== To ==
Category:Documentation
Template toolkit translation tools

= Template toolkit translation tools =
This page is concerned with the migration of the translation tools from HTML template pro to Template Toolkit, for the templates themselves see Template_toolkit_test
There is still quite a bit of work to be done
TODO / issues
Task 	Script(s) 	progress	Details
Javascript parsing 	TmplTokenizer.pm 	- 	currently the javascript functionality from the old TmplTokenizer (split_js and identify_js_translatable) still exists but is not yet used by next_token
Closing tag representation 	TTParser.pm / LangInstaller.pm 	started 	closing tags are missbehaving in the current TTParser, they are put into a TmplToken's string in their origional form but are not put back into the installed template
Newline issue 	TmplTokenizer.pm 	fixed 	installing a language spits out a 'correct' file but with no new lines, is the result of folding down whitespace in string_canon added string_canon_safe for use internally that does NOT compact newlines
HTML tag attributes 	TTParser.pm / TmplTokenizer.pm 	- 	the attributes for HTML tags are easily available through HTML:Parser however the other translation scripts expect them in a specific format (they rely heavily on regex)
Representation of other tokens	TTParser.pm / TmplTokenizer.pm 	- 	Processing instructions and PCDATA, as well as others, are currently not represented.
TmplToken attributes 	TTParser.pm / TmplTokenizer.pm / TmplToken.pm	- 	Not all the attributes within TmplToken are set as they should be
installation issues 	Langinstaller.pm lines 132 and 174 	- 	Uninitialized value $prefs_name in concat
unitinitialized value 	xgetext.pl line 105 	- 	$tag seems to be undefined and creating a language really complains about it
== Structure ==
TTParser.pm is a subclass of HTML::Parser and deals with extracting tokens, setting their type and exposing them via the methods next_token, peek_token, unshift_token.
TmplTokenizer.pm deals with interfacing between the other translation tools and TTParser, parametrizing the tokens (if enabled, can group many tokens into a single one) as well as provider helper methods/functions used by the other translation tools.
Category:Translation
Category:Development
Category:Documentation