[crossposted to foundation-l and wikitech-l]
"There has to be a vision though, of something better. Maybe something that is an actual wiki, quick and easy, rather than the template coding hell Wikipedia's turned into." - something Fred Bauder just said on wikien-l.
Our current markup is one of our biggest barriers to participation.
AIUI, edit rates are about half what they were in 2005, even as our fame has gone from "popular" through "famous" to "part of the structure of the world." I submit that this is not a good or healthy thing in any way and needs fixing.
People who can handle wikitext really just do not understand how offputting the computer guacamole is to people who can cope with text they can see.
We know this is a problem; WYSIWYG that works is something that's been wanted here forever. There are various hideous technical nightmares in its way, that make this a big and hairy problem, of the sort where the hair has hair.
However, I submit that it's important enough we need to attack it with actual resources anyway.
This is just one data point, where a Canadian government office got *EIGHT TIMES* the participation in their intranet wiki by putting in a (heavily locally patched) copy of FCKeditor:
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
"I have to disagree with you given my experience. In one government department where MediaWiki was installed we saw the active user base spike from about 1000 users to about 8000 users within a month of having enabled FCKeditor. FCKeditor definitely has it's warts, but it very closely matches the experience non-technical people have gotten used to while using Word or WordPerfect. Leveraging skills people already have cuts down on training costs and allows them to be productive almost immediately."
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
"Since a plethora of intelligent people with no desire to learn WikiCode can now add content, the quality of posts has been in line with the adoption of wiki use by these people. Thus one would say it has gone up.
"In the beginning there were some hard core users that learned WikiCode, for the most part they have indicated that when the WYSIWYG fails, they are able to switch to WikiCode mode to address the problem. This usually occurs with complex table nesting which is something that few of the users do anyways. Most document layouts are kept simple. Additionally, we have a multilingual english/french wiki. As a result the browser spell-check is insufficient for the most part (not to mention it has issues with WikiCode). To address this a second spellcheck button was added to the interface so that both english and french spellcheck could be available within the same interface (via aspell backend)."
So, the payoffs could be ridiculously huge: eight times the number of smart and knowledgeable people even being able to *fix typos* on material they care about.
Here are some problems. (Off the top of my head; please do add more, all you can think of.)
- The problem:
* Fidelity with the existing body of wikitext. No conversion flag day. The current body exploits every possible edge case in the regular expression guacamole we call a "parser". Tim said a few years ago that any solution has to account for the existing body of text.
* Two-way fidelity. Those who know wikitext will demand to keep it and will bitterly resist any attempt to take it away from them.
* FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.
* There is no specification for wikitext. Well, there almost is - compiled as C, it runs a bit slower than the existing PHP compiler. But it's a start! http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html
- Attempting to solve it:
* The best brains around Wikipedia, MediaWiki and WMF have dashed their foreheads against this problem for at least the past five years and have got *nowhere*. Tim has a whole section in the SVN repository for "new parser attempts". Sheer brilliance isn't going to solve this one.
* Tim doesn't scale. Most of our other technical people don't scale. *We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for comparison, I work as a sysadmin at a tiny, tiny publishing company with more money and staff just in our department than that to do *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY efficient organisation.)
- Other attempts:
* Starting from a clear field makes it ridiculously easy. The government example quoted above is one. Wikia wrote a good WYSIWYG that works really nicely on new wikis (I'm speaking here as an experienced wikitext user who happily fixes random typos on Wikia). Of course, I noted that we can't start from a clear field - we have an existing body of wikitext.
So, specification of the problem:
* We need good WYSIWYG. The government example suggests that a simple word-processor-like interface would be enough to give tremendous results. * It needs two-way fidelity with almost all existing wikitext. * We can't throw away existing wikitext, much as we'd love to. * It's going to cost money in programming the WYSIWYG. * It's going to cost money in rationalising existing wikitext so that the most unfeasible formations can be shunted off to legacy for chewing on. * It's going to cost money in usability testing and so on. * It's going to cost money for all sorts of things I haven't even thought of yet.
This is a problem that would pay off hugely to solve, and that will take actual money thrown at it.
How would you attack this problem, given actual resources for grunt work?
- d.
On Tue, Dec 28, 2010 at 6:50 AM, David Gerard dgerard@gmail.com wrote:
So, the payoffs could be ridiculously huge: eight times the number of smart and knowledgeable people even being able to *fix typos* on material they care about.
Jan Paul Posma's inline editor seems pretty promising. It's not exactly WYSIWYG, but people would be able to fix typos with it. And since he's working on it for school, I suspect he might not even be getting paid. :-)
http://www.gossamer-threads.com/lists/wiki/wikitech/205322 http://www.gossamer-threads.com/lists/wiki/wikitech/208128 http://www.gossamer-threads.com/lists/wiki/wikitech/213447 http://www.gossamer-threads.com/lists/wiki/wikitech/216940
On Tue, Dec 28, 2010 at 8:16 AM, Benjamin Lees emufarmers@gmail.com wrote:
On Tue, Dec 28, 2010 at 6:50 AM, David Gerard dgerard@gmail.com wrote:
So, the payoffs could be ridiculously huge: eight times the number of smart and knowledgeable people even being able to *fix typos* on material they care about.
Jan Paul Posma's inline editor seems pretty promising.
That looks like a neat project, certainly good for some use cases. Kudos to JPP.
We could use a variety of editor options, with a simple way to switch between them while editing.
For instance, simple small icons to indicate different types of editing could let you choose an inline-section-editor when fixing a typo, without losing the option to open a full editing screen. Useful to power-users and new users alike.
Hi David,
from what I understand, there's a fundamental problem: There is no formal description of WikiSyntax. Its specification is: "what the MediaWiki parser does". It seems that it's not very hard to write a WYSIWYG that covers 99% of all WikiSyntax, the problem is the remaining 1%.
That being said, I think WMF should try to tackle this difficult problems. It's a huge job, but worth the effort.
-- Tobias
I have thought about WYSIWYG editor for Wikipedia and found it technically impossible. The main and key problem of WYSIWIG are templates. You have to understand that templates are not single element of Wikipedia syntax, they are integral part of page markup. You do not insert "infobox template", you insert infobox *itself*, and from what I heard the templates were the main concern of many editors who were scared of wikitext.
Now think of how many templates are there in Wikipedia, how frequently they are changed and how much time it would take to implement their editing.
--vvv
I have thought about WYSIWYG editor for Wikipedia and found it technically impossible. The main and key problem of WYSIWIG are templates. You have to understand that templates are not single element of Wikipedia syntax, they are integral part of page markup. You do not insert "infobox template", you insert infobox *itself*, and from what I heard the templates were the main concern of many editors who were scared of wikitext.
Now think of how many templates are there in Wikipedia, how frequently they are changed and how much time it would take to implement their editing.
--vvv
Exactly, that's why someone should start over and create a fork which is a wiki, quick and easy editing. I've, involuntarily, learned a lot about coding though fooling with templates, but that is not what I came for.
Fred Bauder
More thoughts.
I always viewed wikitext vs. WYSIWYG dilemma as similar to LaTeX vs. Microsoft Word one.
On 28 December 2010 16:06, Victor Vasiliev vasilvv@gmail.com wrote:
I have thought about WYSIWYG editor for Wikipedia and found it technically impossible. The main and key problem of WYSIWIG are templates. You have to understand that templates are not single element of Wikipedia syntax, they are integral part of page markup. You do not insert "infobox template", you insert infobox *itself*, and from what I heard the templates were the main concern of many editors who were scared of wikitext. Now think of how many templates are there in Wikipedia, how frequently they are changed and how much time it would take to implement their editing.
Yes. So how do we sensibly - usably - deal with templates in a word-processor-like layout? Is there a way that passes usability muster for non-geeks? How do others do it? Do their methods actually work?
e.g. Wikia has WYSIWYG editing and templates. They have a sort of solution to template editing in WYSIWYG. It's not great, but people sort of cope. How did they get there? What can be done to make it better, *conceptually*?
What I'm saying there is that we don't start from the assumption that we know nothing and have to start from scratch, forming our answers only from pure application of personal brilliance; we should start from the assumption that we know actually quite a bit, if we only know who to ask and where. Does it require throwing out all previous work? etc., etc. And this is the sort of question that requires actual expense on resources to answer.
Given that considerable work has gone on already, what would we do with resources to apply to the problem?
- d.
On Tue, Dec 28, 2010 at 11:43 AM, David Gerard dgerard@gmail.com wrote:
On 28 December 2010 16:06, Victor Vasiliev vasilvv@gmail.com wrote:
I have thought about WYSIWYG editor for Wikipedia and found it technically impossible. The main and key problem of WYSIWIG are templates. You have to understand that templates are not single element of Wikipedia syntax, they are integral part of page markup. You do not insert "infobox template", you insert infobox *itself*, and from what I heard the templates were the main concern of many editors who were scared of wikitext. Now think of how many templates are there in Wikipedia, how frequently they are changed and how much time it would take to implement their editing.
Yes. So how do we sensibly - usably - deal with templates in a word-processor-like layout? Is there a way that passes usability muster for non-geeks? How do others do it? Do their methods actually work?
e.g. Wikia has WYSIWYG editing and templates. They have a sort of solution to template editing in WYSIWYG. It's not great, but people sort of cope. How did they get there? What can be done to make it better, *conceptually*?
What I'm saying there is that we don't start from the assumption that we know nothing and have to start from scratch, forming our answers only from pure application of personal brilliance; we should start from the assumption that we know actually quite a bit, if we only know who to ask and where. Does it require throwing out all previous work? etc., etc. And this is the sort of question that requires actual expense on resources to answer.
Given that considerable work has gone on already, what would we do with resources to apply to the problem?
I think the second part of what I just posted answers this. Split parser to disallow markup constructs that would break editing interfaces and confuse new editors (the complicated stuff happens out of sight out of mind in templates and article layouts). With a little work, the way templates are designed could be changed to insure they provide a usable prototype to be able to be edited like forms. Make the editor WYSIWYM rather than WYSIWYG, it's close enough to WYSIWYG to provide a good editing experience, but dispenses with 1:1 fidelity in favor of clarity within the editing environment when necessary - we allow for some elements to be rendered in an "editing friendly" manner that can be drastically different from the way the article renders when only viewing it, for example, by having a template show up as a block or inline element symbol (according to it's prototype), which can be clicked on and edited as a form. Some formatting can also be ignored in WYSIWYM mode, so long as there is some representation that shows the user what to expect (think "show formatting codes" mode in some WYSIWYG word processors, except, in this case rather than show all formatting codes, we show the ones that aren't being rendered at the moment. Other than the initial surprise factor for those that haven't used that sort of interface, there's not much in the way of a learning curve - one or two edits at most before someone picks up on what's happening and can roll with it, and it beats a WYSIWYG interface for a lot of complicated tasks because it emphasizes "say what you mean" rather than worrying about how exactly to format it.
On Tue, Dec 28, 2010 at 8:43 AM, David Gerard dgerard@gmail.com wrote:
e.g. Wikia has WYSIWYG editing and templates. They have a sort of solution to template editing in WYSIWYG. It's not great, but people sort of cope. How did they get there? What can be done to make it better, *conceptually*?
What I'm saying there is that we don't start from the assumption that we know nothing and have to start from scratch, forming our answers only from pure application of personal brilliance; we should start from the assumption that we know actually quite a bit, if we only know who to ask and where. Does it require throwing out all previous work? etc., etc. And this is the sort of question that requires actual expense on resources to answer.
Given that considerable work has gone on already, what would we do with resources to apply to the problem?
My primary interest at the moment in this area is to reframe the question a bit; rather than "how do we make good WYSIWYG that works on the way Wikipedia pages' markup and templates are structured now" -- which we know has been extremely hard to get going -- to instead consider "how do we make good WYSIWYG that does the sorts of things we currently use markup and templates for, plus the things we wish we could do that we can't?"
We have indeed learned a *huge* amount from the last decade of Wikipedia and friends, among them:
* authors and readers crave advanced systems for data & format-sharing (eg putting structured info into infoboxes) and interactive features (even just sticking a marker on a map!) * most authors prefer simplicity of editing (keep the complicated stuff out of the way until you need it) * some authors will happily dive into hardcore coding to create the tools they need (templates, user/site JS, gadgets) * many other authors will very happily use those tools once they're created * the less the guts of those tools are exposed, the easier it is for other people to reuse them
The incredible creativity of Wikimedians in extending the frontend capabilities of MediaWiki through custom JavaScript, and the markup system through templates, has been blowing my mind for years. I want to find a way to point that creativity straight forward, as it were, and use it to kick some ass. :)
Within the Wikimedia ecosystem, we can roughly divide the world into "Wikipedia" and "all the other projects". MediaWiki was created for Wikipedia, based on previous software that had been adapted to the needs of Wikipedia; and while the editing and template systems are sometimes awkward, they work.
Our other projects like Commons, Wiktionary, Wikibooks, Wikiversity, and Wikinews have *never* been as well served. The freeform markup model -- which works very well for body text on Wikipedia even if it's icky for creating tables, diagrams and information sets -- has been a poorer fit, and little effort has been spent on actually creating ways to support them well.
Commons needs better tools for annotating and grouping media resources.
Wiktionary needs structured data with editing and search tools geared towards it.
Wikibooks needs a structure model that's based on groups of pages and media resources, instead of just standalone freetext articles which may happen to link to each other.
Wikiversity needs all those, and more interactive features and the ability for users to group themselves socially and work together.
Getting anything done that would work on the huge, well-developed, wildly-popular Wikipedia has always been a non-starter because it has to deal with 10 years of backwards-compatibility from the get-go. I think it's going to be a *lot* easier to get things going on those smaller projects which are now so poorly served that most people don't even know they exist. :)
This isn't a problem specific to Wikimedia; established organizations of all sorts have a very difficult time getting new ideas over that hump from "not good enough for our core needs" to "*bam* slap it everywhere". By concentrating on the areas that aren't served at all well by the current system, we can make much greater headway in the early stages of development; Clayton Christensen's "The Innovator's Dilemma" calls this "competing against non-consumption".
For the Wikipedia case, we need to incubate the next generation of templating up to the point that they can actually undercut and replace today's wikitext templates, or I worry we're just going to be sitting around going "gosh I wish we could replace these templates and have markup that works cleanly in wysiwyg" forever.
My current thoughts are to concentrate on a few areas: 1) create a widget/gadget/template/extension/plugin model built around embedding blocks of information within a larger context... 2) ...where the data and rendering can be reasonably separate... (eg, not having to pull tricks where you manually mix different levels of table templates to make the infobox work right) 3) ...and the rendering can be as simple, or as fancy as complex, as your imagination and HTML5 allow.
-- brion vibber (brion @ pobox.com)
How about attacking the problem by using something that already exists...
- The Wikimedia Foundation gets a lot of support from Google, financially. How about we ask for some technology support as well? Google has a completely plugin-independant JS-based editor in Google Docs, as well as plenty of coders. - The simplest solution seems to be to translate WYS output into wikicode, so using the Google Docs editor, we simply have to translate the bold-looking text into wikicode.
Timeline of editing: [WYSIWYG editor view:] *Albert Einstein *was a popular
[Save page]
[One moment please] <HIDDEN> (translation)
(wikicode output): *'''Albert Einstein''' *was a popular </HIDDEN>
[Article re-appears] *Albert Einstein *was a popular
What do you think?
On Tue, Dec 28, 2010 at 10:27 AM, Brion Vibber brion@pobox.com wrote:
On Tue, Dec 28, 2010 at 8:43 AM, David Gerard dgerard@gmail.com wrote:
e.g. Wikia has WYSIWYG editing and templates. They have a sort of solution to template editing in WYSIWYG. It's not great, but people sort of cope. How did they get there? What can be done to make it better, *conceptually*?
What I'm saying there is that we don't start from the assumption that we know nothing and have to start from scratch, forming our answers only from pure application of personal brilliance; we should start from the assumption that we know actually quite a bit, if we only know who to ask and where. Does it require throwing out all previous work? etc., etc. And this is the sort of question that requires actual expense on resources to answer.
Given that considerable work has gone on already, what would we do with resources to apply to the problem?
My primary interest at the moment in this area is to reframe the question a bit; rather than "how do we make good WYSIWYG that works on the way Wikipedia pages' markup and templates are structured now" -- which we know has been extremely hard to get going -- to instead consider "how do we make good WYSIWYG that does the sorts of things we currently use markup and templates for, plus the things we wish we could do that we can't?"
We have indeed learned a *huge* amount from the last decade of Wikipedia and friends, among them:
- authors and readers crave advanced systems for data & format-sharing (eg
putting structured info into infoboxes) and interactive features (even just sticking a marker on a map!)
- most authors prefer simplicity of editing (keep the complicated stuff out
of the way until you need it)
- some authors will happily dive into hardcore coding to create the tools
they need (templates, user/site JS, gadgets)
- many other authors will very happily use those tools once they're created
- the less the guts of those tools are exposed, the easier it is for other
people to reuse them
The incredible creativity of Wikimedians in extending the frontend capabilities of MediaWiki through custom JavaScript, and the markup system through templates, has been blowing my mind for years. I want to find a way to point that creativity straight forward, as it were, and use it to kick some ass. :)
Within the Wikimedia ecosystem, we can roughly divide the world into "Wikipedia" and "all the other projects". MediaWiki was created for Wikipedia, based on previous software that had been adapted to the needs of Wikipedia; and while the editing and template systems are sometimes awkward, they work.
Our other projects like Commons, Wiktionary, Wikibooks, Wikiversity, and Wikinews have *never* been as well served. The freeform markup model -- which works very well for body text on Wikipedia even if it's icky for creating tables, diagrams and information sets -- has been a poorer fit, and little effort has been spent on actually creating ways to support them well.
Commons needs better tools for annotating and grouping media resources.
Wiktionary needs structured data with editing and search tools geared towards it.
Wikibooks needs a structure model that's based on groups of pages and media resources, instead of just standalone freetext articles which may happen to link to each other.
Wikiversity needs all those, and more interactive features and the ability for users to group themselves socially and work together.
Getting anything done that would work on the huge, well-developed, wildly-popular Wikipedia has always been a non-starter because it has to deal with 10 years of backwards-compatibility from the get-go. I think it's going to be a *lot* easier to get things going on those smaller projects which are now so poorly served that most people don't even know they exist. :)
This isn't a problem specific to Wikimedia; established organizations of all sorts have a very difficult time getting new ideas over that hump from "not good enough for our core needs" to "*bam* slap it everywhere". By concentrating on the areas that aren't served at all well by the current system, we can make much greater headway in the early stages of development; Clayton Christensen's "The Innovator's Dilemma" calls this "competing against non-consumption".
For the Wikipedia case, we need to incubate the next generation of templating up to the point that they can actually undercut and replace today's wikitext templates, or I worry we're just going to be sitting around going "gosh I wish we could replace these templates and have markup that works cleanly in wysiwyg" forever.
My current thoughts are to concentrate on a few areas:
- create a widget/gadget/template/extension/plugin model built around
embedding blocks of information within a larger context... 2) ...where the data and rendering can be reasonably separate... (eg, not having to pull tricks where you manually mix different levels of table templates to make the infobox work right) 3) ...and the rendering can be as simple, or as fancy as complex, as your imagination and HTML5 allow.
-- brion vibber (brion @ pobox.com) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hi Brion,
Thanks for laying out the problem so clearly! I agree wholeheartedly that we need to avoid thinking about this problem too narrowly as a user interface issue on top of existing markup+templates. More inline:
On Tue, Dec 28, 2010 at 9:27 AM, Brion Vibber brion@pobox.com wrote:
This isn't a problem specific to Wikimedia; established organizations of all sorts have a very difficult time getting new ideas over that hump from "not good enough for our core needs" to "*bam* slap it everywhere". By concentrating on the areas that aren't served at all well by the current system, we can make much greater headway in the early stages of development; Clayton Christensen's "The Innovator's Dilemma" calls this "competing against non-consumption".
Thankfully, we at least we're not trying to defend a business model and cost structure that's fundamentally incompatible with making a change here. However, I know that's not the part that you're highlighting, and I agree that Christensen's "competing against non-consumption" concept is well worth learning about in this context[1], as well as the concepts of "disruptive innovation" vs "continuous innovation"[2]. As you've said, we've learned a lot in the past decade of Wikipedia about how people use our the technology. A new editing model that incorporates that learning will almost certainly take a while to reach full parity in flexibility, power, and performance. The current editor base of English Wikipedia probably won't be patient with any changes that result in a loss of flexibility, power and performance. Furthermore, many (perhaps even most) things we'd be inclined to try would *not* have a measurable and traceable impact on new editor acquisition and retention, which will further diminish patience. A mature project like Wikipedia is a hard place to hunt for willing guinea pigs.
For the Wikipedia case, we need to incubate the next generation of templating up to the point that they can actually undercut and replace today's wikitext templates, or I worry we're just going to be sitting around going "gosh I wish we could replace these templates and have markup that works cleanly in wysiwyg" forever.
My current thoughts are to concentrate on a few areas:
- create a widget/gadget/template/extension/plugin model built around
embedding blocks of information within a larger context... 2) ...where the data and rendering can be reasonably separate... (eg, not having to pull tricks where you manually mix different levels of table templates to make the infobox work right) 3) ...and the rendering can be as simple, or as fancy as complex, as your imagination and HTML5 allow.
Let me riff on what you're saying here (partly just to confirm that I understand fully what you're saying). It'd be very cool to have the ability to declare a single article, or probably more helpfully, a single revision of an article to use a completely different syntax. There's already technically a kludgy model for that now: wrap the whole thing in a tag, and put the parser for the new syntax in a tag extension. That said, it would probably exacerbate our problems if we allowed intermixing of old syntax and new syntax in a single revision. The goal should be to move articles irreversibly toward a new model, and I don't think it'd be possible to do this without the tools to prevent us from backsliding (for example, tools that allow editors to convert an article from old syntax to new syntax, and also tools that allow administrators to lock down the syntax choice for an article without locking down the article).
Still, it's pretty alluring to think about the upgrade of syntax as an incremental problem within an article. We could figure out how to solve one little corner of the data/rendering separation problem and then move on to the next. For example, we could start with citations and make sure it's possible to insert citations easily and cleanly, and to extract citations from an article without relying on scraping the HTML to get them. Or maybe we do that certain types of infoboxes instead, and then gradually get more general. We can take advantage of the fact that we've got millions of articles to help us choose which particular types of data will benefit from a targeted approach, and tailor extensions to very specific data problems, and then generalize after we sort out what works/doesn't work with a few specific cases.
So, which problem first?
Rob
[1] Those with an aversion to business-speak will require steely fortitude to even click on the url, let alone actually read the article, but it's still worth extracting the non-business points from this article: http://businessinnovationfactory.com/weblog/christensen_worldinnovationforum [2] While there is a Wikipedia article describing this[3], a better description of the important bits is here: http://www.mail-archive.com/haskell@haskell.org/msg18498.html [3] Whee, footnote to a footnote! http://en.wikipedia.org/wiki/Disruptive_technology
On Tue, Dec 28, 2010 at 8:28 PM, Rob Lanphier robla@wikimedia.org wrote:
Let me riff on what you're saying here (partly just to confirm that I understand fully what you're saying). It'd be very cool to have the ability to declare a single article, or probably more helpfully, a single revision of an article to use a completely different syntax. There's already technically a kludgy model for that now: wrap the whole thing in a tag, and put the parser for the new syntax in a tag extension. That said, it would probably exacerbate our problems if we allowed intermixing of old syntax and new syntax in a single revision. The goal should be to move articles irreversibly toward a new model, and I don't think it'd be possible to do this without the tools to prevent us from backsliding (for example, tools that allow editors to convert an article from old syntax to new syntax, and also tools that allow administrators to lock down the syntax choice for an article without locking down the article).
I'd actually approach it from the opposite direction. Add a tag to mark the
old syntax at the same time as the new parser is ready, but before it's installed. Set up the interface initially to mask the presence of the "oldsyntax" marker, but still have it present when the text is saved. Make sure the old parser ignores the "oldsyntax" tag, and then run a job to add it everywhere. Install the new parser, which defers the delimited text to the old one. Bring the new UI online that is able to edit the new markup, and make sure it's used for all new articles. Start "unhiding" the oldsyntax marker and letting conversions happen on an "all or nothing" basis. After a few weeks of that, throw an editfilter up that stops the addition or readdition of the oldsyntax marker. Keep converting, and start doing more and more rounds of automatic conversions. Finally, when it's down to a handful of articles still using the old parser throw an editfilter up that won't allow saving until you convert the wikitext.
That gives us a way to do it that's not all at once, and lets us use existing tools to keep decreasing the use of the old syntax until it dies completely. And an administrator or other appropriately flagged user could overrule the edit filter to go back to the old syntax on an article if it broke.
On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier robla@wikimedia.org wrote:
Let me riff on what you're saying here (partly just to confirm that I understand fully what you're saying). It'd be very cool to have the ability to declare a single article, or probably more helpfully, a single revision of an article to use a completely different syntax.
Yes, though I'd recommend jettisoning the word "syntax" entirely from the discussion at this stage, as I worry it distracts towards bikeshedding about unimportant details.
Rather, it could be more useful to primarily think of data resources having "features" or "structure". With images for instance, we don't make people pay too much attention about whether something's in JPEG, PNG, GIF, or SVG format.
At the level of actual people working with the system, the file's *format* is completely unimportant -- only its features and metadata are relevant. Set a size, give a caption, specify a page if it's a paged format, or a time if it's a video format. Is it TIFF or PDF? Ogg Theora or WebM? Don't know, don't care, and any time a user has to worry about it we've let them down.
We need to think about similarly concentrating on document structure rather than markup syntax for text pages.
I definitely agree that the idea of progressively moving bits and pieces in that direction is a wise one. If we can devise a *document structure* that lets us embed magic templatey _things_ into a paragraph-oriented-text document and maintain their structural identity all the way to browser-ready HTML and back, then we can have a useful migration path:
* identify possibly unsafe uses of templates, extensions, and parserfunctions (machines are great at this!) * clean them up bit by bit (bots are often good at many common cases) * once a page can be confirmed as not using Weird Template Magic, but only using templates/images/plugins that fit within the structure, it's golden. * depending on which flavor of overlords we have, we might have various ways of enforcing that a page will always *remain* well-structured from then on.
That might not even involve changing syntax per se -- we shouldn't care too much about whether italic is <i> or ''. But knowing where a table or a div block starts and ends reliably is extremely important to being able to tell which part of your document is which.
And heck, even if not everything gets fixed along that kind of path, just being able to *have* pages and other resource types that *are* well-structured mixed into the system is going to be hugely useful for the non-Wikipedia projects.
-- brion vibber (brion @ pobox.com)
Really good points. I still advocate moving the possibility for these "ugly" constructs to templates, so that we keep all the magic tricks we have now, but lose the ability to make an article that is "write only" by littering it with code that only the wikigods and the parser itself could decypher.
Well-formedness checks would be a huge step forward - if the edit form could catch showstoppers like mismatched braces , brackets, quotes, and even misused templates it would go a long way towards making the site safe to edit.
As for all the deep magic, like parser functions, inline html, and the like, why do we even need to allow the parser to recognize such nonsense in article space. Treat templates as a special case and be rid of just about everything thats not on the editing toolbar.
There will be some people upset that they cant turn an article into an elaborate html and css work of art but they will get over it and go back to writing articles, or if they didn't have any interest in doing that they will go back to myspace. Either way net gain - article code becomes readable and we promote the development and expansion of freely available content, which is the real business we are in.
On 12/29/10, Brion Vibber brion@pobox.com wrote:
On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier robla@wikimedia.org wrote:
Let me riff on what you're saying here (partly just to confirm that I understand fully what you're saying). It'd be very cool to have the ability to declare a single article, or probably more helpfully, a single revision of an article to use a completely different syntax.
Yes, though I'd recommend jettisoning the word "syntax" entirely from the discussion at this stage, as I worry it distracts towards bikeshedding about unimportant details.
Rather, it could be more useful to primarily think of data resources having "features" or "structure". With images for instance, we don't make people pay too much attention about whether something's in JPEG, PNG, GIF, or SVG format.
At the level of actual people working with the system, the file's *format* is completely unimportant -- only its features and metadata are relevant. Set a size, give a caption, specify a page if it's a paged format, or a time if it's a video format. Is it TIFF or PDF? Ogg Theora or WebM? Don't know, don't care, and any time a user has to worry about it we've let them down.
We need to think about similarly concentrating on document structure rather than markup syntax for text pages.
I definitely agree that the idea of progressively moving bits and pieces in that direction is a wise one. If we can devise a *document structure* that lets us embed magic templatey _things_ into a paragraph-oriented-text document and maintain their structural identity all the way to browser-ready HTML and back, then we can have a useful migration path:
- identify possibly unsafe uses of templates, extensions, and
parserfunctions (machines are great at this!)
- clean them up bit by bit (bots are often good at many common cases)
- once a page can be confirmed as not using Weird Template Magic, but only
using templates/images/plugins that fit within the structure, it's golden.
- depending on which flavor of overlords we have, we might have various ways
of enforcing that a page will always *remain* well-structured from then on.
That might not even involve changing syntax per se -- we shouldn't care too much about whether italic is <i> or ''. But knowing where a table or a div block starts and ends reliably is extremely important to being able to tell which part of your document is which.
And heck, even if not everything gets fixed along that kind of path, just being able to *have* pages and other resource types that *are* well-structured mixed into the system is going to be hugely useful for the non-Wikipedia projects.
-- brion vibber (brion @ pobox.com) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Right. Wikipedia is about interesting and useful information, not about coding.
Fred Bauder
Really good points. I still advocate moving the possibility for these "ugly" constructs to templates, so that we keep all the magic tricks we have now, but lose the ability to make an article that is "write only" by littering it with code that only the wikigods and the parser itself could decypher.
Well-formedness checks would be a huge step forward - if the edit form could catch showstoppers like mismatched braces , brackets, quotes, and even misused templates it would go a long way towards making the site safe to edit.
As for all the deep magic, like parser functions, inline html, and the like, why do we even need to allow the parser to recognize such nonsense in article space. Treat templates as a special case and be rid of just about everything thats not on the editing toolbar.
There will be some people upset that they cant turn an article into an elaborate html and css work of art but they will get over it and go back to writing articles, or if they didn't have any interest in doing that they will go back to myspace. Either way net gain - article code becomes readable and we promote the development and expansion of freely available content, which is the real business we are in.
On 12/29/10, Brion Vibber brion@pobox.com wrote:
On Tue, Dec 28, 2010 at 5:28 PM, Rob Lanphier robla@wikimedia.org wrote:
Let me riff on what you're saying here (partly just to confirm that I understand fully what you're saying). It'd be very cool to have the ability to declare a single article, or probably more helpfully, a single revision of an article to use a completely different syntax.
Yes, though I'd recommend jettisoning the word "syntax" entirely from the discussion at this stage, as I worry it distracts towards bikeshedding about unimportant details.
Rather, it could be more useful to primarily think of data resources having "features" or "structure". With images for instance, we don't make people pay too much attention about whether something's in JPEG, PNG, GIF, or SVG format.
At the level of actual people working with the system, the file's *format* is completely unimportant -- only its features and metadata are relevant. Set a size, give a caption, specify a page if it's a paged format, or a time if it's a video format. Is it TIFF or PDF? Ogg Theora or WebM? Don't know, don't care, and any time a user has to worry about it we've let them down.
We need to think about similarly concentrating on document structure rather than markup syntax for text pages.
I definitely agree that the idea of progressively moving bits and pieces in that direction is a wise one. If we can devise a *document structure* that lets us embed magic templatey _things_ into a paragraph-oriented-text document and maintain their structural identity all the way to browser-ready HTML and back, then we can have a useful migration path:
- identify possibly unsafe uses of templates, extensions, and
parserfunctions (machines are great at this!)
- clean them up bit by bit (bots are often good at many common cases)
- once a page can be confirmed as not using Weird Template Magic, but
only using templates/images/plugins that fit within the structure, it's golden.
- depending on which flavor of overlords we have, we might have various
ways of enforcing that a page will always *remain* well-structured from then on.
That might not even involve changing syntax per se -- we shouldn't care too much about whether italic is <i> or ''. But knowing where a table or a div block starts and ends reliably is extremely important to being able to tell which part of your document is which.
And heck, even if not everything gets fixed along that kind of path, just being able to *have* pages and other resource types that *are* well-structured mixed into the system is going to be hugely useful for the non-Wikipedia projects.
-- brion vibber (brion @ pobox.com) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
-- Faith is about what you really truly believe in, not about what you are taught to believe.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I think this has been brought up before, but a thought I've had: Apart from the fact that it will require a ton of work in coding, what would keep us from separating templates (and, for that matter, images) from the article text? Article text would exist by itself, and categories, templates, images and metadata would all be kept and edited separately from the article itself, with "pointers" indicating where the templates and images should go within the article.
Ryan Lomonaco wrote:
I think this has been brought up before, but a thought I've had: Apart from the fact that it will require a ton of work in coding, what would keep us from separating templates (and, for that matter, images) from the article text? Article text would exist by itself, and categories, templates, images and metadata would all be kept and edited separately from the article itself, with "pointers" indicating where the templates and images should go within the article.
Nothing. But images and /some/ inline templates can't be done that way since they also need a "position". That can be automated for eg. license templates, or infoboxes, but not for a template formatting a quote.
It wouldn't be all that hard. Elements are either "inline" or "block" elements. Inline elements insert into the text flow, while text flows around block elements. If we make the distinction as simple as that, and disallow all methods of positioning other than that which is natively available in wiki code (ie, no html or css positioning), we can make that process very easy.
That said, the editing interface needs to be tightly integrated - you shouldn't have to go to a separate page to edit a template or other "external" element. For users that are able to function with a nice pretty AJAX-capable editor, that interface could be clicking on the element marker, and a dialog pops up to edit the element. For users that have to use a flat HTML form, make these elements "list defined", like list defined references, and then use simple syntax to indicate all the markers, basically as entities.
This would result in a WYSIWYM interface, with any and all complex markup being rendered as placeholders editors could click to get a property screen for that item, and it would probably be way more practical than WYSIWYG given the complexity of the markup we are trying to "fix".
On Fri, Dec 31, 2010 at 8:13 AM, Platonides Platonides@gmail.com wrote:
Ryan Lomonaco wrote:
I think this has been brought up before, but a thought I've had: Apart
from
the fact that it will require a ton of work in coding, what would keep us from separating templates (and, for that matter, images) from the article text? Article text would exist by itself, and categories, templates,
images
and metadata would all be kept and edited separately from the article itself, with "pointers" indicating where the templates and images should
go
within the article.
Nothing. But images and /some/ inline templates can't be done that way since they also need a "position". That can be automated for eg. license templates, or infoboxes, but not for a template formatting a quote.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
David Gerard wrote:
Our current markup is one of our biggest barriers to participation.
[snip]
- Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for comparison, I work as a sysadmin at a tiny, tiny publishing company with more money and staff just in our department than that to do *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY efficient organisation.)
You inexplicably posted this to foundation-l, so let's look at this from an organizational/political standpoint.
The issue isn't a technical one, though there are technical challenges, to be sure. The issue is one of priorities. If there were a grant involved, Wikimedia would find a way to push out some half-assed code at the eleventh hour. If there were some way to tie this to fundraising, you could get one or two full-time developers working on this, plus a staff of "associates." But this isn't tied to a grant and it isn't fundraising-related. It isn't glamorous work and it doesn't directly involve money, so it's left in The Pile next to the thousands of other ideas that desperately need attention.
Or put another way, "this seems like far better outreach than a thousand outreach officers."
It's clear where Wikimedia is putting its priorities. Screw being able to click edit on the "Microsoft" article and not wanting to kill yourself, in-person wiki editing training is the way forward! Or so the funds flow.
The saving grace of this idea (i.e., the reason it might one day move forward) is that, as you note, easier editing bolsters participation. And if one thing has been made clear through the strategic planning charade, it's that participation is actually viewed as very important to Wikimedia. Quality be damned, Wikimedia wants quantity. It's this attitude that might finally drive some resources toward making the edit screen less of a nightmare, but I wouldn't hold my breath. It still assumes a higher level of competence than has been demonstrated historically.
All of this sidesteps that even if you had a brilliant extension/patch that could solve this problem (and it's not as though such a patch or extension would be simple), the likelihood of it being committed to SVN and going live before 2012 is pretty low. (Unless, again, there were a grant attached.)
I think this is an important problem that deserves thoughtful consideration and attention. Which of course begs the question of why you think Wikimedia will be the one to solve it. This is the prime target for a competitor coming in and making something better. Why stand in the way?
MZMcBride
z@mzmcbride.com wrote:
David Gerard wrote:
Our current markup is one of our biggest barriers to participation.
[snip]
- Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for comparison, I work as a sysadmin at a tiny, tiny publishing company with more money and staff just in our department than that to do *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY efficient organisation.)
In comparison $14m does seem highly profligate. Our R&D budget was £10m (approx $16) in 2009, spent almost entirely on software development, and we have over 160 software engineers working on our products. Remind me just how many full time developers does WMF have?
wiki-list@phizz.demon.co.uk wrote:
z@mzmcbride.com wrote:
David Gerard wrote:
Our current markup is one of our biggest barriers to participation.
[snip]
- Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for comparison, I work as a sysadmin at a tiny, tiny publishing company with more money and staff just in our department than that to do *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY efficient organisation.)
In comparison $14m does seem highly profligate. Our R&D budget was £10m (approx $16) in 2009, spent almost entirely on software development, and we have over 160 software engineers working on our products. Remind me just how many full time developers does WMF have?
These two pages should give you an approximate count: * http://wikimediafoundation.org/wiki/Staff * http://meta.wikimedia.org/wiki/Wikimedia_Foundation_contractors
MZMcBride
z@mzmcbride.com wrote:
wiki-list@phizz.demon.co.uk wrote:
z@mzmcbride.com wrote:
In comparison $14m does seem highly profligate. Our R&D budget was £10m (approx $16) in 2009, spent almost entirely on software development, and =
we
have over 160 software engineers working on our products. Remind me just =
how
many full time developers does WMF have?
These two pages should give you an approximate count:
We make a profit on a turnover of £32m with 500+ direct employees, and a further 200 in joint oversees ventures. We have offices in most European countries, and regional centres in the US, India, China, Japan, Korea, and a team of application engineers flying the world to train, and provide expert sales support etc.
Draw your own conclusions.
On 29 December 2010 05:13, MZMcBride z@mzmcbride.com wrote:
You inexplicably posted this to foundation-l, so let's look at this from an organizational/political standpoint.
I deliberately posted it there because what I'm asking for is broad and difficult organisational commitment. And almost didn't post it to wikitech-l, fearing that doing the latter would result in what it did, i.e, more of the same from the past five years, where the necessity is buried under more off-the-cuff ideas that won't get it through.
And a pointer here from internal-l and wikien-l.
Sorry, was it not entirely clear that was what I was doing? It is. My dream is that more than me will consider this worth the serious pushing it will take.
I think this is an important problem that deserves thoughtful consideration and attention. Which of course begs the question of why you think Wikimedia will be the one to solve it. This is the prime target for a competitor coming in and making something better. Why stand in the way?
Unfortunately, Wikia seems to treat its codebase with nearly the hygiene WMF does at times, so using their work would be comparable effort to reimplementing it ...
- d.
David Gerard wrote:
On 29 December 2010 05:13, MZMcBride z@mzmcbride.com wrote:
You inexplicably posted this to foundation-l, so let's look at this from an organizational/political standpoint.
I deliberately posted it there because what I'm asking for is broad and difficult organisational commitment. And almost didn't post it to wikitech-l, fearing that doing the latter would result in what it did, i.e, more of the same from the past five years, where the necessity is buried under more off-the-cuff ideas that won't get it through.
And a pointer here from internal-l and wikien-l.
Sorry, was it not entirely clear that was what I was doing? It is. My dream is that more than me will consider this worth the serious pushing it will take.
I was aware that you'd posted to four separate mailing lists about this. The underlying motive wasn't as clear to me. Thank you for clarifying.
You seem to have snipped out the reasons laid out in my previous post for why I think your dream (broad and difficult organisational commitment) is just a dream, though. ;-)
I think this is an important problem that deserves thoughtful consideration and attention. Which of course begs the question of why you think Wikimedia will be the one to solve it. This is the prime target for a competitor coming in and making something better. Why stand in the way?
Unfortunately, Wikia seems to treat its codebase with nearly the hygiene WMF does at times, so using their work would be comparable effort to reimplementing it ...
The way I read this, you're almost suggesting that Wikia is a competitor to Wikipedia. Of all the sites on the Web, I think it's reasonable to say that Wikia is one of the few that inherently was not designed to be a competitor to Wikipedia, given its founders.
As for Wikia's codebase, the idea of Wikimedia's code improving Wikia and Wikia's code improving Wikimedia is certainly a nice one. However, I can't say the reality has really matched the ideal. I think we agree here.
MZMcBride
On 29 December 2010 11:03, MZMcBride z@mzmcbride.com wrote:
The way I read this, you're almost suggesting that Wikia is a competitor to Wikipedia. Of all the sites on the Web, I think it's reasonable to say that Wikia is one of the few that inherently was not designed to be a competitor to Wikipedia, given its founders.
I wasn't saying they're a competitor, but they're an organisation that has code that aims to allow the widest possible range of editors. With varying success. And that they do actually share their code.
- d.
I can promise you that the reason edit rates has gone down is not because of problems with wikitext. Though the cruft is a symptom.
On Tue, Dec 28, 2010 at 6:50 AM, David Gerard dgerard@gmail.com wrote:
[crossposted to foundation-l and wikitech-l]
"There has to be a vision though, of something better. Maybe something that is an actual wiki, quick and easy, rather than the template coding hell Wikipedia's turned into." - something Fred Bauder just said on wikien-l.
Our current markup is one of our biggest barriers to participation.
AIUI, edit rates are about half what they were in 2005, even as our fame has gone from "popular" through "famous" to "part of the structure of the world." I submit that this is not a good or healthy thing in any way and needs fixing.
People who can handle wikitext really just do not understand how offputting the computer guacamole is to people who can cope with text they can see.
We know this is a problem; WYSIWYG that works is something that's been wanted here forever. There are various hideous technical nightmares in its way, that make this a big and hairy problem, of the sort where the hair has hair.
However, I submit that it's important enough we need to attack it with actual resources anyway.
This is just one data point, where a Canadian government office got *EIGHT TIMES* the participation in their intranet wiki by putting in a (heavily locally patched) copy of FCKeditor:
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
"I have to disagree with you given my experience. In one government department where MediaWiki was installed we saw the active user base spike from about 1000 users to about 8000 users within a month of having enabled FCKeditor. FCKeditor definitely has it's warts, but it very closely matches the experience non-technical people have gotten used to while using Word or WordPerfect. Leveraging skills people already have cuts down on training costs and allows them to be productive almost immediately."
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
"Since a plethora of intelligent people with no desire to learn WikiCode can now add content, the quality of posts has been in line with the adoption of wiki use by these people. Thus one would say it has gone up.
"In the beginning there were some hard core users that learned WikiCode, for the most part they have indicated that when the WYSIWYG fails, they are able to switch to WikiCode mode to address the problem. This usually occurs with complex table nesting which is something that few of the users do anyways. Most document layouts are kept simple. Additionally, we have a multilingual english/french wiki. As a result the browser spell-check is insufficient for the most part (not to mention it has issues with WikiCode). To address this a second spellcheck button was added to the interface so that both english and french spellcheck could be available within the same interface (via aspell backend)."
So, the payoffs could be ridiculously huge: eight times the number of smart and knowledgeable people even being able to *fix typos* on material they care about.
Here are some problems. (Off the top of my head; please do add more, all you can think of.)
- The problem:
- Fidelity with the existing body of wikitext. No conversion flag day.
The current body exploits every possible edge case in the regular expression guacamole we call a "parser". Tim said a few years ago that any solution has to account for the existing body of text.
- Two-way fidelity. Those who know wikitext will demand to keep it and
will bitterly resist any attempt to take it away from them.
FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.
There is no specification for wikitext. Well, there almost is -
compiled as C, it runs a bit slower than the existing PHP compiler. But it's a start! http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html
- Attempting to solve it:
- The best brains around Wikipedia, MediaWiki and WMF have dashed
their foreheads against this problem for at least the past five years and have got *nowhere*. Tim has a whole section in the SVN repository for "new parser attempts". Sheer brilliance isn't going to solve this one.
- Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for comparison, I work as a sysadmin at a tiny, tiny publishing company with more money and staff just in our department than that to do *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY efficient organisation.)
- Other attempts:
- Starting from a clear field makes it ridiculously easy. The
government example quoted above is one. Wikia wrote a good WYSIWYG that works really nicely on new wikis (I'm speaking here as an experienced wikitext user who happily fixes random typos on Wikia). Of course, I noted that we can't start from a clear field - we have an existing body of wikitext.
So, specification of the problem:
- We need good WYSIWYG. The government example suggests that a simple
word-processor-like interface would be enough to give tremendous results.
- It needs two-way fidelity with almost all existing wikitext.
- We can't throw away existing wikitext, much as we'd love to.
- It's going to cost money in programming the WYSIWYG.
- It's going to cost money in rationalising existing wikitext so that
the most unfeasible formations can be shunted off to legacy for chewing on.
- It's going to cost money in usability testing and so on.
- It's going to cost money for all sorts of things I haven't even
thought of yet.
This is a problem that would pay off hugely to solve, and that will take actual money thrown at it.
How would you attack this problem, given actual resources for grunt work?
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hello all,
about WYSIWYG have a look to to this links:
* http://meta.wikimedia.org/wiki/WissensWert/75_-_Einsatz_des_TWX_WYSIWYG_Edit... * http://www.wiki4enterprise.org/index.php/Datei:Artikelbearbeitung_Twoonix.jp...
TWOONIX is working on an on an MediaWiki based editor.
Best Juliana
Thanks, interesting. Go to
http://www.wiki4enterprise.org/index.php?title=Editor&action=edit
for example, and click on [Rich Editor] (above the button bar at the top of the edit window). This gives you a WYSIWIYG display in the edit window. Users can toggle between the two types of display.
A.
--- On Tue, 4/1/11, Juliana da Costa José julianadacostajose@googlemail.com wrote:
From: Juliana da Costa José julianadacostajose@googlemail.com Subject: [Foundation-l] Big problem to solve: good WYSIWYG on WMF wikis To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Tuesday, 4 January, 2011, 21:03 Hello all,
about WYSIWYG have a look to to this links:
- http://meta.wikimedia.org/wiki/WissensWert/75_-_Einsatz_des_TWX_WYSIWYG_Edit...
- http://www.wiki4enterprise.org/index.php/Datei:Artikelbearbeitung_Twoonix.jp...
TWOONIX is working on an on an MediaWiki based editor.
Best Juliana
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
2011/1/4 Andreas Kolbe jayen466@yahoo.com:
Thanks, interesting. Go to
http://www.wiki4enterprise.org/index.php?title=Editor&action=edit
That's just FCK, an existing MediaWiki extension. http://www.mediawiki.org/wiki/Extension:FCKeditor_%28Official%29
Their own editor still appears to be under active development at this point. I didn't see any pointers to either a code repository or a demo yet.
2011/1/5, Erik Moeller wrote:
Their own editor still appears to be under active development at this point. I didn't see any pointers to either a code repository or a demo yet.
Yes, this is correct. The status is in development. Releasedata estimated Cebit 2011.
* http://www.wiki4enterprise.org/index.php/Datei:Artikelbearbeitung_Twoonix.jp...
Best Juliana
wikimedia-l@lists.wikimedia.org