Talk:WYSIWYG 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).

How to add a new YT icon to the WYSIWYG Editor Extension?

Hello! How to add a new YT icon to the WYSIWYG Editor Extension (bundle6) ? Wakthrough'ed please! :)

https://www.mediawiki.org/wiki/Extension:YouTube

THanks!

Bold, anyone?

Is it impossible to implement bold and italic into the text editor, without caring about extras like pictures and tables? Can't we just read and write in the same environment, like in any text editor? Because it simply looks like crap.

BBComposer : A WISIWYG Wiki editor

It can be used to edit simple Wiki : BBComposer

If you want to help me improve the Wiki support of the BBComposer, Contact me.

There are 2 ways to improve him :

• Improve the html to wiki convertion functions (html2wiki and wiki2html) in the mediawiki.js file.
• Create an extension for the BBComposer adding a sidebar with some buttons for internal Wiki syntax and other stuff. If someone feels able to create it, an externalisation of the conversion functions can be done too.

This message was created with the BBComposer by Nicolas FROIDURE

• Question: How to configure the Settings für uploading images?

--Thanks, Manuel (Oct 26,2009)

wikipedia WYSIWYG(?)

Where do I get the Wikipedia WYSIWYG(?) The MediaWiki download doesnt come with as many functions as can be seen on WikiPedia. --Magick 21:22, 6 November 2006 (UTC)

Semi WYSIWYG(?)

I think this misses the point. Wiki is so popular because the markup is easy to learn and once you get hold of it is so much more convenient than unpredictable WYSIWYG behavior (I have MS Word on my mind).

I used various on-line WYSIWYG editors and they are -- obviosuly -- just so terribly clumsy to use (much worse than MS Word). Therefore I think a semi-WYSIWYG mode would work better for Wiki. The only thing that people need from an editor is simple things: show boldface as boldface, show italics as italics (instead of the '''''...''''' markup), underline external links, etc.

Other than that it is very convenient to mark lists with a *, indent paragraphs with :, etc.

--A2 19:06, 5 April 2006 (UTC)

Removed

Opera plans to support either the IE or the Moz API in its upcoming version 8, so pretty much all browsers in use today will be supported (the only not-yet-supported one is khtml).

Opera 7.5 is not even out yet, and Opera 8 is nothing but a concept at the moment. If anyone from Opera indeed did state either API would be supported I would really like to see a quote. Darkelf 00:48, 14 Mar 2004 (UTC)

Alexander Limi, one of the main plone developers is involved with opera (does some of their css stuff etc) and mentioned these plans on #plone at 2004-01-24:

(19:37:52) ***limi discovers yet another insanely cool feature in Opera 7.50 :)
(19:38:35) limi: sm, well, mostly to avoid two doctype declarations in Plone, as it's decided by main_template and not the individual templates anymore
(19:38:41) Shifters: thought the latest was 7.23 ?
(19:39:05) limi: there is a Tech Preview out
(19:39:11) limi: TP2 coming soon :)
(19:39:27) limi: one of my closest friends is the UI designer there
(19:39:40) gwicke: all this shameless Opera promotion...
(19:39:41) limi: so I normally run the "nightly build" :]
(19:39:43) limi: hehe
(19:39:44) Tiran: dreamcatcher: ayt?
(19:40:01) Tiran: dreamcatcher: could you pls read my four lines above?
(19:40:09) limi: gwicke, Superior Norwegian Technology! ;)
(19:40:59) gwicke: bah... all those random bugs...
(19:41:02) dreamcatcher: Tiran: uh?
(19:41:40) gwicke: limi: they don't even support Epoz, do they?
(19:42:19) dreamcatcher: Tiran: does that only happens for metadata?
(19:43:06) Tiran: dreamcatcher: I'm not shure but I think that the Descrption() method is not created
(19:44:11) Tiran: dreamcatcher: that's why the description of the parent folder is shown instead of the right description
(19:44:29) dreamcatcher: uhm.... doesnt sound like it
(19:46:11) Tiran: dreamcatcher: adding this method to ExtensibleMetadata solved it
(19:50:00) jmce [jmce@195-23-9-8.nr.ip.pt] entered the room.
(19:52:28) limi: gwicke, not yet - the Epoz stuff is two different techs invented by IE and Mozilla developers, so it's not really a standard. I believe they have plans to support it in 2.0, though
(19:52:38) limi: uhm, 8.0
(19:53:14) gwicke: limi: following the moz api?
(19:53:59) gwicke: hopefully not yet another one...
(19:54:14) limi: gwicke, either the Moz or IE APIs

Gwicke 03:20, 14 Mar 2004 (UTC)

HTML to wikitext converter

There are a few out there, including Magnus Manske's C++ version and David Wheeler's version in en:C, but I decided to create my own en:HTML to en:wikitext converter anyway. It differs from others in that:

1. it's got a web-based interface (http://diberri.dyndns.org/html2wiki.html)
2. it's in en:object-oriented en:Perl, as HTML::WikiConverter
3. it shouldn't break on considerably broken HTML code (though I don't know the exact threshold for other converters)
4. it has some nice image-handling en:DWIMmery (read more at the URL above)

When I get a chance, I'll upload the Perl module to en:CPAN, but for now I figured I'd share the tool with the WP community. Please comment on my talk page. --Diberri | Talk

Combining one of these converters with Epoz could be a good start for WYSIWYG editing (See WYSIWYG editor). -- Gabriel Wicke 01:01, 8 May 2004 (UTC)

FWIW, I've uploaded the module to en:CPAN. It's available at my CPAN author page. --Diberri | Talk 00:38, May 11, 2004 (UTC)

My WYSIWYG editor proposal

Here's my idea for how a WYSIWYG editor could work...

1. The article is sent to the browser as standard XHTML, but with extra meta information. All information contained in the wiki source is translated to custom XML attributes, for instance [[Wikipedia|link text]] would be outputted something like <a href="http://en.wikipedia.org/wiki/Wikipedia" wiki:linktype="internal">link text</a>.
2. Use IE/Gecko's built-in editor to edit the document, so you don't have to reinvent the wheel.
3. Send the edited document back to the server, where the extra XML meta data is used to transform the document back into wikitext.

