Roadmap/Archive

Unless you are a MediaWiki developer, please edit this page only for corrections.

For more general info, see MediaWiki release cycle

Version 1.3
MediaWiki 1.3 will be released fairly soon; this here is a beta version. Most likely release date will be end of May. -- 14:39, 22 May 2004 (UTC)

New skin
In 1.3, the default MediaWiki interface will be replaced with the new MonoBook skin, which is mainly based on css, aiming at providing a way to base more skins on the same xhtml. The template is using PHPTal.

The three original skins will be kept as user preferences. A test wiki for rtl support is at http://rtl.wikidev.net, the main testing is done at http://test.wikipedia.org/.

Template syntax
Templates, or custom messages, have grown from humble beginnings as an afterthought in a localisation feature. They are now used in almost 10% of pages in the English Wikipedia database. The 1.3 release brings several changes in recognition of this new role:


 * Custom messages are separated from interface text (internal messages). The interface text will remain in the MediaWiki namespace, and the custom messages will be moved to the new Template namespace. The moving will be done with a script.
 * The syntax will be changed, from   to   . Backwards compatibility is maintained. A script will convert the text.
 * It will be possible to include text from other namespaces, for example  .
 * The full range of title characters will be allowed, including spaces
 * Any change to a page in the Template namespace automatically clears the cache of any pages which use that template.
 * Template parameters are supported, either named or numbered. The syntax is   with    tags in the template, or    with   ,   , etc. tags in the template. (Note that parameter tags in the template have three braces rather than two).
 * The parser for inclusions has been improved, to allow for recursive inclusion. The full wikitext syntax is allowed inside templates, rather than a restricted set as was previously the case.

Languages and localisation
In 1.2, language files generally had variables in them such as $wgSiteName (for the local site name) and $wgMetaNamespace. When the data from a language file was loaded into the MediaWiki namespace, these variables were expanded. Hence, any changes to the variables weren't immediately reflected in the site. In 1.3, this is fixed by passing internal messages through a variable expansion phase. A number of syntax elements have been added to make use of this:


 *  </tt>: the site name, for example "Wikipedia" or "Wiktionary"
 *  </tt>: the server, for example "http://en.wikipedia.org"
 *      </tt>: expands to a local namespace name. For example,       </tt> or       </tt> is expanded to the local name for the talk namespace
 *  </tt> and   </tt>: these tags are used to generate a URL for a given title. An optional query string can be given. For example, the URL to edit the main page is   </tt>

To further enhance portability of language files, the namespace names used on the English Wikipedia will now work everywhere. This should also be a useful feature for users attempting to navigate a wiki in an unfamiliar language.

Edit conflict merging
Users of en:Wikipedia:Votes for deletion know the edit conflict screen only too well. 1.3 brings CVS-style edit conflict merging, courtesy of the diff3 utility. Confirmed to work on both Unix and Windows platforms, this feature will only trigger an edit conflict if users attempt to edit the same few lines.

See also: Edits as patches

Hieroglyphs
The 1.3 release allows the insertion of hieroglyphs into articles using syntax from the Hieroglyph coding manual by way of  </tt> tags.

See also: WikiHiero

Timelines
The 1.3 release allows the insertion of timelines into articles. Links can be embedded into timelines. Those links are clickable using an automatically generated image map. It uses Erik Zachte's timeline module and ploticus to generate the timeline images and image maps.

See also Wikipedia Project Time Charts

Code in CVS now. Try it at test.wikipedia.org

User Styles
Users can define their own styles and javascripts as a subpage of their user page. File name is /monobook.css and /monobook.js for the monobook skin, other skins will follow.

Some samples at User styles

Other visible changes

 * Special:Import: available only to sysops, this special page gives users the ability to import full histories into a wiki, using the XML output by Special:Export.
 * RSS syndication available for many special pages, such as Special:Newpages.
 * Prefilled edit summaries will be displayed in grey text, rather than bracketed with "=" signs.
 * Links in summaries allowed.
 * Links and other formatting in images allowed.
 * New image option "framed". The image is not scaled down to a thumbnail and the magnify-button is not shown. Image can float to the right and left.
 * Real names. Users can (optionally) specify a "real name" they want to use for author credits.
 * On-page credits. Administrators can enable an on-page paragraph giving credit to editors who've worked on a page.
 * Page protections/unprotections now require confirmation.
 * Other magic words added: ,

Technical changes, bugfixes

 * Link table uses IDs in both fields
 * The security risk of global insertion from the query string is eliminated, provided users disable register_globals
 * Lots of PHP notices fixed
 * XHTML-compatible output (or darn close to it), tidy integration
 * RDF metadata
 * Fixed section editing issues with commented or nowiki'd sections

To be done

 * Fix bugs, bugs, bugs, bugs, bugs (solved), bugs, bugs, and bugs.
 * Documentation updates.
 * Make sure upgrading from previous versions is a clean, easy process.
 * Conversion script MediaWiki: -> Template: -- Tim wrote maintenance/archives/moveCustomMessages.php
 * link table conversion -- maintenance/convertLinks.php
 * run these automatically on upgrade if the wiki is small (link table conversion takes a few hours for en)?
 * Additional touches to in-place install.
 * Getting maintenance scripts usable (but safe) in the in-place environment.
 * The template parameter syntax chokes on something like . (seems to be a rather rare corner case, TimStarling indicated he had a fix for this but wasn't satisfied with it so far Gwicke 23:46, 19 May 2004 (UTC))
 * Category link table? See this bug report on test. (done) Additional date field to make members of a category sortable by date (-> important for things like a Vfd category). (partly done)
 * Preferences page to be rewritten to actually be legible. a js function generates a toc and folds the sections on most browsers
 * "Overflow" credits page -- if the number of people who've worked on a page is greater than some limit, show credits on a separate page. --Evan 18:40, 21 May 2004 (UTC)

Might not make it into 1.3.0
(candidates for 1.3.1)
 * Finish Special:Import.
 * Update all the language files with new stuff (update translations in mediawiki namespace first, dump them to php & merge them afterwards)
 * It might be wise to fix up Snok's parser cache and enable it on the live site.
 * db load balancing? (not really needed for 1.3, but would be very nice to have with the two db's we have)
 * Category ui might need more thought- category lists might get very long. Separate page was suggested.
 * Categories need more work in general re scaling, bug fixes
 * Show the user some info in case of merging other people's edits, maybe a diff or a message and a link to one
 * Unicode support for EasyTimeline
 * All Skins are missing edit links for the first heading, an idea is to move the section edit/whatever click stuff to js (see also 1.4, move prefs to js)

Bugs and comments
Once 1.3 is installed on the live wikis, please report bugs and comments at: MediaWiki 1.3 comments and bug reports

To be done
Add your name next to any of these items if you want to complete that task.


 * Database schema redesign
 * User:Brion VIBBER
 * Implement FileReplacement, i.e. a way to semi-protect pages
 * In the long term (post 1.3) it might be nice to have a general way to deal with schema changes, involving automatic detection of missing fields and tables, based on a single schema specification. The specification could then be used for both installing and updating.
 * move most prefs to generated css/js, esi caching
 * WikiCommons to store commonly used ressources like images

If 1.4 will include a schema redesign, maybe we should call it 2.0. -- Tim Starling 05:57, 3 May 2004 (UTC)