Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
Greetings, Andre
El 5/7/09 12:18 PM, apri a.vd.wiel escribió:
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
It asks me to install Flash Player 10, then dies when I say no.
-- brion
It needs flash 10.
Andre
Op 7 mei 2009, om 22:11 heeft Brion Vibber het volgende geschreven:
El 5/7/09 12:18 PM, apri a.vd.wiel escribió:
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
It asks me to install Flash Player 10, then dies when I say no.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This means we will probably not see this enabled on WMF sites. Flash is a proprietary format. Forcing users to install this is in conflict with Wikimedia's mission to spread open file formats and software. See also http://en.wikipedia.org/wiki/Adobe_Flash#Disrespecting_freedom_of_the_web
Regards,
ChrisiPK
apri a.vd.wiel schrieb:
It needs flash 10.
Andre
Op 7 mei 2009, om 22:11 heeft Brion Vibber het volgende geschreven:
El 5/7/09 12:18 PM, apri a.vd.wiel escribió:
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
It asks me to install Flash Player 10, then dies when I say no.
-- brion
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
2009/5/8 ChrisiPK chrisipk@gmail.com:
This means we will probably not see this enabled on WMF sites. Flash is a proprietary format. Forcing users to install this is in conflict with Wikimedia's mission to spread open file formats and software. See also http://en.wikipedia.org/wiki/Adobe_Flash#Disrespecting_freedom_of_the_web
Yes, but (a) other MediaWiki sites welcome Flash (b) it's interesting as an example implementation of WYSIWYG, as we try to crack the problem.
Given (a), mediawiki-l is probably the list for it.
- d.
Ok. options: a. we wait for Adobe to make this format opensource ;-) b. we let the end-user chose (no forcing). I know still in conflict with the mission but....
This example/prototype wiki editor is developed in a way that makes integration with MW sites easy. It can be used by ' simple' wikiusers and wiki-language experts so it will be used I think. When the editor component has enough functionality and is stable enough, it can be integrated in some kind of wikiclient / desktop application. And as you can guess a lot of RIA functionality will then be available. Then no forcing and relative independent from MW development.
I am floating on my dream and still see beautifull things in the near future......
Thanks for your reactions. Andre
Op 8 mei 2009, om 11:35 heeft David Gerard het volgende geschreven:
2009/5/8 ChrisiPK chrisipk@gmail.com:
This means we will probably not see this enabled on WMF sites. Flash is a proprietary format. Forcing users to install this is in conflict with Wikimedia's mission to spread open file formats and software. See also http://en.wikipedia.org/wiki/Adobe_Flash#Disrespecting_freedom_of_the_web
Yes, but (a) other MediaWiki sites welcome Flash (b) it's interesting as an example implementation of WYSIWYG, as we try to crack the problem.
Given (a), mediawiki-l is probably the list for it.
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 13:20, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
Ok. options: a. we wait for Adobe to make this format opensource ;-)
That's the only option, and it must be not just opensource, but Free. The source must be Free, the spec must be Free, the patents must not be a burden, etc.
Maybe you could try making it work with some of the free Flash players, such as Gnash or Swfdec.
There's a good reason for making WMF projects accept only OGG and not MP3, for example.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't think making it work with free flash players is an option. Just like MP3, free software is able to play it, but the format itself is not free and will thus not be used by the WMF.
Regards,
ChrisiPK
Amir Elisha Aharoni schrieb:
On Fri, May 8, 2009 at 13:20, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
Ok. options: a. we wait for Adobe to make this format opensource ;-)
That's the only option, and it must be not just opensource, but Free. The source must be Free, the spec must be Free, the patents must not be a burden, etc.
Maybe you could try making it work with some of the free Flash players, such as Gnash or Swfdec.
There's a good reason for making WMF projects accept only OGG and not MP3, for example.
On Fri, May 8, 2009 at 9:00 AM, ChrisiPK chrisipk@gmail.com wrote:
I don't think making it work with free flash players is an option. Just like MP3, free software is able to play it, but the format itself is not free and will thus not be used by the WMF.
The problem with MP3 is it's patent-encumbered. Is Flash patented? The only objections I've heard to it are that there are no decent free players, so it's not possible to run most Flash on a free software stack. If pains were taken to ensure that the Flash worked with gnash, I don't think there would be a problem.
from the Adobe site http://www.adobe.com/devnet/swf/: SWF File Format Specification (Version 10) The SWF file format is available as an open specification to create products and technology that implement the specification.
This looks like MW can use flash 10 and its swf format. I asked Adobe about this question. I let you know what there answere is.
Andre
Op 8 mei 2009, om 15:11 heeft Aryeh Gregor het volgende geschreven:
On Fri, May 8, 2009 at 9:00 AM, ChrisiPK chrisipk@gmail.com wrote:
I don't think making it work with free flash players is an option. Just like MP3, free software is able to play it, but the format itself is not free and will thus not be used by the WMF.
The problem with MP3 is it's patent-encumbered. Is Flash patented? The only objections I've heard to it are that there are no decent free players, so it's not possible to run most Flash on a free software stack. If pains were taken to ensure that the Flash worked with gnash, I don't think there would be a problem.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 12:35 PM, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
from the Adobe site http://www.adobe.com/devnet/swf/: SWF File Format Specification (Version 10) The SWF file format is available as an open specification to create products and technology that implement the specification.
"Open" in their parlance does not mean "not encumbered by patents". Adobe also considers PDF an "open" standard despite significant parts that are patent-encumbered. In principle, patent-encumbered PDFs should not be allowed on Wikimedia (although we lack the technical ability to easily filter them at present).
Don't mistake marketing claims for reality.
This looks like MW can use flash 10 and its swf format. I asked Adobe about this question. I let you know what there answere is.
We are legally permitted to use the format. That doesn't mean we want to.
On Fri, May 8, 2009 at 19:39, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
This looks like MW can use flash 10 and its swf format. I asked Adobe about this question. I let you know what there answere is.
I am not a lawyer and I am not speaking on behalf of MediaWiki developers or the WMF, but there's a simple practical problem: the format may be open, but if you cannot actually use this WYSIWYG editor with nothing but Free Software, then it cannot be on a WMF project. Flash 10 is not Free Software. If this editor will work with an appropriately Free Flash player, such as Gnash or swfdec, then it can be considered to be included in a WMF project. Is this right?
There is nothing bad about the flash format. If it works in a free player I'm not aware of any other objections.
On Fri, May 8, 2009 at 11:19 AM, Amir Elisha Aharoni <amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 19:39, Aryeh Gregor <Simetrical+wikilist@gmail.com Simetrical%2Bwikilist@gmail.com> wrote:
This looks like MW can use flash 10 and its swf format. I asked Adobe about this question. I let you know what there answere is.
I am not a lawyer and I am not speaking on behalf of MediaWiki developers or the WMF, but there's a simple practical problem: the format may be open, but if you cannot actually use this WYSIWYG editor with nothing but Free Software, then it cannot be on a WMF project. Flash 10 is not Free Software. If this editor will work with an appropriately Free Flash player, such as Gnash or swfdec, then it can be considered to be included in a WMF project. Is this right?
-- Amir E. Aharoni
heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com
"We're living in pieces, I want to live in peace." - T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 20:26, Brian Brian.Mingus@colorado.edu wrote:
There is nothing bad about the flash format. If it works in a free player I'm not aware of any other objections.
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free. This may not seem relevant to users, but people need to have a reasonable way to use a program without being deprived of Freedoms #1 and #3 of Free Software. (See [[Free_software#Definition]] in Wikipedia.)
On Fri, May 8, 2009 at 1:43 PM, Amir Elisha Aharoni amir.aharoni@gmail.com wrote:
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free.
So you can't do stuff acceptably in ordinary text editors here? If not, then yeah, it wouldn't be a really free format regardless. Better to make it JavaScript with contenteditable -- that's what most existing solutions do, AFAIK. Or you could write it in Java. Flash, probably not. Although non-Wikimedia sites might still want to use it, of course.
Are you really addressing a deficit in Gnash, or some hypothetical situation?
On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni <amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 20:26, Brian Brian.Mingus@colorado.edu wrote:
There is nothing bad about the flash format. If it works in a free player I'm not aware of any other objections.
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free. This may not seem relevant to users, but people need to have a reasonable way to use a program without being deprived of Freedoms #1 and #3 of Free Software. (See [[Free_software#Definition]] in Wikipedia.)
-- Amir E. Aharoni
heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com
"We're living in pieces, I want to live in peace." - T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 21:11, Brian Brian.Mingus@colorado.edu wrote:
On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni <amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 20:26, Brian Brian.Mingus@colorado.edu wrote:
There is nothing bad about the flash format. If it works in a free player I'm not aware of any other objections.
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free. This may not seem relevant to users, but people need to have a reasonable way to use a program without being deprived of Freedoms #1 and #3 of Free Software. (See [[Free_software#Definition]] in Wikipedia.)
Are you really addressing a deficit in Gnash, or some hypothetical situation?
Gnash is a *player*, a Free replacement for Adobe Flash *Player*. It works pretty well as a player, but it is not supposed to be an authoring tool.
There are certain Free Flash authoring tools, but to the best of my knowledge there is no complete replacement for Adobe Flash, the authoring tool.
Ok, but is there one that supports the features found in Gnash? Isn't flash a language specification, and doesn't Gnash have an emacs mode?
On Fri, May 8, 2009 at 12:21 PM, Amir Elisha Aharoni <amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 21:11, Brian Brian.Mingus@colorado.edu wrote:
On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni <
amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 20:26, Brian Brian.Mingus@colorado.edu wrote:
There is nothing bad about the flash format. If it works in a free
player
I'm not aware of any other objections.
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free. This may not seem relevant to users, but people need to have a reasonable way to use a program without being deprived of Freedoms #1 and #3 of Free Software. (See [[Free_software#Definition]] in Wikipedia.)
Are you really addressing a deficit in Gnash, or some hypothetical situation?
Gnash is a *player*, a Free replacement for Adobe Flash *Player*. It works pretty well as a player, but it is not supposed to be an authoring tool.
There are certain Free Flash authoring tools, but to the best of my knowledge there is no complete replacement for Adobe Flash, the authoring tool.
-- אמיר אלישע אהרוני
heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com
"We're living in pieces, I want to live in peace." - T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I am confused.
- swf format is not a problem - flex application is not a problem, there is a open source flex sdk. all source is editable with texteditor (flex:mx and actionscript)
problems(?): - runtime plugin must be free (flash 10 is) and must be open so it can be modified? (can we modify IE?) - flex compiler must be free (the sdk is) and must be open so it can be modified? (can we modify javac?) - patents are a problem?
I am also not a license expert, i like to create a great application . If the MediaWiki organisation can give me a clear yes or no to use flex/swf in MW I would be very pleased. If not, I have to change my plans.
Greetings, Andre
Op 8 mei 2009, om 20:25 heeft Brian het volgende geschreven:
Ok, but is there one that supports the features found in Gnash? Isn't flash a language specification, and doesn't Gnash have an emacs mode?
On Fri, May 8, 2009 at 12:21 PM, Amir Elisha Aharoni <amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 21:11, Brian Brian.Mingus@colorado.edu wrote:
On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni <
amir.aharoni@gmail.com
wrote:
On Fri, May 8, 2009 at 20:26, Brian Brian.Mingus@colorado.edu wrote:
There is nothing bad about the flash format. If it works in a free
player
I'm not aware of any other objections.
*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free. This may not seem relevant to users, but people need to have a reasonable way to use a program without being deprived of Freedoms #1 and #3 of Free Software. (See [[Free_software#Definition]] in Wikipedia.)
Are you really addressing a deficit in Gnash, or some hypothetical situation?
Gnash is a *player*, a Free replacement for Adobe Flash *Player*. It works pretty well as a player, but it is not supposed to be an authoring tool.
There are certain Free Flash authoring tools, but to the best of my knowledge there is no complete replacement for Adobe Flash, the authoring tool.
-- אמיר אלישע אהרוני
heb: http://haharoni.wordpress.com | eng: http:// aharoni.wordpress.com cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com
"We're living in pieces, I want to live in peace." - T. Moore
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
On Thu, May 7, 2009 at 3:18 PM, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
Greetings, Andre
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have flash player installed, and I didn't understand what to do. I saw a few boxes to the left and right, but nothing in them made sense. I pressed add a link, but I didn't see any way to control the target of the link or what the link text says.
-Chad
As I mentioned this is a prototype. UI has to be redesigned but what you see (better: what you will see) at the left are the properties of the tags/text which are focused. This will be the place to fill in the url property of the link tag.
At the right you will find the actions you can do on the selection in the text.
Andre
Op 7 mei 2009, om 22:35 heeft Chad het volgende geschreven:
On Thu, May 7, 2009 at 3:18 PM, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
Greetings, Andre
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have flash player installed, and I didn't understand what to do. I saw a few boxes to the left and right, but nothing in them made sense. I pressed add a link, but I didn't see any way to control the target of the link or what the link text says.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'd just like to get this thread back on track with a couple notes.
1) Wikimedia will not be interested in an editing widget based entirely on Flash.
2) If someone wants to make their own, hey have fun! That's cool. Try to keep list discussion about it on-topic and productive.
3) General issues with Flash and Wikimedia's software freedom demands have previously been discussed. We're not against using it in limited ways with graceful degradation as a fallback alternative to other web standard technologies, so long as no patent-encumbered formats are involved.
If folks are interested in further general discussion about how free Flash or Flash authoring are or aren't, please feel free to take it off-list.
-- brion
Flash has a lot going for it. It could be that because flash makes it so easy to create usable, good looking interfaces that it is in fact the ideal testbed for interface prototypes. I'd be curious to see the rationale on which it has been rejected, and why it won't be given a fair chance next to other technologies.
On Fri, May 8, 2009 at 12:39 PM, Brion Vibber brion@wikimedia.org wrote:
I'd just like to get this thread back on track with a couple notes.
- Wikimedia will not be interested in an editing widget based entirely
on Flash.
- If someone wants to make their own, hey have fun! That's cool. Try to
keep list discussion about it on-topic and productive.
- General issues with Flash and Wikimedia's software freedom demands
have previously been discussed. We're not against using it in limited ways with graceful degradation as a fallback alternative to other web standard technologies, so long as no patent-encumbered formats are involved.
If folks are interested in further general discussion about how free Flash or Flash authoring are or aren't, please feel free to take it off-list.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
El 5/8/09 11:48 PM, Brian escribió:
Flash has a lot going for it. It could be that because flash makes it so easy to create usable, good looking interfaces that it is in fact the ideal testbed for interface prototypes. I'd be curious to see the rationale on which it has been rejected, and why it won't be given a fair chance next to other technologies.
If you're creating a huge giant UI in Flash, it'll take a lot of extra work to duplicate an entire second version in cross-platform high-functioning web standards, and maintain both versions. If you've only programmed a Flash version, then when Flash isn't available, you've got nothing.
That's not very nice for something we'd want to ship. :) Hence, we're most interested in Flash for small pieces which degrade gracefully, not an entire page editing widget.
But as I said, third parties are more than welcome to use whatever they like for their own development. If the result is interesting, we'd be happy to learn lessons on UI and workflow from it, but we'd never use it directly.
-- brion
This is clear to me. Thank you all for your contribiutions. I continue developing this FLEX application and hope that I can give you an update real soon.
Greetings and succes, Andre
Op 8 mei 2009, om 20:53 heeft Brion Vibber het volgende geschreven:
El 5/8/09 11:48 PM, Brian escribió:
Flash has a lot going for it. It could be that because flash makes it so easy to create usable, good looking interfaces that it is in fact the ideal testbed for interface prototypes. I'd be curious to see the rationale on which it has been rejected, and why it won't be given a fair chance next to other technologies.
If you're creating a huge giant UI in Flash, it'll take a lot of extra work to duplicate an entire second version in cross-platform high-functioning web standards, and maintain both versions. If you've only programmed a Flash version, then when Flash isn't available, you've got nothing.
That's not very nice for something we'd want to ship. :) Hence, we're most interested in Flash for small pieces which degrade gracefully, not an entire page editing widget.
But as I said, third parties are more than welcome to use whatever they like for their own development. If the result is interesting, we'd be happy to learn lessons on UI and workflow from it, but we'd never use it directly.
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, May 8, 2009 at 2:39 PM, Brion Vibber brion@wikimedia.org wrote:
I'd just like to get this thread back on track with a couple notes.
- Wikimedia will not be interested in an editing widget based entirely
on Flash.
Even if it's designed to work perfectly in gnash?
The answer is no if I may speak for mediawiki. for example the gnash is only usable with mozilla derived browsers.
Andre
Op 8 mei 2009, om 21:28 heeft Aryeh Gregor het volgende geschreven:
On Fri, May 8, 2009 at 2:39 PM, Brion Vibber brion@wikimedia.org wrote:
I'd just like to get this thread back on track with a couple notes.
- Wikimedia will not be interested in an editing widget based
entirely on Flash.
Even if it's designed to work perfectly in gnash?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
El 5/8/09 12:28 PM, Aryeh Gregor escribió:
On Fri, May 8, 2009 at 2:39 PM, Brion Vibberbrion@wikimedia.org wrote:
I'd just like to get this thread back on track with a couple notes.
- Wikimedia will not be interested in an editing widget based entirely
on Flash.
Even if it's designed to work perfectly in gnash?
It still wouldn't work on platforms that lack any form of Flash, Gnash, etc. Like, say, embedded web browsers where you've got no way to install some third-party plugin.
Our primary commitment will always be to have as much functionality as possible working with core web standards.
-- brion
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:BAD0867F-8787-445D-BB83-5D9A0D025937@apri.nl...
Hello to all,
I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality.
Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.
I'd be interested to see how far you get with this. The problem is not the interface - that is relatively easy even using HTML/JS, so creating a slick interface in Flash should be trivial. The problem is in correctly handling the more complicated elements of the wikitext markup, and round-tripping between your internal representation and that markup without losing information.
If I were you, I would concentrate on that firstly, and then work on the editing UI, otherwise you'll end up with something that looks good and works nicely for simple pages, but is too dangerous to deploy as it risks messing up anything more sophisticated. Here are some of the trickier elements for you to look into so you don't end up just wasting your time (in no particular order):
* Tables * Template inclusion * Parser functions * Magic words (including ISBN, etc.) * Comments * Category links * Extension-supplied HTML-style tags.
For a relatively complete list, and some exploration of the problems, see http://www.mediawiki.org/wiki/Markup_spec.
- Mark Clements (HappyDog)
Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.
Application acts now as an addon to the standard MW functionality. It reads the textarea in the html given by MW editpage, returns again wikitext to this textarea after editing and save to wikitext button. The base functionality of MW stays intact. Template inclusion for example, will need some more conversation between the editor and the MWserver but again this must be possible. Properties for semantic mediawiki inline queries can be made more userfriendly by directly showing results (or errors), etc..
It is exciting to see how easy it is to add new alike elements but also a big challenge to fit in new ones in a way that is flexible and reusable. It is this combination that gives me the pleasure doing this thing. I like this manner of developing. Discovering the posibilities of new technics like Flex. It must be a combination of building the engine and making the chairs comfortable.
Right now I am wrestling with fonts in Flex/TLF for a good presentation. After that I switch back to the engine.
Thanks for your reaction. Andre
Op 11 mei 2009, om 12:04 heeft Mark Clements (HappyDog) het volgende geschreven:
'd be interested to see how far you get with this. The problem is not the interface - that is relatively easy even using HTML/JS, so creating a slick interface in Flash should be trivial. The problem is in correctly handling the more complicated elements of the wikitext markup, and round- tripping between your internal representation and that markup without losing information.
If I were you, I would concentrate on that firstly, and then work on the editing UI, otherwise you'll end up with something that looks good and works nicely for simple pages, but is too dangerous to deploy as it risks messing up anything more sophisticated. Here are some of the trickier elements for you to look into so you don't end up just wasting your time (in no particular order):
- Tables
- Template inclusion
- Parser functions
- Magic words (including ISBN, etc.)
- Comments
- Category links
- Extension-supplied HTML-style tags.
For a relatively complete list, and some exploration of the problems, see http://www.mediawiki.org/wiki/Markup_spec.
- Mark Clements (HappyDog)
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:E7EEBF75-8452-48BB-8479-DB449AABA507@apri.nl...
Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.
Good idea in principle. Currently doesn't cleanly round-trip, e.g.
http://ria.apri.nl/mediawiki-1.14.0/index.php?title=Main_Page&action=edi...
(compare text in standard edit box before and after clicking 'save to wikitext').
This is the kind of thing I'm talking about... :-)
- Mark Clements (HappyDog)
Yes, I did see this. Template is not configured yet. I did configure swm ask wich has the same end tag ' }}'. A bug wich I will correct in the engine. Comment configuration is easy but howto present in wysiwg? Hidden property? Do you have an idea?
My plan is to make a testapplication which calls the editcomponent for different wikitext files and compares the result with goodresult- files. One push on the button will give the answer if changes is the engine are ok.
Andre
Op 11 mei 2009, om 14:30 heeft Mark Clements (HappyDog) het volgende geschreven:
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:E7EEBF75-8452-48BB-8479-DB449AABA507@apri.nl...
Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.
Good idea in principle. Currently doesn't cleanly round-trip, e.g.
http://ria.apri.nl/mediawiki-1.14.0/index.php?title=Main_Page&action=edi...
(compare text in standard edit box before and after clicking 'save to wikitext').
This is the kind of thing I'm talking about... :-)
- Mark Clements (HappyDog)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
comments and template added. single ''' gives error : more or less the same bug as mentioned before with smw ask. Some engine work to do ;-)
'''how about ''this edit'''s more complicated bold/italic markup?''' Do you think MW gives the right result? MW: 'how about this edits more complicated bold/italic markup? Apri: how about this edits more complicated bold/italic markup? should be (I think): how about this edit's more complicated bold/ italic markup?
Andre
Op 11 mei 2009, om 14:52 heeft apri a.vd.wiel het volgende geschreven:
Yes, I did see this. Template is not configured yet. I did configure swm ask wich has the same end tag ' }}'. A bug wich I will correct in the engine. Comment configuration is easy but howto present in wysiwg? Hidden property? Do you have an idea?
My plan is to make a testapplication which calls the editcomponent for different wikitext files and compares the result with goodresult- files. One push on the button will give the answer if changes is the engine are ok.
Andre
Op 11 mei 2009, om 14:30 heeft Mark Clements (HappyDog) het volgende geschreven:
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:E7EEBF75-8452-48BB-8479-DB449AABA507@apri.nl...
Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.
Good idea in principle. Currently doesn't cleanly round-trip, e.g.
http://ria.apri.nl/mediawiki-1.14.0/index.php?title=Main_Page&action=edi...
(compare text in standard edit box before and after clicking 'save to wikitext').
This is the kind of thing I'm talking about... :-)
- Mark Clements (HappyDog)
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
I see there is no formating (bold and italic) in the message. But for this case my conclusion is: MW formatting is (also) not correct. The markup spec says: Note that improper nesting of bold and italics is currently permitted. Which means that the formatting can't be correct in all cases. The markup spec must be more strict.
Andre
Op 11 mei 2009, om 16:42 heeft apri a.vd.wiel het volgende geschreven:
comments and template added. single ''' gives error : more or less the same bug as mentioned before with smw ask. Some engine work to do ;-)
'''how about ''this edit'''s more complicated bold/italic markup?''' Do you think MW gives the right result? MW: 'how about this edits more complicated bold/italic markup? Apri: how about this edits more complicated bold/italic markup? should be (I think): how about this edit's more complicated bold/ italic markup?
Andre
Op 11 mei 2009, om 14:52 heeft apri a.vd.wiel het volgende geschreven:
Yes, I did see this. Template is not configured yet. I did configure swm ask wich has the same end tag ' }}'. A bug wich I will correct in the engine. Comment configuration is easy but howto present in wysiwg? Hidden property? Do you have an idea?
My plan is to make a testapplication which calls the editcomponent for different wikitext files and compares the result with goodresult- files. One push on the button will give the answer if changes is the engine are ok.
Andre
Op 11 mei 2009, om 14:30 heeft Mark Clements (HappyDog) het volgende geschreven:
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:E7EEBF75-8452-48BB-8479-DB449AABA507@apri.nl...
Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.
Good idea in principle. Currently doesn't cleanly round-trip, e.g.
http://ria.apri.nl/mediawiki-1.14.0/index.php?title=Main_Page&action=edi...
(compare text in standard edit box before and after clicking 'save to wikitext').
This is the kind of thing I'm talking about... :-)
- Mark Clements (HappyDog)
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, May 11, 2009 at 10:54 AM, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
I see there is no formating (bold and italic) in the message. But for this case my conclusion is: MW formatting is (also) not correct. The markup spec says: Note that improper nesting of bold and italics is currently permitted. Which means that the formatting can't be correct in all cases. The markup spec must be more strict.
There is no spec. It's "whatever Parser.php does". The current behavior cannot be easily changed to simplify the markup for third parties, because that would break some unknown percentage of the literally billions of old revisions that have accumulated in the last seven years across countless thousands of MediaWiki installations. Wikimedia alone is likely somewhere over a billion revisions. So you probably have to reimplement Parser.php more or less line-by-line in your language of choice if you want it to work reliably. That's why there's not already an official WYSIWYG editor packaged by default.
apri a.vd.wiel schrieb:
I see there is no formating (bold and italic) in the message. But for this case my conclusion is: MW formatting is (also) not correct. The markup spec says: Note that improper nesting of bold and italics is currently permitted. Which means that the formatting can't be correct in all cases. The markup spec must be more strict.
Andre
There is no "incorrect" in wikitext. any input is valid wikitext. and in the absense of a formal specification, the correct behaviour is, per definition, whatever mediawiki's parser does.
You are only scratching the surface of the pain that parsing wikitext is. There have been several attempts of formalizing it, and all failed at some point - among other reasons, because the parsing depends on localization, configuration settings, database content, and the phase of the moon.
Basically, this is the reason why there is no really good WYSIWYG editor for MediaWiki. I don't want to discurage you, I just want to point out where the problems are. Some examples: the closing }} of a template may actually be contained in the definition of another template, same with thables. I have seen |} being replaced by something like {{TableEnd}}. Lots of fun there.
Also, you can nest images into the caption section of image links (but not regular links). Detecting what an image link is requires you to know all aliases of the image namespace (that would be four names on most installations)...
Anhyway, did you look at http://www.mediawiki.org/wiki/Markup_spec ? That's the best we have in terms of a formal spec. And it'S incomplete and abandoned.
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
-- daniel
Thanks you all for your thoughts. Helps me great to make up my mind about all kinds of things.
I realize that there is more than one person can oversee. I also have much respect for what mediawiki stands for and where they are now. My thoughts: If there is a way out, it must be via standardization.
I also realize that my contribution to this list ends here. If I have other ideas to overcome this problem I let you know ;-) Thanks for your attention and contributions.
Andre
Op 11 mei 2009, om 17:05 heeft Daniel Kinzler het volgende geschreven:
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
On Mon, May 11, 2009 at 5:05 PM, Daniel Kinzler daniel@brightbyte.dewrote:
Basically, this is the reason why there is no really good WYSIWYG editor for MediaWiki. I don't want to discurage you, I just want to point out where the problems are. Some examples: the closing }} of a template may actually be contained in the definition of another template, same with thables. I have seen |} being replaced by something like {{TableEnd}}. Lots of fun there.
Also there are people who use date/time to switch between template contents... it's really funny how people can use something like the MW markup - they end literally there where no man eh coder has been before.
Marco
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-)
On Mon, May 11, 2009 at 8:50 PM, Daniel Schwen lists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Sounds cool, but it'd require a formalization of MW markup first (something that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions?
Marco
On 5/11/09 11:54 AM, Marco Schuster wrote:
On Mon, May 11, 2009 at 8:50 PM, Daniel Schwenlists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Sounds cool, but it'd require a formalization of MW markup first (something that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions?
Marco
During the Berlin conference, a very popular and passionate topic of conversation was the need for better testing of MediaWiki. However, if we can't define what it's supposed to do, how can we test it. Last I heard the parser has yet to pass all of the unit-tests written for it, which aren't even very robust. so the concept of the parser's behavior being it's own documentation is clearly conflicting with good software development practices. This said, any changes to the parser cause a risk of breaking old, or even current revisions of articles, which is I've noticed to generally be seen as unacceptable. So - this topic is probably a justifiably touchy one for those involved in working on this software since there's no really elegant solution and lots of complaints.
Seems like there's been some general talk about this idea...
* Link a revision to a version of the parser * Allow multiple parser versions to co-exist * Provide an upgrade path for revisions to be brought into compatibility with a more modern parser
Nothing about this sounds easy, but if we ever want to improve MW markup or parser behavior we will need to do something. Is there any support / criticism for this direction? I'm very curious what other potential directions could be taken which could also result in:
* The parser's behavior being a reflection of a well-documented standard * Ability to make changes to MW markup standards over time without abandoning old revisions
- Trevor
I thought it was generally agreed upon that the path to fix the parser goes something like this:
* Define a new wiki language that is compatible with bison/flex * Write a converter between the old language and the new (when possible) * Implement per-revision parsers * Implement the new parser * Begin the migration
On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
On 5/11/09 11:54 AM, Marco Schuster wrote:
On Mon, May 11, 2009 at 8:50 PM, Daniel Schwenlists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new
parser
the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Sounds cool, but it'd require a formalization of MW markup first
(something
that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions?
Marco
During the Berlin conference, a very popular and passionate topic of conversation was the need for better testing of MediaWiki. However, if we can't define what it's supposed to do, how can we test it. Last I heard the parser has yet to pass all of the unit-tests written for it, which aren't even very robust. so the concept of the parser's behavior being it's own documentation is clearly conflicting with good software development practices. This said, any changes to the parser cause a risk of breaking old, or even current revisions of articles, which is I've noticed to generally be seen as unacceptable. So - this topic is probably a justifiably touchy one for those involved in working on this software since there's no really elegant solution and lots of complaints.
Seems like there's been some general talk about this idea...
- Link a revision to a version of the parser
- Allow multiple parser versions to co-exist
- Provide an upgrade path for revisions to be brought into compatibility
with a more modern parser
Nothing about this sounds easy, but if we ever want to improve MW markup or parser behavior we will need to do something. Is there any support / criticism for this direction? I'm very curious what other potential directions could be taken which could also result in:
- The parser's behavior being a reflection of a well-documented standard
- Ability to make changes to MW markup standards over time without
abandoning old revisions
- Trevor
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
See also:
http://www.mediawiki.org/wiki/One-pass_parser http://www.mediawiki.org/wiki/Alternative_parsers
On Mon, May 11, 2009 at 1:22 PM, Brian Brian.Mingus@colorado.edu wrote:
I thought it was generally agreed upon that the path to fix the parser goes something like this:
- Define a new wiki language that is compatible with bison/flex
- Write a converter between the old language and the new (when possible)
- Implement per-revision parsers
- Implement the new parser
- Begin the migration
On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
On 5/11/09 11:54 AM, Marco Schuster wrote:
On Mon, May 11, 2009 at 8:50 PM, Daniel Schwenlists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field
to
the revision table, drag the old parser along as 'legacy', make the new
parser
the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you
be
made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Sounds cool, but it'd require a formalization of MW markup first
(something
that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions?
Marco
During the Berlin conference, a very popular and passionate topic of conversation was the need for better testing of MediaWiki. However, if we can't define what it's supposed to do, how can we test it. Last I heard the parser has yet to pass all of the unit-tests written for it, which aren't even very robust. so the concept of the parser's behavior being it's own documentation is clearly conflicting with good software development practices. This said, any changes to the parser cause a risk of breaking old, or even current revisions of articles, which is I've noticed to generally be seen as unacceptable. So - this topic is probably a justifiably touchy one for those involved in working on this software since there's no really elegant solution and lots of complaints.
Seems like there's been some general talk about this idea...
- Link a revision to a version of the parser
- Allow multiple parser versions to co-exist
- Provide an upgrade path for revisions to be brought into compatibility
with a more modern parser
Nothing about this sounds easy, but if we ever want to improve MW markup or parser behavior we will need to do something. Is there any support / criticism for this direction? I'm very curious what other potential directions could be taken which could also result in:
- The parser's behavior being a reflection of a well-documented standard
- Ability to make changes to MW markup standards over time without
abandoning old revisions
- Trevor
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Just my thoughts: in case of a new wiki language: make use of ODF and integrate OpenOffice with MW.
I see somekind of agreement in the reactions, thats a start. :-)
Andre
Brian schreef:
I thought it was generally agreed upon that the path to fix the parser goes something like this:
- Define a new wiki language that is compatible with bison/flex
- Write a converter between the old language and the new (when possible)
- Implement per-revision parsers
- Implement the new parser
- Begin the migration
On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
On 5/11/09 11:54 AM, Marco Schuster wrote:
On Mon, May 11, 2009 at 8:50 PM, Daniel Schwenlists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new
parser
the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Sounds cool, but it'd require a formalization of MW markup first
(something
that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions?
Marco
During the Berlin conference, a very popular and passionate topic of conversation was the need for better testing of MediaWiki. However, if we can't define what it's supposed to do, how can we test it. Last I heard the parser has yet to pass all of the unit-tests written for it, which aren't even very robust. so the concept of the parser's behavior being it's own documentation is clearly conflicting with good software development practices. This said, any changes to the parser cause a risk of breaking old, or even current revisions of articles, which is I've noticed to generally be seen as unacceptable. So - this topic is probably a justifiably touchy one for those involved in working on this software since there's no really elegant solution and lots of complaints.
Seems like there's been some general talk about this idea...
- Link a revision to a version of the parser
- Allow multiple parser versions to co-exist
- Provide an upgrade path for revisions to be brought into compatibility
with a more modern parser
Nothing about this sounds easy, but if we ever want to improve MW markup or parser behavior we will need to do something. Is there any support / criticism for this direction? I'm very curious what other potential directions could be taken which could also result in:
- The parser's behavior being a reflection of a well-documented standard
- Ability to make changes to MW markup standards over time without
abandoning old revisions
- Trevor
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
2009/5/11 Daniel Schwen lists@schwen.de:
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-)
Actually, this makes sense, and I've heard a very similar suggestion from another developer (I believe it was Tim, not sure) at the Berlin meet-up.
Roan Kattouw (Catrope)
Roan Kattouw schrieb:
2009/5/11 Daniel Schwen lists@schwen.de:
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-)
Actually, this makes sense, and I've heard a very similar suggestion from another developer (I believe it was Tim, not sure) at the Berlin meet-up.
Yes, if we ever want to get out of this mess, that is the way to go. The problem I see is: if we try to come up with a formalization that removes all the brokennes, we will have discussions about that to now end. Because the nicer we want the spec to be, the more stuff we have to break.
My pet peve: marcup parts comminf from templates, like |} from {{TableEnd}} or whatever. Or | from {{!}}. Getting rid of that means rewriting a lot of templates and fixing a lot of pages...
Anyway - if we seriously want to do this, there should be at least one person working on it full time, to keep things together. And pull it through. Then we have a chance.
-- daniel
El 5/11/09 12:17 PM, Daniel Kinzler escribió:
Yes, if we ever want to get out of this mess, that is the way to go. The problem I see is: if we try to come up with a formalization that removes all the brokennes, we will have discussions about that to now end. Because the nicer we want the spec to be, the more stuff we have to break.
My pet peve: marcup parts comminf from templates, like |} from {{TableEnd}} or whatever. Or | from {{!}}. Getting rid of that means rewriting a lot of templates and fixing a lot of pages...
Anyway - if we seriously want to do this, there should be at least one person working on it full time, to keep things together. And pull it through. Then we have a chance.
I think we need a clearer idea of how such fancy templates can be restructured in a more clear definition language; this should be something we'll start to learn as we work on template-editing tools to integrate into the UI.
Why hello there, usability team. :)
-- brion
you have my vote. But still first make standard spec say WikiText 2010, second make parserWT2010. and after that: xml-ize backend; api-standards;conversion-tools; wysiwyg editor(s);ria-wikiclients;...
lots of work todo ;-)
Andre
Daniel Schwen schreef:
This sucks, but in the four years we have spend talking abotu it, no one found a way out that will not break a few million existing wiki pages.
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.
Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-)
On Mon, May 11, 2009 at 2:50 PM, Daniel Schwen lists@schwen.de wrote:
The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser.
That would require specifying the new language, getting people to actually agree on it, and writing a parser for it. There doesn't seem to be enough support for such a monumental effort to actually happen.
Cases that break could be detected by comparing tidied HTML output from both parser versions.
And then what would you do? It's unlikely you could fix them all automatically. Of course, these are wikis, so fixing a reasonable number of cases by hand isn't out of the question.
Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-)
It's not dumb, just apparently not considered worth the effort right now by the powers that be (and I tend to agree).
"apri a.vd.wiel" a.vd.wiel@apri.nl wrote in message news:628A0508-2A37-41AA-8CCC-77A2F96DC2FD@apri.nl...
'''how about ''this edit'''s more complicated bold/italic markup?''' Do you think MW gives the right result?
Yes and No. :-)
Yes, because, as others have said, what parser.php does is, by definition 'the right result'. No, because the parser currently behaves inconsistently with this particular phrase (which I have logged as bug 18765 [1]).
- Mark Clements (HappyDog)
wikitech-l@lists.wikimedia.org