While from a user's perspective the various editors seen on the page you linked to appear to be drop-in replacements for the current plain text solution, I can assure you that there are many other reasons for not yet deploying them on Wikipedia that go far beyond our ability to provide users with a preference to turn them off. Almost all of those visual editors require the use of not-yet-stable reverse parsing, and many cause articles to change in ways the user did not intend, such as adding white-space places the user did not touch, or stripping out HTML comments from the code. There are other downsides as well, which are represented in an article closely related to the one you linked to, which is the results of the extensions chosen for evaluation from the list of nominated ones. http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions… An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional. - Trevor Parscal On 4/24/09 5:30 AM, Jacopo Corbetta wrote:

2009/4/24 Jacopo Corbetta <jacopo.corbetta(a)gmail.com>om>: I don't believe any WYSIWYG (or close to) editor that exists for MediaWiki is good enough that you can completely avoid editing the wikitext directly (in order to do complicated stuff), that means you can't use one and only one editor unless that editor is the default wikitext editor.

Alex wrote: A preference name could be reserved to be consistently used by all alternate editors. Anyway, IMHO any alternate editor should offer an option to disable it directly on the edit page, regardless of a preference which would define "don't appear by default".

What does this have to do with not horribly breaking many extensions at the same time? The WMF has cultivated an extension ecosystem and it makes sense to protect it. On Fri, Apr 24, 2009 at 2:23 PM, Soxred93 <soxred93(a)gmail.com> wrote:

I am just hoping to prevent a repeat of ParserPP. On Fri, Apr 24, 2009 at 2:56 PM, Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com> > On Fri, Apr 24, 2009 at 4:23 PM, Soxred93 &lt;soxred93(a)gmail.com> > Keep in mind that when MediaWiki is developed, the best interests of > > Wikimedia are in mind. Wikimedia takes priority on MW development. > > Not as a general rule. If we really didn't care about third-party > users, we'd require the very latest version of PHP (since Wikimedia > uses it), write large chunks of the software in other languages > (Wikipedia has Python installed), and so on. The suggestion to allow > embedded Lua in templates seems not to be happening primarily because > it would make Wikipedia content unusable by third parties on shared > hosting. > > Although development of MediaWiki tends to focus primarily on > Wikimedia's needs, it does *not* do so if that would significantly > hurt MediaWiki's utility to third parties. Part of Wikimedia's goals > is to make its content as useful as possible to third parties. That > applies to MediaWiki insofar as it's a Wikimedia project, and doubly > so insofar as it's needed to effectively use content from Wikimedia's > other projects like Wikipedia. > > On Fri, Apr 24, 2009 at 4:25 PM, Brian &lt;Brian.Mingus(a)colorado.edu> > What does this have to do with not horribly breaking many extensions at > the > > same time? The WMF has cultivated an extension ecosystem and it makes > sense > > to protect it. > > Do you have evidence that many extensions are, in fact, horribly > broken? And if so, that they can't be easily fixed? > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

Whatever happened to object-oriented programming and abstraction? Why can't you define and provide a consistent API? On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com> > On Fri, Apr 24, 2009 at 4:59 PM, Brian &lt;Brian.Mingus(a)colorado.edu> > I am just hoping to prevent a repeat of ParserPP. > > A *lot* more extensions use parser-related stuff than preferences. In > any event, the upheaval of ParserPP was probably necessary given what > it sought to achieve. That sort of thing happens from time to time -- > it's not feasible for extensions with access to so many hooks and > methods to just work forever. > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

Brian wrote: The old preferences system didn't use anything like that, which is why it needed to be totally rewritten. The old system was basically a hardcoded form and extensions had to add preferences by appending to the HTML. While backwards compatibility is nice, if it stands in the way of improving something that needs improvement, the improvement should take priority. -- Alex (wikipedia:en:User:Mr.Z-man)

On Fri, Apr 24, 2009 at 6:50 PM, Brian &lt;Brian.Mingus(a)colorado.edu&gt; wrote: Object-oriented programming and abstraction do not magically avoid the problem of requirements and functionality changing over time. It's possible to provide a very stable API, but it takes a lot of work. It's necessary for, say, an operating system (and even they often mess up), but it's just not worth it in most other cases. Firefox extensions also sometimes break on upgrade, for instance. The same is true for extension mechanisms in the large majority of software. You have to weigh the costs against the benefits in all cases. Since no actual significant costs have yet been presented here, this whole line of discussion seems like a tempest in a teapot.

Le 24 avr. 09 à 16:15, John Doe a écrit : Global preferences were added with this rewrite. There is just a checkbox saying "use these preferences on all projects" at the bottom of Special:Preferences. Alexandre Emsenhuber (ialex)

On Sat, Apr 25, 2009 at 3:08 AM, Brion Vibber &lt;brion(a)wikimedia.org&gt; wrote: I mean, of course, that the back-end business logic interface can be called internally, not that the API can be called internally. -- Andrew Garrett

Hoi, How much work do you think it will be to repair an extension that needs repair ? For someone who knows the code and for someone who just has to repair his one extension ?? Thanks, GerardM 2009/4/24 Brian &lt;Brian.Mingus(a)colorado.edu&gt;

Is an autoconverter feasible? There are many, many extensions guys! On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett &lt;agarrett(a)wikimedia.org&gt;wrote;wrote:

2009/4/24 Chad &lt;innocentkiller(a)gmail.com&gt;om>: How gracefully will old extensions fail?

On 4/24/09 10:34 AM, Aryeh Gregor wrote: I believe they'll just not have their extended preferences displayed until they've updated to work with the non-crappy, actually sanely extensible, preferences interface. Nothing else would be affected. -- brion