Talk:MediaWiki Ideal

Automated Moderating System

What wikipedia needs is a solid foundation for weeding out false information .With statistical filtering based on quality of contributions. Quality of contributions should be judged based on meta-moderations (e.g members rating each other edits) . - naturally those with lower rating will have less weight in moderation. For members with low moderation rating pre-moderation could be implemented (so sr. memebr with solid rating could screen out bad edits before they get in). Without such systme wikipedia will never be a relibale and declared goal will never be reached

I like your idea. But first we need to consider a few questions, the most important of which being: if we actually wanted to implement this idea of yours, how will be do it?? Explain the administrative/bureaucratic steps involved. If other people have interesting ideas, which would improve wikipedia, surely we need some sort of forum in which they can voice their opinions - as does this talk page. But this talk page was difficult to find. Other people with good ideas may not even know about wikimedia (i didn't until recently) and may focus on wikipedia instead. Just say we wanted to put in the normal template of the screen interface a separate link saying "ideas to improve wikipedia" - how would we go about doing that? How would we go about even selected the various forms of improvement that can be made? It is easy to suggest ideas, rather, what we need to know is how to implement them.

As for the merits of your actual idea itself - I do not know your understanding of the wiki system as yet, but on the whole it is fairly accurate. When incorrect entries are seen, someone with a more correct understanding will edit them. Contentious issues and facts are liable for discussion on the discussion page. Everything, thus, where contentious is solved by consensus - a majority opinion. And, most important to understand is that a fact IS a MAJORITY OPINION. It doesn't matter if something is true, and you're the only one in the world who knows it, but the whole world knows otherwise. Facts are a statistic. i.e. if a newspaper reports something, this is seen to be more credible than what the average guy says off the street based on his own experience/knowledge in wikipedia, eventhough whatever is stated in the newspaper will be necessarily second hand material - but the problem lies, in wikipedia, not being able to authenticate people who actually saw the evens and experienced them first hand; so we necesarily have to rely on 'reliable newspaper sources' etc rather than deffering to someone's first hand experience, thence resulting in a slight derogation of the actual 'truth' in deference to what the newspaper is saying as opposed to the person who actually experienced the events, and who would thus be able to give a better account of them. Secondly, people could say other people are incorrect, when they are not; and it assumes that if you have a high rating, what you are saying is probably true, when it may not be. On the whole, I think that the way wikipedia is currently running is fine, and there is no need for the rating system you have suggested. BUT, that is only MY opinion on the issue. Other people may say that your idea is a fantastic idea. That is why I am more conerned to develop a process where ideas for improvements can be suggested, and a fair process by which the good ideas are actually suggested for further implementation. What do you think? --ToyotaPanasonic 02:02, 10 February 2007 (UTC)

Wysiwyg editor

See also WYSIWYG editor page

I use the MediaWiki software also in our organisation as intranet. It works fine, but people are somewhat reluctant to add information, because the Wikisyntax is different from what they are used to from using MS Word.

Xwiki has the feature of editing in Wysiwyg as well as in standard Wikisyntax. I would really love to see a Wysiwyg editor incorporated in the MediaWiki software. It would really make live easier for the before-internet generation and attract more people with know-how but mild feelings toward computer programs to the Wikimedia-projects.Londenp 09:13, 23 January 2007 (UTC)

• But one only needs to know the basic == ==, [[ ]] and '' '' to write an article. --Hillgentleman|書 09:24, 23 January 2007 (UTC)

• Indeed, but still it is my experience that this is difficult for a lot of people and it takes explanation and time. In my opinion not having a Wysiwyg-editor limits participation on the projects a lot. I see on wikibooks several times people trying and failing with the wikisyntax. We never see them back again, although what the wrote had potential. The first experience is a very important factor, not only with software. So for experienced wikians this seems like a minor thing, which in fact it is not, it is a major thing for the non-experienced. Londenp 10:19, 23 January 2007 (UTC)

For general purpose work, we do not need wysiwyg. For the enhanced functionality of a wiki, you need a lot of work to program a graphical interface. However, in that case, you still need a dedicated manual for a wysig editor. So, imho a wysiwyg editor has no real added value. Annabel 10:48, 23 January 2007 (UTC)

I am not talking about the internet-generation and the above average educated person here, for whom a Wysiwyg editor is not needed. I am talking about a lot of the people working in my factory team. They have no particular skills for software/computer, but I would like them to participate in the intranet process. Things need to be very simple for them and yes a wiki-syntax is not at all simple for them. Prove that it can be done you will find on XWiki. I would be very happy if this could even be an extension. Besides I don't like this discussion, like I need to defend this idea?!! I thought we are sort of brainstorming here. Please read Andre Engels opinion as well.Londenp 10:23, 24 January 2007 (UTC)

I believe you did not understand me. I was not talking about above average educated people either. Nevertheless if wywiwyg would be implemented, an option should be available to switch between wysiwyg and the current text mode (although I'd like some kind of a wysiwyg interface for the suggestions below). Annabel 13:56, 24 January 2007 (UTC)

I concur that a wysiwyg interface - a very basic one - would help people who have no concept of what a wiki is. We have 4 different wikis that are used for sharing data on a project, and most of the people barely use the internet - for little more than e-mail and going to large websites like CNN - they have no idea of HTML tagging, but they use things like Word frequently. having the ability to switch to a WYSIWYG editor would be nice. JustinLong 10:58, 9 February 2007 (UTC)

A drag & drop interface for images TeunSpaans 09:57, 24 January 2007 (UTC)

A drag & drop interface to locate stuff on a world map. TeunSpaans 09:57, 24 January 2007 (UTC)

A drag & drop interface to insert templates (maybe to media galleries in word-processors). Annabel 13:56, 24 January 2007 (UTC)

• I agree that WYSIWYG editing would be a feature of an ideal wiki engine. It's perhaps difficult to introduce into MediaWiki software at this stage, but check out the WYSIWYG editor page. Some people have a stab at it. There's also links to some examples of hosted wiki services, which do allow WYSIWYG editing, and I've have to say I'm impressed by some of these elegant implementations. It makes me think the open source wiki development community needs to play catch-up a little. -- Harry Wood 16:32, 24 January 2007 (UTC)

• Second Londenp's opinion. Wiki syntax for basic edits, == ==, [[ ]] and '' '' , seems very easy to me. Most people get scared off and don't make valuable edits. In my experience at my workplace there's been a lot of discussion about implementing a wiki, and Mediawiki is probably the most proven engine and people comment on how nice Wikipedia looks. What I don't think they realize is how much of a framework is provided to Wikipedia by very dedicated editors who know the volumes of Mediawiki syntax, templates, etc. I'm not saying that we need an editor, at this point, which makes very advanced editing (like templates) easy. That can still be done via source editing (traditional mediawiki syntax editing) for some time. A basic WYSIWYG editor to cover bold, italics, underline, list, interwiki links, external links, and maybe even an image inserting functionality would greatly benefit the Mediawiki project. --Oreo masta 18:06, 2 February 2007 (UTC)

Collaborative editing may be more important than WYSIWYG editing

I sympathize with Londenp's claim that things need to be very simple for average users in a corporate setting. So why not make things really simple---let the new users type their input as plain text and dispense with markup entirely? Senior editors can monitor new users' activity, and wikify their rough drafts.

I think the problem for a typical corporate wiki may be greater than can be solved by a WYSIWYG interface alone. Wikipedia succeeds because it attracts users from the whole world; if even a tiny percentage of people in the general population can figure out wikitext, that is still tens of thousands of people doing serious edits. Anyone who has done technical writing with any sort of markup language (e.g., HTML, DocBook, LaTeX) will find learning wikitext a breeze. A corporate wiki, on the other hand, cannot succeed with 0.001% participation. It must (somehow) appeal to a much larger percentage of people in a given corporation. (How many employees in a typical corporation are already editing articles on Wikipedia or other public wikis in their spare time? Where I work, the number was apparently zero until I took an interest.) In a typical corporation which did not select its employees for writing skill, few employees are likely to enjoy writing or be good at it. To get good articles from them requires more than a WYSIWYG interface---it requires the active assistance of skilled human intelligence.

In my several-month experience with a couple of MediaWiki-based corporate wikis, I've seen that it is not necessary for beginning wiki users to learn any markup syntax initially. All they need to know is the <pre> tag. Just let them type their content as plain text. Their rough drafts look terrible, of course, so to make the system work, the wiki needs at least one senior editor who monitors the Special:Recentchanges page to see what the newbs are trying to do, and quickly goes around and wikifies their crude inputs. (We designed variations on some templates from Wikipedia to mark articles that need wikifying, or help from specific persons. For useful ideas, see: w:Template:Helpme, w:Template:Wikify.)

Having senior editors who monitor activity on the wiki and quickly help the new users is far superior to any available stand-alone WYSIWYG editing system I have yet seen. An intelligent human editor can see what the new users are trying to do, ask them questions to clarify their intent, and quickly turn their rough input into polished-looking articles. Then it is easy for new users to make further small edits to wikified pages, without having to understand what all the markup code means. Almost anyone who is smart enough to use a computer at all is smart enough to recognize the difference between the wiki markup codes and the plain text content in the edit window. Even if they do mess up the markup codes, the senior editors on the site come by to clean up the damage.

Therefore, I would say the most important factor in the success of a corporate wiki is not the computer-only portion of the user interface, but the organizational component, through the intelligent use of collaborative editing. Until artificial intelligence progresses enough to let a computer do what an intelligent human editor does, corporate wikis will need intelligent human editors. Merely throwing the MediaWiki (or any other wiki) software to the average corporate community is unlikely to produce results on par with the quality of Wikipedia. To get Wikipedia-like results requires having some people on your staff who have substantial experience editing on Wikipedia (or another high-quality wiki), along with a corporate mandate to adopt and enforce specific editing standards (for example, something like w:WP:STYLE).

It's possible to add the necessary machinery to support this kind of collaborative editing to MediaWiki through the use of templates and categories and such. However, it might be nice to consider adding features to MediaWiki that directly account for the vast disparity in editing skills likely to be common in corporate environments. That is, the software should have a setting for the user's skill level (controlled by the senior editors), and present different options accordingly. New users should have very obvious, and more detailed, help options, along with a way to input plain text with no markup at all. Perhaps the system should not even require new users to think of article titles; let them make untitled rough drafts for the attention of a senior editor, who will think of what to call them. The system should then automatically categorize all user input by user skill level, and send the appropriate notification to the senior editors. As users gain skill with wiki editing, the senior editors can assign them higher skill rankings, and this will cause the system to rank them as needing less immediate oversight whenever they edit something.

Providing a WYSIWYG option might even be counterproductive, as it would enable users with no knowledge of editing standards to mark up their articles any way they want. There will be lots of random variation, because most users will just click buttons without regard to what anybody else is doing. Look at the random garbage coming out of a typical corporation from all the semi-literate do-it-yourself Word users---many documents are jarringly inconsistent with the others. The resulting inconsistency is probably more than a mere annoyance; it probably makes documents harder to read and understand. If users are too lazy to learn a markup language, they are probably too lazy to learn an editing style guide. Therefore I would suggest not even giving them this power; the system should encourage new users to type their input with no markup at all, and let the expert users wikify it for them. Let the system harness the natural laziness of people, by encouraging them just to focus on typing their content, and leave the markup to someone else. --Teratornis 17:34, 29 January 2007 (UTC)

How cool would it be if there wasn't a separate editing window? If you could just type text into the existing article and it formats automatically? i.e., I type "==" and I have an I-beam cursor typing in a blank header? Our would I need to type the two equals; have a "new header" button! Maybe new text would appear as red, and then prompt to be saved with a button at the bottom. Or maybe it could update instantly across all computers viewing the page? A seamless, instantaneous, user-freindlycommunication medium! (Though vandalism and accidental modifications would increase dramatically.)--HereToHelp (talk) 13:17, 1 April 2007 (UTC)

Information from oracle databases

Maybe this is a feature I just have not found, but might be there. I would like to be able to point to information from an oracle database we use for our ERP-software. Redundancy is really a problem. So if we change information on one point, it should be also changed automatically inside the MediaWiki program output. Londenp 09:13, 23 January 2007 (UTC)

An alternative would be the result of a SQL-query made visible inside a MediaWiki page (or even part of a page, or even part of a template). Londenp 07:20, 26 January 2007 (UTC)

You can probably already solve this problem if you're able to connect to your Oracle database through PHP's Oracle module and can write a parser hook extension. robchurch | talk 08:29, 26 February 2007 (UTC)

Simplicity

It may be related to Wysiwyg (in fact, wysiwyg might be a way to get this), but one thing that IdealWiki would have would be simplicity. The basic wiki syntax is simple, but when you go to current Wikipedia pages you get templates, tables, image syntax, interwiki links that are all not readily understood by those seeing wiki-text for the first time. I would not want to lose those features, and making them simpler can be done only to a certain extent, but perhaps it could be made so that someone can edit a 'cleaned up' page, where there are as few as possible 'complicated' elements, which they then can edit and save, and not mess up with the rest of the page.

One way I can think of is turning all these things into some template-like things so that all that is shown on the edit page is something like <<table 1>>, and a separate edilayed. However, that still is not ideal, because someone wanting to correct a spelling error in a text table 1 should preferably be able to do so just as easily as someone editing the 'clean' part of the page. Only when they actually want to work on the table syntax should they need to go into the more complicated edit screen. So probably wysiwyg is the way to go here after all. - Andre Engels 12:14, 23 January 2007 (UTC)

• Colouring the|templates ,etc, on the editor may help. The inexperienced may avoid them and edit only the text on white.--Hillgentleman|書 06:45, 25 January 2007 (UTC)

Categorisation

This is a technical point: mediawiki is very good at directing users to similar information in the same (categorisation) or in other languages (interwiki-links). These should not be included in the main text, however. Instead this information should be saved in a different field in the database. By doing so, you can simplify text editing, both using a plain text interface or a wysiwyg interface. In extension, you can have another field for storing links to recommended wiki-literature or multimedia-files. Annabel 21:12, 23 January 2007 (UTC)

True immersion

In an ideal world, we would not even need an ideal wiki. The wiki concept itself as we know it today would be obsolete and instead we would have complete and total consciousness immersion. That is the true "wiki way" (quick way'). Why bother typing in information in such a primitive way (in addition, using archaic syntax) when we can transfer such information directly into the machine? This is the 21st century, and yet due to lack of vision we are still doing things almost the same way they were doing them back in the 1960s-1990s. Only today our technology is just a little bit more advanced. But it is still built on that very same foundation. This is what I have shared with Richard Stallman many times before, that the innate problem of GNU/Linux is that it is a "UNIX-like" OS. UNIX is the stone age, it was always a flawed, inefficient architecture to begin with. But rather than develop newer, more fluid and efficient architectures (like BeOS), they are still building upon a system architecture dating back to the 1960s-1970s.

Likewise, the wiki concept was formulated in 1994-1995, based on concepts going back even earlier. The unfortunate thing is that wiki took so long to actually become established as a viable method of collaboration and exchange. Wiki has shown that vast collaborative information sharing projects such as Wikipedia are viable. However, we are dealing with a technology well over fifteen years old. At some point in the near future this methodology of wiki will become stagnant. The focus should be upon working to achieve seamless immersion between the user and the machine, but unfortunately this will never become possible so long as we hopelessly cling to outmoded, outdated system architectures such as UNIX and (even worse) Microsoft Windows that will never be able to withstand such performance loads. Trent Carson 19:03, 23 January 2007 (UTC)

I suspect part of the reason wikis took so long to achieve widespread visibility is that in 1995, wikis weren't really necessary, because Web development via HTML editing was still relatively simple. Most early adopters of the Web were technically-inclined to begin with, and HTML editing back then was only about as difficult as wikitext editing is today. Most early Web sites used simple static HTML pages, and it was easy to learn HTML just by clicking View | Page Source in a browser, while viewing pages that had features one wanted to emulate. Much of the Web was easy to reverse engineer back then. But that quickly changed, as all the major Web sites began using increasingly complex software to produce their pages, often dynamically, and Web editing evolved into a specialized professional skill. Try making sense of View | Page Source on any major Web site today! It's about as illuminating as looking at a core dump.

One way to think of wikis is as a reaction against the anti-democratization of the Web---giving the Web back to ordinary people. When Tim Berners-Lee invented the Web, he did not envision a system in which the billion-dollar corporations dominated discourse. But that has been the effect of the increasing technical complexity of Web site construction. People who have the specialized skills, or the money to hire them, gain more control over what gets published as the skill requirement climbs.

The stunning success and quality of Wikipedia are changing the way people look at the Web (that is, at least the people I know). Before Wikipedia achieved sufficient scope to be generally useful, when I wanted to investigate something online, I typically used a search engine, and then I slogged through the mish-mash of results. The various Web pages that mentioned my search terms had a variety of inconsistent formats, some were not applicable to my particular use of the terms, and it was often hard to find even one page that defined my topic of interest and introduced it in an encyclopedic way. Now that we have Wikipedia, it's often the most efficient starting point for a search. If a reasonably-well-developed Wikipedia article exists on some topic, it's almost always a better introduction to the topic than results from a general Web search---that is, unless the Wikipedia article appears at the top of the search results, which seems to be getting more common in my experience.

The general concept of a wiki is already fairly old, that is true. However, the first wiki probably lacked many of the features which combine to make Wikipedia what it is. And as I explained above, I don't see the "oldness" of wiki technology as a disadvantage---I see it as a beneficial return to the early days when Web editing was simpler than it has become today.

As far as the general notion that present-day user-interface technology is insufficiently immersive, I doubt many thinking persons could disagree. Similarly, most of us would probably prefer to be smarter, better-looking, wealthier, robustly healthy, and immortal. It's easy to think of things that would be better; the question is, how do we get there? For a wiki to be truly ideal, it must exist or at least be realizable (conversely, one might argue that by definition, anything which is ideal does not exist in reality, rather its existence is merely in the realm of ideas, but that is probably not what those who started this discussion had in mind). Having computers that could read our thoughts and automatically program themselves in real time to do our bidding would seem nice, on the face of it, but obviously such computers are decades away, requiring quite a few more iterations of Moore's Law before we have the necessary CPU power, let alone the software.

In the meantime, wiki technology and Wikipedia-scale social organization (the key to making wiki technology work) are pretty cool things. Rather than asking about the ideal wiki, perhaps we should discuss something less ambitious, such as the next realizable incrementally better wiki. --Teratornis 16:52, 31 January 2007 (UTC)

Semantic support

There is an extension called Semantic MediaWiki that already provides much of the framework for a semantic system. The main site for the extension is at http://ontoworld.org/. ~MDD4696 03:40, 24 January 2007 (UTC)

Corporate Wiki

We are using a MediaWiki-installation do document some software. There are some core functions, that are repeatadly asked for:

• LDAP-Support
  • Authentication (solved with extension)
  • LDAP Groups = User Groups with different rights
• WYSIWYG
• Search Engine supporting less than 4 characters
• User Rights Management (read and write access)
  • And make it bulletproof with no security issues --Teratornis 18:13, 29 January 2007 (UTC)
• Edit check before release (editor and quality assurance before release)
• Attachements (especially Word, Excel, pdf), searchable and with versioning
• Tasks (not yet suitable solved with extensions)
• Calendar (partly solved with extensions)
• User deletion (solved with extension)
• space reduction: Selective deletion of articles and histories (GUI)
• converter for word and excel documents
• Tagging of information for tabular database retrieval (solved with semantic wiki)

Note: This is no judgement on MediaWiki, as it is great software, aimed to a different usage!

Have you looked at w:TWiki? TWiki may be a better fit for some tasks in the corporate environment, as that was the intent of TWiki's designers. I really like w:MediaWiki, and for low-security corporate content it's great, but MediaWiki clearly isn't designed specifically for corporate use, requiring extensions and various hacks to get some of the features you list above. I have not tried TWiki yet, but now that I discovered I can easily run workstation instances of MediaWiki under w:XAMPP (even on old w:Windows 98 computers), I may play around with TWiki to see how it measures up. I gather that it uses a different markup syntax, which does sound irritating to me, now that I have grown used to MediaWiki syntax. Even if there are conversion tools, what a nuisance. --Teratornis 18:13, 29 January 2007 (UTC)

User extensions

Better management of user extensions. Many user extensions exist, mostly coded in Javascript or css or both, which enhance or change the editing/usage experience. Build some sort of standard set of management functions in. Have the ability to have a library of user extensions that are available to many (currently you manually load them from some other users files) and that you can select from. Have the installation be less code driven and more menu driven. Have standards for how extensions do common things to make them easier to fit together. How Firefox handles extensions may be a good starting point for further discussion, although it's not perfect. For an example of what a mess it is sometimes, see w:User:Lar/monobook.js which is a bunch of hacks and mysterious includes... I could take the time to make things better but it's not my primary hobby... ++Lar: t/c 14:28, 30 January 2007 (UTC)

Better watchlists, or some sort of real threaded discussion

The current watchlist feature does not allow for efficiently tracking the various kinds of changes one might watch for. The only option is to watch an entire page, or not. The user cannot specify to watch particular sections on a page, nor to receive e-mail notification for only some watched pages. The wiki has no real understanding of threaded discussion which occurs on talk pages. Discussion threads on talk pages are really only simulated with ordinary wiki markup. The wiki does not really know when one blob of text on a talk page is really a reply to some other blob of text.

When I post a comment on a talk page, a first reply might occur weeks later. By then I may have forgotten about my comment on that particular page. If the wiki has disabled e-mail notification, I will have to remember to manually check my watchlist to receive any notification at all that someone has replied to me. The wiki has no actual knowledge that someone has, in fact, replied to me. The wiki is only aware that a change has been made to a page.

I'm not quite sure how I would like to see the wiki do it, but it would be nice if there was a way for the wiki to be aware of when someone has replied to someone else on a talk page, and then to display a notification similar to what the user sees when someone leaves a comment on that user's talk page.

Perhaps a workable method would be to have, in addition to the existing "watch this page" feature, a way to watch specific sections on talk pages. If I leave a comment in a particular section on a talk page, I would like to have a notification on the wiki (similar to the notification that someone has edited my talk page) that someone has edited that section. The method should be robust against changes to the section heading. That is, the wiki should watch for any edits appearing in any section where I have left comments on a talk page. If someone edits the section headings, the watch should re-orient to cover the current section containing my comments.

If I'm watching a section, and I select e-mail notification on that section, I would like the e-mail to contain a plain-text version of the new addition to the section, or at least the first 500 characters. Something to make the e-mail meaningful. I don't want to have to look at a talk page every time someone fixes a typo, to see if I really got a reply. I don't think MediaWiki needs a full-blown threaded discussion engine, but something in that direction would be better than nothing.

The Wikipedia advice for two people to discuss something by alternately leaving comments on the other's user talk page strikes me as being very unsatisfactory, because the result is fragmented and difficult for others to follow later. Many people appear to prefer to keep threads together on single talk pages because the result is far more coherent, even though it essentially requires manual watching. --Teratornis 17:27, 31 January 2007 (UTC)

IMO, the forum concept should be merged with the wiki concept. Common accounts, consistent logins, etc. Each would derive features from the other; PhpBB (as an example) could do much better with templates while a talk space could better be treated as a forum thread. --Ikester 07:00, 27 February 2007 (UTC)

Can't help on wikipedia, but for other wiki's I created a threaded discussion extension that might serve the 'basics' of this requirement: Discussion Threading -- Jack 15:25, 10 April 2007 (UTC)

Search engine

Hello,

I would simply suggest that an ideal MediaWiki software would feature a search engine. Not just the current one, but something extra-shiny which finds what you want, suggests other possibilities, allows cross-searches or searches limited to categories, to titles, with regular expressions... you got the point :-) le Korrigan →bla 17:00, 5 February 2007 (UTC)

Benign Viral Nature

MediaWiki, even with XAMPP, is hard to install, and installations do not know about each other. This greatly limits its distribution and participation in the project, and allows a more viral product to possibly replace it. To make MediaWiki ubiquitous, it should first download and install as easy as malware, should work equally well on Macs, Linux and Windows, be compatible with Oracle, Sybase, MS SQL-Server and flat files. (This does not mean that it should be malware; it should only install when requested, should be apparent as installed software, and should uninstall when requested.) Second, and equally important, to the extent their administrators desire, MediaWiki installations should be visible in the MediaWiki universe, servicing incoming search requests, allowing incoming edits, forwarding internal search requests to other MediaWiki engines, and doing content diffs between MediaWiki engines. (TDNMT all MediaWikis are to be trusted. Administrators need to be able to blacklist, whitelist, and graylist, i.e. rate, other sources.) JimGettman 23:11, 5 February 2007 (UTC)

when I tried installing it, all I had to do is download it, browse to 127.0.0.1, fill in a questionnaire and away I went. It was easier then quite a lot of normal software I have to install (especialy on linux when its from source). Bawolff 00:41, 20 February 2007 (UTC)

The importance of process improvements in wikimedia/wikipedia etc.

I think the success of wikipedia lies in the processes within which changes can be made. Note its current success in the changes that can be made in and within articles. Now imagine how WIKIPEDIA itself could be improved if there was some sort of system in which change could be possible to make it better - better in every conceivable way, in layout, in the code used (it is very cumbersome at the moment in seeing changes etc.) - if people could be able to suggest and somehow implement changes for the better, that will be critical. i.e. what i mean by processes (in the car industry, for example) would not lie in making better cars, but in improving the way cars are made, or improving the ways in which better cars are made. For example, one could build an extra station for cars to be checked, and where mistakes could be corrected.

Similarly, I think we have to find a way in which to improve the wikiengine AS A WHOLE - I am talking about the absolute fundamentals of the wiki model here; and am seeking to push it even further. Because at the rate wiki is growing, it already is starting to get cumbersome, clumsy. A previous example of such a system would be the general law system for land titles. Now most of the world is under a torrens system of registration (which is a thousand times better for all). I would like to see a way, in which we can facilitate such changes to wikipedia/wikimedia. Tweaking of policy, while it hsa a substantial effect on wikipedia/wikimedia is not what I am specifically referring to. I am talking about changes to THIS the computer interface, and changes that can be made (not textual changes within articles) to improve wikimedia as a whole. Therein lies the success of wikimedia, to be better engines than other wikiprojects.

--ToyotaPanasonic 01:45, 10 February 2007 (UTC)

Who can make the suggested changes?

who is actually reading this and in a position to make the suggested improvements???--ToyotaPanasonic 02:05, 10 February 2007 (UTC)

Well, I'm reading various bits and pieces of it with interest, and noting areas where there's very strong support for an idea, and also commenting on areas where things are, in fact, being done. But I can't make any promises at the moment. robchurch | talk 08:31, 26 February 2007 (UTC)

Correlating discussion changes to the text in the main article

When discussing an issue, especially something controversial, it would be nice to have some sort of system that allows for discussions to correlate directly to the specific paragraphs or image in question. Right now we have to click on a different page entirely. Perhaps outlines should be on the main page where people can right click on a particular image or something to take it straight to the relevant discussion section, rather than going to the discussion page via the discussion link. --ToyotaPanasonic 10:02, 10 February 2007 (UTC)

Javascript library

I think IdealWiki could use Mootools to create a WYSIWYG editor and SmoothGallery with slimbox's effects for images. --88.112.35.148 15:47, 12 February 2007 (UTC)

many name of one article

I'm working with Wiktionary (Polish Wiktionary - Wikisłownik), I think it could be able to give many name for one page. In Wiktionary we must several page about this same word, ex. have and had, has. On polish wiktionary we did it only for irregular verbs, but on (for ex.) german wikt. I saw many page of one noun (for plural form and cases). Sorry about me english. pl:wikt:wikipedysta:Ślepiec

short text on link's hint

able to add some short text to link's hint (I don't know what is the name of this element) and alternative text for images. It could by useful in wiktionary : name of page and translations of this name.

Sorry about me english. pl:wikt:wikipedysta:Ślepiec

You can already add alternative text to images. [[Image:Wiki.png|foo]] will produce , which should have the alternative text "foo".