As far as I can see, this would allow for lossless editing. Every single little bit of information would be transformed into XML and back again.

Can anyone see any major issues with this? Thanks, Tom- 22:12, 20 Sep 2004 (UTC)

Sounds smart to me Axel Kittenberger 16:14, 26 March 2006 (UTC)

I did make a look into it, actually coding this... the Problem is that the wikipedia wikitext parser is really a very big chaotic thing. First there are no seperated wikiparse - html generation parts, so you could split up xhtml generation. It does parsing and html generation in one mixed up step. Axel Kittenberger 06:57, 16 April 2006 (UTC)

Why is WYSIWYG taking so long?

This really isn't that complicated. Let's make a WYSIWYG editor a priority please! Before Microsoft figures out that Wiki's are important and build MSWiki 1.0.

I wish there were a quick dirty and simple implementation of this ASAP. bold, ital, simple tables. just the basics. non-wiki types are really really put off by code of any sort.

Too late, MS just built wiki functionality into the forthcoming version of Sharepoint

So is it too late for Wikipedia also? Since MS Encarta is also already shipped ;) Axel Kittenberger 20:49, 26 April 2006 (UTC)

The wiki in Sharepoint is a joke, it misses most of the functionality beyond rich text and links.

Hmm.

I couldn't comment on why it's taking long - it would probably be a very involved thing to program it (or maybe not), though I believe if it were a high priority it would already be coded :)

May I be frank? Programmers often take for granted the level of thier abilities, leaving other people confused. I believe adding WYSIWYG to MediaWiki would increase usability for common people tenfold. Someone at this news group said writers on a team didn't like wiki markup, and someone in response said essentailly "wiki markup really isn't hard to learn." It may not be hard to you, but it is hard to learn for those writers. Techy people have an easier time with code/markup. But no matter how simple it is, a non-technical person will look at it and balk/panic. I sincerely believe that most people would far prefer editing pages just as if they were using Word. To heed that, I believe, would make MediaWiki enormously more popular - and it wouldn't have to be such that you can only edit with the WYSIWYG, but use markup also - as I believe has been proposed.

--Mr alex hall 18:36, 24 Dec 2004 (UTC)

Well said!

--Timothy Takemoto 18:36, 24 Dec 2004 (UTC) I hacked my movable type to use htmltarea, and I am a moron. Surely someone must have dones this already? Ther article is long and theoretical, but it does not say how to. Please can you have a how to give your media wiki a Html area section?

MediaWiki's markup IS NOT HTML. --brion 12:17, 26 Apr 2005 (UTC)

no, but it´s still a ML... --84.169.33.33 10:04, 12 Jun 2005 (UTC)

is something out there already?

I was planning to use a wisiwig editor for wikipedia for a gadget and was just wondering if someone didn't do already this in an external webpage. I mean there are so many external tools(hacks) for flickr and google maps, I wonder why there are so few external for wikipedia. Maybe everyone just thinks that " Why am I going to do this on my site? those nice wiki guys will surely put that on wikipedia officially anytime soon"...

see FCKeditor Mafs 7 July 2005 20:17 (UTC)

OpenOffice 2.0 (Open Document) to MediaWiki format

Is there a macro or export filter that will allow one to create documents in OpenOffice, and export them in MediaWiki format? -- 68.10.113.7 21:08, 29 August 2005 (UTC)

Yea this is what Im hoping for. I want an easy way to make some coloured tables, and Im sure a wysiwyg editor is the easiest... --70.77.45.209 04:18, 13 May 2007 (UTC)

I hope there will never be a WYSIWYG editor

I hope there will never be a WYSIWYG editor in the strict sense. If there really were such an editor we would see all the problems all too common with Word documents surfacing on Wikipedia.

• People will use blank lines to insert space between paragraphs.
• Spaces will be used to align text.
• "Headings" will be made by selecting a larger font size and inserting blank lines.
• Inconsistent font sizes will be used.

With a "What you see is what you get" editor people will focuses, as they do with Word, on what they see, and if it looks right to them they will submit. They will also start worrying about the layout of the page. If the font is too small on their Computer, instead of adjusting their browsers setting, they will increase the font size of an article. There will be edit wars over Arial, Verdana and Times New Roman.

A "What you see is what you mean" editor similar to Lyx might be usefull.

I don't see why there needs to be support for font sizes or font styles. I've never seen a page that changes font size or style. And aren't multiple blank lines automatically conflated down to a single blank line? Same for spaces?

No wysiwyg or wysiwym is the single impediment in my office

I've implented MediaWiki for our office intranet. The single impediment to its wide spread use in our office is the need to learn wiki markup. I've searched in vain looking for alternatives but no one so far has nailed it Wiki WYSIWYG. I've stuck with MediaWiki for now because of its large userbase and resigned myself to the fact that I have to do most of the editing of our intranet until WYSIWYG is supported natively or via an extension. I really hate to think of the amount of people who are excluded from participating in wikis around the world because of this impediment. -Christiaan 13:53, 7 April 2006 (UTC)

As far I support WYSIWYM extension for wikimedia, I must tell that I was able to teach wiki markup to blondes ;). But it seems you can't teach ease of use to some people.

Wiki markup has some "sticker shock" effect on lots of people, particularly when they contemplate creating complex wiki pages from scratch, and they have never edited on a wiki before. However, almost anyone can click the edit links on an existing marked-up wiki page, distinguish the markup code from the visible text, and make small edits to the visible text, on the very first attempt. Learning enough basic markup to get by isn't that hard, and could be eased considerably by printing out cheat sheets and hanging them up around the office. Also, check out the MediaWiki training videos. I expect that with the proliferation of public wikis, it's only a matter of time before just about everybody needs to edit on one. Back in the early days of the Web, HTML was also held to be a massive deterrent to broad participation, but zillions of non-technical people easily learned enough HTML to make simple Web pages once they understood the benefits enough to become motivated to learn a little. Wikis do make it practical, at least in theory, to hire editing help from anywhere in the world, perhaps from English-speaking countries with technically trained workforces and low labor costs (hello, India). Then people who refuse to learn wiki markup can easily paste in ugly messes of plain text inside <pre> tags, and the help from Bangalore could mark it up nicely at $5/hour or whatever they charge. Also, there are rumored to be automatic ways to convert Word documents to MediaWiki pages. Even if MediaWiki had some Word-like method of editing, building a high-quality wiki is still going to be a lot of work. Documenting is inherently a hard problem, which is why most of the world is vastly under-documented. --Teratornis 02:16, 6 March 2007 (UTC)

