Wikipedia Client

(See also: Dedicated Wikipedia editor, Machine-friendly wiki interface)

---

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

---

I am unsatisfied with using a web-browser to edit content. I am unsatisfied with switching between editors and other applications to use Wikipedia. I am unsatisfied with the latency and pull nature of the "RecentChanges" link. I am unsatisfied with the lack of immediate collaboration on articles, i.e. people working on the same document truly simulateneously.

These are all limitations that are imposed on the Wikipedia user by web interfaces, and they are not going to go away anytime soon. The only solution is to create a client that can access Wikipedia and which provides these features. Such a client would not replace the existing web interface, of course: it would merely be an additional, more effective way for advanced users to use Wikipedia.

Specificially, the client should

• include a (visual) editor with Wikipedia-specific features and allow integration of alternative editor components
• automatically fetch RecentChanges updates in regular intervals
• make it very simple to navigate revisions, for example with a two-panel window that highlights differences
• integrate with the Wikipedia IRC channel
• when two users open the same document with the client, allow collaboration mode: a chat is opened, and one user can assume control of the cursor and mouse
• cache articles locally and allow offline browsing, searching and indexing of wikipedia tarballs
• do anything else you can think of.

To implement such a beast, at first one would only be able to hack the existing Wikipedia using the "protocol" as defined by the HTML layout and forms. This is a very unsatisfying solution, and eventually, the Wikipedia server should learn to accept standardized XML-RPCs.

The actual implementation could go forward in several steps. At first, a simple browser/editor component would be the most important: Being able to navigate and use Wikipedia without an actual web-browser would be nice. More advanced features could be implemented later.

I would personally very much like to use such a client, and possibly be interested in writing it (in my case, likely in C++/Qt or C/GTK). Is there any broader interest in such a tool?

---

Oh dear god, not XML-RPC! I agree that having to parse out the table of contents and extra links and so forth is bad, but there are ways to do what we ned via plain old HTTP. For instance, to get the raw data for a page, you might use a URL like "http://www.wikipedia.org/wiki/some_article?output=raw". It would also be nice to be able to get the page as HTML, but without the extra links, like so: "http://www.wikipedia.org/wiki/some_article?output=html". - TOGoS

I agree that XML-RPC (or SOAP or WebDAV) feels like overkill. A simple XML return format for thinsg like recentchanges, history, and metadata (author, revision date) might be useful, but plain old HTTP should provide all the calling semantics we need. --Brion VIBBER 01:34 Dec 11, 2002 (UTC)

