MediaWiki Ideal

Do not post general purpose feature requests for MediaWiki here. These should go on the bug tracker. This page is for abstract discussion of wider concepts and features.

If we can answer this question, developmental direction is made clear. It is easy to develop MediaWiki with view to improving it, streamlining it, ironing out bugs - but much more difficult to look beyond it. For the future of the Wikimedia projects and the ethos behind the Foundation, better software must emerge that caters for the new functions required by modern wiki users.

In an ideal world, what features would the ideal wiki software have, and what would it be like?

Wikis can be characterised in terms of their end goals (e.g. the end goal of Wikipedia is a complete, accurate and referenced encyclopedia). A wiki software engine may be called maximally successful if it best promotes a wiki's goal. Our questions for the ideal wiki engine are thus:

• How would the ideal software achieve maximal wiki success?
• What features would encourage the most amount of users to make the best contributions most easily?
• What functions would ensure success for a long time into the future?
• What would the software be like if it spread the Wikimedia philosophy and wiki paradigm anywhere it could go?

The answers to these questions might be impossible (or very difficult) to implement; it is still of great value to decide upon what we think these answers are.

See also: vision, the ideal Wikipedia board, and other pages on ideals/visions. Also other feature requests and problem statements.

Discussion

• Please feel free to add your suggestions below
  • For the sake of discussion, call the ideal wiki engine ideal_wiki
  • Use one section per suggested feature
  • Write in prose paragraphs, using the tense: "it would be ..."
  • Please do not suggest minor improvements or bugfixes; these belong on Bugzilla
  • You do not need to sign your name, as this page is more like an article
• Please feel free to discuss each suggestion on this page
  • Respond to suggestions by indenting your response beneath it
  • You may sign your name with the responses
• Feel free to refactor the current suggestions so they are more easily readable
  • Fix bad phrasing, wording, spelling and grammar
  • Combine sections and suggestions that are similar
  • Separate thick sections into multiple suggestions if needed
• You can discuss the concepts in general on the Talk page

Archive /Archive 1 Please archive dead suggestions. A section is declared "dead" if the feature suggested: has become (or is already) available is shown to be in some sense contradictory or impossible is shown to be useless or redundant is superceded by another well-received suggestion that covers it or is not really a suggestion for ideal_wiki (the text belongs better in another place) and that section of the page has not changed in a long time.

User experience ideas

Usability ideas

Before posting in this section please go to the current usability project pages:

• Usability Initiative Wiki
• Usability home page on Wikipedia

WYSIWYG Intuitive editor

According to my own survey for the Design Platform wiki, the main barrier to usability could be wikitext. For example if we extrapolate the statistics this could prevent millions of users from contributing on Wikipedia. This even relies to the ideal of Wikipedia: Are we making a site for the whole of humanity or a site for people who are not afraid of code?

The FCK editor is available, yet there are many questions outstanding:

• It sometimes damages existing code;
• Some advanced features are questionable;
• It makes sites slower.

I think the efforts could be focused on intuitive editor development. First would be to measure and quantify the exact impact on users of the standard wiki editor. Then design and implement the new editor.

• Create a special directed category in the donation campaign?

• Or just make it a priority for developers and usability specialists to enhance this function?

Community tools

The idea would be to enhance community tools, for example the current general discussion threads, the used pages, the projects spaces... A community or a sub comunity needs tools to develop. The idea is not to add tools like forum, social network, blogs, etc... All sub communities don't need it and this would transform wikipedia in a complex network of tools wich could become uneasy for the user. The idea is most to develop light integrated functionalities and to make sure that all dynamics and user cases can be done with this functionalities. Even by users that are not really experimented in Mediawiki or in technic.

This could look like easier to say that to make. A way to lead it could be a step by step integration of light funcionalities among time. Each time a functionality is released it is criticized and evaluated, ameliorated... Keeping in mind that it should lead to a global light and user friendly system.

A proposition to start could be to make a global messaging system, inspirated from the SocialProfil extension wall to wall, but that could take also in account messages leaved to discussion pages. So that the user could manage all his messaging from a centralised panel. All the discussion pages would be transformed into "discussion walls" and the user could see all his discussions on his own talk page. This is just an idea on the go, putted here as an example.

Administration Ideas

Software Administration Panel

The software would have an Administration Panel where you can completely configure the settings for the software. The code itself would never need to be accessed.

This has been discussed at length before, with little outcome. Part of the reason development in this area is nonexistent is because Wikimedia is the main target audience for MediaWiki, and our system administrators are quite comfortable with the current method of software configuration. robchurch | talk 08:21, 26 February 2007 (UTC)

Someone should remind them that there's a lot more sites using Mediawiki than just Wikimedia. On many of these, the people actually running the wiki don't have server level access at all. --- 71.170.20.24 16:22, 11 October 2007 (UTC)

Management of. access control

For the management of certain kind of communities it would be good to have an easier management of the access control. w:gACL is available and works well in tikiwiki. But it would be better to be compatible with w:Bitfrost long term to help w:OLPC users.

wiki source

Ability to hide the wiki codes. Every time I have to rename EditPage.php in order to hide my wiki source from content thieves. --144.122.250.144 13:37, 22 February 2009 (UTC)

Parsing Ideas

Page storage

Stores pages in a standardised, intuitive code, with a parser built from a formal grammar of it.

Parsing

Turn parsing into a staged process:

• building a DOM tree (with nodes like 'bold', 'internal link' etc.)

  all elements are in raw form (extension tags or parser functions, or magic words not parsed)

• calling hooks to let extensions work the dom
• recursively expanding the dom (DFS)
  • expand inclusions

    this means an 'include' node is expanded. it will have child nodes for parameters, which are first expanded (to allow parser functions) recursively

  • expand parser functions (that is, nodes 'parser-function' (maybe only topmost nodes))
  • expand extension tags

    all expansions result in replacing a node with another dom node

  • in each stage, call hooks.
• rendering the DOM

Both should be hookable: hooks for when an element ('internal link') is encountered and hooks to add new elements.

This can then help in storing other formats as part of the wiki, and rendering them as normal wiki pages, and, exporting to other formats (so, the DOM building is a medium that allows conversion), as well as more robust plugins.

This should also be available as an external library, in order to allow other applications to parse and analyze wiki markup.

Lint

MediaWiki could use its own lint. One problem that appears frequently on the Wikipedia Help desk is a failure to close the <ref> tag (for example in this help request). The edit window should have a "Check syntax" button to go along with Save and Preview.

excellent idea AaronPeterson 23:48, 29 March 2007 (UTC)

WikiCreole support

It would support the emerging wiki markup standard of WikiCreole as well as its native MediaWiki syntax.