Jimbo Wales recently went to India to spread the wiki gospel:

• http://wikicamp.in/wiki/index.php?title=Main_Page
• http://wikicamp.in/wiki/index.php?title=The_Hindu_Feb_25_2007

Since wikis may be one of the most effective technologies for remote collaboration yet invented, and since good wikis require so much labor to build, perhaps the large-scale success of corporate wikis depends on outsourcing a big chunk of the wiki grunt work to countries like India. Imagine, you set up a file server, dump all your company's disorganized documents and e-mail and everything else up there, then let your army of industrious and affordable Indians refactor it all into a beautifully organized wiki for you. Granted, there would be a rather large issue of trust to resolve up front, but local labor is even more of a security risk, since they have physical access to the company stuff, and the ability to exploit inside knowledge in the local market more readily than someone who is half a world away. The local first-world help costs three to five times as much, and with a wiki, the labor doesn't really need to be physically present to get the job done. --Teratornis 07:49, 6 March 2007 (UTC)

Move page to WYSIWYM Editor, and put in a redirect

Often Critics comes from the misunderstanding of WYSIWYG and WYSIWYM (see top discussion), has anybody something against to move this page to WYSIWYM Editor, and put in a redirect? At some point at last we need to become correct. --Axel Kittenberger 20:53, 26 April 2006 (UTC)

The most common name for this technology is WYSIWYG. The WYM thing is precise but rare. Rather than force-feeding a new acronym to people, let's concentrate on how to make this technology work. --Evan 14:21, 15 July 2006 (UTC)

As I said the renaming is due to the fact, some people hate WYSIWYG because they take that get to narrow. So I do think that calling it proper, does help in creation of something like that. Since the graphical editor view does not have to be exactly like that the webpage will look like. A strong requirement for true WYSIWYG that we don't really want. --Axel Kittenberger 10:23, 22 July 2006 (UTC)

Take also a look here in the distinction why wikipedia especially does proparly need WYSIWYM and never really wants WYSIWYG: Lyx quote: LyX is a document processor following the self-coined "what you see is what you mean" paradigm (WYSIWYM), as opposed to the WYSIWYG ideas used by word processors. This means that the user only has to care about the structure and content of the text, while the formatting is done by LaTeX, an advanced typesetting system. LyX is designed for authors who want professional output with a minimum of effort and without becoming specialists in typesetting. --Axel Kittenberger 08:19, 23 July 2006 (UTC)

recently added to the article:

---

1. An editor should support the user in getting a headline right instead of using a big font, marking a citation instead of italicizing text, and so on. Imho most wysiwyg-editors lures people away from thinking about the meaning, and this is wrong. -- ∂ 01:47, 6 August 2006 (UTC)

---

Thats just another example why we certantly DONT want WYSIWYG but DO want WYSIWYM! And another example why there is objections because people misunderstand the Get in WYSIWYG. (which means a graphic editor where e.g. italics and citations are graphed differently altough they might look the same in the resulting article, we don't see what we get! An objection that would not even be necesarry if we would just label the project correctly. --Axel Kittenberger 12:24, 8 August 2006 (UTC)

i think the real problem is, most new users do in fact want WYSIWYG: most of them want to make their writings look pretty. not as many, but still a lot are willing to conform to "the rules" as far as is concerns the looks. but only few really want to think about what they mean, because thinking is wearisome.

if you are a newbie, and i guess newbies form the majority of the target group for a visual editor, you have enough other things to think about when editing a wiki, so the reaction to avoid thinking is perfectly natural. there's only one way to get around this: think for them as much as possible, and put it in software. you'll still have to deal with the kind of people talking like "if you want italics, just use the 'cite'-button".. -- ∂ 14:53, 8 August 2006 (UTC)

If for example a citation would look in the editor as text with a green squared background, with the small letters "Citation" on the upper left side, its obvios for every user that this is not the same as "italic", although in the standard article presentation it may look italic. Thats why such a graphic editor would not be WYSIWYG but WYSIWYM an thats what IMHO we want. --Axel Kittenberger 11:43, 10 August 2006 (UTC)

I agree with -Christiaan =

I am just waiting for somebody to implement a stable enouph free wiki with wysiwyg, the wysiwyg editor is the killer application that people want, the 1st wiki to implement it stable and free wins.

People just want to write stuff and share/embelish the same information, they dont want to be tortured with new syntax or markup languages. People have already learnt word, they are familiar with the interface, now they want to make sure that 5 people in the same organisation do not write the same piece of documentation, so what we want is word + wiki.

How difficult can it be to jack this FCKeditor into mediawiki, make it work and lets get on!. I am being held back from media wiki because of this and am reluctantly using alternatives.

The most practical wiki I have seen that matches the needs of the people who could not care less about the syntaz is MoinMoinWiki, but it is still buggy. it integrates the FCKeditor and passes the my criteria of being able to link within the wiki and externally, WITH NO FUSS!. I am sticking with it until wikimedia gets there act together on this. Asking people to learn the table syntax, is not practicle, when there are simple, intuitive interfaces to build tables.

Possible desicion

Talking about how the method should work we should remember that not every one prefer visual editing to wikitext. So we should give users an option to select the most confortable way of editing (dinamicaly at run-time if possible). I'm already working over it. At that very moment I've integrated InstaView with FCKeditor. And for the back html2wiki transformation I use my own development (though I used another open source project as origin). This approach is working in spite of FCKeditor doesn't preserve line-breaks and both wiki2html and html2wiki are rather limited now (in development). So if the idea seems interesting please contact me via mail, leave a message on my user page or just continue this thread. --Shtriter 08:31, 17 July 2006 (UTC)

Table

Perhaps this will be useful: I am pretty sure WYSIWYG should include the functionality discussed at w:Wikipedia:Table: namespace and editor.--Piotrus 20:49, 5 August 2006 (UTC)

Im pretty sure if at first step having an editor that will only handle bold text (self reference), sections and links might be a real big step forward already, leave tables, templates, graphics and all that fancy stuff for WYSWYM version 2.0. Keep the milestone goals realistic ;o) --Axel Kittenberger 11:46, 10 August 2006 (UTC)