You're right. I like to complain about XML (I think XML-RPC is especially over-hyped), but it has its place. Anyway... What I'm really thinking is that the interface between the server and the client should be as simple and intuitive as possible. For instance (to expand on what I already said), to update a page, you would just do a PUT (or POST, more likely) request to 'http://www.wikipedia.org/wiki/article_name' with the new raw wiki data as the body of the request. Right now, with the web interface, you have to post data to some weird, non-inintuitve URL. I know the client would take care of this (and I actually don't really mind it for the web interface), but having a simple, intuitive, not-bound-to-the-implementation client-server interface has a number of benefits:

• makes the system more modular
• easier job for the implementors
• we don't want our computers to end up speaking the equivalent of English, do we? (go loglan!)

So I think it would be worth it in the long run to do a little extra work to get the server to understand a more intuitive 'language'. What'sit running? Apache...? Might take a little work. But hey, that's what Ruby's for. Write your own server! (Perhaps this rant belongs on another page. Feel free to move it if you think so.) - TOGoS

---

First, I don't quite understand the first paragraph. Can you expand on these problems you see? For instance, I don't see how it's a bad thing that we can't work on articles "truly simulateneously."

Wouldn't the disadvantages of such a tool (mainly, having to download it--whereas at present anybody with a web browser can edit Wikipedia) trump the advantages of requiring a Wikipedia editing program? --172.139.98.xxx (which is to say, Larry Sanger in the field :-) )

---

The existence of a separate client for editing pages (as opposed to merely reading them) might also serve as a useful pons asinorum for editors. --LDC

---

We could probably have a dual interface option: you can use your browser for quick access, or download the client for increased functionality.

I'd be interested in such a beast. However, I'm not sure about the real-time collaboration mode. I don't think everyone gets along well enough to work in real-time. ;-)

For the record, the Opera web browser has a feature to automatically reload any page at set intervals. --Stephen Gilbert

Oh, one more thing. Have you ever used the wxWindows library? (http://www.wxwindows.org) It's a C++ framework designed for cross-platform programming. I'm told it plays nicer with Win32 than either QT or GTK. --Stephen G.

---

I'd recommend writing something that would work as an add-on to Mozilla. I suspect most of the functionality desired is already built-in or is available in other plugins already. Also, it seems to be the easiest way to construct platform-agnostic software these days. --TheCunctator

---

Wow, thanks for all the feedback. First, my idea was never to replace the web interface, but only to provide an additional way to access Wikipedia for regular users. However, I think the client could have some features that the web interface does not offer (e.g. collaborative editing), which would always be optional for all concerned parties to use.

I'm familiar with Opera's nice reloading feature, but for the client I would, at least in the long term, envision something different, namely a refresh that only shows changes made after the last load. This would require both additional client and server intelligence, but would drastically reduce the bandwidth required for refreshes. The Recent Changes page, especially when very large, takes hundreds of kilobytes, and reloaded in regular intervals, generates quite significant amounts of traffic. Now, I certainly hope that Wikipedia's financial situation is good, but from a cost-benefit-analysis, it is clear that the money saved by having a low-footprint refresh would easily outweigh the time requierd to implement the server and client intelligence.

Regarding wxWindows, yes, I have seen it in action, but never used it myself. It may be a good alternative to Qt or GTK.

Mozilla expansion -- hmm, I'm not sure about that, there's nothing in Mozilla (not even the web browser component) that I would like the client to support, rather, it would render the limited subset of HTML Wikipedia uses directly. This would make it possible to write a small combined browser/editor component (what the web browser should have been in the first place). - Eloq.

Ah, I see. Recent Changes does indeed eat up bandwidth; it's been a source of problems for us in the past when floods of new traffic came in. w:Jimbo Wales could tell you more about that.

A mozilla plugin makes a lot of sense to me. I usually have a number of tabs open for references when I'm editing, and the editor component integrated with my regular browser would be much easier to use than having to constantly switch applications. -- Arvindn

You'll probably want to chat with w:Magnus Manske. He's the main guy coding our new Wiki software. Or better yet, if you're handy with PHP and SQL, head over to http://wikipedia.sourceforge.net and play with the code --Stephen Gilbert

The UseModWiki RecentChanges already supports 'List new changes starting from t' where t is the last time you loaded RecentChanges (actually, it's the time of the last change you saw). Others have patched UseModWiki to put this in the user cookie ala MoinMoin. It isn't very difficult. See http://www.usemod.com/cgi-bin/wiki.pl?WikiPatches/ChangesSinceLastVisit. -- SunirShah

---

Post from Intlwiki-l, Sat, 7 Dec 2002 17:54:48 +0100 (CET)

I'm writing this to the international list because I doubt the English Wikipedians care much about this issue. Today I received an email from a guy in Russia who wants to start his own Esperanto encyclopedia project because it costs too much to constantly be online just to work on an encyclopedia and he wants to distribute the encyclopedia on CD. I also know that we will NEVER have a Czech Wikipedia without it because there is a communications monopoly which requires all people (except very large companies) to pay for the Internet by the minute at quite high rates for the average Czech.

A Wikipedia client is desperately needed if we want more work to be done on the non-English Wikipedias. Users will be able to have the entire encyclopedia (in whichever languages they want) on their hard drives and it could syncronize when they connect to the Internet. Also, such a program MUST be non-English user friendly.

Having a user-friendly process (preferably offline) for people to translate the Wikipedia interface would also speed up the process of getting new languages into Wikipedia.

Could anyone please write such a program?

Thanks, Chuck

---

just some thoughts: a e-mail service for wikipedia, you send an email to a specific address (edit@cz.wikipedia.org for example) with a subjectline like:

SEARCH Tristan Tzara

You receive a mail with the search results.

Then you write:

GET Tristan Tzara (or whatever article title you want)

You do your modifications offline and then you send:

PUT Tristan Tzara, with your modified version in the body of the mail.

If nobody has changed the article in the meantime, the modifications are applied, else you get an editconflictmail...

To protect this service from spammers it could be limited to registered mail-addresses.

This would of course never work for the English Wikipedia, but for smaller Wikipedias, especially in such a situation as the Czech, it would be a possible solution which requires not much programming (at least I hope so - could this be done easily?). Complete this with compressed HTML-versions of Wikipedias for download and offline reading. --elian

---

I have been writing such a program, in Rebol...
It will be able to get and post articles, online and offline, etc... --Athymik

---

People talk about the implementation of "a client" here, but there can be multiple ones. Some want instantaneous collaboration, others would prefer to work offline, later merging their new stuff... I don't think ONE implementation should address all these. Rather, publish a "machine-friendly" interface spec atop of HTTP, using special URLs or whatever, and let people start their own clients. (and share them, if they want so) I've seen this debate "i like C++"/"I use Rebol"/"Did you check wxWindows" multiple times before... come on - each his own - we just need a simple machine friendly interface and things will get started. In fact, it should be easier to do (on the side of Magnus Manske / the Wikipedia coders) than a human-friendly interface.

Repost: Oh sorry, i'm dumb, i missed Machine-friendly wiki interface before posting...

Dirk