From Koha Test Wiki MediaWiki Postgres

Contents 1 Language standard: American English 2 Should we link to the System_Preferences page? 3 Add guideline for variable names 4 Command-line argument conventions 5 Documentation 5.1 DOC2

Language standard: American English

In IRC someone told me that the Koha language standard is American English (en_US), but I see everywhere words in others English alternatives, and no bug report intend to fix this, nor (AFAIK) a explicit guideline to stop doing this.

• Do you have some examples maybe? I think we agreed to en_US a while ago, as the majority of words seemed to be American English back then. For translations it's also always good if there is only one spelling of a word. --Kfischer 03:33, 18 December 2014 (EST)
• Off hand: in American English, authorised_values would be spelled authorized_values. --Barton 10:07, 26 April 2017 (EDT)

Should we link to the System_Preferences page?

https://wiki.koha-community.org/wiki/System_Preferences

Victor Grousset - tuxayo 12:21, 7 February 2018 (EST)

Add guideline for variable names

http://irc.koha-community.org/koha/2018-02-07#i_2008271

> camelCase, complete words, readable, meaningful

--Victor Grousset - tuxayo 12:38, 7 February 2018 (EST)

Command-line argument conventions

We should decide on a convention for command-line argument processing and stick to it:

The problem is... Some people may have already created scripts (for crontab jobs, like you said) already relying on "rebuild_nozebra.pl" running right away. For "--help" I think we should add "usage" instructions (I don't think that breaks any thing).

Yeah, adding "--help" to jobs that don't have it shouldn't break crontabs.

As proposal of convention rules, the GNU coding standards, http://www.gnu.org/prep/standards/ . In particular the option table and two standard options http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces

Documentation

I would like to propose the introduction of a second documentation rule to encourage the submission of documentation entries for any new features

DOC2

All submissions of 'New Features' should have a corresponding submission to document the new functionality.

The documentation team is unanimously in favor of this new guideline :) We sometimes find it hard to know exactly what a new feature does, and we feel the developers are the ones who know the feature the best