FCKeditor fails

Like many of you, I've run into the same no-code culture problem regarding wiki. So, I did push ahead with FCKeditor as a solution; we did get it working after a time and the solution is sound, but it just doesn't cut it for wikitext handling. The problem isn't creating a visual editor; that's simple (well, no, but at the very least it's already been done). The problem is creating a visual editor that plays by the wikitext rules instead of using html. I can't sacrifice one group's ability to use extensions for another group's need to have visual editing, nor can I ask the former group to lose all their work everytime they try to edit (FCKeditor destroys pretty much any existing wikitext tags in parsing... even if you work in source view, you'll have problems next time you edit). What's needed is for someone to take FCKeditor and rip the html out of it. Take their concept and completely rebuild it using wikitext as the target language. The problem is the FCKeditor devs are completely unwilling to do that themselves like the should have. Honestly I think they should be blacklisted by wikimedia. Their extension should be removed from meta and use of FCK discouraged by wikimedia until such time as they make their code work with within the system, instead of forcing people to choose between FCKeditor and practically every other extension that adds functionality to wikitext. -Verlocs 12.104.195.32

Yeah, that's cruel... ;) In general I think there's no need to blacklist FCK devs... Moreover there's no need to rip FCK at all (well, maybe some corrections can be done but by FCKeditor developers only). My solution to the problem can be found here. wclEditor is a combination of some useful js that allows choosing between the original editing style and FCK. The article's text would be saved as wikitext anyway. This approach is similar to FCK VS HTML Converter, but all of the transformations are made on the client-side by js. IMHO, that approach can solve most of the described problems.

PS: The project is in beta stage and there are many things to be done, but on that very moment we can already see the concept and check the correctness of wiki2html and html2wiki transformations (There are no diffs between the result of html2wiki(wiki2html(txt)) transformation and original wikitext for the most elements of the wikitext). --Shtriter 13:18, 19 August 2006 (UTC)

Javascript editor

Most if not all presented WYSIWYG (or WYSIWYM :) editors are based on browsers "htmlarea". Which is IMHO most times I've seen rather bad implemented. I learned for one to hate the WYSIWYG editors even on clean html editors without the wikitext problematic at all. For example if a line starts with an URL, you can no longer write normal text before the Url.. everything will be part of the URL. Also bullets work strange and so on.

So I'm just wondering, wouldn't it be possible to totally ignore <htmlarea>, and write an editor with javascript-power only? A Javascript that will write html code to a page as keys are pressed on keyboard, and also stores parallel to it how the wikitext looks like. The cursor would be for example be needed to be simulated by a black DIV or so. This way the usual wikitext->html->wikitext conversion problematic with possible contamination of the wikitext just by the conversion circle is circumvented. --Axel Kittenberger 19:24, 19 August 2006 (UTC)

Well, from my point of view everything is possible. But every brilliant idea needs the brilliant developer to implement it... It seems to me that it would be much easier to adopt existing editors to our needs that to develop new one. I believe that error reporting exists just for such cases - why not to tell about the problems to editor's developers? Besides even if we'll manage to develop such an editor we wouldn't avoid some sort (html2wiki or wiki2html) of text transformation. So what are the advantages? --Shtriter 14:46, 20 August 2006 (UTC)

With a well customized editor, we would only need a wiki2html transformation ..not a for and back transformation which is unacceptable IMHO. Until the implausible case of perfect transformations in both sites it would alter the original site just by opening and saving. Just look at the wiki2html parser of mediawiki's current implementation how complicated it is. Just the Bold and Italic handling is a science itself. Take for example stuff like this double enclosed. Mediawiki’s implementation does this correctly as you see (produced even valid html, by inviblly closing the bold tag before opening the cursive tag. But which editor would do it? --Axel Kittenberger 21:25, 21 August 2006 (UTC)

I can't understand why html2wiki transformations are unacceptable. In my project I use both transformations (see the previous thread). As I've already said, those transformations don't affect the original wikitext. Though I test the correctness without the editors for the purity of tests, I can say that I don't get diffs for paragraphs, simple lists, tables, links, nowiki's and preformatted text.

Talking about the MW's parser all I can say that it's not perfect. I've printed it's source and study it regularly, cause I'm developing InstaView. I know, InstaView isn't perfect too (that's why I'm working over it...) but it's source at list 6 times smaller than MW's parser (10 pages against 60+...). And btw, bold/italics handling in InstaView is implemented simpler and rather more beautiful. So there's no need for complicated code in simple cases...

The only idea that I do support is the correctness of visual editor's output. Imho, that's the consequences of the WYSIWYG approach itself. So all I can propose is my project mentioned above. It will give us opportunity to select not only between the original wikitext/visual editing, but in potential we could even select the desired editor... Btw, FCKeditor claims to output valid XHTML in future...

--Shtriter 07:38, 22 August 2006 (UTC)

Does this work correctly for example? Note that:

<b>this <i> work </b> corectly</i> 

is not valid html (or at least XHTML for sure). It has to be e.g.:

<b>this <i> work </i></b><i> corectly</i> 

--Axel Kittenberger 14:37, 24 August 2006 (UTC)

You are right. InstaView's output has to be corrected. Are there any other similar examples? Btw, why not to use RegExp for it? It can be smth. like:

output.replace(/<i>((?!<b>)+?)<\/b>(.+?)<\/i>/gim , '<i>$1</i></b><i>$2</i>' );

I guess that this variant is better then following the way of the MediaWiki's parser. I've heard that many developers said that that parser is monstrous and it has to be rewritten. Moreover, even devs don't know everything about wikitext (For example there is no single point of view how nested dl's must be treated - see bug #6569). So I think that we should create smth. like wikitext standard first.

--Shtriter 17:21, 24 August 2006 (UTC)

I think regexp replacing is an unideal approach all the way. Mediawiki parser works also that way. A far better parser is an: wikitext -> object stream -> html. Where objects are programming language objects for each accepted tag, like text, headline, bold on, link start, bold off, and so on. Then next step to html generation is also far more addaptable, you can create generators for xhtml, or even latex, without to worry about the parser, or parsing differently. Here in my work with "experimental wiki designs" we implemented such a parser in the ruby language, because regexps replaces more and more hit their limits in technology (things you can parse correcly). The new parser is even faster. --Axel Kittenberger 11:28, 25 August 2006 (UTC)

Yes, speed may be important. But in general I see no difference with built-in MW features (for example live preview...) How would this help to develop visual editor to mw? I can't see the results of other developments and so it seems to me that we only talking about visual editors, not implement... As I've already said there is even no wikitext standatd!!!

A well done parser would make it easier to standarize wiki IMHO. also a parser done this way would make it easier to parse WYSIWYG *exactly* the way MW (improved) built-parser would do. (as side effect it would greatly ease to create various export features To MW) But it would require to change that MW-parser, which is a heart-piece of MW, so not likely to be able to be done by outsiders. The state of the MW parser code is bad if you ask me, and I think it would really help if it might be edited by someone who got or aquries himself experience in parser construction technology (borrowed from compiler-construction). There has been so much to be learned from 30 years of informatics-experience, yet most start to "design" one all with their general coding-howto :) --22:14, 25 August 2006 (UTC)

This seems interesting to me. Does Brion know about your parser? If so what does he think about it? Cause if he doesn't plan to make your parser built-in MW feature I doubt that some else will do it in future. Btw, what's the need to produce correct XHTML for the visual editors? At list some of them can make the cleanup by themselfs. In any way we should make the back html2wiki transformation after the edits so why can't we handle non-correct XHTML? --Shtriter 05:49, 26 August 2006 (UTC)

Let me explain this in 3 words: Who is brion? :-I Well i can send what we have, its a GPL License. A co-worker wrote it (upon same suggestions, parser discussion), but the source code is commented badly (speaking absolutly not) Additionally its ruby, I guess MW-code-gurus don't like that language. I tried once to understand this special parser, but didn't do in one hour work. That time had not the time to think into this more. Before that parser, unsatisfied with the traditional wikitext-regexps I tried to write a wikitext parser in complete java-compiler-style parser structure. But failed utterly in "error handling", since unlike any programming language in wikitext EVERY combination is a valid syntax. After he analyzed my parser in midwork he wrote an actual functioning one which is in structure a compromise between classic-style parser construction, and the typical wikitext-regular-expressions. --Axel Kittenberger 17:45, 26 August 2006 (UTC)

Afaik, User:Brion is one of the main MW's developers (if not the chief...). Sometimes he can be seen at MW's irc channel. It will be interesting to look at the your parser's code. If you can't provide a link here please mail me. --Shtriter 18:07, 26 August 2006 (UTC)

I'm not an expert into this, but as said all these editors (as far I can tell) use the browsers htmlarea.. which is in core a browser specific editor functionally they hang on, and often the browsers did it bad. I just see this a problem, since we wouldn't have access to alter unwanted behavior, just try to tell internet explorer devs it should handle this or that htmlarea editor stuff better, so it becomes sensefull usable for mediawiki. :o) --Axel Kittenberger 21:30, 21 August 2006 (UTC)

