Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users. So we decided to write to this list. Any feedback/suggestion will be very helpful.
P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4
Regards, Pavel
Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users. So we decided to write to this list. Any feedback/suggestion will be very helpful.
P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4
Regards, Pavel
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
From the screencast, it seems your technology is based in a local
application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in wikitext-l. Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
On Tue, Aug 3, 2010 at 00:49, Platonides Platonides@gmail.com wrote:
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in wikitext-l. Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
I agree, wikitext is notoriously developer-unfriendly. A survey of currently existing ideas and extensions is on http://www.mediawiki.org/wiki/WYSIWYG_editor
As a shameless self-promotion, I encourage you to look at http://www.mediawiki.org/wiki/Extension:MeanEditor for the approach we took: 1. supporting only a limited subset of wikitext 2. supporting that subset well, leaving a clean history
The rationale here is that supporting all quirks of wikitext adds little value both for new users (they should not be editing complex stuff anyways!) and for advanced users (who probably already know wikitext). I hope this idea can be useful to you.
However, the "editing mode" provided by browsers is a nightmare of incompatibilities. Basically, each browser produces a different output given identical commands, so currently MeanEditor is not completely up to the task. An external application might be an interesting solution.
On Tue, Aug 3, 2010 at 10:53 AM, Jacopo Corbetta jacopo.corbetta@gmail.com wrote:
However, the "editing mode" provided by browsers is a nightmare of incompatibilities. Basically, each browser produces a different output given identical commands, so currently MeanEditor is not completely up to the task. An external application might be an interesting solution.
I don't have the link ready, but Google solved this in Google Docs by re-implementing this in Javascript... they intercept mouse movements/clicks and keyboard events and then javascript-render the page. Given the complexity of wikitext, I fear rewriting the parser in Javascript is the only way to get a 100% compatible wikitext editor...
Marco
On 8/3/10 2:18 AM, Marco Schuster wrote:
I don't have the link ready, but Google solved this in Google Docs by re-implementing this in Javascript... they intercept mouse movements/clicks and keyboard events and then javascript-render the page.
http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs...
Every time this comes up, I feel compelled to point out that true WYSIWYG has to work with all parser tag extensions. Otherwise, it's not really WYSIWYG.
Jim
On Aug 3, 2010, at 12:25 PM, Neil Kandalgaonkar wrote:
On 8/3/10 2:18 AM, Marco Schuster wrote:
I don't have the link ready, but Google solved this in Google Docs by re-implementing this in Javascript... they intercept mouse movements/clicks and keyboard events and then javascript-render the page.
http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs...
-- Neil Kandalgaonkar ( neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Every time this comes up, I feel compelled to point out that true WYSIWYG has to work with all parser tag extensions. Otherwise, it's not really WYSIWYG.
Not to mention, it puts all of the presentation logic in the article which eliminates the benefits of using CSS. I'd much prefer a Content Editor that is WDYGITDYG (What Data You Give Is The Data You Get) - much like Semantic MediaWiki Forms does.
Mark W.
On Wed, Aug 4, 2010 at 12:05 PM, Mark Wonsil wonsil@4m-ent.com wrote:
Not to mention, it puts all of the presentation logic in the article which eliminates the benefits of using CSS.
That is not an inherent characteristic of WYSIWYG. It's true of WYSIWYG as implemented in, for instance, Microsoft Word, but it doesn't have to be true of other WYSIWYG systems. The defining characteristic of WYSIWYG is that while editing the page, it looks the same as it will be displayed when you save, rather than looking like plaintext markup while you edit and then looking like rendered non-plaintext when you save. No one is suggesting that we give users a menu to change the color or size of text, or do any other purely presentational thing like that. A WYSIWYG system that we'd use and support would probably have similar features to the current edit toolbar -- headers, links, bold, etc.
On 3 August 2010 11:18, Marco Schuster marco@harddisk.is-a-geek.org wrote:
On Tue, Aug 3, 2010 at 10:53 AM, Jacopo Corbetta jacopo.corbetta@gmail.com wrote:
However, the "editing mode" provided by browsers is a nightmare of incompatibilities. Basically, each browser produces a different output given identical commands, so currently MeanEditor is not completely up to the task. An external application might be an interesting solution.
I don't have the link ready, but Google solved this in Google Docs by re-implementing this in Javascript... they intercept mouse movements/clicks and keyboard events and then javascript-render the page. Given the complexity of wikitext, I fear rewriting the parser in Javascript is the only way to get a 100% compatible wikitext editor...
*cracy idea here*
What about compiling PHP for the Flash extension? http://labs.adobe.com/technologies/alchemy/
Then you can use a modified version of the original PHP files.
Tei wrote:
On 3 August 2010 11:18, Marco Schuster marco@harddisk.is-a-geek.org wrote:
I don't have the link ready, but Google solved this in Google Docs by re-implementing this in Javascript... they intercept mouse movements/clicks and keyboard events and then javascript-render the page. Given the complexity of wikitext, I fear rewriting the parser in Javascript is the only way to get a 100% compatible wikitext editor...
*cracy idea here*
What about compiling PHP for the Flash extension? http://labs.adobe.com/technologies/alchemy/
Then you can use a modified version of the original PHP files.
That talks about compiling C/C++ to Flash, not PHP to Flash. Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash...
A really crazy idea :)
On 8/4/10 2:47 PM, Platonides wrote:
What about [various insanity snipped] Flash
On a more serious note: when it comes to Flash on Wikimedia projects, the WMF board has said no.
In this modern age of HTML5 and so on, I wouldn't ever pick Flash as a technology the WMF should use going forward, but it could have helped us with some older browsers.
However, I'm not really complaining -- Flash has way too many issues for our projects. Even if you accept Adobe's claim to Flash now being an "open" technology, there are all sorts of other issues. Security, accessibility, take your pick. Plus it's better for us to put our full weight behind technologies that we *can* live with long term.
On Wed, Aug 4, 2010 at 6:10 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
On a more serious note: when it comes to Flash on Wikimedia projects, the WMF board has said no.
Has it? Where? I think everyone is grudgingly okay for Flash as a fallback for browsers that don't support standards-based markup . . . but not if it's the only way to get the functionality.
On 8/4/10 3:14 PM, Aryeh Gregor wrote:
On Wed, Aug 4, 2010 at 6:10 PM, Neil Kandalgaonkarneilk@wikimedia.org wrote:
On a more serious note: when it comes to Flash on Wikimedia projects, the WMF board has said no.
Has it? Where? I think everyone is grudgingly okay for Flash as a fallback for browsers that don't support standards-based markup . . . but not if it's the only way to get the functionality.
I looked for some sort of meeting minutes before posting, but couldn't find them. Maybe I don't know where or how to look.
Anyway, this is what I heard from Danese. A few weeks ago Tim Starling noted that the PLupload library* looked interesting, which falls back to Flash quite a bit for older browsers. So I tried to figure out if we could use it (or its approach to things) and started asking around. Danese and I had a short informal discussion, but it seemed pretty unambiguous to me, but I could be mistaken.
Danese is on vacation until August 8th, but maybe others have heard this?
[1] PLUpload's model of separating presentation and backend upload transport is nice, definitely cleaner than ours. But we were doing something similar anyway. The difference is that we're trying to make HTML4 really good and then swapping in HTML5/modern browser trickery when we can, whereas they started with Flash/Silverlight/Gears/HTML5 and their HTML4 version isn't that good.
Hi,
Le mercredi 04 août 2010 à 15:39 -0700, Neil Kandalgaonkar a écrit :
On 8/4/10 3:14 PM, Aryeh Gregor wrote:
On Wed, Aug 4, 2010 at 6:10 PM, Neil Kandalgaonkarneilk@wikimedia.org wrote:
On a more serious note: when it comes to Flash on Wikimedia projects, the WMF board has said no.
Has it? Where? I think everyone is grudgingly okay for Flash as a fallback for browsers that don't support standards-based markup . . . but not if it's the only way to get the functionality.
I looked for some sort of meeting minutes before posting, but couldn't find them. Maybe I don't know where or how to look.
I don't think there is an official Board resolution about the use of proprietary technologies on Wikimedia projects. However, Brion and Erik have been known to have a pretty strong opinion on that, and I believe Danese and a large part of the WMF tech staff are in the same place.
A few relevant links for a historical perspective:
* "We should permit Flash video playback" thread on foundation-l in 2007 http://thread.gmane.org/gmane.org.wikimedia.commons/2220/
* "Software policy draft" thread on foundation-l in 2007 http://thread.gmane.org/gmane.org.wikimedia.foundation/19547/
* The actual draft: http://meta.wikimedia.org/wiki/Wikimedia_Draft_Statement_of_Principles_Regar...
On Wed, Aug 4, 2010 at 6:59 PM, Guillaume Paumier gpaumier@wikimedia.org wrote:
A few relevant links for a historical perspective:
Another, somewhat more recent one: http://wikimediafoundation.org/wiki/Minutes/October_3-5,_2008#Open_Standards_.2F_Free_File_Formats
"The board asked Sue to have Mike Godwin revise the draft policy to a version that would make it clear that only free formats are permissible."
Did that ever happen? (Or did anything useful ever come about of it?)
On Wed, Aug 4, 2010 at 7:04 PM, Casey Brown lists@caseybrown.org wrote:
On Wed, Aug 4, 2010 at 6:59 PM, Guillaume Paumier gpaumier@wikimedia.org wrote:
A few relevant links for a historical perspective:
Another, somewhat more recent one: < http://wikimediafoundation.org/wiki/Minutes/October_3-5,_2008#Open_Standards...
"The board asked Sue to have Mike Godwin revise the draft policy to a version that would make it clear that only free formats are permissible."
Did that ever happen? (Or did anything useful ever come about of it?)
There was also a proposed policy on Meta: < http://meta.wikimedia.org/wiki/File_format_policy%3E, but it looks like it's historical now.
Alex
Flash is evil.
Also, I'm a little confused what you are trying to accomplish in flash that you can't do in HTML. To do a WYSIWYG editor, you would need to make sure the editing interface is being rendered exactly the same as the viewing interface. You will be constantly trying to mimic the way HTML is rendered in a browser. This seems like a difficult task that has nothing to do with editing wikitext.
- Trevor
On 8/4/10 7:22 PM, Alex Zariv wrote:
On Wed, Aug 4, 2010 at 7:04 PM, Casey Brownlists@caseybrown.org wrote:
On Wed, Aug 4, 2010 at 6:59 PM, Guillaume Paumier gpaumier@wikimedia.org wrote:
A few relevant links for a historical perspective:
Another, somewhat more recent one: < http://wikimediafoundation.org/wiki/Minutes/October_3-5,_2008#Open_Standards... "The board asked Sue to have Mike Godwin revise the draft policy to a version that would make it clear that only free formats are permissible."
Did that ever happen? (Or did anything useful ever come about of it?)
There was also a proposed policy on Meta:< http://meta.wikimedia.org/wiki/File_format_policy%3E, but it looks like it's historical now.
Alex
On Wed, Aug 4, 2010 at 11:47 PM, Platonides Platonides@gmail.com wrote:
Tei wrote:
What about compiling PHP for the Flash extension? http://labs.adobe.com/technologies/alchemy/
Then you can use a modified version of the original PHP files.
That talks about compiling C/C++ to Flash, not PHP to Flash. Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash...
Nope, Tei indeed proposes something nice here... compile the php interpreter itself in Flash.
Marco
Hi.
Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories...
BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2].
[1] https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ [2] http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official)
Regards, Nux.
Category stuff is a separate extension independent of the RTE. https://svn.wikia-code.com/wikia/trunk/extensions/wikia/CategorySelect/ Their RTE is an improvement, but last I checked it still has enough annoying faults to have a number of wikia request it be disabled wiki-wide.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Maciej Jaros wrote:
Hi.
Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories...
BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2].
[1] https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ [2] http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official)
Regards, Nux.
On 8/20/10 12:57 PM, Maciej Jaros wrote:
Hi.
Does anybody know which extension Wikia uses currently? On Wikia's SVN I've found the RTE extension[1], but I think they at least something extra for adding categories...
Not really sure, but I know what you mean.
BTW, I am working on something similar, but only as a sort of sideline to my work on Multimedia Usability. Not really ready for prime time yet.
HotCats is still the most featureful and most compatible with various use cases (such as category editing).
BTW. I think that usability might consider working from their version rather then developing everything from scratch. Wikia's editor seems to work quite well for most basic pages and doesn't seem to clutter code with unwanted tags. After some tests I can certainly say it's much better then the official version of FCKeditor extension [2].
At the WMF, we just met with Wikia on Monday about how we can move forward together on the whole WYSIWYG front.
Wikia does have a lot of nice GUI features and they say they've ironed out most of their "dirty diff" issues. Nevertheless they only have part of an engineer's time dedicated to editing issues[1]. So one way or another, it's going to be the MediaWiki community that takes WYSIWYG forward. The question is whether Wikia's editor is a good basis for progress on Wikimedia projects. We're trying to figure that out right now.
Anyway, we're going to be talking with Wikia on a more regular basis in the future, no matter what.
[1] My impression is that Wikia is really more about building on *top* of the MediaWiki platform. (They said as much in that meeting). Their main business is hosting thousands and thousands of wikis, building features that are amusing or engaging to their audience, adapting the software for advertising and commercial entities, and so on.
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkar neilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (| neilk@wikimedia.org
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченко pavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkar neilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (| neilk@wikimedia.org
Hi,
I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well.
The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript.
If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project.
All the best,
William
2010/8/13 Павел Петроченко pavel@onpositive.com:
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченко pavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkar neilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (| neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This looks very interesting.
1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include "parents" and "joint ventures" in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext > HTML / HTML > wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser?
Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community.
- Trevor
On 8/13/10 8:27 AM, William Le Ferrand wrote:
Hi,
I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well.
The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript.
If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project.
All the best,
William
2010/8/13 Павел Петроченкоpavel@onpositive.com:
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченкоpavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkarneilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (|neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Trevor,
Thanks for the reply! Actually I wrote this code for fun a few months ago; the core is done but there is still a lot of room for improvements ;)
I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it?
It comes with several fancy tools; I used ocamllex to generate the lexer; and a custom parser to cope with the grammar. I didn't reused any line of the mediawiki parser, it is entirely written from scratch in pure ocaml. The ocaml code is compiled to javascript to get the js code you can see on the website. Using those tools, I've been able to set up a rather complicated program in js that I couldn't have written in a non typed language. (but perhaps because I'm a bad js programmer..)
About your questions:
1) No, I haven't check that. It is a very important issue, but if the current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue.
2) Yes, this case is not correctly handled. One more time, I didn't spent too much time on this, even if I'd love to !
3) Ah, perhaps, yes. This js is autogenerated. A friend of mine released a new ocaml->js compiler ( available from www.ocsigen.org ), perhaps his compiler will produce more compact code.
4,5) I only tested on safari and chrome where the preformance is actually quite good. Of course, the computations that were originally handled by the server have to be done by the browser, so it is slower; but with this method there is less load on the server (at least I believe so), the load is distributed to the users; it is a nice scheme for a community project isn't it ;)?
5) Well, the best should probably that you have a look to the source code. I can put it on github if you want; would you be interested? Is there an ocaml developer on the list that could give his opinion about the global process ?
Thanks !
William
2010/8/13 Trevor Parscal tparscal@wikimedia.org:
This looks very interesting.
1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include "parents" and "joint ventures" in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext > HTML / HTML > wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser?
Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community.
- Trevor
On 8/13/10 8:27 AM, William Le Ferrand wrote:
Hi,
I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well.
The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript.
If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project.
All the best,
William
2010/8/13 Павел Петроченкоpavel@onpositive.com:
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченкоpavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkarneilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (|neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/8/13 William Le Ferrand william@corefarm.com:
I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it?
Our math extensions for displaying TeX use it. In fact, they've been languishing for a lack of OCaml programmers ...
- d.
Very exciting work, thanks for the quality responses.
I'm not an OCaml programmer, so I'd likely be useless in giving input - but open-sourcing it and putting the code in a repository is always a good way to find people who are and to get them involved.
- Trevor
On 8/13/10 12:19 PM, William Le Ferrand wrote:
Hi Trevor,
Thanks for the reply! Actually I wrote this code for fun a few months ago; the core is done but there is still a lot of room for improvements ;)
I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it?
It comes with several fancy tools; I used ocamllex to generate the lexer; and a custom parser to cope with the grammar. I didn't reused any line of the mediawiki parser, it is entirely written from scratch in pure ocaml. The ocaml code is compiled to javascript to get the js code you can see on the website. Using those tools, I've been able to set up a rather complicated program in js that I couldn't have written in a non typed language. (but perhaps because I'm a bad js programmer..)
About your questions:
- No, I haven't check that. It is a very important issue, but if the
current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue.
- Yes, this case is not correctly handled. One more time, I didn't
spent too much time on this, even if I'd love to !
- Ah, perhaps, yes. This js is autogenerated. A friend of mine
released a new ocaml->js compiler ( available from www.ocsigen.org ), perhaps his compiler will produce more compact code.
4,5) I only tested on safari and chrome where the preformance is actually quite good. Of course, the computations that were originally handled by the server have to be done by the browser, so it is slower; but with this method there is less load on the server (at least I believe so), the load is distributed to the users; it is a nice scheme for a community project isn't it ;)?
- Well, the best should probably that you have a look to the source
code. I can put it on github if you want; would you be interested? Is there an ocaml developer on the list that could give his opinion about the global process ?
Thanks !
William
2010/8/13 Trevor Parscaltparscal@wikimedia.org:
This looks very interesting.
- Have you been checking the cleanliness of your diffs?
- It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include "parents" and "joint ventures" in the second paragraph.
- This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz
- What's browsers does this work in?
- What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers.
- What is your Wikitext> HTML / HTML> wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser?
Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community.
- Trevor
On 8/13/10 8:27 AM, William Le Ferrand wrote:
Hi,
I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well.
The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript.
If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project.
All the best,
William
2010/8/13 Павел Петроченкоpavel@onpositive.com:
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченкоpavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkarneilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
> Hi guys, > > At the moment we are discussing an opportunity to create full scale > true WYSIWYG client for media wiki. To the moment we have a technology > which should allow us to implement with a good quality and quite fast. > Unfortunately we are not sure > if there is a real need/interest for having such kind of client at the > media wiki world, as well as what are actual needs of media wiki > users. > Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki > http://www.screencast.com/t/MDkzYzM4 > That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (|neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/8/13 Trevor Parscal tparscal@wikimedia.org:
I'm not an OCaml programmer, so I'd likely be useless in giving input - but open-sourcing it and putting the code in a repository is always a good way to find people who are and to get them involved.
Particularly with such a desirable functionality as this.
- d.
2010/8/13 William Le Ferrand william@corefarm.com:
- No, I haven't check that. It is a very important issue, but if the
current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue.
There is a very fundamental issue with converting wikitext to HTML, then back, which is that there are multiple wikitext alternatives that produce the same HTML: [[Foo]] and [[Foo|Foo]] for instance. Earlier versions of FCKeditor used to 'normalize' all links looking like [[Foo]] to [[Foo|Foo]], which resulted absolutely hideous diffs that were nigh impossible to review because the actual changes got buried in lots of link 'normalizations'. This is what Trevor is talking about when he asks about the "cleanliness of your diffs".
I believe this particular bug was fixed, but the general point stands: you need to somehow remember things about the wikitext that went in in order to have a chance to get it back relatively unscathed. I personally believe that the round-trip approach is fundamentally flawed and that you should have some internal representation (not HTML) closely connected to the wikitext in which you track changes, but that's just my personal conviction and I'm not aware of any successful editors built this way.
Roan Kattouw (Catrope)
Yes, you have a point. The problem is that I wanted to reuse the google closure editor, which manipulates pure html.
Anyway, I've *slightly* cleaned the sources (at least it builds smoothly, with the latest version of the required tools as explained in the README), and it is online at http://github.com/williamleferrand/mediawiki-ocaml-js
If anyone is willing to investigate on my work I'll be pleased to answer all the questions that may occur! I wrote this code primarily as a "proof of concept" for the ocaml to javascript toolchain, but if it can help wikipedia it would be great.
I've included a brief roadmap in the README, but of course it is only what I have in mind right now.
Best,
William
2010/8/13 Roan Kattouw roan.kattouw@gmail.com:
2010/8/13 William Le Ferrand william@corefarm.com:
- No, I haven't check that. It is a very important issue, but if the
current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue.
There is a very fundamental issue with converting wikitext to HTML, then back, which is that there are multiple wikitext alternatives that produce the same HTML: [[Foo]] and [[Foo|Foo]] for instance. Earlier versions of FCKeditor used to 'normalize' all links looking like [[Foo]] to [[Foo|Foo]], which resulted absolutely hideous diffs that were nigh impossible to review because the actual changes got buried in lots of link 'normalizations'. This is what Trevor is talking about when he asks about the "cleanliness of your diffs".
I believe this particular bug was fixed, but the general point stands: you need to somehow remember things about the wikitext that went in in order to have a chance to get it back relatively unscathed. I personally believe that the round-trip approach is fundamentally flawed and that you should have some internal representation (not HTML) closely connected to the wikitext in which you track changes, but that's just my personal conviction and I'm not aware of any successful editors built this way.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org