I would say the defacto standard is MediaWiki syntax since it is used on the biggest wiki in the world : wikipedia. =)

Not only is it standard, it's better. The "WikiCreole" project made many obviously wrong decisions, including weird syntax like "// italics //" which just doesn't match either mediawiki or tikiwiki and overloads a character that ought to be rarely used given everything else it means. And, weird restrictions such as no links in section titles (Wikipedia doesn't do this but it makes a lot of sense in some other contexts), suggest they just didn't talk to enough people.

Supporting two syntaxes cuts the amount of engineering time to support each in half. The correct answer is to tell WikiCreole to become a backwards-compatible extension of mediawiki, and that it'll be supported when it can be supported without distractions.

Seriously also, do you think the WikiCreole group actually looked at all the many problems of working in all languages? They haven't got the same list of punctuation characters allowed in names!! This makes it impossible to copy over the GFDL corpus namespace without weird rules that will fail for sure, forcing manual adjustments and constant intervention. It's dead in the water.

Whitespace managment

br's should be added automatically... the wiki should be like a text document except for where another style is specified. If somebody wants to quickly avoid a newline end the line with a backslash (\)

The current method of dealing breakline reminds me the syntax used in LaTeX or in the HTML source code, while the one proposed here remind me the command line syntax used in unix shell. The fact that a br is treated as a space has the advantage that his avoid the need of very long lines. However in the current wiki syntax the br are not always treated as a withespace (it ends the line in an unordered list or in an ordered list). The current situation is, in my opinion a little bit confusion, and leads to the need of writing long line with no br inside ordered/unordered list. (for instance if the text is copy and paste in a way that br are inserted, the result is a mes up) -- AnyFile 10:55, 11 April 2007 (UTC)

Editing Ideas

Inline (AJAX) editing

Uses AJAX scripting to make edit pages no longer needed. Changes are made and saved on the same page as the article itself, with edit boxes appearing and disappearing exactly where the text is to be edited.

This is available at de:Benutzer:ASM/quickedit.js. ChP94 05:58, 5 April 2007 (UTC)

But it doesn't work in the catalan wikipedia. See de:Benutzer Diskussion:ASM/quickedit.js#QuickEdit in catalan wikipedia--Iradigalesc 22:12, 7 April 2007 (UTC)

Similar problems on other wikipedias (it:) arose because of malformed XML on system messages (for example, <BR> instead of <BR />, etc. Check them on your wikipedia. --Alfio 11:00, 10 April 2007 (UTC)

Support for this idea, minimal the ability to link (wikify) or delink (unwikify) terms quickly and painlessly. And it should work in all project, independent of language. A Firefox/Chrome app maybe? Bennylin 15:54, 21 January 2011 (UTC)

Fine editing

Offers editing at very fine levels, e.g. altering singular words, lines or paragraphs.

A second idea on this same page is to manage general and specific permissions for editing. For example, it will be useful to be able to block edits on the main article, but allow minor edits on the sub sections.

WYSIWYG editing

Supports full WYSIWYG editing - to the degree that the edit box looks exactly like the article text, but with a box around it and some edit buttons.

Should have a UPO (user preference option) to turn it off, as well as a way to toggle it on or off on a per-edit basis no matter what option you have in your preferences (the toggle is for the current edit only and doesn't carry through like the preference does). --Skizzerz (talk) 01:10, 29 June 2008 (UTC)

Structured content

Enable to replace the normal free-text editor with a form for certain pages. The ability to use free text should remain, but the form will be easier. E.g., Task pages, Bugs etc.

Table Management

It would be nice to have a more visual table editing system. Many new users who are unfamiliar with wikisyntax find editing tables difficult on our wiki site. Particularly as the data does not line up in nice neat rows and columns. How difficult would it be to create a table tagging where a table can be tagged with a wiki tag and an "edit" link set up (similar to the headings). Clicking the edit link would bring up a forms based table editor. Specific changes to table cells could be more easily tracked that way, too.

Tables should have their own namespace and be treated like images.

You bring up a good point but we have to be able to edit the table inline. Please note, if you put a table under it's own header you can call it by [[page#header]] Now, I don't know if you can embed a subsection.

Take a look at the TableEdit Extension JimHu 15:19, 10 April 2007 (UTC)

auto completion

This would require ajax, when creating a link, get a list of already created pages should pop up, allowing a link to an already made page. Basically like how many programming IDE's have syntax completion,

If you want to link to another page, while writing an article, the wiki should suggest and advise you, that there exists connections to other already written pages. That would support the author more to write his Information down, and the systems helps to show connections to other articles. --Ichbinweg 16:28, 17 June 2007 (UTC)

This is not what is requested here, but it helps: en:User:Nickj/Can We Link It --Waldir 17:51, 18 December 2007 (UTC)

In response to the first suggestion here, Wikia already do this with LinkSuggest, so it is possible, and a very good idea that I would love to see on non-Wikia sites (as I have recently left Wikia due to not liking almost anything else that they do!).

Simpler header syntax

It's quite annoying to do

==secondary==
===tertiary===
====fourthlevel====
=====fifth=====

It should be allowable to do

=1 page title level
=2 secondary
=3 tertiary
=4 forth level
=5  h5
=6  h6... etc
Maybe even have styles
=2 name of header = style type

meta-data / annotation

A related feature is the ability to add meta-data (annotations) to a page, and enable extensions to utilize this. This will have the same meaning as categories, but: (a) will not be visible, (b) will be able to contain arguments. The categories functionality can be implemented on top of that.

Clean up syntax

The syntax for template parameters is mind boggling (esp., when using conditional parameters). parser functions are the same. Tables are very hard to read, as are nested lists (** instead of ' *'). About the first two, I suggest using one of the zillion templating languages out there.

Tables should not be entered in code at all. We need a table creation and editing feature.

A more readable template syntax would be a godsend.

God yes!!!

Just adopt tikiwiki's, it works fine.

I gotta agree, also bundling some good standard example templates would help..

I work on a twiki site all the time and find that their table representation is trivial to interpret compared to mediawiki.

                | Col1 | Col2 | Col3|

as compared to:

                | Col1
                | Col2
                | Col3
                |-

You realize | Col1 || Col2 || Col3 is an alternate syntax, and the double |s are used to allow for table cell properties and styles. Pomte 21:18, 15 June 2007 (UTC)

What have you Learnt?

For wikis that deal with basic knowledge, it'll be good to have a self-test section for students to know how much they have learnt. To make things simple for the programmer and the student, it can be limited to

• true/false
• multiple choice

Other than mathematics, this shouldnt be used for more matured topics as they are rarely that simple. Were it to be created for those kind of topics, its likely to be an attempt to impose some from of social conditioning by people small and large.

Inter-wiki Ideas

Support for WKML

Wiki Mark Up Language (WKML) is a group that seeks to create a XML based format for Wikis so that the information they present may be used by third party programs such as mashups.

This format should be created in a way that allows wikis to be syndicated similar to an RSS feed.

importing whole wikis/categories

Similar to the namespace and categorization issue is that whole namespaces can't be overlaid (or underlaid, meaning, only those names that are not defined locally will be looked up from the globals).

Today getwiki and tikiwiki both do wiki feeds fairly well, making them better choices than mediawiki for those who need to nest wikis. The feature of XML import of a whole external wiki is hinted at now on Special:Export but where's the specification?

One might want to export the entire contents of a MediaWiki, or certain sections of it to another format. For example Microsoft Compiled HTML Help (CHM). Likewise those with existing help files may very well like to make them available in MediaWiki format. Tools are available that can decompile a CHM file into folders and HTML files, and to convert HTML into CHM.

It would be good to have a system that would convert many linked html pages into MediaWiki Format. Being able to round-trip the data would also be ideal. That way helpfiles that are edited and updated by users on the wiki could then be packaged as CHM files and distributed to offline users of the software. While I'm using CHM as an example, there could other formats that could also be considered, especially since CHM is an old technology that will likely be replaced by an XML-based format. In that case providing this functionality may be easier to implement.

adjunct wikis / category feeds

Ideally different categories could be imported from different sources, for instance to refer to very improved articles at other public wikis where the article is being actively improved. This would enable the adjunct wiki proposal and let specialist wikis evolve, keeping Wikipedia at the center of those, rather than fighting with 'em.

Why should a wiki category feed be any more complex than an RSS feed?

Embedded Wiki

case in point: http://trac.edgewall.org - the bug system is 'wikitized'. This leverages the power of wiki for things other than articles. As for mediawiki, the idea is to allow developers to create pages where the wiki content is only a part of the page (not the page).

• Allow 'special' namespaces - where the rendering is taken care of by an extension (which, in the case of the bug tracking example will render bug lists, forms etc.)
• Allow an API to easily parse wiki text - currently much work is being done by index.php and such and is tied heavily with a request cycle ($wgRequest)

the one watchlist

It'll be very good to merge the watchlists from many Wikis. For example: I work on plwiki and I check the watchlist, next I check next watchlist from enwiki, next from dewiki, next from ... If we merge the accounts (H:UL), why we don't merge watchlists. I will be much more effective.

I have now one userpage with links to all my watchlists. That's easy but I think one watchlist would be much better! SPQRobin 12:36, 9 April 2007 (UTC)

Inter-wiki copying of pages

Copying content from one wiki to another is a nontrivial task. The example I run into on every test wiki I build is the Help section. You can't copy one file. You need to copy each subtopic and all of the templates envoked by them. A possible solution would be to have direct links to the Mediawiki help pages included with the base installation, eliminating the need altogether.

Inter-wiki inclusion of pages

Alternatively, we could have a central hosting place (prolly meta) and have MW look there if there's no local page (behaviour similar to images & commons) – Mike.lifeguard | ^@en.wb 23:45, 28 November 2007 (UTC)

In some ways having Help: namespace stuff come from a central place if it's not on the local wiki is similar to how Image: namespace stuff comes from Commons. Whether that place is Commons or Meta or the HelpWiki or whatever is an implementation detail but I think this idea has merit. ++Lar: t/c 03:15, 29 November 2007 (UTC)

Inter-wiki confederation

When multiple wikis wanted to confederate, they could enable interwiki transclusion and their search tools would search transcluded pages or even whole wikis.

Content Management Ideas

Semantic support

Follow the steps of the semantic mediawiki extension in the core. Either use its syntax, or RDFa. Among other things, this would include full support for spatial and temporal tagging, and be able to "semanticize" categories and templates.

The system should be able to support complex semantic queries based on this tagging: for example, "all people involved in the Hundred Years' War". See also person DTD, spacetime DTD, and category:time for locating events in space and in time.

Sociosemantic web features

Top-down imposition of semantics is one way to proceed, and works well for very uncontroversial things. Where relevance to a group or process or intent is important, some sociosemantic web features might will be necessary: categories as just another tag, voting-assigned tags, and better control of verbs with higher level implications than "find" or "edit", like "contrast" or "contradict", any of which might show up as link types.

Layering and nesting

Enable layers of data on a page. E.g., the initial content in one layer and a discussion in another. When rendering, the layers are merged. Use policies to determine which layers are merged (and how) based on user profile.

Then, for example, when using a wiki in an organization, one layer contains public data and another contains private data. This can later be generalized to nest wikis or allow one wiki to maintain multiple layered databases, like the wikipedia/wikinfo relationship (which shows the real utility of this).

Inflexible category and namespace system

Mediawiki-based services emphasize social software features while content management seems to lack, e.g. inability to incorporate dynamic input from RSS feeds keeps it behind w:TikiWiki (contrast a simple tikiwiki page with four RSS feeds on it). Focusing on peer contact may well be an advantage as gACL and other hard security distractions tend to be minimized. However there are some inexcusable misfeatures:

No special "Special", "help", "template" and separate "project" namespaces

While treating a project namespace and help namespace as "special", notably in naming of talk pages, there is no provision for other normative namespaces being treated in the same way, e.g. specifying that a position:namespace should have a position_talk:namespace to discuss it, or a term:namespace or slogan namespace for contentious terms (which you definitely don't want to show up in main namespace, for controversial terms or phrases. See the way Wikipedia itself does this, with the page name prefix slogan: 'controversial term and so on. Very political projects often create a "Term:namespace" for terms that are being argued over like "war on terror" or "pro-life" as here.

Project namespace should include all "special" pages

If there's going to be a special namespace for information about the project, one would think it would at least include all mediawiki special pages despite bad names noted above. So mediawiki reports information about the wiki database into this "Special:" namespace, which is not the "special" project namespace. It would be helpful to be able to take the information from the wiki software, and decisions from the project contributors, and keep it integrated all in one with the name of the project. Some wikis go to the bother of creating pages in project namespace that correctly name the pages to make linking easier and make the names more exact and readable.

Nice names like [[project:uncategorized page]] must replace non-English trash like Special:Uncategorizedpages.

no hardwired exceptions, allow any namespace to be assigned a parallel talk space

Presently there are coded particular priveleged names as exceptions (like [[User_talk:]] and [[Help_talk:]], and this would obviously have to go away too, in favour of arbitrary assignment of talk pages, or just supporting any set of pages that appear after a colon as a namespace.

merging with keywords/tagging

The old category system, which has supported us until know, is becoming more and more of a pain to maintain...

a cross research with keywords would be amazing.

Elaborate? --Alfakim 04:34, 1 March 2007 (UTC)

Basically treat each category as tags that just happen to be supported as part of the interface, but otherwise idential to any other tag. Keywords are just standardized tags.

The only thing really wrong with the current category system is that it doesn't allow for pages that are not on this wiki to be in the category, therefore forcing some kind of artificial distinction between tagging and categorizing that just doesn't make sense.

require tags/categories to be applied to all articles in a namespace

Even when a category has exactly the same name as a namespace, e.g. [[category:verb]] and verb:namespace, there is no way to simply indicate that all articles in the namespace are to be automatically assumed to be in that category. It would be easy enough to assume so unless otherwise directed (by some notation like -[[category:verb]]), especially if this feature can be turned on and off.

Separate or additional categories/keywords/tags can't be assigned to a redirected name

You must be able to assign categories, keywords, tags, whatver to a redirected name. At present, name cannot appear in the categories unless it is associated with at least a one-liner article on a different page altogether. This is extremely clumsy and debilitating when multiple levels of category abstraction are required. To avoid a lot of shallow pages, it should be possible to redirect and categorize/keyword/tag.

What links here' (which should be called what links to this page instead) does separate the redirects, therefore, so should the categories: When extremely specific concepts are explained that are a subset of the concerns in the article, and which make little sense to explain on their own, usually these are related to some domain or narrow problem that takes a very specific perspective. If use of that term in particular has any operational implications, then users need to track all use of that term without confusing it with all reference to that concept, i.e. all linkage to the more general article explaining it.

This would be very very useful when trying to categorize vendor-specific terms but also redirect them to a vendor-neutral article. You can then put propaganda terms like "DASD" in category IBM but also redirect them to w:hard drive without extra clicks.

It also helps to clearly separate the names from concepts, and be able to categorize the names without having to also categorize the concepts. This is really important in integrating category/keyword/tag notation, since there are many versions of tags per keyword, and possibly many keywords per category that overlap.

This is already possible. Never tried it? #REDIRECT [[Whatever]] [[Category:Foo]] works fine.

merge category, namespace and template

The concepts of category and namespace are overlapping. There is no reason not to merge them (except for the vast quantity of people using current format, and the new way would be incompatible)

wiki.com/page_name:namespace

Namespace should come after the page name. A page should be able to be in multiple namespaces. Basically a person should be able to limit searches by categories of pages. Each page should be able to be in multiple namespaces.. or categories...

page name:namespace1:namespace2:namespace3 sexually graphic content would be a namespace. talk pages would be a namespace...

Specific headers could be associated with namespaces, and be hidden if said namespace is excluded. Namespaces would be preserved by the browser, and specifically changed by the user, or the link if it has namespaces. This would simplifiy linking greatly, as I could be browsing a page in the help namespace, and click a link to bookmarks and it would automatically take me to the bookmarks:help page.. er as it is now: help:bookmarks.

Category would remain a like a namespace, To add a page to another page's category, We currently have awkward syntax for adding a page to a category and to link to a category. one would follow [[Category:page name]] should link to the cateogory instead of add to it. To add a page to a category, there should be a separate field to manage categories. Also, category:page name could also add the page to a category, for convenience in embeded pages. Note that a category is a namespace of the category page!

---

We don't have to change the syntax of the namespace, Every page should link to all pages with the same name in just different namespace, and all links should automatically assume that you want to stay in your current namespace, except for when there is no content in that namespaced version of the page, and then you get the default page.

This just wouldn't facilitate showing content from multiple namespaces at once like the sytnax: pagename:namespace1,namespace2,namespace3,talk,category would

Revision Management Ideas

CMS Functionality

While a CMS focus is on managing content, a wiki's focus is on creating it. But, once created, any content needs to be managed.

• document lifecycle (drafts, approvals, inline commenting) supported, ideally with tags and explicit modelling of the process of publication, such as MS Word has in nit
• modular layout - have the ability to add new elements to a page without hacking a php / css file, for instance, to better control the "toolbox" etc. as tikiwiki does now
• 'views' - enable for a context based view of the system. e.g., view documents in 'version XP' (that is, 'Installation' doc is viewed differently in different version contexts and a link to 'FAQ' leads to different content, based again on the context)

Version Control

Mediawiki "page history" (bad name, versions is far better for various reasons) has a direct parallel to the version control systems used in the software development world. As such, software and ideas might be taken from such projects. Salient examples include darcs, git, mercurial and svn. Svn and Git more readily reflect the current history method, whereas darcs has a more interesting technique - storage of a hierarchy of interdependant patches. This would allow the removal of a spam edit simply by applying an inverse patch (builtin to the system). Such inverses by a reputable person (see accountability below), and marked as spam removal might minimize the visual impact on history, reserving more space for interesting history. Darcs' primary advantage is its decentralized implementation, perhaps more apt for something like Tiddly Wiki.

The use of an SCM tool has these benefits:

• efficient storage in terms of space
• ability to see a history over all articles (see what the wiki was like on januarary 1st). this is not so important to wikipedia, but is important for documentation wikis
• ability for branches. not useful for wikipedia, but if i have a wiki for a product, it would be nice to be able to choose the 'ver2.0' branch and browse the wiki as relevant to that branch.
• accessible outside: no need for 'mvs' any more.

Sounds good to me, but it has to be able to be displayed on a web page. A tree would take up a lot of visual space. —Alexnye 00:03, 15 February 2007 (UTC)

Didn't understand the comment. Same as you can browse a source tree, seeing only the contents of the current branch, so will you see the contents of the page in the branch you have selected. If you're referring to history view, then, like there are history viewers for SCM systems (see viewvc), so can you create a view for page histories.

Make past versions of articles apparent without having to visit a separate page

For example, there could be an option to color-code text based on how long it's remained unchanged (or color-code by user). You should also be able to view the article's verion history as an animation.

I know Roman Nosov is or was very recently working on an extension (and asking for core changes to support it) to provide the first. robchurch | talk 08:27, 26 February 2007 (UTC)

IBM TJ Watson Labs also has a tool to show it graphically, they might donate that.

Spatial scope history

Select a region of a page and be presented with a history of all modifications applying to this particular region.

You could for instance see all the history relating to a particular paragraph of a long page without delving in thousands of modifications though the classic history page.

You could also point out who contributed to a particular phrase or group of phrases that you find very good. Maybe that would be a huge incentive to people out there who feel that their work is not recognised in a wiki editing process and thus don't participate.

More informative page version histories

In some pages with heavy vandalism, most but not all the vandalism gets reverted.

In a page that faces a reasonable amount of vandalism, being able to see what edits have been reverted (and having the option of hiding them and the reverts from the edit history) would help users identify which edits still need evaluating. In addition, if a user evaluates an edit, they should be able to note what they think about that edit.

Page patrolling isn't very helpful, as it is only visible to admins and is only a binary flag.

Histories managed better

There should be metadata in the history page. Was this article spun off from another article? Was it translated from another language? What languages has it been translated into? This should be documented in a machine-readable format, not just in the text in the "edit summary" box.

Also, there should be no reason to cut-and-paste edit histories when, say, an image is deleted and recreated in another format. And we certainly shouldn't have to use an external link to point to a specific version in the history.

Quick 'links' from diff display

The ability to click anywhere on the recent version of a diff, and be taken to the very part (section?) of the page which corresponds to the clicked part. Very useful when reading a large discussion page through the latest diff, and seeing a interesting new response to some thread one doesn't immediately recognize.

Category content history

Presently it is impossible to see what articles have been removed from a category. "Related changes" only shows changes to articles presently in the category. This makes it very easy for vandals and others to remove articles from the categories which makes the articles lost in the uncategorized space. There should be a way to watch the content of a category, and not only it's page as it is now. --V111P 03:53, 14 May 2007 (UTC)

Extensions Ideas

Incorporating certain extensions into the core code

I'm finding that certain extensions are being installed on MediaWiki installations as a matter of course, including but not limited to:

• ParserFunctions
• InputBox
• StringFunctions

I'd like to see these extensions incorporated as part of the core MediaWiki code instead of extensions that have to be installed. --Hoggwild5 12:38, 15 July 2008 (UTC)

Plugins

Allow easy installation of plugins and easy configuration. Right now, each extension has its set of instructions on how to install, and requires changing of LocalSettings.php

Hmm. Well, all extensions should define a single entry point, and the change to be made to LocalSettings.php is more or less standard for each. Some extensions use additional tables, which require installation, but I've been messing about with miniature installation scripts, such as those provided with Patroller and BadImage, and others are taking up this sort of idea and doing that whole mix-it-up-and-see-what-happens open-source thing, so perhaps some further poking in this area will result in some standardised installer format. robchurch | talk 08:24, 26 February 2007 (UTC)

I've been working on an extension and have been thinking about one aspect - requiring settings for the extension. If there was a standard naming for extension settings (e.g. extname.set) then conceivably there could be a way (via maintenance script) to sweep through all the sub-directories under wiki\extensions\, collect all *.set and put includes to them automatically into an ExtensionSettings.php which in turn is always included in LocalSettings.php. That would avoid manually editing anything other than the specific extname.set file (which in turn could be managed by a php web-page-based settings editor). Such an ExtensionSettings.php could be at a higher level to be captured by all wikis in a family so no duplicate extensions are required.Michael Daly 05:37, 10 April 2007 (UTC)

I would love to see this as well. Perhaps the Reflection API can be used to automate the installation of extensions without having to edit LocalSettings? A sysop interface where extension-specific configuration settings could be modified would be an added bonus. Although it's been a while since I looked at it, Drupal has a wonderfully easy interface for adding "modules" to a Drupal installation; perhaps that's worth looking into? --Hoggwild5 13:36, 14 July 2008 (UTC)

Number of pages

Now there is a magic word "{{NUMBEROFPAGES}}" (=12,306,603) and a magic word "{{NUMBEROFARTICLES}}" (=141,987), but it would be much better if there are also such magic words for each namespace. For example: {{NUMBEROFCATEGORIES}}, {{NUMBEROFHELPPAGES}}, {{NUMBEROFPROJECTPAGES}}, ...

Syntax Highlighting

For articles that contain code for programming languages, it would be possible to select the language and have the engine automatically render syntax highlighting and formatting.

There are extensions for MediaWiki which do this, e.g. Highlight, available in Subversion. robchurch | talk 08:21, 26 February 2007 (UTC)

There's also http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi, which is expected to be rolled out on Wikimedia sites soon. —dto (talk) 04:46, 10 April 2007 (UTC)

Note: That's the same extension; it was renamed prior to rollout on Wikimedia. 86.133.208.191 22:22, 5 August 2007 (UTC)

Implement SuperMemo as a MediaWiki extension

SuperMemo is a set of methods and tools to learn and never forget the knowledge you care for.

It is based on Dr Piotr Wozniak's research on repetition learning and incremental reading: http://www.supermemo.com/english/smintro.htm

It has gained popularity thanks to an article published in Wired: http://www.wired.com/medtech/health/magazine/16-05/ff_wozniak

SuperMemo is also a software product, implementing and demonstrating Dr Wozniak's ideas:

• Spaced repetition: learn something by having it repeated to you. Dr Wozniak studies lead to design spacing algorithms, which compute the best interval between two repetitions.
• Use of cloze tests: a cloze test is a portion of text with certain words removed, where the participant is asked to replace the missing words (http://en.wikipedia.org/wiki/Cloze).
• Incremental reading: how to split a huge piece of knowledge such as a chapter from a text book, an article on the web or the lyrics of a song into small learnable pieces.

The problem (and the opportunity) is that SuperMemo as a product is not satisfactory:

• It relies on a fundamentally flawed design: use HTML to structure the documents forming your knowledge, whereas HTML is not about structure, it's about visual rendering.
• It builds on a proprietary knowledge format which makes importing and exporting difficult, therefore exposing your written knowledge to obsolescence.
• In more than 10 years of existence, it didn't gain popularity, despite of the wonderful ideas. As for modern knowledge management standards, a proprietary desktop application doesn't match with the ambitions of the method. It has to be open source and collaborative.

To sum up, I wish my kid could use a tool such as SuperMemo for her studies, but not SuperMemo itself, because it would be too risky to rely on a proprietary solution with such little audience.

There fore, here is what I suggest: Bring SuperMemo ideas to MediaWiki, and maybe later to WikiPedia.

MediaWiki has extension points that would allow to implement SuperMemo key features:

• Cloze tests: use WikiMedia wikitext markup extensions to materialize clozes
• Incremental reading: use WikiMedia articles creation features to implement incremental reading.
• Repetition spacing algorithm: use WikiMedia special pages to implement the repetition algorithm interfaces.

The use of MediaWiki would solve the fundamental flaws of SuperMemo design:

• Use wikitext markup to structure the articles that compose the knowledge.
• Use hyperlinks to keep topics and clozes related.
• Use an existing solid and open document management architecture to guarantee perennity of the knowledge you decide to write down.
• Leverage the extraordinary existing knowledge base that is already structured as MediaWiki content: WikiPedia and many other knwoledge bases.
• Leverage the existing audience to spread SuperMemo ideas.

Benefit for MediaWiki

Be more than a content manager: provide extraordinary tools to learn the contents.

Possible issues and ideas to solve them

SuperMemo is a commercial software, so the question of how to develop an open source competitor needs to be addressed.

But there are already such competitors: for example Mnemosyne (http://mnemosyne-proj.sourceforge.net/) and Anki (http://ichi2.net/anki/).

And I hope that, as researchers, the SuperMemo team would see it as positive that MediaWiki (and possibly WikiPedia) helps them spread their ideas.

Client-side scripting with source to JavaScript compiler

We have several extensions for scripting : ParserFunctions and Scribunto more recently. They are secure, so anonymous users can use them on wikimedia projects. On the client side, we still need to use regular JavaScript. The result is heavy procedures take places on wikimedia projects which prevent most functionalities getting created. Moreover, js Script are loaded globally : this mean if you create a script for a specific article, then it will be loaded on all the pages of the wiki. There is no real way for The result is many modules which can run on client-side run on server-side. Most of them simply update values by doing simple inoffensive computations like computing DST or the speed of space probes. This would be also beneficial for dynamics event : Currently, I saw raster gif images to dynamically updates value inside tables (the table is written inside the gif instead of wiki syntax). Using client-scripting would be simpler than a server-side solution which send results to the client over the network. Note that the compiler itself can be written in JavaScript entirely. Basically, a very minimal support would solve most problems (most models don't use Scribunto and don't need the power of lua) :

• support date and time and a timer.
  
• support basic maths operation like + - *.
  
• support basic string operation like replacing and concatenating.
  
• conditional statements.

It wouldn't need to support:

• floating points and negative numbers.
  
• medium level mathematical functions like % / ! sin() cos() tan() sqrt() pow().
  
• advanced mathematical functions like Discrete Fourier transform; Bilinear transform; Differential equations...
  
• variables
  
• loop statements

So it would provide a similar functionality to ParserFunctions but even more stripped, so even safer. Just never bring the power of JavaScript since it is a security risk.
When a module for a specific article is invoked, the user on the article can chose to either invoke it once on the page load, or several times based on a change like the current time or a timer.
If it appear the client disabled JavaScript, then and only then, the server compute the value during the article load or use a cached result if not needed.

An alternative would be update Scribunto to support dynamic event where those events would be computed by the client and not the server. This would work in a transparent way : Existing Scribunto modules are computed on the client side or on the server side otherwise. Of course the actual implementation might need to be rewritten. 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA 13:40, 9 August 2014 (UTC)

Uploading Ideas

Enhanced media functionalities

Media (all kinds of media) should be uploadable without hassle. Next to PDF's, pictures, sounds and small anims, Other types of media should be supported, such as spectra of chemical compounds.

The software should be able to present and play media embedded within the article without needing to launch a separate application, in a fashion similar to that provided by YouTube.

Yes, that's an area we're keen to continue developing in - one of our Google Summer of Code projects for last year worked on this sort of thing, using free plugins, although I don't recall offhand how far the developer got. I do know he's not committed changes for some time, so the branch is more or less abandoned at present. It might be nice to chase him up and see if he's still willing to continue this work (and perhaps Wikimedia can offer a little financial incentive?), and if not, find other willing developers to take over. robchurch | talk 08:26, 26 February 2007 (UTC)

Yes, embeded videos à la the kind youtube offers would be SPECTACULAR. I for one would spend a considerable amount of time and energy creating english as a second language videos for wikiversity that could easily be adapted for whatever language the student currently speaks to allow them to learn english. Visual and audio presentation is vital in learning a language and I think it would be spectacular if wikiversity could be a free place that people come to learn english and visa-versa. Obviously linking to wikimedia and making people download small video and then go back to a wikiveristy page and then go download some more is just not going to work. Plus, video lessons would be in line with wikiversity's mission of delivering unique learning materials for free. I would also be wiling to donate to a fund that was set up to try to make this a realtiy (the wikimedia foundation could ask for donations from google in the form of video technology information and support... I know they run youtube and google video and I heard people mention stuff about wikimedia being iffy on donations from google). - 165.134.187.137 00:25, 5 March 2007 (UTC)

Presentation of media should be more wiki-amenable. For example, suppose there is a piece of music one wishes to use in a spoken Wikipedia article. One can simply specify in the wikicode to switch to the music five minutes into the reading, then switch out again to finish the article. Thus the same piece of music can be easily incorporated into spoken articles on different language projects, just as images are now on text articles. In the same vein, there should be a wikicode-specified automatic cropping function for images.

I agree with the media embedding, but DO NOT USE EMBED TAGS! They are not allowed. An alternative needs to be used.

P.S. My Wikipedia accout is Jesin, but I have no Meta account, and I am not even accessing this from my usual IP address. 70.177.165.188 01:29, 14 March 2007 (UTC)

Searching Ideas

Search

The current search could do with much improvement. For one thing, combination of the Go and Search. Like google, spelling errors would be caught and corrected. It is fairly ridiculous that google does a better job of search, when it has such a huge database. Likely they have some nice algorithm-foo, yet the wikipedia database is much smaller. Efficiency could be reasonably sacrificed for quality. A simple thing like case insensitve search would already be a big step ahead.

I know everyone was worried about Google's giving money to the Wikimedia foundation, but I'd love to see some collaboration with Google on the search feature... if at all possible.—Alexnye 23:59, 14 February 2007 (UTC)

Suffixindex

There is already a prefixindex, so I the ideal wiki, there would be a suffixindex.

I completely agree! --71.139.1.14 22:19, 14 July 2007 (UTC)

Vote for Bugzilla:10808 like me. Jidanni 08:41, 20 November 2010 (UTC)

I second this idea. Very helpful indeed. Bennylin 16:02, 21 January 2011 (UTC)

Inter-wiki searching

When multiple wikis wanted to confederate, they could enable interwiki transclusion and their search tools would search transcluded pages or even whole wikis.

Content Evaluation Ideas

Accountability

An accountability system would allow such trusted patch inversion as above. This accountability would be based on rankings, as well as not having spam reverts on your edits. This might be abused, though, as a malicious user might gain accountability, and then abuse the position. Thankfully, most of these people aren't willing to really go through with (or are aware of) such processes.

Collaborative filtering

Wikipedia is not censored, but occasionally someone objects to article content on the Wikipedia Help desk, on talk pages, or by edit warring. Since Wikipedia cannot be comprehensive while simultaneously being inoffensive to everyone, due to the vast diversity of human and cultural sensitivities, a possible solution might be Collaborative filtering. This would not necessarily have to be an integral part of MediaWiki, it might even someday become a standard Web browser feature, and apply to filtering World Wide Web content in general. However, MediaWiki's designers might look at collaborative filtering technology and see if anything useful from that might become part of MediaWiki. For example, collaborative filtering might allow different groups of readers to dynamically filter content from articles they consider offensive, in real time.

Discussion Ideas

Forum-like Talk pages

LiquidThreads.

There is also a hack/extension that emulates this that might be worth considering.

Discussion Threading

Recent Comments/Discussion Agreggator

It would be quite useful to have some way of presenting a summary of the latest discussion posts across a whole mediawiki installation for example. This would enable a list of the most recent comments to appear on the main page, and allow another access point for surfers to engage in the discussions.

XMPP Integration

Interaction with Talk Pages through Jabber would be nice. If a user enter their XMPP address besides hes email, they could chose to receive additions to their personal user_talk page via XMPP. Replying would add the reply to the talk page and forward it to the user who submitted the original message (if they registered their XMPP account)

Non user Talk pages would have their own "account" and users could "listen" to a talk page. --193.188.46.254 06:54, 10 April 2007 (UTC)

Supporting newbs with forums, while keeping forums from polluting wiki

Allow common accounts and consistent login process. Perhaps start with a popular package like phpBB. Merge template capabilities with the forums.

phpBB is a giant bleeding piece of skript kiddie bait. Fortunately that'll probably never happen since it looks like the 'official' path is gonna be LiquidThreads. --71.237.255.126 10:18, 25 January 2008 (UTC)

talk pages vs. forums

Perhaps even have forum capabilities tied to the Talk namespace.

This is a bad idea. In general, "blogs" and "forums" are worthless because they leave badly written, obsolete or inflexible content on a page that can't be easily answered to interwoven with the questions (as in email or present talkj pages, and (Worst) they end up with a lot of non-dialogue like this:

I am pretty sure X is true.

No, you are thinking of Y.

Ah, yes, thank you, disregard, Y is true.

Here is a source for Y.

Oh, thank you very much.

You are welcome.

While geeks with no social life enjoy this, no real person wants to read it. What a real person wants is for "X" to be replaced with "Y [reference]".

By no means should the current talk namespace be replaced. Rather, other namespaces can be supported.

...but Wikipedia's policies prevent people altering other people's comments so it ends up like that anyway.

---

Not all information sharing sites want nor need to be structured like WikiPedia. :)

OK perhaps a separate namespace would satisfy differing uses of the talkspace. And true, forums are more of a social medium. However wiki collaboration also requires a social interaction. That's what the talk space is for however it's often difficult to track the discussion.

Also, boards are typically composed of several forums. With features that integrate forum capabilities, each forum could be "front-ended" with a wiki main page that hosts all the important documents related to that forum topic. Each topic could have it's own wiki document page. The discussions could make use of templates that tie the wiki pages more closely to the discussion.

---

The purpose of a "talk page" is to talk. That's why it's named a talk page. Yes, obviously there needs to be the capability to paste in chunks of wiki markup for collaborative editing when something is being hashed out. But a wiki page makes a horrible medium for discussion. Just look at the discussion in this section alone. Can you be sure where one person's comments end and another's begin? Did anyone sign their comments? Why are we depending on users, many of whom don't know wiki markup and/or don't understand a site's evolved conventions, to indent and sign their 'posts?' I can't wait until a stable package of LiquidThreads is available. If I had plenty of money I'd already have IPBWiki installed on my wiki. The day the talk namespace gets replaced with something that doesn't suck cannot come soon enough. --71.237.255.126 10:17, 25 January 2008 (UTC)

Page Content Ideas

Inflexible control sections on pages

It should be easier to add more custom controls to the "navigation", "search", "toolbox" and also easier to add extra items along the bottom row with "about", "disclaimers".

Terminological Ideas

Avoid mixed, weak or misleading metaphors

Metaphors that seemed in the past to have helped new users learn wiki are now retarding them by imposing w:ontological metaphors on debates, e.g. the embodimentwiki.org analysis of stupid mediawiki metaphors that bias debates on the topics of interest to them.

Eliminate spatial and community metaphor

Some things worth eliminating are:

• use of "here" to mean "this page"

  "click here" has been part of the Web since its creation. It has disadvantages but it sounds like what you want to do is rewrite the Web, not MediaWiki

• use of "go" where "find" would do
• use of "navigation" which sure isn't what navigation means when you're accessing the wiki in a car or on a bicycle
• use of "community" (already some moves to get rid of this, as it seems to favour one or more conflicting Wikipedia philosophies and cause fights over "who runs things")
• use of "toolbox" which is a mixed metaphor

See this list of metaphor problems and workarounds.

Cosmetic Ideas

Informative skins for various types of users

The current skin mechanism is primarily to change site cosmetics. Also needed are skins (or some comparable mechanism) to provide levels of informativeness to different users. For example:

• A new user who only wants to read Wikipedia could receive context-sensitive help via flyover tooltips, links, etc., to give a brief summary explanation of every visible user-interface item on a Wikipedia page, with emphasis on the features a reader would use.
• A new user who wants to edit would also receive context-sensitive help on user-interface features relating to editing.

Look at a typical MediaWiki page. Manual pages exist to document almost every visible aspect of the user interface, but the user has to know how to manually search through the MediaWiki Handbook for most of them. For example, the "search" box provides no link to Help:Search; the toolbox | Special pages link points to Special:Specialpages, but not to Help:Special page; and so on. The user has no straightforward way to ask "What's this?" about a given feature he or she sees. It would be nice to be able to right-click on any object and get a context menu with options to view a popup help summary, or open the object's manual page in a new browser tab.

Can already be done via user CSS (e.g. experienced users can hide the explanation of what an edit summary is above the summary field, 'hover' text could be added to items). Creating separate skins for newcomers and experienced users wouldn't really work because experienced users have each developerd their own way of using the interface and have their own unique preferences – so would still end up customizing the interface anyway 82.36.120.68 16:11, 21 March 2007 (UTC)

cosmetic changes

I think that the developers should work on cosmetic changes for newer versions of MediaWiki. For example, much of the text in the "preferences" page isn't aligned to one side. This makes the software look less professional. The "Recent Changes" page could also be redesigned to look more neat, like the TransformChanges extension. --71.139.1.14 04:47, 15 July 2007 (UTC)

Hate the category three column table

Especially their width varies and they're often not even in length.

Also, while talking about category, ideal_wiki should have some kind of tooltip of what the sortkey of particular entry in a category by hovering over it. Bennylin 15:57, 21 January 2011 (UTC)

Navigation Ideas

backlinks

backlinks are vital for ease of navigation.

Explain?

Delete and show backlinks

Many ideas for backlinks. For example, when an admin delete a page, it should show the backlinks (that will go read because of the deletion), so the admin could fix them all (if they're only a few) or ask for help, or maybe realized that the page shouldn't have been deleted. Bennylin 15:51, 21 January 2011 (UTC)

IDEALLY

In ideal_wiki, in an article there should be algorithm to automatically suggest related articles, especially that have backlinks to the article. Bennylin 15:51, 21 January 2011 (UTC)

Case insensitive links

Links should be case preserving / insensitive. If capitalization is the only distinction between to pages, there is a problem because we can't even pronounce the distinction. That page should be used as a disambiguation page. I'm sick of CamelCase and Broken links Broken Links Broken lInks[[Silly LONG NAME|silly long names]] . We end up spending large quantities of time making sure that our links have correct grammar and still point to the right site.

Extension Development

Move away from "private" methods in MediaWiki Core Code

I would like to see the developers move away from declaring methods as "private" in the MediaWiki core code and use a less restrictive classification, like "protected", unless the class is extending a base or abstract class in MediaWiki. When you're writing extensions that include classes that extend some of the core class modules, it makes it difficult to keep from either duplicating code (which is never a good thing) so that the "private" methods can be made available to the child class, or you have to modify the core code to change the method declaration to something less strict, like "protected".

While those of us who are comfortable modifying the scripts have no problem with the second approach, those who are not programmers or are not familiar with php either won't use the extension because it requires core code modifications, or they inadvertently mess something up with a simple typo or by deleting a needed comma, parentheses, bracket or semicolon and break their wiki.--Hoggwild5 17:14, 25 June 2008 (UTC)

Multilingual/language related ideas

Multilingual is one of the strength and key of success of Wikipedia and its sister projects. Wikipedians from non-English projects please pitch your ideas here.

German suggestions

Please translate to English:

• Das ideale MediaWiki sollte guten XHTML-Code mit dem richtigen Content-Type ausgeben. Nicht so etwas wie jetzt.
• Die Seiten sollten leicht mit einem WYSIWYG-Editor bearbeitet werden können.
• Die mitgelieferten Designs sollten besser sein
• Es sollte eine Funktion geben, die Autoren eines Textes anzeigen zu lassen. Also z.B.

MediaWiki ist eine Wiki-Software (eine sogenannte Wiki-Engine)
|    ||    Benutzer a            |   Benutzer C   |Benutzer D|
     Benutzer B

• SVG-Dateien sollten eingebunden werden können
• Für ein Buch, einen Kurs oder eine Seite sollte eine eigenes CSS-Stylesheet gesetzt werden können.
• Es sollte die Online-Bearbeitung von hoch geladenen Dateien ermöglichen

Translated

Translators note: I had several years of German in school and learned a chunk thanks to my great-grandmother, but I haven't used the language except in a few rare instances since. The ones that puzzled me or were inexplicably strange before translation are in parentheses and have notes following them.

• The ideal Mediawiki should send out XHTML pages with the correct content type. It doesn't always do this now.
• It should be easy to edit pages in a WYSIWYG editor.
• (The provided designs should be better)
  • The meaning of the previous is lost to me.
• (There should be a function provided to let authors of a text indicate)

(example... "Benutzer" is "User", I think)

• • Possibly referring to indicating who is using what the article is about.
• (SVG files should be able to be merged)
  • This might mean merging several SVG files into a single chunk of data, but I'm unsure.
• A book, course or site should be able to set their own CSS stylesheet(s).
• (It should make it possible to treat high traffic pages differently)
  • ("It should the online treatment of highly loaded data make possible") - this is a word-for-word translation. I think I got it right, but there are some words used differently in regards to computers and the internet in German. (for instance, transmit/send in German is "spend")

A magic word for your preference language

There are some wikis (here, commons, mediawiki.org, ...) that are multilingual. Most pages are translated, for example: "Main Page" is translated to Dutch at "Hoofdpagina Nederlands". In the ideal wiki, there is a magic word {{PREFLANG}} that gives the language code of your preference language, for example "en". There would be also a magic word {{PREFERENCELANGUAGE}} that gives the full name of your preference language, for example "English".

This is an example how a translated Main Page would be:

{{#switch:{{PREFLANG}}
| {{Main Page}}
| en = {{Main Page}}
| de = {{Hauptseite}}
| nl = {{Hoofdpagina}}
}}

I don't know if this is related, but for Wikimedia projects, I'd like to see a centralized preferences. Beside languages also time zone, signature, etc. Especially useful for projects that are related, for example in Indonesia there are Indonesian Wikipedia and 8 local languages Wikipedias. Not counting their sisters. And 30 other eggs waiting to be hatched It would be easier for SUL users to set their global preference once, and be able to modified it locally if needed. Bennylin 15:39, 21 January 2011 (UTC)

Ability to change interface language for non-logged in users (anons)

Anons right now cannot change the language interface. This is a pity. While it should not be a complete list, there should be an language interface options available at the menu, given that a lot of languages have the interface translated already. Bennylin 15:46, 21 January 2011 (UTC)

AFAIK it can already guess by IP address and show the local language, but it's not ideal for people who live abroad or other circumstances where the local language is not his/her mother tongue. Bennylin 15:59, 21 January 2011 (UTC)

Unsorted Ideas

Please move sections from here into the larger sections above.

Allow usernames to be email addresses

It would be nice if people could logon with their email address (e.g. something of the form firstname.lastname@mydomain.com).

I fear for the amount of email traffic spambots would generate if the username was my email address and was publicly visible... Wojciech Pędzich Talk 14:10, 21 January 2011 (UTC)

Per Wpedzich. Privacy & spam issues. Further it will conflict with the userrights-interwiki thing. -- Dferg ^{☎ talk} 14:36, 21 January 2011 (UTC)

Ability to Export Printable Version of Page Content

It would be really useful if there was a simple method of exporting the printable version of page content (without the sidebar, etc.) as a html file without embedded style sheets (i.e. should contain relative links to any css).

Centralized template for all Wikimedia projects

Just like commons, but instead for templates. Currently the most advanced templates are in en.wp, so users from various projects copied templates from there. But as the time goes the templates are often updated, which leaves outdated parameters in articles. Other difficulties are incompatible parameters, branches of the same template (which in turn wastes people time, reinventing the wheel, etc.), and most of all there's no central place for the best minds (template masters ^_-) to come and talk at particulars. Other nice templates from projects outside en.wp seldom got the recognition they deserved too. Bennylin 15:31, 21 January 2011 (UTC)