Imho, it's not interesting for IE devs, they wouldn't do it... And it's still interesting for me who will develop js editor. I don't know such guys though the idea is interesting. The basics can be found here. --Shtriter 07:38, 22 August 2006 (UTC)

Javascript editor (continued)

So still there? Does not seem to be much happening on the Wikipedia WYSIWYM(G) front lately :-) I lately tried to code exactly this idea descriped above with the google web toolkit (GWT). You can view a technology preview here: [1] and I uploaded the sourcecode at [2]. --Axel Kittenberger 08:29, 2 July 2007 (UTC)

More modest needs...

I think that thinking about how to handle WYSIWY? editing within MediaWiki is an obvious thing to consider, but I think that the winning product will be something a bit more modest. For one, I do not believe that such a thing could be easily implemented on the edit page without being incredibly cumbersome - which is the real reason it hasn't been done already. Sure, you could do it with js, and have what amounts to an entire little word processor running inside of a web browser. The thought makes me shudder, but I'm sureit will be done eventually.

But an offline tool would be a lot more useful. Using WikiText is easy when you are basically editing someone else's work. They already have most of the tags in there - just by paying attention to what is already there and not being a complete moron while mucking about, you can add content without really knowing anything. Just follow the original author's lead, and don't try to do something you don't know how to do. And the longer you do muck about, the more you learn (and after awhile you find yourself up at 4AM making tables while your wife is yelling at you to come to bed, even though technically you don't know squat about a big scary Markup Language).

Where WikiText really falls down is when you are either writing something really long, or transcribing something from another source that is equally long.

Example: I am implementing MediaWiki in a way that I think is quite brilliant (I thought of it, in case you were wondering). To give you the short version, we are working on a large school curriclum project for a software program we distribute free to schools. We've written about four big classroom units, and we have about 100 trainers (secondary school teachers) who are also, in exchange for being granted trainer status, going to help us write material. So the great idea is, put the curriculum on a MediaWiki server, get the 100 trainers to contribute there, and then open it up to the 14,000 teachers we have using the materials, and let them edit away. We'll have a massive library of free classroom curriculum in no time.

So we have these units, which are 40-odd page Word documents, generally consisting of two-column tables, with instructions on the left side, and screenshots on the other. The guy who wrote all of it works for me, and I am facing being the manager who tells him to convert the entire thing to Wikitext.

I appreciate that you hardcore wiki types love Wikitext, and I understand why - it is really wonderful, like Everyman HTML. But imagine the job he has of creating all those tables and uploading all those images, linking them into the table, and generally typing the pipe character 150,000 times, all the while needing to keep previewing to make sure it's formatted right. I am not looking forward to telling him that this grunt work project is his. I can help him with some good templates (like the meta help page templates), but it is still tedious as hell.

If I had a standalone WYSIWY? editor, he could set up tables, then cut and paste (or even import) from Word. It could generate the output and he could paste the result into the edit window. And by running offline, we could avoid the quirkiness and browser differences that make javascripts apps such a pain in the ass. Why would it be a big deal to copy and paste the WikiText in and out? Anyone editing a long article could do the same - the time lost by selecting all, copying, pasting, and doing the reverse at the end (30 seconds) would be more than made up by having a snappy local app.

Now there ought to be ways to do this already. But there really aren't. He ain't going to use emacs - need to keep it in this century - and there is the problem of the tables. I figured there would be a utility to parse through HTML and clean it into Wikitext. Not really. Besides, I tried exporting the Word document as HTML, and it came out looking like the orignial LISP source code to Eliza translated into German and then romanized Chinese through an early version of Babelfish. It is utterly uneditable by any high school teacher, that is for sure.

Tomorrow when I get to the office (and to the only Windows machine in my life) I will try the Word2WikitextPlus VBA script. Maybe that works better than the Talk page comments indicate - but with the number of images involved, it seems hard to believe that will help much.

An application that offers basic WYSIWY? editing of text, tables, and images, and outputs nice clean Wikitext that follows the rules and will be comprehensible to normal people doing edits after me - whether they copy it out into the same editor, or just do it in the browser window - that is much less ambitious that trying to build it into the Edit page, and arguably more functional at this stage in the history of the web. There's your killer app, looking very simple compared to the discussion here.

In the meantime, I am interested if you have any suggestions for my specific problem, if only out of sympathy for the poor sods who have to build the starting content of my project. Peace. Kgdickey 22:39, 28 August 2006 (UTC)

There are 2 things that speak against an application-mode editor.

* First its plattform dependance, you seem to be concentrating on microsoft windows only, but many users prefer other operating systems we do not want to lock out. (A free encyclopedia should certantly be freed from platform dependence (on user side, especially if that platform is not free))

* 2nd and more important the WYSIWYM editor targets the amateur and new user group. The "professionals" are fine with wikitext. Requiring to download/install anything is very much contra productive, as it dramatically would raise the "entrance-barrier". To some degree this also applies to a large java applet, when it takes long time to run the editor, and also (unfortunally to many different reasons) a quite noticable group hasn't java installed (properly). --Axel Kittenberger 15:20, 2 September 2006 (UTC)

How's the document-conversion project going? Have you thought about hiring outside contractors to help with the editing? Imagine how many English-speaking people in India could do this kind of "grunt work" at a fraction of first-world tech labor costs. Just ship them all your old junk computers and get them an Internet connection. Or find some company in Bangalore which does this kind of thing. I'm not convinced MediaWiki needs yet another editor, since the world is full of editors, and they inspire endless editor wars. Do we really want to see MediaWiki ripped apart by a vi/emacs-like schism? Maybe what MediaWiki really needs are robust tools for converting to and from every sort of document file format that is at least partly representable in wikitext (see w:WP:TOOLS for a modest start). If people had simple ways to blast all their existing word processing documents, spreadsheets, and everything else into MediaWiki pages, preserving as much of the existing document structure as possible, they could learn enough wiki markup easily enough just by studying the result to continue editing their documents on the wiki. Or, the resident wiki evangelist trying to convert the heathens at Amalgamated Consolidated Incorporated could score credibility points by showing people their familiar, personally relevant documents in wiki format, unleashed from their desktop information islands and ready to be collaboratively edited. --Teratornis 02:59, 6 March 2007 (UTC)

Also, maybe you don't necessarily want to slavishly follow the same document format on the wiki that you used in Word. Tables, in particular, are not necessarily the best platform for collaborative editing. Since you have long documents with repetitive structure, you might want to spend some time experimenting with just one sample page, to find the easiest wiki layout that works. For example, not that it applies to what you're doing, I and a co-worker converted a Visio diagram of a company organization chart into a non-graphical MediaWiki page, using sections and links to represent everything that is blocks and lines on the Visio diagram. The result is surprisingly easy to navigate, it is usable, and easy for wiki novices to edit, even though it doesn't have the initial visual impact of the diagram. If you can organize your material mostly with sections, lists, and image thumbnail tags, it will be vastly easier to edit than if you put everything into tables. --Teratornis 02:59, 6 March 2007 (UTC)

Mozile

Discussion of the Mozile MediaWiki editing demo. Also see irc.freenode.net #mozile.

WOW! Thats (mostly) exactly what I ment before (above), I'm impressed! This has the potential to become something really great if you ask me! --Axel Kittenberger 15:12, 2 September 2006 (UTC)

It's just a bit too much WYSIWYG and a bit too less WYSIWYM editor if you ask me, meaning the graphic view should show you all information what you entered, not what it looks like. The main difference is that some things may look the same, but mean different things like citation and italics. Also I think its better if the table of contents e.g. is not be included in the edit mode. A better differentation between meaning and seeing could be done by using "wikitext" html attributes (attributes the browser ignores, but are used by the engine)--Axel Kittenberger 15:12, 2 September 2006 (UTC)

Thanks for the feedback. The MediaWiki parser isn't as "semantic" as it could be but there's lots information there we can use. I'll look into adding a stylesheet that's only active when editing. Hiding the table of contents and distinguishing cite/italics/em are two good improvements. I'm eager to hear more suggestions, and we're looking for more Mozile developers. James A. Overton 16:24, 2 September 2006 (UTC)

Hmm, maybe it might improve handling when the editor does not rely on mediawikis parser output, but parse the wikitext with javascript into a WYSIWYM view? This way the user can switch between wikitext and WYSIWYM view without consoluting the server, it also removes the problems with templates and other "unsuitably" attributes of the native mediawiki parser in this use. But I love the editor done this way, just what i always dreamed of, and so often thought to be impossible. --Axel Kittenberger 17:23, 2 September 2006 (UTC)

This would be nice. InstaView uses JavaScript. We just need to be completely sure that they will output the same HTML as the official parser. Otherwise it's what-you-see-is-what-you-might-get editing. James A. Overton 19:20, 2 September 2006 (UTC)

It should be, as I sermonise on this talk page so much, what-you-see-is-what-you-mean editing. Meaning it doesn't matter *that* much if one or other speciality is still written in wikitext. It doesn't matter if you don't see the TOC in edit view. You do not need to view pictures just the way they are in the article. You should view things differently that mean something different, but view the same in the resulting article. etc. So its not a dramatic if some smaller issues are differnet, it would be a small annoyance whatsoever. WYSIWYG is constructed for paper print systems and does not really fir into webenvironment that much, as what you get is different on every system, and espeically on wikipedia you do not make any layouting.. Therefore the GET in a narrow sense is not needed. e.g. for pictures it is more important for the user to see the approperiate link (and beeing able to easily edit it), than actually seeing the picture. --Axel Kittenberger 19:56, 2 September 2006 (UTC)

One issue that always pestered me a lot in htmlareas, if a line starts with a special enviromentment (bold, italic, link), it should be possible to go with the cursor one left, not moving the cursor but leaving that environment.

be or not to be <- I missed the "to" in the beginning, but don't want it to be italic.

IMHO I think a proper roadmap to go would be with closer milestones. In start concentrate on only a view tags to be handled by the WYSIWYM-editor like bold, italics, section headings. Best is in a first attempt to ignore tables, templates, tocs, pictures and all that, and leave the wikitext for this stuff intact as it is. Then perfect this editor handling some simple tags until it really runs without bugs and other "teething problems". Get a user base and do some beta testing until it comforts most users. Then slowly over time, add tag after tag to be handled, get the user response, perfect out various problems until its feature complete. Starting with a full fledged editor can easily result into a throwing out the baby with the bath water (as all Browserbased graphic editors I yet treid are quite buggy and I often find unsuitable behaviour after only minutes of trying to use it "for real". E.g. I gave up with the WYSIWYG editor from wikispaces.com, as it drove me nuts always doing things differently than I intended. --Axel Kittenberger 17:38, 2 September 2006 (UTC)

I agree that a conservative approach should be taken when it comes to making changes to MediaWiki. My goal with the demo is to show that WYSIWYG editing is can really be done, and explore the possible implementations. Although MediaWiki editing is only one application of Mozile, I'm hoping that the demo will attract some interest to the project. At this point we need more testers and contributors to iron out bugs and add features. James A. Overton 19:20, 2 September 2006 (UTC)

I truely believe it can theoretically be done, altough as explained all the editors I viewed take the feature-greedy but buggy-implementation approach, essentially just make it *look* good, dirty-implementation. Therefore I can really just stress to take it easy on features and make a clean-as-possible implementation. However thats just my opinion, but I guess its the main error alls WYSIWYG editors do. --Axel Kittenberger 19:56, 2 September 2006 (UTC)

@Shtriter, Since I sufferred from a sickness last week (and still do, just feeling somewhat better now) I'm sorry I've not yet managed to extract the new-concept parser from our sourcetree, I will certainly do. (However as has be said, it does not fit directly into the mediawiki environment, but is written for another webenvironment) --Axel Kittenberger 15:12, 2 September 2006 (UTC)

Wishlist

Please add features which you think could improve the demo.

• A full set of wiki editing commands for Mozile.
• Interfaces for inserting templates, images, references, categories, etc.
• Client-side wikitext parsing. This would allow switching between WYSIWYG and wikitext editing. Probably supported by InstaView.
• Parser should use <em> instead of <i> in most cases. Mozile is currently configured to use <i>.
• Changes to the article should be reflected in the table of contents.
• Changes to footnotes should be reflected in references.

Editing Mode Behaviors

The following behaviors should apply while the user is editing an article.

• Citation and emphasis tags should be marked to distinguish them from italics.
• Strong tags should be marked to distinguish them from bold.
• Span, big, small, and font tags should be marked.
• Table of Contents should be hidden.
• Category links should become visible.
• Templates should be marked as protected from editing.

Demo Updates

I've added a stylesheet that's only active while editing: mediawiki.css. As a first pass, I've used the CSS :before and :after pseudo-selectors to add "tags" to marked elements. That part works in Firefox but not in IE. Hiding the table of contents also works in Firefox but not IE. Category links are made visible and templates are marked with a dashed red border. Tell me what you think. James A. Overton 19:29, 2 September 2006 (UTC)

Please take a look at Writely.com

Have you guys seen Writely? Isn't that inspiring as an example of WYSIWYG editor? I would really love to see anything similar for MediaWiki. Some features could actually be ignored, as is the case with cooperative editing and more pure visual editing (like font sizes and faces). Of course, table editing is absolutely necessary. And what about the technology? AJAX is *the* solution.

And please let me oppose to the idea that newbies would be the main target audience of a WYSIWYG (or WYSIWYM) editor. I use MediaWiki as a knowledge and information base to assure that distributed teams of software developers cooperate. We really use MediaWiki features extensively. Despite that, we consider that a WYSIWYG editor would be a very important factor to stimulate the use of the wiki. Agility is the word. With AJAX we could eliminate the unpleasant cycle that includes following an edit link + page reload + losing visual formatting. We could simply edit what is right in front of us when we are reading it. And if people use different colors and fonts in some cases, this will be fixed in the end by the very nature of wikis anyway... The important thing is getting people to write it down.

Despite being rather new, Writely is so nice and appealing that several documents once put in our wiki have been moved to Writely in the past few weeks (in fact, an important feature is that Writely allows uploads and downloads in .doc and .odt formats). And remember... Google is behind Writely now. So I would't be surprised at all should they start their own wiki software (read [3]).

Just my two cents.

Intuative use of WYSIWYM

There still just doesn't seem to be anything that isn't a compromise compared to a fat client type system (i.e. I've used Lotus Notes in the past) The ideal would be being able to copy text, tables, images from any other window and paste them into a Wiki page and hit save. Currently as I understand it, to get a screen shot into a Wiki page you have to: - Capture the screen in the paste buffer - Open a graphics program and paste the buffer into a new image - Save the image file somewhere - Upload the image file to the Wiki server - Start editing the Wiki page and create a link to the image Where as what would be far more sensible (forgetting how it would be achieved for a minute): - Capture the screen in the paste buffer - Open the Wiki page for editing and select paste with the cursor at the appropriate point Is there a way to achieve that with a Wiki? Or is there something about the underlying technology that just needs a different approach.

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.

MediaWiki+FCKeditor

We have just started a project called MediaWiki+FCKeditor: http://mediawiki.fckeditor.net.

I would love to hear comments about it.

FredCK 17:34, 28 July 2007 (UTC)

• It is the best attempt I have seen so far!!! I have started reporting issues on the main page's "Discussion" page. Basically, the main stopper for me is that it does not support so built in MW tags (like "nowiki"), and parser extension tags.--Y.combarnous 22:23, 28 July 2007 (UTC)

peblusto says: yes, it must be 100% compatible with current wiki markup. the current fckeditor also looses the existing wikimarkup toolbar so we can't even toggle back and forth between wikimarkup toolbar and fckeditor toolbar - bad idea. also, the content of typing seems at risk where whatever i typed under fckeditor seemed to disappear when i click on the wikitext button, so i retyped it, then when i saved, it appeared twice - where was it hiding? i almost abandoned my edit because i thought it was lost! there's much work to do. too bad word perfect isn't in the running here since their reveal codes would have been the perfect web editor. macromedia dreamweaver came close, but they're an adobe module now. anyway, i salute anyone addressing the challenge of how to edit comfortably for anyone who shows up to contribute to a wiki. revealing wiki markup is off putting to non-coders. perhaps something that analyzes your typing in real time and converts whatever is convertible whenever we type a word break character (space or punctuation). that way the codes would disappear and be interpreted as soon as they made sense, and one screen could be used for either type of editing or toolbar input. peblusto 19:04, 7 November 2007 (UTC)

I want to implement a ulipad plugin to edit media wiki code

ulipad: http://code.google.com/p/ulipad/

I try all the editor of Wikipedia:Text_editor_support and think none of them is good to use.

I just want to make the editor support feature like wikEd,though wikEd should use firefox... Smilodon 02:33, 7 November 2007 (UTC)

Is anyone still working on this?

I feel that Wikipedia must eventually have a WYSIWIG editor. Is anyone still actively interested in this? I notice the posts on this talk page are quite old. ---- CharlesGillingham 03:28, 2 June 2009 (UTC)

some think that a missing WYSIWYG-Editor is the biggest problems (if you focus the discussion on "how to aquire new authors") so i guess there is still use for one --Suit 19:45, 24 January 2010 (UTC)

A semi-WYSIWYG work-around using Tomboy Notes

Tomboy Notes with the Copy as... plugin works to some extent. You need to download the mediawiki XSLT file that I wrote. It interprets font sizes to be headings, works with the LaTeX plugin for equation support, and has some functionality with Tomboy's links. So if you're looking for something "right now!" this is a work-around:

• Create WYSIWYG in Tomboy Notes
• Click Copy-As... mediawiki - goes into your clipboard
• On the mediawiki page, paste the contents and preview
• If it doesn't look right, make minor changes.

I used this to move my Tomboy notes archive over to mediawiki, but I have since found it useful as WYSIWYG.

Marupio 23:15, 8 April 2010 (UTC)

Color-Coding

May I suggest: color coding. I like the recent additions to the editor to make most operations simpler for the user (such as bold, italics, and references), as well as keep the wiki markup displayed for simplicity and more advanced users, but it creates a very cluttered display. Most text editors use a simple color coding to identify strings, integers, and tokens which makes editing lots of text very easy. Why not do this in the media wiki editor?

Jacob 22:25, 18 April 2011 (UTC)

What about the Wikia editor?

When are you guys going to implement the Wikia editor? It works great...!!!

http://www.wikia.com/
I totally agree, the Wikia editor is fantastic and would be perfect as a plugin for Mediawiki (and later core?). --Nhudell 15:50, 11 July 2011 (UTC)

Labels of pictures disapearing

When I edit a page with this editor, the labels of pictures previous placed on the page disappear. For example, "((File:Image.png|thumb|none|300px|Image label))" will become "(([[-File:Image.png|thumb|none|300px))" or sometime "((-File:Image.png|thumb|none|300px|Image.png))" (obviously, the (( and )) represent square brakets in the original code). Has anybody figured out how to fix this?

Bump

I'm currently at the third company that is failing to adopt wiki technology because the staff responsible for creating the documentation is horribly offended that they might have to learn anything resembling a markup language. I'm looking at yet another round of reconciling multiple incompatible versions of MS Word files. I do hope someone takes up this challenge. Mythobeast 23:40, 17 January 2012 (UTC)

The Wikimedia Foundation is working on it with the Visual Editor. But that will take a while. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 17:12, 17 February 2012 (UTC)

SharePoint chosen again

I gave my company a turn-key intranet/Internet solution in the form of a pile of VMs on 11/1/2012 as part of our vision moving forward to 2013. Adoption of the latest, the greatest, and most importantly the most consistent and easy to manage tools. Well, everything on my plate was accepted with exception to Mediawiki. Thanks to the "sorry, every employee has to learn some coding stuff" prerequisite, it died before I was done with my pitch. Please consider some engine to fund accelerating this development. I would have much rather seen a $50k contribution go to some open source coders than to Microsoft to implement a SharePoint deployment, only because "it's easier" for the staff to use. It's literally jaw dropping to watch from the outside, more or less a circle-jerk of excuses.

Caption table missing |+ when switching to RichTextEditor

Hi,,

I am using : WYSIWYG extension (Version 1.5.6_0 [B551], based on this version, modified further, using CKEditor 4.4.4 (revision 1ba5105)). I got problem : Caption table missing |+ when switching to RichTextEditor, Please I need a help, thanks

Wayan Suparja