Dedicated Wikipedia editor

(See also: Wikipedia Client)

- '''A client-side reader/editor is currently under development. Contact Magnus Manske if you'd like to help or test.''' -

The idea
To create a cross-platform, multi-lingual, stand-alone editor for Wikipedia authors.

Rationale
Working on Wikipedia articles through the web browser interface is suboptimal. There are functionalities that can not (or are difficult) be achieved. Wikipedia authors can benefit from this tool.

Pros

 * most authors are comfortable with using editors (word processors)
 * time-saver
 * cycle write/preview/check is annoying
 * improves text quality (spell checker, thesaurus, dict)
 * PHP script won't be overloaded with advanced features

Cons

 * almost all use some editor for their work anyway
 * one needs to change habits while switching to dedicated editor
 * tasks can be delegated to server-side

Implementation

 * software solutions
 * Java / eclipse
 * tk/tcl
 * wxwindows
 * python + ?
 * extend an existing editor (emacs)
 * extend an existing web browser (mozilla)
 * functionalities (from author's perspective)
 * simplified WYSIWYG
 * spell-checker
 * formatting
 * inserting mark-up
 * thesaurus
 * dict
 * translator (using external services ?)
 * quick navigation between drafts or cached files
 * multiple editing windows (for example different language versions of the same article)
 * list sorter
 * alphabetical
 * by date (reverse)
 * search and replace
 * text statistics
 * text style feature
 * math formulas editor
 * diagram editor (SVG ?)
 * auto-starting edits
 * 'what links here' 'watch links'
 * unicode converter/prompter
 * html to wiki translator
 * research help for extracting facts out of several sources
 * technical functionalities
 * tracing recent changes in multiple Wikipedias (no need to reload the whole page of rc)
 * locking of articles
 * local article caching
 * local article navigation
 * off-line mode
 * "syntax" colouring
 * auto-text, text expansion, vi/VIM 'ab'
 * folding
 * image uploader
 * automatic notification when watched article changes

Developers

 * coders
 * translators
 * documentation and help team

Physical location of the project

 * Bomis ?
 * Sourceforge ?
 * Savannah ?

Instead of coding a Wikipedia editor from scratch, I'm more interested in rigging up Emacs to do the job I know that there are a couple of wiki modes, but I'm not skilled enough to put the thing together. -- Stephen Gilbert


 * A lot of people have a different editor of choice than Emacs. Surely it is much more work, but it could be made customizable and expandable to everybody's needs.Kpjas 2002-11-04

Like I said, I am more interested in Emacs. :) -- Stephen Gilbert 20:09 Nov 6, 2002 (UTC)


 * I think there is a number of good arguments for adapting Emacs to fit the needs of a dedicated Wikipedia editor (we could rely on w3 for WYSIWYG-preview, there are already a number of good editing facitilities and it is already fully customizable). Another good choice would be to add a wikipedia mode to jedit, an open source editor in Java with utf-8 and unicode support and almost as many plugins as emacs has. And my general comment: I'd love to have a dedicated wikipedia editor :-) (but regexp search is a must!) I am ready to help with testing and documentation, but I can't program. --elian


 * i've started to write a jEdit plugin, see http://djini.de/software/wikipedia/ -- D 22:07, 5 Apr 2004 (UTC)

For Emacs, see Emacs:SimpleWikiMode and related pages. -- Alex Schroeder

Thanks Alex. I'll check it out. I should have remembered EmacsWiki! -- Stephen Gilbert 20:09 Nov 6, 2002 (UTC)

Rather than just an editor, it might be better to have a full-fledged Wikipedia reader on the client side. Hey, if you're already thinking of doing WYSIWYG editing, you gotta render the stuff already!
 * Multiple data stores
 * A previously downloaded or CD-distributed dump could be referenced for speed, with additional updates grabbed when needed off the net
 * Compression: the static HTML dump is a nice start, but takes a lot of space. A client program which speaks gzip enables the dump to be compressed, squeezing a lot more stuff into less space (and keeping the data in wikicode means we can do offline editing as well)
 * Offline browsing
 * Can fetch updates to items in a watchlist, and pages they link to, then browse offline
 * Filtering: since the client controls which pages it grabs updates for, 'watch', 'ignore', and 'wait for admin approval' lists could easily be included. This can be usd to implement quality filtering.
 * Mirroring
 * A school could have a full (or filtered) central datastore on a network share, with the clients set to offline-only and grabbing updates periodically on the central store.
 * In theory, the client could have an HTTP daemon built in and serve as a mirror to web clients too. ;)

However this is implemented, it should be mind-numbingly easy to install: a single executable file should be all you need to run it; site-specific configuration might add a config file and base data store on a network share. (I'm dubious of Java for easy install; execution isn't world-standard, and if there's not an appropriate JVM on the machine, the user has to find and install one too.) A CD-ROM distribution might include a data dump and executables for a few major platforms (Win32, Linux/x86, Mac) and the source, which could be compiled by techheads on other UNIX-like systems. --Brion VIBBER 19:57 Nov 28, 2002 (UTC)

Just in the case that it's possible, I would prefer a cvs access to the database thus that everyone could simply use his own editor. This would result in being possible to mirror the entire Wiki as well as it would result in getting rid the annoying concurency editing problems as cvs works on the base of modifications. --Bodo Thiesen