On 31 May 2010 22:53, William Le Ferrand <william(a)corefarm.com> wrote: What you're working on is a *hard* problem a lot of people have attempted, with varying success. There's been some discussion of this of late on mediawiki-l. The default editor on new wikia.com wikis is WYSIWYG-only. This works tolerably well (a bit buggy, but actively worked on). The common WYSIWYG solution for MediaWiki is FCKeditor, which works *almost* pretty well but: (a) falls down badly when you try to mix WYSIWYG editing with wikitext editing and chews up the wikitext (b) doesn't cope very well with the weirdest stuff done on English Wikipedia, where wikitext is tortured horribly to squeeze out every possible emergent side-effect for editor's use (c) is not actually being worked on at the moment. (Though one mediawiki-l contributor says he's been using it to good effect on his work intranet and is seeking permission to release back his changes under GPL.) http://mediawiki.fckeditor.net/ http://www.mediawiki.org/wiki/Extension:FCKeditor_%28Official%29 FCK+MediaWiki discussion recently: http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/thread.html#33896 http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/thread.html#34061 You may care to have a look at FCKeditor+MediaWiki and see if you've just reinvented the wheel and can help get that up to scratch. Or, alternately, if your approach is different enough and better enough to pursue nevertheless ;-) - d.

On 31 May 2010 23:31, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: ... and the problem with the wikitext being mangled is that diffs show a 100% text change for any alteration whatsoever and become useless. Even if the content isn't semantically mangled. FCK+MW is so *almost* there it's frustrating how close it seems. But then, this is a problem where the last 5% of the list is the last 95% of the work. (Will *this* be what tempts me to take up coding? Be afraid ... I have the algorithmic insight of a sysadmin and only know about force and brute force ...) - d.

On 31 May 2010 23:50, Angela <beesley(a)gmail.com> wrote: :-D How installable and workable is this on, say, any random work intranet with a fairly generic MW 1.16 installation? I may give it a go at work ... [cc to mediawiki-l] - d.

On 31 May 2010 23:37, David Gerard <dgerard(a)gmail.com> wrote: The other solution is to use a proper MVC framework, and define everything in terms of modifications to the wikitext (and you can then constrain what those modifications are to avoid mangling) and run that through a parser to generate the html preview. Alternatively, if your wikitext modifications are constrained enough, it is possible to implement modifications as a pair of functions, one of which edits the wikitext and the other edits the HTML (this is the method used by English Wiktionary for the translation adding interface - and makes undo/redo really easy). Building such a thing is time-consuming - particularly if you have to ensure that the wikitext modification and the HTML modification are the same - as there's a pretty large number of things people would like to do with wikitext. That said, it's pretty possible to use a wysiwyg for editing the contents of a paragraph, so you could have one action for "change the content of" in addition to actions for inserting/deleting and moving things around (in a perfect world, a wysiwyg would trigger constrained actions based on user-interaction - that is the "hard" part of this - the rest is just complicated). As there's already a javascript thing for general template arguments modifications (based on xml somehow), so this would be extendable to work with templates too. Conrad

Just noting that we at WMF have been talking to Wikia about taking a look at their code to see if it can be made useful for WMF properties. Expect to hear more about Rich Text Editing soonish. Danese On 5/31/10 4:00 PM, Angela wrote:

On Tue, Jun 1, 2010 at 4:09 AM, Jacopo Corbetta <jacopo.corbetta(a)gmail.com> wrote: We could do the really hard way, like Google did with Google Docs (http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-doc…): make *everything* via JS by capturing keystrokes and mouse movements. This way a consistent and reproducible user experience on all platforms can be achieved. And by doing it all in JS, the editor could also generate a wikitext-delta right away and doesn't need to transfer the whole page's wikitext. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de

On 31 May 2010 23:53, William Le Ferrand <william(a)corefarm.com> wrote: This is a nice approach, It will be really helpfull for no-geek people, and theres millions (literally) of no geek people you may want to be able to edit a MediaWiki based wiki. "Beyond this place, there be dragons!" I like your implementation, because feel almost fullscreen. Too bad theres two scrollbars. Are these two scrollbars needed? Maybe the whole "page" can scroll, and the toolbar be stuck on the top of the screen. I suppose your implementation still pretends is a textarea, because that way the toolbar is always visible. But this is not needed if theres some CSS magic that can make the toolbar visible.. floating. You can even have different toolbar in different regions, like a "Close / Save " toolbar on the North-Right that only show if the mouse is near that location. -- -- ℱin del ℳensaje.

On 6/1/10 8:24 AM, Roan Kattouw wrote: First off, I try not to get involved in these threads because they are almost always the same circle of "Why not?" -> "Because!" and "What if?" -> "No!", etc. In Berlin I gave a quick demo in the UX working group of a new parser I've been writing that understands the structure and meaning of Wikitext, rather than just converting it on the fly into HTML like the current parser (actually a hybrid parser/renderer) does. To be fair, the current pre-processor does properly parse things into a node-tree, but only for a small subset of the language, namely templates. My alternative approach parses the entire wikitext document into a node-tree, which can then be rendered into HTML (or any format for that matter) or back to wikitext. By having a unified data-structure for an entire article, we can do all sorts of things that were never before possible. What we need is to be looking at building a first-class wikitext-editor, rather than adapting a buggy HTML editing system (ContentEditable). Wikitext deserves an editor that thinks in wikitext. Wikitext is a round peg, and ContentEditable is a square hole. It doesn't matter how much you try and force it in, it will never fit properly. Google has come to this conclusion after years of struggling with buggy browsers and poorly designed APIs. I would prefer not to go down a long road of hardship and struggles just to come out with a similar conclusion. - Trevor

On Tue, Jun 1, 2010 at 11:22 PM, Marco Schuster <marco(a)harddisk.is-a-geek.org> wrote: Google Doc's interface acts like sh*t unless your on a super dooper decent computer and gives negative views on the usability of a service. -Peachey

Hi there Happy-melon (great handle, btw). Its not quite that straightforward. We have met with Wikia folks and they've acknowledged that it will be a fair bit of work to adapt it to our uses. Wikia has offered us engineering resources to assist this effort. As I say, we are planning to investigate further in the coming months and of course we'll disclose our findings. Danese On 6/1/10 4:37 PM, Happy-melon wrote:

"David Gerard" <dgerard(a)gmail.com> wrote in message news:AANLkTimhzXdzWQwyT748NEmUsit_5ckLLVwLEByef2yx@mail.gmail.com... True. Waiting with eager anticipation :-D --HM