This is an independent proposal; it is not here for voting, there are no current plans for this to be effected, and this is not endorsed by the Wikimedia Foundation. This page currently exists for conceptual discussion only.

Wikimark2 is the name of a proposed new Wikimarkup code designed for the viable supercedence of the current one used in MediaWiki 1.7. The name is a play on "Wikimarkup, Mark II". Suggest colloquial and jocular unabbreviation to "Wikimarktu", as if it's a natural language. Abbreviation, wiki2 or wikitu.

The core concept of Wikimark2 is to be so consistent as to be intuitive. The language makes perfect sense.

  • Maintains the complete consistency of a formal language, allowing for intuitive re-use of core concepts.
  • Easy and simple, but bearing in mind that any code can never be 100% instantly understood (i.e. it's not for complete laymen, it's still a code; no sacrifices to make it look pretty).
  • Similar enough to the original Wikimarkup not to cause major crossover disturbance; current MediaWiki 1.7 pages algorithmically convertable to new syntax without problems. New syntax can do everything old syntax did; correlation for all functions.

An upgrade to Wiki syntax will be needed at some point in the future, but maybe not at the present. Nevertheless the current version will not last forever, so this page outlines what might supercede it. There is a separate proposal for a new markup at Wikitax, but it is not designed with MediaWiki in mind, nor is it designed as a viable upgrade. Furthermore, some may find it inadequate as a markup language, for various reasons.

This proposal is currently open and not completely defined. Please add to this page with view to its core principles, but do not change parts without discussion. Discussion can be added on the talk page, or on this page if it is discreet enough not to break up the article.

