Slashdot Mirror
How Can Wikipedia's Visual Editor Top Other Word Processors?
First time accepted submitter azadnama writes "Wikimedia Foundation, the organization behind Wikipedia, is aware of the fact the MediaWiki formatting syntax is a major obstacle for people's participation in writing on the site. To address this problem, the Foundation is developing VisualEditor—a web-based WYSIWYG interface for editing articles. It's supposed to be similar to a word processor, like LibreOffice, Microsoft Word, Pages, Google Docs, and others. And this is the time to ask: What did your word processor get wrong and how can Wikipedia's VisualEditor get it right?"
I use them all the time and abhor when they do not behave consistently.
Funny thing, styles work better in OO.o than in MS Office.
And don't do what they did. It's the most frustrating wiki editor on the planet.
Many wiki pages have large amounts of structured information, and the Confluence editor is spectacularly bad at managing that. It's the most aggravating thing to use.
And don't get rid of plain text markup for when the rich editor fails.
Get rid of buttons for italic, bold, underlined and other manual ways of editing. Using these instead of proper format use hinders good documents and makes later reformatting a pain in the ass.
The problem with visual editors is... well.
If you look at ms word clones, they always fight an uphill battle: what's the minimum subset of features needed?
Answer depends on who you ask, and if the sampling group is big enough, the minimum subset becomes "everything".
..they need to make something that imports the current format in a WYSIWYG fashion, renders and exports it properly. Dealing with the table structure there is a nightmare for low-intermediate experience editors.
It should place structure above formatting.
i.e., sectioning and lists rather than screwing around with fonts, colours and line spacing.
LaTeX gets this right. a UI where users have to specify sectioning and such would be good.
Good luck to Wikipedia making a WYSIWYG editor for an unparsable, moronic syntax.
Just take a look at the MediaWiki parser (and the 'graveyard' folder of broken parsers). I hope whoever coded that horrid shit stain is never somebody on my production team.
It is nothing short of a disservice to the very values it seeks to embody.
It can not.
Recreate LyX, or clean up LyX specifically for wiki editing and make it HTML 5. What You See Is What You Mean is what wiki writing needs.
The ribbon bar in office. So much for file, edit, view.
That's the long name for vi. Why don't they consider emacs?
It should have built in warnings so you know not to waste time on an article that belongs to one of the regulars. It might be possible to calculate this on the fly for each article by seeing how long an average edit lasts before being reverted by one of a small number of players.
Publish a template, style guide, and move along.
Really, works fine for most websites. Add a few scripts for references and such, automate some of the layout and done.
Incidentally can we get a CSS switch that makes links the same colour as the rest of the text, user preferences kind of thing? The multicoloured text is really hard to read.
What am I missing? what's wrong with TInyMCE or CKEditor?
Just throwing this out there -- two of the major hurdles to doing this right are (a) that Wikipedia's syntax is not formally defined, and (b) that its current implementation is (as defined by the output of the MediaWiki parser) is not a context free grammar. Which means that writing robust, fast parser for it is very hard.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Their lack of coherent coding and / or a WYSIWYG editor is the LEAST of WikiMedia / WikiPedia's issues.
Number one issue keeping new blood away: Asshat editors-for-life with "ownership" issues, who park their fat asses on various pages / subjects / media classes, and shit diarrhea on any "newbe" who dares add / change / question so much as punctuation...
If you want news from today, you have to come back tomorrow.
The right question is:
Does your word processor do the job it claims to do well, and what, if any, of its failings are relevant to a Wikipedia-specific word processor.
I agree with previous commenters: A page-editor for a wiki page needs to be about structure, not WYSIWYG. Now, it's convenient if what you see as you are editing is approximately what you will get when using your computer and your web browser, but there should be no illusion that everyone else will see the same thing, or even anything close to it.
In any case, it's critical that editors be able to tell in real time the difference between a structural element, such as a section heading or the start or end of a template, and pure formatting, such as a change in font.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
They should avoid going WYSIWYG, because WYSIWYG never works correctly. There's a reason TeX is so popular.
Hell, there's your answer. Just get everybody to write in TeX.
it is a complete nightmare if you have any kind of accessibility issues. i never understood why they didn't just use HTML, or LaTex. Both better understood and with an already established community with good editors.
Problem with modern user interfaces is that they usually have waay too many buttons/options!
Every user interface is actually two user interfaces, one in the mind, and one on the screen. Every image on the screen first goes trough the "filter" in your brain, and this filter is different for everyone. But if you make a large part of the user interface a part of the "filter" in your mind, you also gain a better understanding of what you're doing. Would you think it would be better if while programming you had a button for "for loop" "while loop" "new method", a button for everything? Learning programmling like that would be very annoying.
It's a bit like the "command line" vs "user interface" debate. You trade a slightly higher learning curve for a better understanding and usage later on. If you're gonna build a WYSIWYG interface with all the capabilities of the normal interface, it'll probably end up more complicated than the normal interface.
Look, I'm not saying abstractions are bad, they're very important, but you have to put those abstractions in the mind of the user, not on a screen as buttons.
Lo and behold, for I am a sig!
I just tried out the beta editor. Pretty neat.
I think the project could make citations easy to do. There's tools to add content using the appropriate font size, etc. However, I don't see anything about citations that go at the bottom of the page.
A lot of programs make citations difficult (Word, LaTeX, etc). There are some tools to assist, like Zotero and Mendeley. Wikipedia could use some smart tool to help people create citations, etc.
Good luck!
And so is MediaWiki syntax.
The whole damn point of HTML is "what you see is what you *mean*. If you write hypertext, and think about looks, you already fail, and have to change your thought patterns.
There is a very specific reason HTML is not about looks. Unfortunately apparently its usefulness and elegance is only obvious to programmers. But then again, only programmers have the competence to decide it, so all is fine. Until the idiots come, and listen to the even more uninformed idiots, and fuck everything up. (Examples: Clippy, Windows 8, iOS/Google autocorrect, Ubuntu Unity, Gnome 3, KDE Plasmids, and even ShowView [if you remember that one].)
And MediaWiki is one of the well-known textbook examples of the inner-platform effect anti-pattern. (TypoScript is another big one.)
It tries to imitate the feature set of HTML, but dumbs it down under a false pretense, and ends up with a just as (or in many cases even more) complicated yet very limited system, that is vastly inferior to the original. It would have made more sense to just use HTML in the first place, and be done with it.
There is no saving the whole thing. The foundation is rotten to the core. The philosophy is deeply, utterly wrong. Nuke it from orbit, and replace it by a nice XHTML subset and a WYSIWYM(ean) model. Done. End of story. End of problems.
Also, if we see Ethiopian kids that never saw a computer before and could not read or write being able to use Android tablets to go to the web, play games and even modify ("hack") it after a few weeks, then nobody can tell me that learning something as ridiculously simple as HTML would be "hard". There is no excuse. If you are a human, and have no extreme mental disability, you can learn HTML! In a DAY.
Wikipedia editing is not about formatting. It's not about font or size. The markup language includes links and many macros with specific parameters. Those are where users require assistance. {{cite book}}, for example, requires many parameters which could be filled in automatically, such as author, title, ISBN, publisher, and date of publication.
Wikipedia's big structure problem, though, is that it is a wiki only. Some kinds of information belong in a different kind of structure. Items like "State Route 92" belong in a spatial database tied to maps. Music and bands belong in databases where songs and performers are automatically indexed. Wikipedia is full of manually maintained popular culture related list items which should be generated with a SELECT statement.
Or at least so I think. Let Wikipedia BE not that easy to edit: someone that wants to edit will have to go through this small extra step.
Those syntax walls are there to keep the ill-determined from jumping right in.
The three laws of thermodynamics:(1) You can't win. (2) You can't break even. (3) You can't even quit.
It's better for Wikipedia to remain tool agnostic and support any editor the users wish to use.
Give me Classic Slashdot or give me death!
The editor should provide facilities for content markup. Wikipedia should have a stylesheet that applies the proper style to each content class. The biggest headache I've ever encountered in collaborative authoring environments is where one primadonna insists that something absolutely has to be done with his favorite font/color/whatever.
Where it is justified to format some content in a specific way, a process needs to be adopted to submit that requirement as a change request to the 'owners' of the style guide for adoption.
Have gnu, will travel.
We should write everything in XML. You can select a formatting template for viewing and everyone will be happy! ,/sarcasm>
If we can't have drag and drop uploads, a least an easier way to upload and place images into a page.
When editing, you need to see more information than someone who is just reading the page. Specifically, you need to be able to distinguish between structure and formatting.
Another problem is the horrendous spaghetti code WYSIWYG tools tend to produce. Imagine Wikipedia source code looked like the HTML produced by Dreamweaver or Frontpage. The result is practically a lock-in, because the code comes out so bloated that you can't make sense it in a text editor. There's a reason nobody uses these anymore.
If the prospective editor can't use mark-up, what does that tell you about their overall intellectual ability? Keep Wikipedia great, full of high-quality articles by intellectuals -- disallow visual editing.
I'm an author at the SCP Foundation wiki, which uses it, and it's head and shoulders better than mediawiki syntax, at least in my opinion. The commands used are more obvious, such as **bold** //italics// instead of wikimedia's deluge of dashes that has to be supplemented by HTML anyways, modules work in much more obvious ways, and there's much less formatting that induces accidental screwups. WYSIWIG is not a good way to edit anything but plain text, either way.
All these need to be much easier to use than they presently are. Perhaps have a dialog for the different type of templates used.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
A visual editor is essentially a very program with many, many features. No one does the interface particularly well, so consider making an interface that is based on information complexity and brain theory rather than the current model.
The current model has features stuffed into every corner - the edges and corners of everything sprout features, a zillion toolbars stuffed with icons, tooltips are everywhere. It's gotten so complicated that I don't think anyone bothers with customization any more.
Do some data mining on the editing process and count the types of changes people make. Take the logarithm of that number and put that many icons and shortcuts for the most used operations on the front page. Make everything else available, but hide it.
Rather than making a zillion incomprehensible icons and using tooltips to clarify, consider using icons of 2-letter abbreviations. Use English abbreviations - no one cares that music notation is in Italian, no one cares that medical notation is in Latin, and no one will care that the interface notation is in English (...but translate the popup messages and help files into native, of course). With 2-letter abbreviations (and throw in a few extra symbols) you can make icons that remind the user of the function. (For comparison, consider the 2-letter abbreviations in Perl: $! means "What went bang?", $= means "number of lines in file", &c.)
If Icons can have 2 letters and other symbols such as dingbats or greek letters, you can have a large number of mnemonic functions such as <scissors>-2 meaning "cut to the 2nd cut buffer".
If you make some good conceptual design decisions you can make the interface intuitive and eliminate lots and lots of widgetry. For example, instead of considering the document a page of text with inserts of other things (as does Microsoft Word and HTML), consider going to an object/position model.
Suppose the page starts blank and requires the user to place objects before anything else. A text box is an object, as is an image or video. Once the user can create and size text boxes (rubber banding), you no longer need a complex "column layout" panel with all sorts of widgets to define columns - just have the user place text boxes where needed, and note how the text should flow from one to the other. Add in some group/distribute/z-order functions to tidy things up (common across all objects) and all the layout becomes intuitive - no complex interface needed.
Instead of making the help files a search in the linear manual, make the help into a tree structure. Start with "is your question about text, images, or video", let the user select one of these, then ask more clarifying questions until you get to the topic the user wants to know about. With 3 options per node, the user can drill down into the subject matter very quickly. This is especially useful when the user doesn't know how to properly describe what they want to do, or when the subject is some jargon word the user doesn't know like "Kerning", "Alpha transparency", and so on.
Include a long list of "How do I..." answers, and have this list be searchable.
It's incredibly useful to be able to leverage functionality externally, so consider making your editor in two pieces - a functional engine and an interface/display engine. Make the connection between these two pieces a socket interface and publish the API - this way other people can invoke your engine using external programs, and make automated scripts &c.
Also, people can make alternate interfaces to play around with different display techniques.
WYSIWYG is misunderstood and over hyped. It is only practical for editing presentation but for actual EDITING it is like forcing somebody who can run to use crutches!
Wikipedia in recent times is largely edited by frequent users and not newbs. They would be best served if they catered to their primary demographic's needs for a productive EDITOR and then maybe put a little effort onto a WYSIWYG version for newbs later (they could encourage userscripts.org to get involved in developing newb editors.) They can plug-in a newb editor later on, have a contest or something.
Keyboard shortcuts + "cheat sheet" its all javascript; program it open enough and people will write their own bindings.
Wikipedia thankfully lacks the formatting options of WYSIWYG editors and that keeps the site more like an encyclopedia. What could really be used is better quality table editors - I've not met a table editor I liked. If they want to innovate, create nice table and hierarchy content editors for structured text... it could lead to more interesting uses of the information beyond just sorting tables by row. One could specify related topics in a hierarchy - akin to breadcrumbs and that information could be interpreted differently than simply a list of links. Properly defined tables can be intelligently converted for better use/presentation. I don't think their markup goes much beyond presentation only so this would involve some changes. For example, typing in table information is easier done as an shallow outline then converting that into a table than it is to fuss with a table editor or even a spreadsheet (but it depends.) A newb would be confused how a table can go to and from an outline but newbs are slow anyhow and should stick to their mouse driven GUI table editor.
Democracy Now! - uncensored, anti-establishment news
While a GUI editor may not be an entirely bad idea, is there such a thing as making editing too easy? Perhaps having to learn the syntax is a good, modest "entrance test" in the abilities of the potential contributor?
The project has made it this far without a GUI, is there really a need to lower the "barrier to entry"?
I haven't played with the particular editor that's being rolled out, but in principle, a visual editor could have buttons for things like "species," "Court case," etc. that translated into either a template that rendered the word or phrase in italics or, if no template were available, something like this:
<!--WikiVisualEditor;type=species;MOSSTYLE=italic;MOSASOFDATE=2012-11-17;timestamp=20121117184703-->''Homo sapiens slashdottus''<!--WikiVisualEditor;type=species-end;timestamp=20121117184703-->
Whether stored in the page as above, as just ''Homo sapiens slashdottus'', or as {{speciesname|Homo sapiens slashdottus}}, it would render on the screen as Homo sapiens slashdottus.
Over time, all uses of italics, bold, etc. could be easily templated.
Except for existing code stored as plain old italics, the visual editor would render such things as italic but with some kind of clue, perhaps a tinted background, that more information was available with a mouse-over or other action and that this wasn't "plain old italic" formatting.
Likewise, signed-in editors could use widgets that recognized these templates and WikiVisualEditor-specific HTML comments and added the color-coded background and mouse-over effects on pages as they were viewing them if they wanted to.
All of this could be done without breaking the wiki, requiring that the Manual of Style be changed, or breaking the ability to edit using a text-only editor.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
My biggest complaint with most word processors is their default behaviour to change e-mail addresses and web addresses into blue, underlined hyperlinks.
I actually use word processors to create stuff that gets printed on paper. Hyperlinking, blueifying, and underlining words is useless to me, and wastes my time. I can think of no good reason why MS or anyone else should assume that every user of their word processor is creating web pages.
And while I'm at it, I can't think of a single time when I wanted the formatting from a web page to be carried into a printed document when I copied and pasted a block of text. Surely the sensible default should be to paste in plain text and pick up formatting from the destination document? At the very least this should be an optional default.
Three Squirrels
From their site:
"The decline in new contributor growth is the single most serious challenge facing the Wikimedia movement in the year 2011. Removing the avoidable technical impediments associated with Wikimedia's editing interface is a necessary pre-condition for increasing the number of Wikimedia contributors."
I'm not sure that the editing is the main problem with dropping contributors. The problem is that most of what you write will be deleted, any image you upload will be deleted, and nearly edit you make will be undone.
Agreed. Seen to many changes just reverted. You have no time to fight over reverts with people that have much more time and termonology to fight revert wars.
And to reflect the optiion that there is room enough for more info, the editor should include ALL options.
Every uses just 20 % of his favorite editor, the problem is that every one uses a different 20% , so you cannot leave the 80% of other options out.
What did my word processor get wrong? I have tried and/or used virtually every word processor currently available for the Macintosh and except for LyX, they all lack the ability to intelligently place stand-alone objects such as graphics, figures, tables, sidebars, etc. Except for LyX, they _all_ treat these objects as giant characters. (Please don't tell me about anchor points etc.—they don't solve the problem.) This was astonishing to me when I discovered this about a year ago as I prepared to do a major piece of technical writing. Not even the vaunted Microsoft Word can do this. My astonishment is due in part because from about 1988 to 1998 there was a word processor for the Mac that did this with aplomb.
Second on my "missing" list is built-in equation editor. Again, LyX handles equations natively, not as an afterthought or as a third-party kludge.
I have some content that is hard to understand. How can I make it easier for people who don't understand what they're doing to fuck with it?
Ob car analogy: My car engine has all these fiddly wires and bits. This is preventing people who are not mechanics from tinkering with it. How can I put larger handles on engine parts so that the average car driver can get them out?
WYSIWYM instead of WYSIWYG :-)
Why bother making a fancy editor when the bigger problem is the cliques of editors driving away new volunteers?
There have been many attempts to tackle this problem (not just with wiki markup) and most of them have foundered when the requirements of the document type went beyond the facilities that could conveniently be represented in a synchronous typographic interface (I have been gathering these for my thesis on structured editing). Let's hope this implementation is more successful, given that the wiki markup is relatively simple.
A megabyte is what, like a milligig, right?
Help stamp out iliturcy.
Ihave a PhD in molecular biology, and know one or two things aobout DNA (if not spelling)
and I stopped contributing cause of , in order
1) the license lets someone take my work and resell it for a profit. I will be dammed if i will work for free and let someone else , some scumbag maybe, profit
2) i am tired of re re re re correcting idiots (I mean like 2+2=3 idiots)
3) wiki syntax is a pain in the ass for anything other then plain text; I agree that is a problem
most of the articles with obnoxious editors seem to be articles with obnoxous trolls, eg "intelligent design" "state torture" etc
esp articles critical of the USofA get pounded by the wingnuts
but I have to agree, the parent is a coward in not naming one or more specific articles where he or she has had a problem with editors; i myself, in over 100 articles, have never had a real issue; yes there have been times I strongly dis agreed, but democracy is messy
most of the posts reflect a typical slashdot arrogance - we know computers, therefore the way we do things is better. I'm not gonna argue this fight, which is older and more bitter then vi/emacs, or even the unix haters handbook, but I will observe, for those interested in reality: Most of the people who use wiki are not computer people for most of these people, an MS word style editor will be easier to use , esp if it has good citation/ref features builtin, then current or any sort of HTML to put it another way, the 100million potential new wiki users would have to spend 10 hours each to get *comfortable* with html, when they already know word. so thats roughly 10^9 wasted hours. I speculate that the wikimedia team can make a good editor in 10^9 man hours - a lot less. case closed this is like slashdotters saying that the avg person should use linux because they can..configure the sector size on the hard drive. hard to argue with someone like that.
Wordstar with easier GUI. Collumn editing and pre-formatted sidebars.
In office I dread every time I do copy/paste since I know it will inevitability do the wrong thing. Please always paste in context. Do not paste with formatting.
The XML approach to text is to wrap stuff in brackets (such as start and end of paragraph). Large-scale brackets are tough on revision merging. The affordable algorithms don't guarantee that brackets remain matched, which can render XML hopelessly invalid. Using separators (like marks between paragraphs) makes it a lot easier to preserve the validity of structure.
There's that other thing: people writing for an encyclopedia should perhaps not have to worry about whether or not <br /> is self-closing or if there's a hanging tag, or any of the bullshit that comes with writing HTML by hand. HTML to my mind is *supposed* to be generated. As a web developer, I do as little actual html-writing as I possibly can.
But it's okay to make casual contributors write out html because, STFU N00B, LEARN TO CODE LOLZ!
Everyone knows that's only acceptable for Linux.
idea - suggestions for wikipedia new editor
Caveats:
- As I don't know the current UI for wikipedia editing well maybe it already has some of these things.
- A new UI probably is not in fact the main reason for dwindling contributors, as someone else pointed out. Just saying.
General UI
- Screens are big these days. Consider an interface that keeps everything on one screen.
- At least a rich text editor type thing with buttons for tags and popup input forms for entry of book info, etc.
Editing Together
- Allow simultaneous editing by more than one person. The portion being edited will update in semi-real time on the other people's screens.
- Within the editor UI include a chat frame to allow people to exchange messages in real time or asynchronously and view the past thread of chat, to discuss the article and edit it together simultaneously.
- Consider adding voice/video chat by that chat frame, or allow another window to opened that has a video/audio/irc chat.
Viewport
- Allow more than one portion of the same file to be visible while editing. MS Word allows you to drag down a viewport separation bar from the ruler area so you can edit two locations in one file simultaneously. LibreOffice can't do this yet which is frustrating to me, wish they would add it.
- Apple P.I.E. (Programmers' Interactive Editor) was an awesome editor for the Apple ][ which was a light year ahead of a lot of editors even today. One function I remember clearly decades later was being able to hit IIRC control+0 which would jump the insertion point to past saved cursor locations, letting you jump quickly through a number of points in the file. I have never found that function in other editors and have often wanted it.
Adding Media Collaboratively
There are relatively few or no illustrations or photographs illustrating articles. It may be due to copyright fears, lack of talented willing illustrators, or difficulty in uploading and referencing the figures in the text. For example, it seems unlikely that the author of an article is also a talented artist, whereas an artist reading the article is not going to want to learn how to edit wikipedia and get deep into it. Anyway there may be some obstacle, so we should try to make it easier. -> Allow inline images, and provide a facility allowing casual users to upload them (with a form vouching CC right to use it) for consideration for inclusion by the article editor, and have someone else edit them.
Templates
- Provide templates in LibreOffice that you can edit and upload. Who wants to edit in a browser window? It isn't yours, it isn't available when you are offline, you might lose your work by closing a tab by accident, etc. etc. The basic idea of editing something important in a browser window is actually anathema to me..
- For that matter, you could integrate with LibreOffice..
Smart Editing
- Allow / Force the user to identify proper nouns, processes, etc. that have / should have their own Wikipedia entry. Wikipedia can search for the article and make the entry a link to the article.
- Editor can provide smart facilities for adding other kinds of content.
For example being able to upload a midi or wav / ogg file in order to explain something about music is an idea.
- Provide a smart import wizard that lets you easily import a table by for example copying a range of cells in LibreOffice Calc or some other spreadsheet program and pasting it into an import text area (or allow a spreadsheet file to be dragged onto an import button area).
Third Party
- Create an API so third party authors can write cool editing apps.
Databases
(after writing I discovered there is an initiative: http://meta.wikimedia.org/wiki/Wikidata )
- Add ways to input and maintain data that is not cartesian rows and columns. How do you input and edit:
o A hierarchical tree?
o A tree with lateral links?
o A bunch of items with faceted metadata?
o A graph wi
...because writing equations in Word takes years, and auto-numbering the equations is impossible
Since Wikipedia is an encyclopedia it must handle large datasets in each article. Then the table is one of the most useful tools to give a comprehensive overview of any subject (chemistry, sports, social sciences etc.).
The tables should support copy&paste from other editors, web pages, whether (as Google Docs) only with ctrl-c/ctrl-v. If you can get a table structure in copy&paste working, excellent.
Of course the table should support all kinds of column sorting as is already done today, where _stable_ sorting is the preferred default I guess.
Tables should be a high priority.
>> Start: 2011-05-15
article appears on ./ about a year and a half after the project started. sounds about right.
The correct question is: do you want a document editor or a page layout tool? WYSIWYG is strictly for the latter. If you want to write a document, worrying about layout and format is absolutely not what you should be doing. Finish writing, and then hand it off to a formatting/layout tool.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
You can't beat EMACS and pandoc! It's impossible.
Sam Flint flintfam.org/~swflint
It could break the mold of all the current WYSIWYG editors and actually be WYSIWYG. So when I delete a bullet point, it shouldn't change the font of the current line, alter the indent of the preceding and successive paragraphs, change the style of the inline image etc. etc. etc.
crowd sourced auto spelling correction
speaking as a person with dyslexia, i've wanted something like this all my life and no of the tech giants ever seemed to catch on.
all the people out there that think this would be bad for language as a whole or make people "lazy" can go suck a lemon
What's the point of the "crowd sourced" part apart from being a nice buzz-phrase?
In the short term, a word is either spelled correctly or incorrectly, it's not a democratic decision, except in the long run where usage defines "correctness".
Where there are ambiguities (e.g. in the case of incorrect homophones of the their/there variety) these require a better grammar checker than I have ever come across, rather than a spell checker.
To have a right to do a thing is not at all the same as to be right in doing it
Sorry to take a while to reply.
No problem. Because Slashdot has no private message system, perhaps the best way to continue the conversation is in the comments section after waiting for trigger-happy moderators to have left.
Someone removed half of it in 2010 because there was too much criticism. This section was well referenced.
Did you try discussing the cuts on the article's talk page?
I've had photos deleted "because they contain a trademark".
Did you try discussing the deletions "because they contain a trademark" with the deleting administrators or taking the incidents to deletion review?
I've always seen the learning curve in editing Wiki articles as an idiot filter.
Learning how to format Wiki text proves you have the capability to learn and that your processes are malleable.
I speculate that if editing Wikipedia becomes any easier the quality of content will decrease while the administrative overhead will increase.
This is what WP really needs.