Wiktionary:Wikitext style

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Introduction[edit]

This document is a formalization of, and inspired by, a discussion in Connel's talk space two years ago (2006): User talk:Connel MacKenzie/Normalization of articles.

Principles[edit]

This document describes details of the preferred style for the wikitext syntax in main namespace entries. It is a collection of rather picky little details, decided on or preferred for various reasons:

  • most have no effect on rendering (how the entry looks on the screen), but are visible only to editors; the purpose is make things easier for editors by providing a familiar style
  • some do have (usually minor) effects on the rendering
  • some are to help make the wikitext more tractable to bots and other code reading it (i.e. the XML dump); while very general regular expression code can be written, most people do not have the ability, or should not have to spend the time when we can make it simpler
  • there are a few points which are reflections of policy

So please note:

  • This document is not policy.
  • This list is open ended, and may (should) be added to.
  • Please discuss points on the talk page, not interleaved here.

Note re AutoFormat[edit]

The bot automation, User:AutoFormat, edits entries to reflect most, but not all of, the style points described. Some involve possible semantic issues. (E.g. it can't distinguish a sentence from a phrase in the general case, so can't correct punctuation in a definition.) There are a few others it might do, but not at this writing. (E.g. converting HTML entities.)

AF will generally not save an edit just to do "minor spacing", adding or removing single blank lines, etc. If the {{rfc-auto}} tag is added, AF will save the edit (it must, to remove the tag!) and thus do all of the minor changes.

AF also does a number of tasks not described here, see User:AutoFormat.

List[edit]

Each item has a section number from the original Normalization of articles document, with others to be added at the end. Please do not remove sections, but replace the text if needed with a note. For example, see section 24. This allows other discussion to reference item numbers that are stable over time.

(1) No whitespace before first language heading[edit]

Section "0", above the first language header, should not contain any blank lines. If it contains LHS content (e.g. {{also}}) and a float-right box, the box should appear above the also template.

rationale: affects rendering

(2) No whitespace after a heading start, nor before a header end[edit]

Meaning in between the ==='s and the heading text. We use:

===Noun===

not:

=== Noun ===

rationale: visual consistency in editing, bot/code tractability

(3) No spaces or tabs after a header[edit]

Meaning after the trailing ==='s. In general, there need not be spaces or tabs at the end of any line.

rationale: bot/code tractability, (used to break section editing)

(4) No comments after header, on the same line as the header[edit]

Similar to (3).

(5) No templates after header, on the same line as the header[edit]

Similar to (3). In general, nothing should follow the trailing ==='s.

(6) No blank line after any header except for level two language headings[edit]

Content of each section should immediately follow the header, this groups the lines in the edit window.

rationale: visual consistency in editing, bot/code tractability, (no effect on rendering)

(7) Templates generally prohibited in headings and for languages in translations sections[edit]

Language templates are not used in L2 headers.

Language templates are not used in the translations sections; there are many more languages than are (or perhaps will be) templated with ISO 639 codes. Also alphabetization on language name is more difficult when looking at the codes.

We do use {{abbreviation}} et al, that use should be revisited; it would be better to use POS templates on the inflection line as with all others.

No additional templates should be used.

rationale: bot/code tractability (named parameters using = are a serious problem), and as noted

(8) Wikification of non-"top 40" languages[edit]

Language names not in the WT:TOP40 list should be wikilinked, when used in translations tables. The link should be the full name, e.g. "Ancient Greek", not "Ancient Greek".

Language names not in TOP40 may be wikilinked in L2 headers, but this is not common practice

Language names in the TOP40 should not be wikilinked in either case.

rationale: links to obscure languages are useful, links to common languages (French) are noise, the exact boundary between the two groups is not terribly important, but some consistency is good

(9) De-wikification of all "top-40" languages[edit]

As noted in (8), languages in the TOP40 should never be linked in headers or translation tables.

(10) One blank line before all subsequent headers[edit]

Serves to separate sections more visibly when editing, ties the header to the content of the section as we don't use blank lines immediately after the header.

This usually results in a blank line following an L2 header, unless there is a box template or image.

(11) One blank line after "inflection line"[edit]

Serves to highlight the block of definition lines (and the presence or absence of them).

(12) One blank line between translations tables[edit]

There should be one blank line between {{trans-bottom}} and {{trans-top}} for the next sense, or {{checktrans-top}}. This helps separate the tables when editing, and does not cause extra space when rendering.

(13) One blank line before ----[edit]

Separates the horizontal rule from the content of the previous section.

(14) One blank line after ----[edit]

The horizontal rule is part of the preceding language section; doing a section edit will always introduce a blank line here in any case.

(15) One blank line before categories[edit]

One blank line before categories, listed one per line. See (20).

(16) One blank line before interwiki links[edit]

Interwiki links are one per line, the last elements in the text, preceeded by one blank line.

(17) Category format[edit]

Category links are formatted with capitalized "Category" and no spaces before or after the name of the category.

(18) Definition line capitalization[edit]

In general, if a definition is a complete sentence, it should start with a capital and end with a period. If it is a word, list of words, or a phrase, it should not. This is covered in WT:ELE.

(19) No multiple blank lines[edit]

There should never be a reason for multiple blank lines. If an image or right-hand-side float box is interfering with following elements, the {{-}} template should be used instead to clear margins.

Any other intentional use to "solve" a problem should be resolved; ask on WT:GP rather than trying to make the entry "look good" by adding blank lines.

rationale: multiple blank lines affect rendering, often unintentionally, when used intentionally results will vary between browsers and window sizes

(20) Categories at end of language section[edit]

Explicit categories are at the end of the language section, preceded by one blank line. Preferably in alphabetical order.

rationale: categories at end of language section is policy, this causes explicit categories and those generated by templates for a language to appear together in the displayed list, in overall alphabetical order by language

(21) No HTML entities or numeric references[edit]

E.g. & and 一 should be in (UTF-8): & and 一.

If it is difficult to enter the desired character, one can write the entity or numeric reference, preview, and copy/paste the character back to the edit window.

rationale: consistency, search matching

(22) No HTML tables[edit]

No HTML table syntax should occur in the wikitext, only wikitable syntax. In general, tables should be in templates. (E.g. conjugation tables, even if the template is used for only one lexeme.)

rationale: use of wikisyntax rather than HTML to make it more independent of rendering, having all tables generated by the software reduces "illegal" table syntax, editors don't need to learn HTML table syntax

(23) All POS (or equivalent sections) must have at least one line starting with "#" before the next heading[edit]

All parts of speech sections must have definition line(s). If the definition is missing/not known, template {{defn}} can be used to produce a definition line that will not render, and add the page to the appropriate language request category.

(24) POS headings[edit]

section kept to preserve numbering, see WT:POS for listing and discussion

(25) Gender templates[edit]

In translation tables the gender and number templates are to be used rather than abbreviations in explicit italics.

The gender/number templates are also used in inflection lines for the headword form, but not for the inflected forms shown, which have the gender and/or number spelled out.

rationale: distinguishes gender and number markers from the terms themselves (else they might look like an article, etc), allow for CSS customization and hover text

(26) Categories one per line[edit]

See (20), one explicit category link per line.

(27) One space after stackable wikiformat characters[edit]

The "stackable" wikitext format characters are "*", ":", and "#". Any combination at the start of a line should be followed by a single space.

rationale: bot/code tractibility, also keeps automation that is reformatting lines as part of other operations from edit-warring by having one consistent form, visual consistency when editing