Talk:Dedicated Wikipedia editor

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

2002

Solution notes

Advanced features and the speed of this solution could be appreciated by advanced users: people writing many articles simultanously, people trying to keep eye on the whole division (e.g. maths or literature), sysops, Wikipedia militia, ambassadors, developers, etc. Browser's solution is adjusted for "plain" contributors.

Instead of pumping up the PHP script with very advanced code which would be used by small percent of "heavy" users we could develop this kind of editor. Reasoning is: if you are "small" contributor use the browser. If you want to track many things don't waste DB's power and bandwidth and install dedicated client.

It wasn't mentioned in the original proposal and I want to stress that: caching browsed/written articles + easy navigation between the articles one wrote/one is writing at the moment (through clicking on just inputted [[link]]) would speed-up writing very much.

One would expect at least (oh, sweet dreams!) some kind of WYSIWYG plugin to the browser - the cycle write/preview/check is annoying.

Out of the point (maybe not):

I tried to use Wikipedia software on a local computer for my private purposes but it... sucks. Main obstacles: the speed is not impressing, the 'write/preview' cycle... see above, the lack of database-dump-in-a-nice-format. Right now I'm in a phase of OOA of wiki editor/wiki net based on OpenOffice. It will use external DB for link maintance. Of course it will be digging in .sxw files for updating, relinking purposes. Things I stress in such solution (for private use) are: WYSIWYG, speed of navigation, support for maths formulas, version contorol, articles-are-already-dumped. Scripts like wiki support for Emacs (found on www.emacswiki.org) are too primitive for the time being.
Youandme 23:21 Nov 2, 2002 (UTC)

2005

Similar efforts

I am (slowly) working on an editor based on XUL and Javascript. The parser is based on the one from Wikiwyg. This means that it is already cross-platform, and can run of off the current code base (though some non-standard options must be set). I will post more as it comes. --Astronouth7303 18:22, 8 May 2005 (UTC)

2007

Round-tripping

With a number of years in various documentation source projects, I think the ideal solution lies in round-tripping. The concept would be that you could grab your existing Word (or whatever editor) documents, publish them to wiki with styles, collaborate on them, and push the content back into the host editor for final print proofing.

Thus people who refuse to use your web interface, can easily work within their editor of choice and still publish back to the wiki.

For this to work well, you need a wiki <==> rtf convertor base application, that various afficiando's of the different processors could then extend to match the advanced features of their editor of choice.

The wiki text then needs some sort of print embeds. Quite frankly, a hidden type of <PageBreak> structure would suffice, as the print only embeds do not to be processed by the online component.

FlexWiki and others are starting to develop extended Wiki editing toolbars for easier markup thru GUI tools. So rather than true WYSIWYG, you aim for GUI-based markup and allow the export into your favourite WYSIWYG editor to provide the WYSIWYGedness desired.

Document creation is mainly about content development - the layout tweaks are the very final step of the process and all we need worry about is preserving those attributes in the wiki text for re-use next round trip.

Workflow would thus be:

1. Upload legacy text into the wiki page(s).
2. Collaboratively edit the page(s).
3. Download prepared text into your editor.
4. Layout the document ready for print.
5. Print.
6. Upload the now prepped up text back into the wiki.

Of course, for highly dynamic content the final step is redundant, as the massive re-editing before next release will invalidate much of the page-based markup provided by you and your favourite editor.

Steve Hudson Word Heretic 203.206.143.180 07:14, 16 March 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.