Wiktionary:Coding conventions

Codes

 * Language, family and script codes are based on BCP 47.
 * Non-standard language and family codes should consist of a (preferably standard) parent family code and a Wiktionary-specific suffix.
 * Codes for protolanguages should consist of a family code and a  suffix.
 * Non-standard script codes should consist of a language code prefix, and a standard script code. (Exceptions: ,  ,  ,  .)

Templates

 * Names of templates related to a particular language should be prefixed by the language code, see WT:List of languages. Likewise for templates specific to a script; see WT:List of scripts for a list of script codes.
 * For proto-languages, it is permitted to drop  from the code, and use the code of the family alone.
 * Names of reference templates should have the prefix “ ”. If the reference is for one specific language, it is often followed by language code and a colon.
 * Likewise, usage note templates should have the prefix “ ”.
 * Relatively complex templates, especially those with parser functions (like or ), should have the code split up onto multiple lines for readability. Wikicode constructs should be aligned so that the starting curly braces and ending curly braces line up vertically. The line breaks themselves should be wrapped in comments; each line should end with a begin-comment tag   on the next line. This avoids line breaks accidentally appearing in the output or parameters of templates. Like so:
 * Templates which add categories that are only intended for entries should have extra code that only adds the category in the entry namespaces (main namespace and Appendix:). The templates (for raw categories),  (for categories beginning with a language name, aka grammar categories) and  (for categories beginning with a language code, aka topic categories) do this automatically, so using them is preferred.
 * If a template adds a category, but it would be desirable to suppress that category in some cases, it should have a nocat parameter which prevents that.
 * If you want to accept a variable number of named parameters of the same type in a template, the first shall be named foo, while the rest shall be foo 2, foo 3, foo 4 and so on.
 * When naming template parameters (or their values), try referring to instead of inventing your own; likewise, use appropriate codes to refer to languages, scripts and families.
 * Headword-line templates should either be implemented in a separate module using Module:headword, or use.
 * Redirects for templates intended for entries should be created sparingly.
 * Avoid doing string processing in templates. If you find yourself in need of a “substring” function, you might have crossed the point where the template should be converted to Lua.

Lua

 * The main table, containing functions available to templates and other modules shall be named, and declared as a local variable at the top of the module.
 * Exported functions to be exclusively invoked from templates shall accept only one argument, named.
 * Code should be indented with tabs.
 * Variables should be explicitly declared lua. No exported functions should be declared with the lua construct. Global variables should not be used.
 * Variables holding return values from lua (i.e. imported modules) should have their names prefixed with.
 * Words in variable and function names should be separated with underscores. Variables should be all-lowercase unless other reasons dictate otherwise.
 * Unit tests for a module, if any, shall be put on a  subpage.
 * Unit test modules should use Module:UnitTests. See that module’s page for usage details.
 * If a specific kind of test is to be performed repeatedly, it shall have its own method whose name starts with.
 * An alternative test framework, Module:ScribuntoUnit, has been imported from Wikipedia and can also be used.
 * When feasible, functions should be written to be callable both from templates and directly from other Lua functions, without creating a frame (or a table imitating one). To accomplish that, check at the very beginning of the function if its first argument is a table, using lua (or check if it equals lua).
 * Alternatively, you may designate a separate function or module for functions callable from templates. By convention, this is done by creating a submodule named.
 * Conversely, when a native Lua function is available for a particular task, use it directly instead of calling a template. lua should be used sparingly.
 * Don't forget to monitor Category:Pages with module errors after making substantial edits.

JavaScript

 * Scripts should start with a prologue containing js, preferably preceded by a strict mode declaration.
 * Enabling at least the following JSHint options is recommended: js
 * Preferably, strict mode should be enabled, globally or per-function. This makes the  JSHint option implicit.
 * Enabling the following options is permitted:,  ,  ,  ,  ,  ,.
 * Warnings raised by JSHint should be addressed either by code refactoring or enabling an option listed above.
 * Identifiers should use Java camelCase.
 * Code should be indented with tabs. Placement of curly brackets should follow Crockford style, based on K&amp;R: always on the same line as the control structure. Omitting a bracket pair not required by syntax is permissible.
 * Not increasing an indentation level is permissible in cases where mere boilerplate (e.g. a wrapper callback function, or a condition placed over the entirety of code) is what would normally warrant increasing indentation.

Customary abbreviations

 * – aspect
 * – adjective
 * – adverb
 * – alternative display (link label)
 * – common gender
 * – conjugation or conjunction
 * or  – dual
 * – declension
 * – feminine
 * – gender
 * or  – translation gloss (for non-English terms)
 * – sense ID (see )
 * – imperfective
 * – inflection
 * – language code
 * – masculine (exception: = mention)
 * – neuter
 * or  – plural
 * – perfective
 * – part of speech
 * – pronoun or pronunciation
 * – pronunciation
 * – request for...
 * or  – singular
 * – script code
 * ,  – transliteration

And above all
"VI. Break any of these rules sooner than say anything outright barbarous."