Also see the freebase / google acre system inline editor: http://wiki.freebase.com/wiki/Acre
What is more impressive than the online editor, is the template and integrated data query system in an seamless sandboxed server / client javascript system. Its not perfect, but definitely includes some ideas that would be interesting to explore long term.
--michael
On 04/04/2011 10:09 AM, Ryan Kaldari wrote:
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!).
If not, hopefully, I've just created a self-fulfilling rumor :)
Ryan Kaldari
On 4/3/11 11:06 AM, Daniel Kinzler wrote:
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May...
-- daniel
On 03.04.2011 15:30, Sumana Harihareswara wrote:
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two:
http://www.mediawiki.org/wiki/Summer_of_Code_2011
best, Sumana Harihareswara
On 04/01/2011 10:11 PM, Conrad Irwin wrote:
Ok — yes loading speeds are definitely something worth improving.
WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact.
I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :).
Conrad
On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here.
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
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