The core of Wiki2 lies in the section on "Code types". These first sections describe a more coherent syntax for structuring the content of a page. Everything else is very much up for discussion and is there only speculatively.


  1. Raw content
    In Wikimark2, all page-content text is referred to as "raw content". This is the "plain text" of the page.
  2. Element
    If it's not raw content, it's an "element", which includes objects, images, categories, etc, that are inserted into a page's content.
  3. Code type
    These are the types of code-forms that perform set actions. So, {{double braces}} is a code type, the type being defined by the symbol used, i.e. the "surrounding double brace". One code-type always performs the same kind of action (see below).
  4. Tag
    All facets of code that involve "surrounding portions of text" are called "tags". For consistency, tags try to be a singular character that is doubled, e.g. [[, {{, etc.

Code typesEdit

The various code types always perform the same action. Hence:

  • Text placed between [[double square brackets]] always creates a page link - no insertion of elements or categorisation using this method.
  • Text placed between {{double braces}} always inserts an element. This is merely an expansion of Wikimarkup's use. See below section.
  • Text placed between <<double triangular brackets>> is always a call to a wiki function.
  • Text placed between <singular triangular brackets> is always HTML - alternatively, no HTML is allowed, full-stop.

Interpage linkingEdit

This is always achieved, and only achieved, with the use of [[double square brackets]]. The square bracket code-type is always an out-pointing, inline, textual link. So:

[[link]] (link to page 'link')
[[Image:Foo.jpg]] (link to, not insertion, of Image page 'foo.jpg')
[[Category:Foo]] (link to, not addition, of category page 'foo')
[[fr:fooé]] (link to, not interlanguage addition, of French article 'fooé')
[[:fr:fooé]] (link to page titled 'fr:fooé')

[[double square brackets]] hence represent a sort of "pointing out" from the article.

This format also encompasses external links. All valid URLs contain a characteristic colon followed by two slashes, which would be easily detectable (like a pseudo-namespace). This initial "http://" would, however, be compulsory; although some users may prefer to write web addresses just as "", MediaWiki already encourages full URLs. Furthermore, with the standardisation of linking code it would be obvious that the full URL is required. So:

[[]] (link to external site '')
[[:]] (link to article '')
[[]] (link to article '')

Insertion of elementsEdit

"Insertion" (also, "inclusion") is always done using {{double braces}}. Elements are the things that are inserted, where an element is everything that isn't the raw content of the page. So:

{{Image:foo.jpg}} (insert image 'foo.jpg')
{{foo}} (include template 'foo')
{{:foo}} (include page 'foo')
{{Wikipedia:foo}} (include Wikipedia namespace page 'foo')
{{Media:foo.ogg}} (insert Media file 'foo.ogg' link)
{{Category:foo}} (insert categorisation under category 'foo')
{{PAGENAME}} (insert MediaWiki variable into text)
{{NUMBEROFARTICLES}} (insert a different MediaWiki variable into text)
{{}} (insert nothing)

{{double braces}} hence represent a sort of "pointing in" to the article.

Wiki functionsEdit

Extensions, magic words, and MediaWiki special functions, henceforth "wiki functions" are all called through the use of <<double triangular brackets>>. There are no closing tags; the content is contained in the tag. See further below for how to specify parameters.

<<ref reference text >>
<<math math formula >>
<<fullurl page name >>
<<fullurl {{PAGENAME}} >>
<<nowiki unparsed text >>
<<code highlighted code >>
<<code <<nowiki highlighted code of unparsed text >> >>
<<includeonly only for inclusion >>
<<noinclude not for inclusion >>
<<redirect page name >>
<<msg Template:Foo >>
<<msgnw Wikipedia:Foo >>
<<subst Foo >> (these tags disappear upon page-save)
<<fr fooé >>

The last example adds an interlanguage ("interwiki") link to the sidebar for the French article "fooé".

Leading spaces on a line force that line to render as nowiki and pre-formatted (inherited from Wikimarkup).


The above three code-types all take parameters. Parameters are seperated by pipes (|), and are always stuck to closing tags (pipes only denote parameters, and the parameter is determined, if it is enclosed inside an appropriate ending tag and a pipe). Hence (ignore spaces):

[[link  |parameter]]

{{include  |parameter}}

<<function input>>
<<function input  |parameter>>

The parameter for a [[link]] is always its alternative text.

You have new messages: [[Practical joke|diff]]

The parameters for an inclusion always specify how the inserted element behaves.

{{Image:Foo.jpg|thumb|15em|left|This is a foo}}

The parameters for a function are as defined by the function, and come after the input.

<<ref As cited in book X, author Y |name=XY>>

Autoparameter for linksEdit

If a tag has one empty parameter, then it is called an "autoparameter" and does a specialised thing.

An internal link autoparameter signifies the automatic removal of namespaces and disambiguations (this is inherited from Wikimarkup).

[[Wikipedia:Foo (policy)|]]

The above gives "Foo", the equivalent of: "[[Wikipedia:Foo (policy)|Foo]]".

To retain consistency, a link to an external website, e.g. [[]], will generate an inline link with that text (""). Parameters will specify alternative text. In other words this works exactly the same as for internal links. Autoparameters for external links convert the link to an inline citation. So:


Generates: "[1]", the equivalent of "[[| [1] ]]". The [1] format is not used by default as it is less common than originally intended. In articles when you want to insert a link, in nearly all cases you will want to use a full URL, an aliased URL, or else an inline reference, e.g.:

  1. External Links
  2. ...blah blah as cited online.[1] Blah blah...

Raw content formattingEdit

The following sections are here speculatively and extraneously; Wiki2's core was in its structuring of code types above.


- unordered list
-- level 2 unordered list item
# numbered list
## level 2 numbered list item

- is used instead of the Wikimarkup * to avoid interference with the bold markup below. An asterisk is intuitive both for lists and for bolding, but lists have the alternative intuitive marker used here.


=h1 header
==h2 header
===h3 header
====h4 header

This is similar to Wikimarkup but without the need to repeat the equals on the other side. This is easier, and also retains consistency: in Wiki2, only "tags" surround text, and all tags are at least (if not, only) doubles (and sometimes triples).



Order is irrelevent, nesting unstrict:

**bold //bold and italics** italics//
**//bold and italics**//


In current wikitext, a simple line-break will not generate a line-break (<br />). This is a feature worth keeping for several reasons.

Manual line-breaks are achieved with a MediaWiki magic-word, i.e. <<br>> (alias <</>>), or by HTML (<br />) if HTML is allowed.


As Wikimarkup. Please see previous proposal which had problems (wiki function interference), and suggest a way to fix them.


\ (backslash), like in many languages, is an escape character. Placed before any of the above code-types ({{}}, [[]], <<>>), it forces the parser to ignore it.

"<<code <<nowiki Look here \>\>\>\>\> at me! >> >>"

The above would give: "Look here >>>>> at me!". If the backslashes were not there it could give: "Look here > at me! >> >>"

This can be used as a shortcut to a simple use of <<nowiki {{spoiler}}>>. Instead one can just write: \{{spoiler\}}.


 "? - ?"  (any character, space, dash, space, any character) outputs as "?, space, en-dash, space, ?"
  "?--?"  (any character, double dash, any character) outputs as "?em-dash?"
"\---*/"  (beginning of line, three adjacent dashes or more, end of line) outputs as a horizontal
          line (HTML horizontal rule, <hr />)

In the above cases, this output conversion can be avoided by nowiki'ing the dashes.

On parsing/saving a page, explicit unicode, eg #345; converts to that unicode character. Likewise with HTML representations such as "%20" or ".3F" in a link.


Current table code is, firstly, a bit hard to write, but just as importantly, hard to read. Tables will always be more complicated bits of code, and whilst Wiki2 attempts to make them as simple and intuitive as possible, in many cases its main focus is to make table code readable (and hence editable).

Tables are parsed through a new wiki function, <<table>>. Everything inside this function is parsed as table code. Exclamations are used to retain the consistency of "pipes for parameters".

A cell is encompassed in double exclamations and spaces. A new row begins with a new line.

row1: cell1 cell2 cell3
row2: 1 2:2 2:3
3:1 3:2 3:3
!! row1: cell1 !! cell2 !! cell3 !!
!! row2: 1     !! 2:2   !! 2:3   !!
!! 3:1         !! 3:2   !! 3:3   !!

Row-spanning and column-spanning is defined through the use of empty cells (e.g. " !!      !! "). In cases where you actually want an empty cell (without merging cells), you can explicitly define it as empty by giving it a content of "nothing", i.e. " !! {{}} !! ".

Row-spanning is assumed unless forced otherwise. In the below example, cell 1:1 has a rowspan of 2, cell 1:3 has a rowspan of 3.

1:1 1:2 1:3
!!   1:1  !!  1:2  !!  1:3  !! 
!!        !!  2:2  !!       !! 
!!  {{}}  !!  3:2  !!       !! 

Column-spanning is assumed for the last cells in a row, based on number of cells in that row and maximum across the whole table, unless made explicitly not so (fourth line). The parser cannot detect your ASCII art, so line 3 needs an explicit parameter to make it span as desired.

1:1 1:2
2:1 2:2 2:3
3:1 3:2
!!  1:1  !!        1:2       !! 
!!  2:1  !!  2:2   !!  2:3   !! 
!!      3:1        !!  3:2   !! 
!!  4:1  !!  {{}}  !!  {{}}  !! 

Explicitly retaining a rowEdit

Sometimes it is useful to break a line in your table code (without wanting to go onto a new row). This is simply achieved by defining explicitly where the next row begins. So:

!! 1:1 !! 1:2 !! 1:3 !!
!! 1:4 !! 1:5 !! 1:6 !!
!! 2:1 !! 2:2 !! 2:3 !!
!! 2:4 !! 2:5 !! 2:6 !!
!! 3:1 !! 3:2 !! 3:3 !! 3:4 !! 3:5 !! 3:6 !!
!! 4:1 !! 4:2 !! 4:3 !! 4:4 !! 4:5 !! 4:6 !!

The above example has 5 rows. The <<row>> wiki function is implied on all lines without it. Where it is used, new lines do not make new rows.

Table parametersEdit

Table parameters/attributes are pieces of pseudo-HTML or pseudo-CSS that can control the look of either cells, rows, or the whole table. The above code is very simple and easy to use, and the use of table attributes slightly disrupts it, but in the minimal way. Still retained is the ability to lay out the table, in code, in an intuitive way such that the code can be read.

Individual cell control functions as a parameter for the closing tag of the cell (for what these parameters mean, see further below):

!! 1:1 |right!! 1:2    !! 1:3 !! 
!! 2:1       !! 2:2 |c2!! 
!! 3:1       !! 3:2    !! 3:3 !! 

Attributes for a whole row require that the row be explicitly marked, and are parameters to the wiki function:

!! 1:1 !! 1:2 !! 1:3 !!
!! 1:4 !! 1:5 !! 1:6 !!
!! 2:1 !! 2:2 !! 2:3 !!
!! 2:4 !! 2:5 !! 2:6 !!
<<row !! 3:1 !! 3:2 !! 3:3 !! 3:4 !! 3:5 !! 3:6 !! |style=abc>>
!! 4:1 !! 4:2 !! 4:3 !! 4:4 !! 4:5 !! 4:6 !!

Attributes for the whole table are parameters to the table wiki function:

!! 1:1 |right!! 1:2        !! 1:3 !! 
!! 2:1       !! 2:2 |middle!! 
!! 3:1       !! 3:2        !! 3:3 !! 
|border=1|style="x: y">>

Attribute aliasesEdit

HTML table attributes are reduced to aliases similar to parameters for images. Aliases include:

header         class="header" (same as Wikimarkup "!!")

center         align="center"
right          align="right"
left           align="left"

middle         valign="middle"
top            valign="top"
bottom         valign="bottom"

#xxxxxx        bgcolor="#xxxxxx"

c#             colspan="#"
r#             rowspan="#"

border         border="1"
noborder       border="0"
nopadding      cellpadding="0"
nospacing      cellspacing="0"

Entering an alias in a table-attribute-position has the effect of the above translations. Multiple parameters are seperated by multiple pipes, as usual. So:

!! 1:1 |right|middle|c2!! 1:2 !! 1:3 !! 
!! 2:1                 !! 2:2 !! 2:3 !!

Aliases are not alternatives to the above translations, but are defined to have those effects.

About crossing overEdit

A new syntax is all very well and good until we realise there are over 5 million pages that would need to be converted to it. As such, a complete conversion would be impossible. Only a gradual change would be viable.

  • For a very extended period, all edit pages would have an option for the markup language they are written in. This determines how that article parses.
  • Editors can thus choose which markup to use (default to old markup), and they don't interfere with each other.
    • Seen as pages are algorithmically convertible between the two markups, it might be possible for editors to directly translate the page between markups, e.g. by clicking a button.
  • Pages will then be gradually changed across to the new markup, whilst a large effort is made to introduce the basics of the new markup to the MediaWiki community.

A non-gradual change might take effect if there is a massive overhaul of MediaWiki infrastructure.

Support and developmentEdit

This proposal is not concrete or 100% complete. Please discuss it and watch it for updates.

Major issuesEdit

The following are some of the major issues and points that people have raised in discussion. Please add your opinions on these matters on the Talk page.

  • Table suggestion may be troublesome.


Facets of Wiki2 that have been changed or removed following discussion are stored at Wikimark2/Old.