[MediaWiki-CodeReview] [MediaWiki r87296]: New comment added
User "TheDJ" posted a comment on MediaWiki.r87296. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87296#c16507 Commit summary: * Impove localization. * Add Dutch localization Comment: UTF-16 text files actually, but apparently SVN isn't smart enough for that. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87317]: New comment added
User "Siebrand" posted a comment on MediaWiki.r87317. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87317#c16506 Commit summary: Removed unused messages: 'extremelycomplextest' 'internallinktest' 'linktest' 'magictest' 'mwe-copyright-custom' 'mwe-copyright-macro' 'mwe-loading-upwiz' 'mwe-upwiz-about-format' 'mwe-upwiz-about-this-work' 'mwe-upwiz-add-file-0' 'mwe-upwiz-browse' 'mwe-upwiz-categories-another' 'mwe-upwiz-categories-intro' 'mwe-upwiz-change' 'mwe-upwiz-click-here' 'mwe-upwiz-desc-add-0' 'mwe-upwiz-editing' 'mwe-upwiz-file-need-complete' 'mwe-upwiz-file-need-start' 'mwe-upwiz-filename-tag' 'mwe-upwiz-license' 'mwe-upwiz-license-incompatible-cc' 'mwe-upwiz-license-incompatible-pd' 'mwe-upwiz-license-show-all-any-license' 'mwe-upwiz-macro-edit' 'mwe-upwiz-macro-edit-intro' 'mwe-upwiz-other-prefill' 'mwe-upwiz-showall' 'mwe-upwiz-thanks-link' 'namespacedtest' 'pluraltest' Comment: Thanks for this maintenance, Niel. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87296]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r87296. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87296#c16505 Commit summary: * Impove localization. * Add Dutch localization Comment: Localisation in binary files?? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Bugzilla Weekly Report
Bounces? That is, some return codes from a program delivery can be interpreted as a failed delivery. Or perhaps the program is segfaulting or running out of memory? Or replies sent to the envelope sender, which can be interpreted as bounces, but which lack the empty sender of a real bounce. Ryan Lane wrote: I'd also love to know how it keeps getting unsubscribed. This is the third time... On Mon, May 2, 2011 at 7:03 PM, K. Peachey wrote: > On Tue, May 3, 2011 at 10:05 AM, Happy-melon wrote: >> Wow, now here's a blast from the past... :-D A lot of these stats are now >> in the BZ4 report page, but it's still very nice to have the weekly >> reminder. Cookie for whoever dug it out and got it going again! >> >> --HM > Ryan resubscribed the email address it sends from to the mailing list :p > -Peachey > > ___ > 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
[MediaWiki-CodeReview] [pywikipedia r9196]: Revision status changed
User "Xqt" changed the status of pywikipedia.r9196. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/9196#c0 Commit summary: Allow lists of Page and User objects to be interogated ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Media embedding: oEmbed feedback?
sorry for the re-post ( having trouble with the wikitech-l list post email migration :( I would also be interested in discussing this in Berlin or otherwise ;) I can offer some notes about video embedding inline: On 04/29/2011 03:30 PM, Brion Vibber wrote: >> > > Enhanced media player goodies like embedding have been slowly coming along, >> > > with a handy embedding option now available in the fancy version of the >> > > media player running on Commons. This lets you copy a bit of HTML you can >> > > paste into your blog or other web site to drop in a video and make it >> > > playable -- nice! Some third-party sites will also likely be interested in >> > > standardish ways of embedding offsite videos from Youtube, Vimeo, and other >> > > providers. It appears the iframe embed method is becoming somewhat standardise way to share videos. With Youtube, Vimeo, and others providing it as an option to deliver both flash and html5 players. The bit of HTML that you copy on commons share video function is just an iframe ( similar to those other sites ). Timed Media Handler works the same way using the same url parameter ( embedplayer=yes ) so that we can seamlessly replace the 'fancy media player' rewrite with a similar embed player page delivered by the TMH extension [1] The iframe player lets you sandbox the player when you embed it in foreign domain contexts, and enables you to deliver the interface that includes things like the credits screen that parses our description template page on commons to present credit information and a link back to the description page. As iframe embed is relatively standard, we simply have to request that our domain be white listed for it to be shared on facebook , wordpress etc. In addition to working as a pure iframe without xss javascript, to support mashups like the googles player [2] if you include a bit of JS where you embed the iframe, the mwEmbed player also has an iframe api that lets you use the HTML5 video api on the iframe as if it was a video tag in the page. [3] oEmbed is a nice way to consistently 'discover' embed code and media properties. Its implementation within mediaWiki would be akin to supporting RSS or OpenSearch, so I think its something we should try and do. As the spec currently stands its api for the "embed code" rather than an api for mashups. I think more interesting things could be done in addition to the iframe, object tag and basic metadata ... like giving the urls to all the media files, and urls to all the associated timed text of a given player ... Something like the ROE standard [4] that we ( xiph, annodex ) folks were talking about a while back might be a good direction to extend oEmbed into. ( Although commercial video service sites are not likely to be interested in mash-ups outside of "their player" hence oEmbed leaning toward 'html' to embed the players... direct links to associated media is one of those standard ideas that in theory is good, but does not play well with video service business models ... but that does not have stop us / oEmbed from promoting it :) I would also add the TMH adds a separate api entry point to deliver some of this info such as the urls for all the derivatives related to a particular media title [5]. I would like to add associated timed text listing to that videoinfo prop and from there it should not be hard to adapt that to a ROE or oEmbed v2 type representation. [1] http://prototype.wikimedia.org/timedmedia/Main_Page#Iframe_embed_and_viral_sharing [2] http://code.google.com/apis/youtube/iframe_api_reference.html [3] http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer/resources/iframeApi/ [4] http://wiki.xiph.org/index.php/ROE [5] http://prototype.wikimedia.org/tmh/api.php?action=query&titles=File:Shuttle-flip.webm&prop=videoinfo&viprop=derivatives&format=jsonfm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87308]: New comment added
User "MaxSem" posted a comment on MediaWiki.r87308. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87308#c16504 Commit summary: better language handling - abandon magic language switch in favor of using int:lang as parameter, use parser->getFunctionLang() instead of wgContLanguage in case of use in interface messages Comment: Needs parser tests - I noticed this bug by pure incident. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87292]: New comment added
User "Aaron Schulz" posted a comment on MediaWiki.r87292. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87292#c16503 Commit summary: * (bug 20468) User::invalidateCache throws 1205: Lock wait timeout exceeded Severly limit the number of calls that actually update the database (for no gain!). Leaving stuff that needs to update memcached Still, there's probably quite a lot of these calls which are still superfluous Comment: I'd recommend using a string param like "cacheOnly" rather than an opaque boolean. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Bugzilla Weekly Report
I'd also love to know how it keeps getting unsubscribed. This is the third time... On Mon, May 2, 2011 at 7:03 PM, K. Peachey wrote: > On Tue, May 3, 2011 at 10:05 AM, Happy-melon wrote: >> Wow, now here's a blast from the past... :-D A lot of these stats are now >> in the BZ4 report page, but it's still very nice to have the weekly >> reminder. Cookie for whoever dug it out and got it going again! >> >> --HM > Ryan resubscribed the email address it sends from to the mailing list :p > -Peachey > > ___ > 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
Re: [Wikitech-l] Media embedding: oEmbed feedback?
I would also be interested in discussing this in Berlin or otherwise ;) I can offer some notes about video embedding inline: On 04/29/2011 03:30 PM, Brion Vibber wrote: > > Enhanced media player goodies like embedding have been slowly coming along, > > with a handy embedding option now available in the fancy version of the > > media player running on Commons. This lets you copy a bit of HTML you can > > paste into your blog or other web site to drop in a video and make it > > playable -- nice! Some third-party sites will also likely be interested in > > standardish ways of embedding offsite videos from Youtube, Vimeo, and other > > providers. It appears the iframe embed method is becoming somewhat standardise way to share videos. With Youtube, Vimeo, and others providing it as an option to deliver both flash and html5 players. The bit of HTML that you copy on commons share video function is just an iframe ( similar to thouse other sites ). Timed Media Handler works the same way using the same url parameter ( embedplayer=yes ) so that we can seamlessly replace the 'fancy media player' rewrite with a similar embed player page delivered by the TMH extension [1] The iframe player lets you sandbox the player when you embed it in foreign domain contexts, and enables you to deliver the interface that includes things like the credits screen that parses our description template page on commons to present credit information and a link back to the description page. As iframe embed is relatively standard, we simply have to request that our domain be white listed for it to be shared on facebook , wordpress etc. In addition to working as a pure iframe without xss javascript, to support mashups like the googles player [2] if you include a bit of JS where you embed the iframe, the mwEmbed player also has an iframe api that lets you use the HTML5 video api on the iframe as if it was a video tag in the page. [3] oEmbed is a nice way to consistently 'discover' embed code and media properties. Its implementation within mediaWiki would be akin to supporting RSS or OpenSearch, so I think its something we should try and do. As the spec currently stands its api for the "embed code" rather than an api for mashups. I think more interesting things could be done in addition to the iframe, object tag and basic metadata ... like giving the urls to all the media files, and urls to all the associated timed text of a given player ... Something like the ROE standard [4] that we ( xiph, annodex ) folks were talking about a while back might be a good direction to extend oEmbed into. ( Although commercial video service sites are not likely to be interested in mash-ups outside of "their player" hence oEmbed leaning toward 'html' to embed the players... direct links to associated media is one of those standard ideas that in theory is good, but does not play well with video service business models ... but that does not have stop us / oEmbed from promoting it :) I would also add the TMH adds a separate api entry point to deliver some of this info such as the urls for all the derivatives related to a particular media title [5]. I would like to add associated timed text listing to that videoinfo prop and from there it should not be hard to adapt that to a ROE or oEmbed v2 type representation. [1] http://prototype.wikimedia.org/timedmedia/Main_Page#Iframe_embed_and_viral_sharing [2] http://code.google.com/apis/youtube/iframe_api_reference.html [3] http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer/resources/iframeApi/ [4] http://wiki.xiph.org/index.php/ROE [5] http://prototype.wikimedia.org/tmh/api.php?action=query&titles=File:Shuttle-flip.webm&prop=videoinfo&viprop=derivatives&format=jsonfm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87232]: New comment added
User "Reedy" posted a comment on MediaWiki.r87232. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87232#c16502 Commit summary: Make a method static per the comment, update the only non static usage (in Parser) itself Comment: That's slightly amusing. It had one doing it one way, one the other ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Bugzilla Weekly Report
On Tue, May 3, 2011 at 10:05 AM, Happy-melon wrote: > Wow, now here's a blast from the past... :-D A lot of these stats are now > in the BZ4 report page, but it's still very nice to have the weekly > reminder. Cookie for whoever dug it out and got it going again! > > --HM Ryan resubscribed the email address it sends from to the mailing list :p -Peachey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
"reporter" wrote in message news:e1pprj3-bs...@kaulen.wikimedia.org... > MediaWiki Bugzilla Report for November 29, 2010 - December 06, 2010 ... "reporter" wrote in message news:e1qgwls-000389...@kaulen.wikimedia.org... > MediaWiki Bugzilla Report for April 25, 2011 - May 02, 2011 > Wow, now here's a blast from the past... :-D A lot of these stats are now in the BZ4 report page, but it's still very nice to have the weekly reminder. Cookie for whoever dug it out and got it going again! --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 5:55 PM, Brion Vibber wrote: > On Mon, May 2, 2011 at 5:28 PM, Tim Starling wrote: > >> I don't think that's a fundamental problem, I think it's a quick hack >> added to reduce the development time devoted to rare wikitext >> constructs, while maintaining round-trip safety. Like you said further >> down in your post, it can be handled more elegantly by replacing the >> complex code with a placeholder. Why not just do that? >> > > Excellent question -- how hard would it be to change that? > > I'm fairly sure that's easier to do with an abstract parse tree generated > from source (don't recognize it? stash it in a dedicated blob); I worry it > may be harder trying to stash that into the middle of a multi-level HTML > translation engine that wasn't meant to be reversible in the first place (do > we even know if there's an opportunity to recognize the problem component > within the annotated HTML or not? Is it seeing things it doesn't recognize > in the HTML, or is it seeing certain structures in the source and aborting > before it even gets there?). > > Like many such things, this might be better resolved by trying it and > seeing what happens -- I don't want us to lock into a strategy too early > when a lot of ideas are still unresolved. > Had a quick chat with Tim in IRC -- we're definitely going to try poking at the current state of the Wikia RTE a bit more. I'll start merging it to our extensions SVN so we've got a stable clone of it that can be run on stock trunk. Little changes should be mergable back to Wikia's SVN, and we'll have something available for stock distributions that's more stable than the old FCK extension, and that we can start experimenting with along with other stuff. Another good thing in this code is the client-side editor plugins; once one gets past the raw "shove stuff in/out of the markup format" most of the hard work and value of an editor actually comes in the helpers for working with links, images, tables, galleries, etc -- dialogs, wizards, helpers for dragging things around. That's all stuff that we can examine and improve or base from. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 5:28 PM, Tim Starling wrote: > On 03/05/11 04:25, Brion Vibber wrote: > > The most fundamental problem with Wikia's editor remains its fallback > > behavior when some structure is unsupported: > > > > "Source mode required > > > > Rich text editing has been disabled because the page contains complex > > code." > > I don't think that's a fundamental problem, I think it's a quick hack > added to reduce the development time devoted to rare wikitext > constructs, while maintaining round-trip safety. Like you said further > down in your post, it can be handled more elegantly by replacing the > complex code with a placeholder. Why not just do that? > Excellent question -- how hard would it be to change that? I'm fairly sure that's easier to do with an abstract parse tree generated from source (don't recognize it? stash it in a dedicated blob); I worry it may be harder trying to stash that into the middle of a multi-level HTML translation engine that wasn't meant to be reversible in the first place (do we even know if there's an opportunity to recognize the problem component within the annotated HTML or not? Is it seeing things it doesn't recognize in the HTML, or is it seeing certain structures in the source and aborting before it even gets there?). Like many such things, this might be better resolved by trying it and seeing what happens -- I don't want us to lock into a strategy too early when a lot of ideas are still unresolved. I'm very interested in making experimentation easy; for my pre-exploratory work I'm stashing things into a gadget which adds render/parse tree/inspector modes to the editing page: http://www.mediawiki.org/wiki/File:Parser_Playground_demo.png (screenshot & links) I've got this set up as a gadget on mediawiki.org now and as a user script on en.wikipedia.org (loaded on User:Brion_VIBBER/vector.js) just for tossing random pages in and getting a better sense of how things break down. Currently parser variant choices are: * the actual MediaWiki parser via API (parse tree shows the preprocessor XML; side-by-side mode doesn't have a working inspector mode though) * a really crappy FakeParser class I threw together, able to handle only a few constructs. Generates a JSON parse tree, and the inspector mode can match up nodes in side-by-side view of the tree & HTML. * PegParser using the peg.js parser generator to build the source->tree parser, and the same tree->html and tree->source round-trip functions as FakeParser. The peg source can be edited and rerun to regen the new parse tree. It's fun! These are a long way off from the level of experimental support we're going to want, but I think people are going to benefit from trying a few different things and getting a better feel for how source, parse trees, and resulting HTML really will look. (Template expansion isn't yet presented in this system, and that's going to be where the real fun is. ;) Some people in this thread have expressed concerns about the tiny > breakages in wikitext backwards compatibility introduced by RTE, > despite the fact that RTE has aimed for, and largely achieved, precise > backwards compatibility with legacy wikitext. I find it hard to believe that those people would be comfortable with > a project which has as its goal a broad reform of wikitext syntax. > > Perhaps there are good arguments for wikitext syntax reform, but I > have trouble believing that WYSIWYG support is one of them, since the > problem appears to have been solved already by RTE, without any reform. > Well, Wikia's RTE still doesn't work on high-profile Wikipedia article pages, so that remains unproven... That said, an RTE that doesn't require changing core parser behavior yet *WILL BE A HUGE BENEFIT* to getting it into use sooner, and still leaves future reform efforts open. I'm *VERY OPEN* to the notion of doing the RTE using either a supplementary source-level parser (which doesn't have to render all structures 100% the same as the core parser, but *needs* to always create sensible structures that are useful for editors and can round-trip cleanly) or an alternate version of the core parser with annotations and limited transformations (eg like how we don't strip comments out when producing editable source, so we need to keep them in the output in some way if it's going to be fed into an HTML-ish editing view). A supplementary parser that deals with all your editing fun, but doesn't play super nice with open...close templates is probably just fine for a huge number of purposes. Now that we have HipHop support, we have the ability to turn > MediaWiki's core parser into a fast, reusable library. The performance > reasons for limiting the amount of abstraction in the core parser will > disappear. How many wikitext parsers does the world really need? > I'm not convinced that a giant blob of MediaWiki is suitable as a reusable library, but would love to see it tried. -- brion _
Re: [Wikitech-l] Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)
On Mon, May 2, 2011 at 7:52 PM, Happy-melon wrote: > If a feature freeze is to work, it has to either a) be for a very short > period so that developers neither get disenchanted and wander off nor start > stockpiling working-copy changes to empty onto trunk once it's thawed, or b) > be part of a fundamental change in the way we approach rewrites. It would > be perfectly acceptable to move to a completely different paradigm where > branches are used properly, regularly reviewed, get plenty of > inter-developer testing and can be smoothly merged back into trunk in an > organised fashion. But right now, the only way to reliably get external > eyes on code is to put it in trunk; the occasions when multiple developers > are working on the same branch are both rare and not quite the same thing. > I'm proposing (a). Shifting to (b) is an organizational shift, and some people don't seem to think it can happen unless we move to the Magical World of Git. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 8:38 PM, Chad wrote: > People want to write their own parsers because they don't want to use PHP. > They want to parse in C, Java, Ruby, Python, Perl, Assembly and every > other language other than the one that it wasn't written in. s/wasn't/was/ -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 8:28 PM, Tim Starling wrote: > I know that there is a camp of data reusers who like to write their > own parsers. I think there are more people who have written a wikitext > parser from scratch than have contributed even a small change to the > MediaWiki core parser. They have a lot of influence, because they go > to conferences and ask for things face-to-face. > > Now that we have HipHop support, we have the ability to turn > MediaWiki's core parser into a fast, reusable library. The performance > reasons for limiting the amount of abstraction in the core parser will > disappear. How many wikitext parsers does the world really need? > People want to write their own parsers because they don't want to use PHP. They want to parse in C, Java, Ruby, Python, Perl, Assembly and every other language other than the one that it wasn't written in. There's this, IMHO, misplaced belief that "standardizing" the parser or markup would put us in a world of unicorns and rainbows where people can write their own parsers on a whim, just because they can. Other than "making it easier to integrate with my project," I don't see a need for them either (and tbh, the endless discussions grow tedious). I don't see any problem with keeping the parser in PHP, and as you point out with HipHop support on the not-too-distant horizon the complaints about performance with Zend will largely evaporate. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
Indeed .. i remember writing this report for brion years ago. brings back memories. --tomasz On Mon, May 2, 2011 at 5:05 PM, Happy-melon wrote: > > "reporter" wrote in message > news:e1pprj3-bs...@kaulen.wikimedia.org... > > MediaWiki Bugzilla Report for November 29, 2010 - December 06, 2010 > > ... > > "reporter" wrote in message > news:e1qgwls-000389...@kaulen.wikimedia.org... > > MediaWiki Bugzilla Report for April 25, 2011 - May 02, 2011 > > > > Wow, now here's a blast from the past... :-D A lot of these stats are now > in the BZ4 report page, but it's still very nice to have the weekly > reminder. Cookie for whoever dug it out and got it going again! > > --HM > > > > ___ > 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
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On 03/05/11 04:25, Brion Vibber wrote: > The most fundamental problem with Wikia's editor remains its fallback > behavior when some structure is unsupported: > > "Source mode required > > Rich text editing has been disabled because the page contains complex > code." I don't think that's a fundamental problem, I think it's a quick hack added to reduce the development time devoted to rare wikitext constructs, while maintaining round-trip safety. Like you said further down in your post, it can be handled more elegantly by replacing the complex code with a placeholder. Why not just do that? CKEditor makes adding such placeholders really easy. The RTE source has a long list of such client-side modules, added to support various Wikia extensions. > Here's an example of unsupported code, the presence of which makes a page > permanently uneditable by the rich editor until it's removed: > > > a > > > You can try this out now at http://communitytest.wikia.com/ Works for me. http://communitytest.wikia.com/wiki/Brion%27s_table > Beyond that let's flip the question the other way -- what do we *want* out > of WYSIWYG editing, and can that tool provide it or what else do we need? > I've written up some notes a few weeks ago, which need some more collation & > updating from the preliminary experiments I'm doing, and I would strongly > appreciate more feedback from you Tim and from everyone else who's been > poking about in parser & editing land: > > http://www.mediawiki.org/wiki/Wikitext.next Some people in this thread have expressed concerns about the tiny breakages in wikitext backwards compatibility introduced by RTE, despite the fact that RTE has aimed for, and largely achieved, precise backwards compatibility with legacy wikitext. I find it hard to believe that those people would be comfortable with a project which has as its goal a broad reform of wikitext syntax. Perhaps there are good arguments for wikitext syntax reform, but I have trouble believing that WYSIWYG support is one of them, since the problem appears to have been solved already by RTE, without any reform. > Another goal beyond editing itself is normalizing the world of 'alternate > parsers'. There've been several announced recently, and we've got such a > large array now of them available, all a little different. We even use mwlib > ourselves in the PDF/ODF export deployment, and while we don't maintain that > engine we need to coordinate a little with the people who do so that new > extensions and structures get handled. I know that there is a camp of data reusers who like to write their own parsers. I think there are more people who have written a wikitext parser from scratch than have contributed even a small change to the MediaWiki core parser. They have a lot of influence, because they go to conferences and ask for things face-to-face. Now that we have HipHop support, we have the ability to turn MediaWiki's core parser into a fast, reusable library. The performance reasons for limiting the amount of abstraction in the core parser will disappear. How many wikitext parsers does the world really need? -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 05/02/2011 06:40 PM, Owen Davis wrote: > I think the current plan is to see what transpires with the > upcoming Parser redesign and keep our code in sync. The > primary authors of this RTE reskin will be at the Berlin > hackathon as well. Who are those authors? I'd like to know so I can find them in Berlin and drag them into any relevant discussions, etc. -Sumana Harihareswara ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)
"Chad" wrote in message news:BANLkTikd4Eb-V8W-kA1qe+=bnjxmj+o...@mail.gmail.com... > > I understand, respect, and value the contributions of people who want to > add new features. Features are what moves the product forward, and at > no point do we want to be hostile to people willing to put in their time > and > effort to add functionality. > > Given that our patch review process isn't fantastic, I really don't think > it > would affect the majority of bugs anyway. Mainly affected would be > people with core access who write a new feature without putting it > through BZ first. Given that our core group is relatively small, I figured > we could come to some sort of consensus, if we do indeed move forward > with this. > > ... > > I don't know what our development community wants. I just happened to > think it was a good idea and so brought it up for discussion. If we > collectively decide I'm nuts, we can toss this proposal, I won't be upset. > I know we'd need to keep development on a very strict timeframe, which > is why I outlined a more strict branching and timeline to stick to. As > Roan > and others pointed out, 6 months is a little long. I don't think we > couldn't > decide on a branch point and stick to it, especially if we're not holding > up > a branch for someone to finish sorting out a rewrite or major feature they > didn't quite resolve. > >> Given our past record, I'm not really confident that we can pull that >> off. There's a risk of screwing it up badly and offending a lot of >> people. Release management isn't exactly an organisational strength. >> > > I agree it's not our strength, but I don't think we can't do it. I > think sticking > to a firm branch date would largely alleviate this issue. I remain > convinced > that a stability-focused release would be a good idea at some point, > whether > we do it now or in a year. Feature freezes don't have much potential in the current development climate because the choice is basically between committing a feature to trunk and not committing a feature at all. Development work done in branches might as well be left in a working copy for all the attention it gets, BZ patches doubly so. What would almost certainly happen in a feature freeze would be that developers who are interested in core rewrites / major features would simply queue up their work for the next release, which would make 1.20 another massively-rewritten monster. That, if not properly managed, is just creating a bigger problem down the line; although conversely you could say it would make for a particularly Awesome(TM) milestone release. If a feature freeze is to work, it has to either a) be for a very short period so that developers neither get disenchanted and wander off nor start stockpiling working-copy changes to empty onto trunk once it's thawed, or b) be part of a fundamental change in the way we approach rewrites. It would be perfectly acceptable to move to a completely different paradigm where branches are used properly, regularly reviewed, get plenty of inter-developer testing and can be smoothly merged back into trunk in an organised fashion. But right now, the only way to reliably get external eyes on code is to put it in trunk; the occasions when multiple developers are working on the same branch are both rare and not quite the same thing. My login rewrite was done as a branch merge and was reverted three times from 1.16 (not unreasonably, for sure, but for bugs flagged up by precisely the sort of diverse testing that being in trunk provides and being in a branch doesn't); it's now 30,000 revisions bitrotted and will probably have to be redone from scratch. The 1.18 blocking rewrite was done in pieces in trunk and looks to have settled in reasonably well. A feature freeze will probably result in rather more of those Big Scary Commits (TM) -- either branch merges or whole features put together in a working copy -- and fewer features implemented through incremental changes. If we don't have provisions in place to handle that in some way, it will probably create more problems than it solves. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Brion Vibber pobox.com> writes: > Note that for Wikipedia that's not just going to affect experienced editors Very true! I think we have more inexperienced editors, and that's been a product design focus for us for a while so I tend to make assumptions based on that. > Do you mean that it doesn't yet provide any way to see and edit the contents > of templates and tag hook extensions, but that infrastructure has come in >which will make it possible in the future? Yep, that's my understanding. We have added custom editing tools for a few home grown Wikia things but it's painful and requires modifications to the Parser and I don't recommend looking at that code. :) One of the internal goals was to make that easier and my understanding is it's been done. I don't know the details yet, we are getting a full presentation on it next week by the developer. For templates, the proposal just showed them expanded/rendered in the page but read-only and I'm not sure if that's going to be in the product or not. For tags, there are hooks that allow the extension developer to put up a modal edit/design mode, and since those are just simple HTML templates and ajax calls, it's a lot easier to develop. An example of that is here (in the old editor, done the old way with an ugly parser hack). http://kirkburn.wikia.com/index.php?title=PollTest8&action=edit ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] auditcode.py - discern class structure
Am using vim, which knows about ctags. Exuberant ctags (which is the name of a piece of software) knows about languages other than C. It seems not to know about class structure, and which function is being overridden where. I want to be able to read through the code that my Swift interface will be executing to look for filesystem calls, and I want to be able to ignore code which won't be executed. grep hasn't been my best friend in this process, although we *are* drinking buddies. From: wikitech-l-boun...@lists.wikimedia.org [wikitech-l-boun...@lists.wikimedia.org] on behalf of Brion Vibber [br...@pobox.com] Sent: Monday, May 02, 2011 7:24 PM To: Wikimedia developers Subject: Re: [Wikitech-l] auditcode.py - discern class structure On Mon, May 2, 2011 at 4:21 PM, Russell N. Nelson - rnnelson < rnnel...@clarkson.edu> wrote: > Maybe there's a better tool to tell you what function is defined in what > class in PHP, but I couldn't find one in the time it would take me to write > it, so I wrote it. Depending on what you're trying to do, this may already be built into your editor or IDE. NetBeans for instance, with the standard PHP plugin installed is able to jump to class, function, or symbol definitions via a hotkey (or ctrl+click or right-click+menu on a mention in source). -- 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
Re: [Wikitech-l] auditcode.py - discern class structure
I totally <3 that you wrote it in python.
On Mon, May 2, 2011 at 4:21 PM, Russell N. Nelson - rnnelson
wrote:
> Maybe there's a better tool to tell you what function is defined in what
> class in PHP, but I couldn't find one in the time it would take me to write
> it, so I wrote it. It's not even a screenful. Give it the class definitions,
> in class hierarchy order, on the command line. It will pull out the class
> name and function names, and tell you which function is actually being
> implemented by which class. It doesn't pay any attention to parent::self()
> calls, so you should watch out for them.
> -russ
>
> #!/usr/bin/python
>
> import sys, re
>
> functions = {}
> classes = {}
> cl = None
> for fn in sys.argv[1:]:
> for line in open(fn):
> match = re.match(r'(abstract\s+)?class\s+(.*?)\s+(extends\s+(.*?)\s+)?\{',
> line)
> if match:
> cl = match.group(2)
> supercl = match.group(4)
> classes[cl] = supercl
> if supercl:
> classes[supercl] # superclass should already be exist
>
> match = re.match(r'\s*(public\s+|static\s+)?function\s+(.*?)\(', line)
> if match:
> # we have a function definition.
> funct = match.group(2)
> functions[funct] = cl
>
> keys = functions.keys()
> keys.sort()
> for key in keys:
> print key,functions[key]
>
> ___
> 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
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 03/05/11 04:54, Alex wrote:
> Question: why does it have to normalise at all?
>
> I do think that the editing environment at Wikipedia means that consistent
> non-normalised editing by wikitext users and subsequent normalisation by
> anyone using WYSIWYG would be messy and disruptive, but would a change
> whereby it more precisely records the wikitext, and then doesn't try and
> change it unless that part of the document is edited, be feasible?
That's basically what it does already. There's no normalisation as
such. For instance if you type x into the source view, you get
x
But if you type '''x''', you just get
x
If you type [[x|x]], you get an anchor tag with a data-rte-meta
attribute containing:
{"type":"internal","text":"x","link":"x","wasblank":false,"noforce":true,"wikitext":"[[x|x]]"}
Whereas if you type [[x]], the data-rte-meta attribute is:
{"type":"internal","text":"x","link":"x","wasblank":true,"noforce":true,"wikitext":"[[x]]"}
These attributes are sent to the server, and in principle, the
wikitext could be reconstructed precisely. There is a bug in the
particular case of [[x|x]], it gets translated to [[x]] at some point,
but lots of other cases work correctly.
If [[x|x]] is the only reason we're not using the WYSIWYG editor,
let's just fix it. It's an isolated case, not an architectural issue.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86927]: New comment added
User "Kaldari" posted a comment on MediaWiki.r86927.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86927#c16501
Commit summary:
adding language support to #time parser function, per bug 28655
Comment:
After talking with Platonides, I've redone the language handling. See r87308.
The magic language switching is gone, but you can still accomplish the same
thing by passing {{int:lang}} as the language param on Commons
(the main place this is needed).
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] auditcode.py - discern class structure
On Mon, May 2, 2011 at 4:21 PM, Russell N. Nelson - rnnelson < rnnel...@clarkson.edu> wrote: > Maybe there's a better tool to tell you what function is defined in what > class in PHP, but I couldn't find one in the time it would take me to write > it, so I wrote it. Depending on what you're trying to do, this may already be built into your editor or IDE. NetBeans for instance, with the standard PHP plugin installed is able to jump to class, function, or symbol definitions via a hotkey (or ctrl+click or right-click+menu on a mention in source). -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] auditcode.py - discern class structure
Maybe there's a better tool to tell you what function is defined in what class
in PHP, but I couldn't find one in the time it would take me to write it, so I
wrote it. It's not even a screenful. Give it the class definitions, in class
hierarchy order, on the command line. It will pull out the class name and
function names, and tell you which function is actually being implemented by
which class. It doesn't pay any attention to parent::self() calls, so you
should watch out for them.
-russ
#!/usr/bin/python
import sys, re
functions = {}
classes = {}
cl = None
for fn in sys.argv[1:]:
for line in open(fn):
match = re.match(r'(abstract\s+)?class\s+(.*?)\s+(extends\s+(.*?)\s+)?\{',
line)
if match:
cl = match.group(2)
supercl = match.group(4)
classes[cl] = supercl
if supercl:
classes[supercl] # superclass should already be exist
match = re.match(r'\s*(public\s+|static\s+)?function\s+(.*?)\(', line)
if match:
# we have a function definition.
funct = match.group(2)
functions[funct] = cl
keys = functions.keys()
keys.sort()
for key in keys:
print key,functions[key]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 4:01 PM, Platonides wrote:
> > But it's not an intractable problem. Essentially, anything in the format:
> >
> > {{start}}
> > content1
> > content2
> > {{end}}
> >
> > can be rewritten something like:
> >
> > {{container|
> > content1
> > content2
> > }}
>
> It's equivalent, but uglier to type and work with. I don'think people
> would resist moving to it. You also get some problems in getting some
> markup because you no longer are in the first line, don't remember exactly.
>
'Uglier' to work with depends very much on what the tools to work with it
looks like... if the result is we make it a billion times easier to maintain
your infoboxes on your articles because the whole box can be treated as a
unit in the editor or even handed off to a specialized infobox wizard, then
I'm a lot less worried about what it _looks like_ in the markup.
Humans *shouldn't* be worrying about whether they got the whitespace or
escaping right to embed one structure in another; they should be able to
just edit text in the box, and the editor worries about constructing the
markup properly to describe the document.
We'll be freer to make use of things like escape sequences to disambiguate
embedded structures if we know that most of the time it'll be a machine, not
a human that's typing the |s (or occasionally \|s) or worrying about whether
there's a newline in a particular place or not -- these are things that
power users doing hardcore template editing can mess with, without most
people needing to worry about them.
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 3:40 PM, Owen Davis wrote: > Hi, I work at Wikia (although I am relatively new and I have only > made small modifications to the editor). Hi! > This basic criticism of > the design is true and is still the source of issues, but it's been > improving. I think another problem for experienced wiki editors > is the "sea of puzzle pieces" that happens when you edit a > complicated page, because it can't render templates (plus a > bunch of other things it can't render that show puzzles) > Note that for Wikipedia that's not just going to affect experienced editors -- it will affect *everyone*, since just about every article includes templates and tag hook extensions for references etc, and we strongly encourage editors to make use of them liberally. It needs to be very easy to create, review, and edit them. This re-skin is feature identical for users, but for > developers it addresses the puzzle piece problem, which > should allow us to more easily add custom widgets to render > particular extension tags. It's not in this first release but > we've also internally been experimenting with ways to render > templates in a more useful way than a green puzzle piece. > Do you mean that it doesn't yet provide any way to see and edit the contents of templates and tag hook extensions, but that infrastructure has come in which will make it possible in the future? -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Brion Vibber wrote:
>> {{Open template}} text {{Close template}} structures are IMHO a big
>> problem for any WYSIWYG editor.
>> But there's no way they are going away.
>
>
> If we determine they have to go, then we can devise ways to find and migrate
> them -- it'll be a process that takes time and a lot of helper tools, and
> it's necessary to not underplay that difficulty.
>
> But it's not an intractable problem. Essentially, anything in the format:
>
> {{start}}
> content1
> content2
> {{end}}
>
> can be rewritten something like:
>
> {{container|
> content1
> content2
> }}
It's equivalent, but uglier to type and work with. I don'think people
would resist moving to it. You also get some problems in getting some
markup because you no longer are in the first line, don't remember exactly.
> Now, it may well be feasible to actually let the table rows just sit there
> in the parse tree and coalesce them into the adjacent table during final
> HTML transformation or something, but if that's not practical to do in the
> parser & translation layers it shouldn't be impossible to migrate.
diebuche moved tables to an AST-like structure recently. I wonder if
it's still efficient enough for wikipedia, though.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 3:32 PM, Platonides wrote:
> > If we can devise a way to consistently treat expansions that *aren't* a
> > hierarchical match fro the HTML node tree, then we might not have to
> change
> > templates much. If we can't, then we might have to start enforcing
> > hierarchical template & other code nesting and go through and migrate a
> > bunch of existing templates.
>
> {{Open template}} text {{Close template}} structures are IMHO a big
> problem for any WYSIWYG editor.
> But there's no way they are going away.
>
If we determine they have to go, then we can devise ways to find and migrate
them -- it'll be a process that takes time and a lot of helper tools, and
it's necessary to not underplay that difficulty.
But it's not an intractable problem. Essentially, anything in the format:
{{start}}
content1
content2
{{end}}
can be rewritten something like:
{{container|
content1
content2
}}
with some variation based on what needs there are on customizing the
start/end and such. That could then expand cleanly:
template: 'container'
param 0:
'content1'
'content2'
->
expanded-template: 'container'
table:
row:
'start'
row:
cell:
'content1'
'content2'
row:
'end'
Now, it may well be feasible to actually let the table rows just sit there
in the parse tree and coalesce them into the adjacent table during final
HTML transformation or something, but if that's not practical to do in the
parser & translation layers it shouldn't be impossible to migrate.
Where wrapping bunches of things in separate rows is done currently, some
basic (and sane) loop parser functions could also help with making those
clean.
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Roan Kattouw gmail.com> writes: > While I'm sure this particular bug has been fixed, it sounds like the > underlying problem remains. FCKeditor seems to be converting wikitext > to HTML, let users edit the HTML, then convert the HTML back to > wikitext. The bugs would then result from the fact that the > wikitext->HTML->wikitext round-trip (or wikitext->whatever internal > representation is used->wikitext) isn't clean. Hi, I work at Wikia (although I am relatively new and I have only made small modifications to the editor). This basic criticism of the design is true and is still the source of issues, but it's been improving. I think another problem for experienced wiki editors is the "sea of puzzle pieces" that happens when you edit a complicated page, because it can't render templates (plus a bunch of other things it can't render that show puzzles) We are currently almost finished with a look-and-feel revamp of the RTE, which is being rolled out over the next few weeks. A blog post about it can be read here: http://community.wikia.com/wiki/User_blog:Sarah_Manley/A_Facelift_for_the_Edit_Page I'd encourage those with an interest in such things to skim the comments, it's an interesting range of responses, but mostly positive. This re-skin is feature identical for users, but for developers it addresses the puzzle piece problem, which should allow us to more easily add custom widgets to render particular extension tags. It's not in this first release but we've also internally been experimenting with ways to render templates in a more useful way than a green puzzle piece. I wish I could point to a running instance, but it will be out there soon and I'll put up a link to a test wiki asap if anyone is interested. Many of the look and feel changes are all specific to the custom skin that Wikia uses so I'm not sure how useful it is to others, but the code just got checked in to our trunk SVN this weekend: http://trac.wikia-code.com/browser/wikia/trunk/extensions/wikia/EditPageReskin > Trevor and I talked about this issue about a year and a half ago, and > figured the best way around round-trip bugs was to not do round-trips > at all. Instead, wikitext or something close to it should be used as > an internal representation, and/or only the parts of the page the user > touches should actually change. Internally we have discussions about the future of the RTE but they are still at the "grand vision" stage to be honest. I think the current plan is to see what transpires with the upcoming Parser redesign and keep our code in sync. The primary authors of this RTE reskin will be at the Berlin hackathon as well. I'm also happy to field any particular questions about the RTE and get them sent to the right people here at Wikia. Owen Davis ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 3:29 PM, Platonides wrote: > Magnus Manske wrote: >> >> So, why not use my WYSIFTW approach? It will only "parse" the parts of >> the wikitext that it can turn back, edited or unedited, into wikitext, >> unaltered (including whitespace) if not manually changed. Some parts >> may therefore stay as wikitext, but it's very rare (except lists, >> which I didn't implement yet, but they look intuitive enough). >> >> Magnus > > Crazy idea: What if it was an /extensible/ editor? You could add later a > module for enable lists, or "enable graphic ", but also instruct it > on how to present to the user some crazy template with a dozen parameters... Generically a nice idea. Specific to Wikipedia / WMF projects - all the extensions you might consider adding are pretty much required for our internal uptake of the tool, as our pages are the biggest / oldest / crustyest ones likely to have to be managed... -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On 05/02/11 15:30, wikitech-l-requ...@lists.wikimedia.org wrote: > Date: Tue, 03 May 2011 00:29:51 +0200 > From: Platonides > Subject: Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong > withWikia's WYSIWYG?) > To:wikitech-l@lists.wikimedia.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Magnus Manske wrote: >> > >> > So, why not use my WYSIFTW approach? It will only "parse" the parts of >> > the wikitext that it can turn back, edited or unedited, into wikitext, >> > unaltered (including whitespace) if not manually changed. Some parts >> > may therefore stay as wikitext, but it's very rare (except lists, >> > which I didn't implement yet, but they look intuitive enough). >> > >> > Magnus > Crazy idea: What if it was an/extensible/ editor? You could add later a > module for enable lists, or "enable graphic", but also instruct it > on how to present to the user some crazy template with a dozen parameters... Seems like it will need to be extensible, to allow authors of MW extensions to add support for cases where they've changed the parser's behavior? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87306]: Revision status changed
User "^demon" changed the status of MediaWiki.r87306. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87306#c0 Commit summary: Remove empty files left by r16526, r29128 and r83029 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 11-05-02 03:32 PM, Platonides wrote:
> Brion Vibber wrote:
>> A bigger deal will probably be actually changing structures that don't
>> render consistently, and that'll depend on how brave we are changing nested
>> template & table structures to fit a hierarchical document model.
>>
>> We've basically got two levels of stuff:
>>
>> * parsing wiki markup into a document structure that's useful for editing
>> * using the document structure to render HTML output or an editing
>> environment
>>
>> Our classic MediaWiki parser does only a tiny bit of the first in the
>> preprocessor, and then leaves a lot more of our markup to the transformation
>> layer, which is how we end up with things like templates that expand into an
>> HTML tag opener, of which which some adjacent templates contain the contents
>> and endings.
>>
>>
>> If we can devise a way to consistently treat expansions that *aren't* a
>> hierarchical match fro the HTML node tree, then we might not have to change
>> templates much. If we can't, then we might have to start enforcing
>> hierarchical template & other code nesting and go through and migrate a
>> bunch of existing templates.
>>
>> -- brion
> {{Open template}} text {{Close template}} structures are IMHO a big
> problem for any WYSIWYG editor.
> But there's no way they are going away.
Sure they will... ;) if we have loop functions.
*snicker*
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Empty files in distribution
Brion Vibber wrote: > Looks like just bad patch reverts that removed the file contents but didn't > actually delete. > > -- brion Gone in r87306. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Brion Vibber wrote:
> A bigger deal will probably be actually changing structures that don't
> render consistently, and that'll depend on how brave we are changing nested
> template & table structures to fit a hierarchical document model.
>
> We've basically got two levels of stuff:
>
> * parsing wiki markup into a document structure that's useful for editing
> * using the document structure to render HTML output or an editing
> environment
>
> Our classic MediaWiki parser does only a tiny bit of the first in the
> preprocessor, and then leaves a lot more of our markup to the transformation
> layer, which is how we end up with things like templates that expand into an
> HTML tag opener, of which which some adjacent templates contain the contents
> and endings.
>
>
> If we can devise a way to consistently treat expansions that *aren't* a
> hierarchical match fro the HTML node tree, then we might not have to change
> templates much. If we can't, then we might have to start enforcing
> hierarchical template & other code nesting and go through and migrate a
> bunch of existing templates.
>
> -- brion
{{Open template}} text {{Close template}} structures are IMHO a big
problem for any WYSIWYG editor.
But there's no way they are going away.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
best idea so far ... On 03. 05. 2011 00:29, Platonides wrote: > Magnus Manske wrote: >> So, why not use my WYSIFTW approach? It will only "parse" the parts of >> the wikitext that it can turn back, edited or unedited, into wikitext, >> unaltered (including whitespace) if not manually changed. Some parts >> may therefore stay as wikitext, but it's very rare (except lists, >> which I didn't implement yet, but they look intuitive enough). >> >> Magnus > Crazy idea: What if it was an /extensible/ editor? You could add later a > module for enable lists, or "enable graphic", but also instruct it > on how to present to the user some crazy template with a dozen parameters... > > > > ___ > 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
[MediaWiki-CodeReview] [MediaWiki r86927]: New comment added
User "Kaldari" posted a comment on MediaWiki.r86927. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86927#c16500 Commit summary: adding language support to #time parser function, per bug 28655 Comment: Fixed in r87305 (only for #time, not for Language in general). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86927]: New comment added
User "Kaldari" posted a comment on MediaWiki.r86927. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86927#c16499 Commit summary: adding language support to #time parser function, per bug 28655 Comment: Hopefully this is fixed in r87305. I don't know much about how the language caching works, so let me know if this is wrong. Also, I'm wondering if this is really even a good idea. Will this cause too much cache fragmentation if people start using it widely? Thoughts? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
Magnus Manske wrote: > > So, why not use my WYSIFTW approach? It will only "parse" the parts of > the wikitext that it can turn back, edited or unedited, into wikitext, > unaltered (including whitespace) if not manually changed. Some parts > may therefore stay as wikitext, but it's very rare (except lists, > which I didn't implement yet, but they look intuitive enough). > > Magnus Crazy idea: What if it was an /extensible/ editor? You could add later a module for enable lists, or "enable graphic ", but also instruct it on how to present to the user some crazy template with a dozen parameters... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87232]: New comment added
User "Platonides" posted a comment on MediaWiki.r87232. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87232#c16498 Commit summary: Make a method static per the comment, update the only non static usage (in Parser) itself Comment: extensions/News/NewsRenderer.php: $text = $parser->extractTagsAndParams ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87265]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r87265. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87265#c0 Commit summary: Fix r87203: don't use a for..in loop on an array ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87303]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r87303. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87303#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-05-02 21:35:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87304]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r87304. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87304#c0 Commit summary: Localisation updates for core and extension messages from translatewiki.net (2011-05-02 21:42:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87290]: Revision status changed
User "Reedy" changed the status of MediaWiki.r87290. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87290#c0 Commit summary: Add makeInsertOptions Allow Sqlite to OR IGNORE on UPDATE or INSERT ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87290]: New comment added, and revision status changed
User "Raymond" changed the status of MediaWiki.r87290. Old Status: new New Status: fixme User "Raymond" also posted a comment on MediaWiki.r87290. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87290#c16497 Commit summary: Add makeInsertOptions Allow Sqlite to OR IGNORE on UPDATE or INSERT Comment: Seen on Translatewiki: PHP Strict Standards: Declaration of DatabaseSqlite::makeInsertOptions() should be compatible with that of DatabaseBase::makeInsertOptions() in /www/w/includes/db/DatabaseSqlite.php on line 669 PHP Strict Standards: Declaration of DatabaseSqlite::makeInsertOptions() should be compatible with that of DatabaseBase::makeInsertOptions() in /www/w/includes/AutoLoader.php on line 877 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86409]: New comment added
User "Krinkle" posted a comment on MediaWiki.r86409. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86409#c16496 Commit summary: (bug 28352) "blocked admins actually can't unblock themselves because it checks the wrong parameter". This doesn't need to be forward-ported as the entire blocking frontend is rewritten in 1.18. Comment: Adding 1.17wmf1 tag per BugTriage of Mon, April 18 2011: http://bugzilla.wikimedia.org/28352 : Highest NEW self unblock with username does not work under 1.17 * User having user right unblockself cannot unblock himself on wmf wikis. * Apparently fixed in trunk. * In which rev? If we know the rev we can merge it :) * mark will track down the revie ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 12:55 PM, Magnus Manske wrote: > On Mon, May 2, 2011 at 7:33 PM, Fred Bauder > wrote: > >>> Beyond that let's flip the question the other way -- what do we *want* > >> out > >> of WYSIWYG editing, and can that tool provide it or what else do we > need? > > > > We want something simpler and easier to use. That is not what Wikia has. > > I could hardly stand trying it out for a few minutes. > > So, why not use my WYSIFTW approach? It will only "parse" the parts of > the wikitext that it can turn back, edited or unedited, into wikitext, > unaltered (including whitespace) if not manually changed. Some parts > may therefore stay as wikitext, but it's very rare (except lists, > which I didn't implement yet, but they look intuitive enough). > There's a lot I like about the WYSIFTW tool: * replacing the section edits inline is kinda nice * folding of extensions and templates is intelligent and allows you to edit them easily (unlike Wikia's which drops in opaque placeholders, currently requiring you to switch the *entire* section to source mode to change them at all) -- some infoboxes for instance show up as basically editable tables of parameter pairs, which is pretty workable! * popup menus on links, images, etc provide access to detail controls without cluttering up their regular view I've added a side-by-side view of a popular article (top of [[w:Barack Obama]]) with its WYSIFTW editing view and the Wikia editor (which just gives up and shows source) at: http://www.mediawiki.org/wiki/Wikitext.next#Problems There are though cases where WYSIFTW gets confused, such as a with multi-line contents -- it doesn't get that the lists, templates etc are inside the ref rather than outside, which messes up the folding. These sorts of things are why I think it'd be a win to use a common wikitext->AST parser for both rendering and editing tasks: if they're consistent we eliminate a lot of such odd edge cases. It could also make it much easier to do fine-grained editing; instead of invoking the editor on an entire section at a time, we could click straight into a paragraph, table, reference, etc, knowing that the editor and the renderer both are dividing the page up the same way. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87277]: Revision status changed
User "Jack Phoenix" changed the status of MediaWiki.r87277. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87277#c0 Commit summary: Fix and add some comments. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87291]: Revision status changed
User "Jack Phoenix" changed the status of MediaWiki.r87291. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87291#c0 Commit summary: Renamed methods as per our coding standards... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 7:33 PM, Fred Bauder wrote: > >> Beyond that let's flip the question the other way -- what do we *want* >> out >> of WYSIWYG editing, and can that tool provide it or what else do we need? > > We want something simpler and easier to use. That is not what Wikia has. > I could hardly stand trying it out for a few minutes. So, why not use my WYSIFTW approach? It will only "parse" the parts of the wikitext that it can turn back, edited or unedited, into wikitext, unaltered (including whitespace) if not manually changed. Some parts may therefore stay as wikitext, but it's very rare (except lists, which I didn't implement yet, but they look intuitive enough). Today's featured article parses in 2 sec in Chrome, so it's fast enough for most situations using a current browser, and it also supports section editing. There's basic functionality for most things, even a one-click "insert reference" function. There's also still lots missing, but nothing fundamental, mostly time-sink functions like "insert table column" etc. Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86962]: New comment added
User "Thenub314" posted a comment on MediaWiki.r86962.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86962#c16495
Commit summary:
The following changes enhance the way texvc handles space around
mathematical function names when translating to HTML; adds support for
the sen, the Spanish name for sin; and corrects a bug that eliminates
spacing around \operatorname{...} in the resulting png. More
specifically, texvc now dectect whether or not a
standard function such as is followed by a delimitier such as (, {, [
etc. and adds a space or not as appropriate. This issue The code has been
reorganized to include a list of standard LaTeX commands whose spacing
rules are the same, and treates them all on an equal footing. It
similarly treats functions defined for mediawiki in the same way it
treats standard latex functions. One addition function is added, \sen,
and others can be added easily if necessary. Finally LaTeX generated
by texvc contained to many braces which altered the spacing created by
the command \operatorname, this has now been corrected. These last
two changes address the issues raised in bug 18912 and the chaning in
translation to HTML address most, but not all, of the issues raised in
bug 6722 .
Comment:
Revision r87117 corrects a small bug introduced in this change. which results
to not inserting a space after the function name when no braces are used. That
is if the input was \sin x the the code sent to LaTeX was \sinx.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 11:54 AM, Alex wrote: > Question: why does it have to normalise at all? > > I do think that the editing environment at Wikipedia means that consistent > non-normalised editing by wikitext users and subsequent normalisation by > anyone using WYSIWYG would be messy and disruptive, but would a change > whereby it more precisely records the wikitext, and then doesn't try and > change it unless that part of the document is edited, be feasible? > Indeed, that's the nicest thing to do. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Question: why does it have to normalise at all? I do think that the editing environment at Wikipedia means that consistent non-normalised editing by wikitext users and subsequent normalisation by anyone using WYSIWYG would be messy and disruptive, but would a change whereby it more precisely records the wikitext, and then doesn't try and change it unless that part of the document is edited, be feasible? On 2 May 2011 19:34, Mark A. Hershberger wrote: > Thomas Dalton writes: > > > On 2 May 2011 13:09, Roan Kattouw wrote: > >> On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz > >> wrote: > >>> Editors do this all the time anyway. Typically using automated tools > >>> so they don't have to do any actual work. > >>> > >> Sure, but those aren't typically mixed with "real" changes in the same > >> edit. That's what was hard: spotting the actual changes in the midst > >> of all the normalization noise. > > > > The normalisation only really needs to happen once, though. > > What about combining the benefits of separated automatic edits with the > ease of WYSIWYG modification? > > Upon starting to edit the page the WYSIWYG editor automatically makes a > “normalization” edit. Such edits are noted with the comment “WYSIWYG > Normalization” or some such so that they're easy to find. > > When the user clicks “Save page”, a separate edit is made containing > just the user's changes. > > This seems like it would preserve the usefulness of diffs, doesn't it? > > ___ > 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
Re: [Wikitech-l] Media embedding: oEmbed feedback?
On 04/29/2011 05:40 PM, Bryan Tong Minh wrote: > On Fri, Apr 29, 2011 at 10:30 PM, Brion Vibber wrote: >> currently there's no exposed >> license metadata (highly desired for Wikimedia's usage, obviously) >> > Krinkle and me have been working on that a while ago, but after > discussion on this list it appeared that we were following a wrong > track. We'll probably have to discuss this in Berlin and get it > started again. > > > Bryan Thanks for already adding that to http://www.mediawiki.org/wiki/Berlin_Hackathon_2011#More_Ideas . -Sumana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 9:17 AM, Daniel Friesen wrote: > On 11-05-02 08:12 AM, Thomas Dalton wrote: > > No. I clearly said there would be small amounts of normalisation to > > deal with new wikitext edits, but that the whole article would only > > need to be normalised once. I was not assuming we would do away with > > wikitext editing entirely (and wouldn't support doing so). > He might be alluding to the fact that even after you normalize it, > someone not using WYSIWYG can go and make an edit that happens to use > pre-normalized stuff, and as a result that gets messed up the next time > someone edits using a WYSIWYG editor. > In a sane world, you might actually end up with the same normalization regardless of what method you used to edit; we do after all perform post-save transforms using the parser, which turns ~~~ into a signature, [[Foo (bar)|]] into [[Foo (bar)|Foo]] etc. It would not be unreasonable for a human- or bot-made source edit to get run through the parser for normalization on save, leaving you with only "real" diffs going forward. I think that "little" markup normalization like this will eventually not be too big a deal; either the system will start applying the normalization consistently, or it won't have to because all the information available to reconstruct the original source is round-tripped through the wysiwig side. A bigger deal will probably be actually changing structures that don't render consistently, and that'll depend on how brave we are changing nested template & table structures to fit a hierarchical document model. We've basically got two levels of stuff: * parsing wiki markup into a document structure that's useful for editing * using the document structure to render HTML output or an editing environment Our classic MediaWiki parser does only a tiny bit of the first in the preprocessor, and then leaves a lot more of our markup to the transformation layer, which is how we end up with things like templates that expand into an HTML tag opener, of which which some adjacent templates contain the contents and endings. If we can devise a way to consistently treat expansions that *aren't* a hierarchical match fro the HTML node tree, then we might not have to change templates much. If we can't, then we might have to start enforcing hierarchical template & other code nesting and go through and migrate a bunch of existing templates. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
Thomas Dalton writes: > On 2 May 2011 13:09, Roan Kattouw wrote: >> On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz >> wrote: >>> Editors do this all the time anyway. Typically using automated tools >>> so they don't have to do any actual work. >>> >> Sure, but those aren't typically mixed with "real" changes in the same >> edit. That's what was hard: spotting the actual changes in the midst >> of all the normalization noise. > > The normalisation only really needs to happen once, though. What about combining the benefits of separated automatic edits with the ease of WYSIWYG modification? Upon starting to edit the page the WYSIWYG editor automatically makes a “normalization” edit. Such edits are noted with the comment “WYSIWYG Normalization” or some such so that they're easy to find. When the user clicks “Save page”, a separate edit is made containing just the user's changes. This seems like it would preserve the usefulness of diffs, doesn't it? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
> Beyond that let's flip the question the other way -- what do we *want* > out > of WYSIWYG editing, and can that tool provide it or what else do we need? We want something simpler and easier to use. That is not what Wikia has. I could hardly stand trying it out for a few minutes. Fred ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r83795]: Revision status changed
User "Happy-melon" changed the status of MediaWiki.r83795. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83795#c0 Commit summary: Follow-up r83794, r83792: restore new SpecialBlock.php code from r83786. This revision should *not* be broken :D ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87270]: Revision status changed
User "^demon" changed the status of MediaWiki.r87270. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87270#c0 Commit summary: Update PHP minimum version checks to 5.2.3 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
On Mon, May 2, 2011 at 12:04 AM, Tim Starling wrote: > Can someone please tell me, in precise technical terms, what is wrong > with Wikia's WYSIWYG editor and why we can't use it? > > I have heard that it has bugs in it, but I have not been told exactly > what these bugs are, why they are more relevant for Wikimedia than for > Wikia, or why they can't be fixed. > > Years ago, we talked dismissively about WYSIWYG. We discussed the > features that a WYSIWYG editor would have to have, pointing out how > difficult they would be to implement and how we didn't have the > manpower to pull off such a thing. Now that Wikia has gone ahead and > implemented those exact features, what is the problem? > The most fundamental problem with Wikia's editor remains its fallback behavior when some structure is unsupported: "Source mode required Rich text editing has been disabled because the page contains complex code." Here's an example of unsupported code, the presence of which makes a page permanently uneditable by the rich editor until it's removed: a You can try this out now at http://communitytest.wikia.com/ It will at least let you edit other *sections* that don't contain anything that scares it, but if the nasty bit is somewhere in what you want to edit, it just doesn't recover. There are some smart things in what they're doing: annotating the markup ought to be a big help in hooking up the rendered HTML bits back to the original source. The way they hold template invocations and plugins as standalone placeholders within the rich text is pretty good (and could be a bit better if it could display some content and provide even more advanced invocation editing tools, which is all detail work). But if it just gives up on entire pages, we've got a problem because to handle Wikipedia we need to handle lllooonnnggg pages that tend to include lots of complex templates which pull in funky code of their own. At a minimum, assuming that other round-tripping problems are all resolved and the treatment of templates and extensions can be improved, it would need to be changed to recognize uneditable chunks and present them as a sort of placeholders too -- like the templates you should be able to dive into source and edit them if need be, but they ought not destroy the rest of the page. Beyond that let's flip the question the other way -- what do we *want* out of WYSIWYG editing, and can that tool provide it or what else do we need? I've written up some notes a few weeks ago, which need some more collation & updating from the preliminary experiments I'm doing, and I would strongly appreciate more feedback from you Tim and from everyone else who's been poking about in parser & editing land: http://www.mediawiki.org/wiki/Wikitext.next And also some of Trevor's notes which I have poked at: http://www.mediawiki.org/wiki/Visual_Editor_design I've got some aggressive ideas about normalizing how we deal with template expansion to work at the parse tree level; this can be friendlier to some levels of caching, splitting portions of parsing between PHP and optimized native code, or even mixing some things between pre-parsed text and client-side work, but most importantly I'm interested in making sure we have a relatively clean hierarchical relationship between parts of the document, which we can use to much more reliably hook up parts of the rendered HTML output: * maintain an abstract parse tree that can be hooked up fully to both the original source text *and* the live output DOM * do section, paragraph, or table-cell editing inline directly on a view page, with predictable replacements It may well be that this is too expansive and we'll want to contract to something that's more like Wikia's annotated parser output -- in most cases it should give us similar information but it'll probably be harder to replace parts of the page at runtime in JavaScript. Another goal beyond editing itself is normalizing the world of 'alternate parsers'. There've been several announced recently, and we've got such a large array now of them available, all a little different. We even use mwlib ourselves in the PDF/ODF export deployment, and while we don't maintain that engine we need to coordinate a little with the people who do so that new extensions and structures get handled. A new visual editor that's built around a normalized, defined parser could be a great help; other folks will be able to use compatible parsers instead of mostly-similar parsers. For the moment I'm mostly schooling myself on the current state of the world and setting up experimental tools to aid in debugging extra parser/editor-related goodies (eg the inspector tool I'm fiddling with at http://en.wikipedia.org/wiki/User:Brion_VIBBER/vector.js ), but hope to get some of these projects starting moving forward after Berlin. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wiki
[MediaWiki-CodeReview] [MediaWiki r87258]: New comment added
User "Kaldari" posted a comment on MediaWiki.r87258. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87258#c16494 Commit summary: FlickrChecker fixes, follow-up to r87002 and r87031 Comment: Oops! Should be fixed in r87269. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)
On 02/05/11 09:06, Max Semenik wrote: > I started that athttp://www.mediawiki.org/wiki/MediaWiki_1.17 some > time ago, needs more collaboration. And I started the 1.18 one with illustrative (and free) pictures :p http://www.mediawiki.org/wiki/MediaWiki_1.18 -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87259]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87259. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87259#c0 Commit summary: revert accidental inclusion of mw.FlickrChecker.js, not ready yet ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87031]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87031. Old Status: fixme New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87031#c0 Commit summary: further work on FlickrChecker module ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87002]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87002. Old Status: fixme New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87002#c0 Commit summary: initial partially functioning version of FlickrChecker ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87258]: New comment added, and revision status changed
User "Catrope" changed the status of MediaWiki.r87258.
Old Status: new
New Status: fixme
User "Catrope" also posted a comment on MediaWiki.r87258.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87258#c16493
Commit summary:
FlickrChecker fixes, follow-up to r87002 and r87031
Comment:
-( function( mw ) {
+( function( mw, $ ) {
You need to update the bottom end too (from (mediaWiki) to
(mediaWiki, jQuery)). My understanding is that this actually
''breaks'' the plugin by setting $ to undefined.
OK otherwise.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Leaderboard extension?
Daniel Mietchen googlemail.com> writes: > > Thank you, Siebrand! > > Daniel > Hello, I work at Wikia and I am familiar with that extension. If you have any specific questions feel free to get in touch with me. Also, there's a less raw view of the code available via trac: http://trac.wikia-code.com/browser/wikia/trunk/extensions/wikia/AchievementsII ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87203]: New comment added
User "Catrope" posted a comment on MediaWiki.r87203. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87203#c16492 Commit summary: (bug 28738) Implement request splitting in mw.loader so ResourceLoader requests with query strings longer than a certain value are split up. The maximum query string length is configurable, and this behavior is disabled by default. It's needed in rare cases where there is a query string length or GET variable length limit in place that the wiki admin can't raise. Comment: /me cries I guess I shouldn't code when I'm tired ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87203]: New comment added
User "✓" posted a comment on MediaWiki.r87203. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87203#c16491 Commit summary: (bug 28738) Implement request splitting in mw.loader so ResourceLoader requests with query strings longer than a certain value are split up. The maximum query string length is configurable, and this behavior is disabled by default. It's needed in rare cases where there is a query string length or GET variable length limit in place that the wiki admin can't raise. Comment: As "reqs" is an array, please don't run through it with a for-in-loop. + for ( var i=0; ihttps://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87262]: New comment added
User "Reedy" posted a comment on MediaWiki.r87262. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87262#c16490 Commit summary: Closures are a PHP 5.3 feature. MediaWiki currently requires PHP 5.2.3 or higher. Replacing anonymous function, aka closure with traditional method. Comment: You're mixing tabs and spaces! :O ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Empty files in distribution
On Sat, Apr 30, 2011 at 4:15 PM, Platonides wrote: > Johannes Weberhofer wrote: > > Dear all, > > > > there are two empty files in the distribution. Are they of any usage? > > > > /maintenance/archives/patch-page_no_title_convert.sql > > /maintenance/archives/patch-image_reditects.sql > > They aren't pointed by the files, so seem safe to delete. > > Brion, any reason to truncate the patches instead of removing? > (r16526 & r29128) > Looks like just bad patch reverts that removed the file contents but didn't actually delete. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87260]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r87260. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87260#c16489 Commit summary: * Removed Skin::reallyGenerateUserStylesheet() nothing uses it and nothing overrides it * Corrected Skin::generateUserJs() and Skin::generateUserStylesheet()'s comments: nothing override them anymore, also marked them as deprecated, only usage is action=raw&gen=(css|js) Comment: Res'''s'''ourceLoader ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87002]: New comment added
User "Kaldari" posted a comment on MediaWiki.r87002. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87002#c16488 Commit summary: initial partially functioning version of FlickrChecker Comment: Fixed in r87258. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87031]: New comment added
User "Kaldari" posted a comment on MediaWiki.r87031. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87031#c16487 Commit summary: further work on FlickrChecker module Comment: Fixed in r87258. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87031]: New comment added
User "Kaldari" posted a comment on MediaWiki.r87031. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87031#c16486 Commit summary: further work on FlickrChecker module Comment: I wanted to get feedback from neil on the interface implementation before I actually did anything with the data. You're correct that right now it doesn't do anything. I added a comment to that effect in r87258, so that it's not confusing. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87257]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87257. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87257#c0 Commit summary: consistant use of jQuery object ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for April 25, 2011 - May 02, 2011 Status changes this week Bugs NEW : 411 Bugs ASSIGNED : 39 Bugs REOPENED : 72 Bugs RESOLVED : 293 Total bugs still open: 5822 Resolutions for the week: Bugs marked FIXED : 151 Bugs marked REMIND : 0 Bugs marked INVALID: 57 Bugs marked DUPLICATE : 50 Bugs marked WONTFIX: 19 Bugs marked WORKSFORME : 17 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 8 LiquidThreads 5 Special pages 4 CentralAuth 3 ArticleFeedback 3 New Bugs Per Product MediaWiki 24 Wikimedia 16 MediaWiki extensions25 Top 5 Bug Resolvers sam [AT] reedyboy.net 13 jayvdb [AT] gmail.com 11 s.mazeland [AT] xs4all.nl 8 diebuche [AT] gmail.com 7 innocentkiller [AT] gmail.com 7 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84169]: Revision status changed
User "^demon" changed the status of MediaWiki.r84169. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84169#c0 Commit summary: Also remove message as followup to r84133 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)
On Mon, May 2, 2011 at 3:06 AM, Max Semenik wrote: > On 02.05.2011, 10:41 Tim wrote: > >> It would be nice if someone could write a user-oriented summary of the >> major changes in the branch, like I did for 1.16. The 1.16 one was >> used for the RELEASE-NOTES file, the mediawiki-announce email and the >> blog post. The 1.17 one would probably be used in the same places. > > I started that at http://www.mediawiki.org/wiki/MediaWiki_1.17 some > time ago, needs more collaboration. > Thank you for starting this. Sam and I are poking at it now. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)
On Mon, May 2, 2011 at 2:41 AM, Tim Starling wrote: >> Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has >> been dropped. Since 1.19's a little further out and hasn't started taking >> shape >> yet, I'd like to go ahead and propose what sort of release we should aim for. >> >> Going back over the past couple of releases, we've had quite a few "rewrites" >> of major portions of code. While these are a necessary part of the process of >> developing MW, they are difficult to review due to their complexity. This >> complexity also makes it more likely for things to break. If I may be so >> bold, >> I would like to ask that 1.19 not contain any of these rewrites. Let's focus >> on >> making it a bugfix/cleanup release. Personally I think it would make for a >> very >> clean and polished release, as well as reducing the time for us to review and >> ship it. > > The usual situation is that some developers are interested in features > and others are interested in bug fixes. If you declare that you only > want bug fixes, you risk losing the feature developers. > > I think that the best way to retain feature developers is to treat > them with respect and to value their contributions. That is why I > haven't proposed a "feature freeze" in the past. > I understand, respect, and value the contributions of people who want to add new features. Features are what moves the product forward, and at no point do we want to be hostile to people willing to put in their time and effort to add functionality. Given that our patch review process isn't fantastic, I really don't think it would affect the majority of bugs anyway. Mainly affected would be people with core access who write a new feature without putting it through BZ first. Given that our core group is relatively small, I figured we could come to some sort of consensus, if we do indeed move forward with this. > It would be possible to do a stability-oriented release if that's > really what the community wants, but it would have to be carefully > managed. We would have to increase our mentoring and review activity > in the development branches, and keep the schedule very tight indeed. > I don't know what our development community wants. I just happened to think it was a good idea and so brought it up for discussion. If we collectively decide I'm nuts, we can toss this proposal, I won't be upset. I know we'd need to keep development on a very strict timeframe, which is why I outlined a more strict branching and timeline to stick to. As Roan and others pointed out, 6 months is a little long. I don't think we couldn't decide on a branch point and stick to it, especially if we're not holding up a branch for someone to finish sorting out a rewrite or major feature they didn't quite resolve. > Given our past record, I'm not really confident that we can pull that > off. There's a risk of screwing it up badly and offending a lot of > people. Release management isn't exactly an organisational strength. > I agree it's not our strength, but I don't think we can't do it. I think sticking to a firm branch date would largely alleviate this issue. I remain convinced that a stability-focused release would be a good idea at some point, whether we do it now or in a year. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 11-05-02 08:12 AM, Thomas Dalton wrote: > On 2 May 2011 15:31, David Gerard wrote: >> On 2 May 2011 15:27, Thomas Dalton wrote: >> >>> The normalisation only really needs to happen once, though. There may >>> be a few little bits where people have made wikitext edits since the >>> last WYSIWYG edit, but the whole article will only need to be >>> normalised the first time there is a WYSIWYG edit. >> >> Only if you immediately go all-WYSIWYG and no-one is ever allowed to >> directly edit wikitext ever again. This strikes me as likely to go >> over very badly indeed. > No. I clearly said there would be small amounts of normalisation to > deal with new wikitext edits, but that the whole article would only > need to be normalised once. I was not assuming we would do away with > wikitext editing entirely (and wouldn't support doing so). He might be alluding to the fact that even after you normalize it, someone not using WYSIWYG can go and make an edit that happens to use pre-normalized stuff, and as a result that gets messed up the next time someone edits using a WYSIWYG editor. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 2 May 2011 15:31, David Gerard wrote: > On 2 May 2011 15:27, Thomas Dalton wrote: > >> The normalisation only really needs to happen once, though. There may >> be a few little bits where people have made wikitext edits since the >> last WYSIWYG edit, but the whole article will only need to be >> normalised the first time there is a WYSIWYG edit. > > > Only if you immediately go all-WYSIWYG and no-one is ever allowed to > directly edit wikitext ever again. This strikes me as likely to go > over very badly indeed. No. I clearly said there would be small amounts of normalisation to deal with new wikitext edits, but that the whole article would only need to be normalised once. I was not assuming we would do away with wikitext editing entirely (and wouldn't support doing so). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87226]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87226. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87226#c0 Commit summary: * (bug 28265) allow outputting of comments for action=expandtemplates ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87242]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87242. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87242#c0 Commit summary: Followup r87225 Best to rename everything when you rename something ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87225]: New comment added, and revision status changed
User "Catrope" changed the status of MediaWiki.r87225.
Old Status: new
New Status: ok
User "Catrope" also posted a comment on MediaWiki.r87225.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87225#c16485
Commit summary:
* (bug 27185) API: Add Special:ComparePages
Comment:
+ if ( isset( $params['fromtitle'] ) ) {
+ $vals['fromtitle'] = $params['fromtitle'];
+ }
Would be nice to unconditionally set $vars['fromtitle'] =
$rev1->getTitle()->getPrefixedText() or something, so it's normalized
and you get the title if you just specified a revid.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87206]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87206. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87206#c0 Commit summary: * (bug 26664) Add 'url' to meta=globaluserinfo and/or 'database' to action=sitematrix Added URL parameter to output of meta=globaluserinfo ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87216]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87216. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87216#c0 Commit summary: Use HTML5 for formatted API output ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83795]: New comment added, and revision status changed
User "Reedy" changed the status of MediaWiki.r83795. Old Status: new New Status: fixme User "Reedy" also posted a comment on MediaWiki.r83795. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83795#c16484 Commit summary: Follow-up r83794, r83792: restore new SpecialBlock.php code from r83786. This revision should *not* be broken :D Comment: ( ! ) Notice: Undefined index: DisableUTEdit in /home/reedy/mediawiki/trunk/phase3/includes/specials/SpecialBlock.php on line 828 While blocking a user ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 2 May 2011 15:27, Thomas Dalton wrote: > The normalisation only really needs to happen once, though. There may > be a few little bits where people have made wikitext edits since the > last WYSIWYG edit, but the whole article will only need to be > normalised the first time there is a WYSIWYG edit. Only if you immediately go all-WYSIWYG and no-one is ever allowed to directly edit wikitext ever again. This strikes me as likely to go over very badly indeed. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 2 May 2011 13:09, Roan Kattouw wrote: > On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz > wrote: >> Editors do this all the time anyway. Typically using automated tools >> so they don't have to do any actual work. Surely someone here has had >> to wade through someone changing every REF to that bag of hammers CITE >> tag. >> > Sure, but those aren't typically mixed with "real" changes in the same > edit. That's what was hard: spotting the actual changes in the midst > of all the normalization noise. The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87031]: Revision status changed
User "Catrope" changed the status of MediaWiki.r87031. Old Status: ok New Status: fixme Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87031#c0 Commit summary: further work on FlickrChecker module ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87031]: New comment added
User "Catrope" posted a comment on MediaWiki.r87031. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87031#c16483 Commit summary: further work on FlickrChecker module Comment: +* Retrieve the list of all current Flickr licenses and store it in an array (mw.FlickrChecker.licenses) [...] + mw.FlickrChecker.licenseList[value.id] = value.name; Documentation doesn't match the actual behavior. Also, this file aliases mw to mediaWiki correctly with a closure, but doesn't do the same with $. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87245]: New comment added
User "Reedy" posted a comment on MediaWiki.r87245. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87245#c16482 Commit summary: bug id : 28094 + bug related to the red link closed Comment: You do realise core MW has jquery 1.4.4 included? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz wrote: > Editors do this all the time anyway. Typically using automated tools > so they don't have to do any actual work. Surely someone here has had > to wade through someone changing every REF to that bag of hammers CITE > tag. > Sure, but those aren't typically mixed with "real" changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On Mon, May 2, 2011 at 1:29 PM, Tim Starling wrote: > What about using a kind of document tree representation of wikitext? > You could have an intermediate representation which precisely > represents all of the source wikitext, but was easy to convert to > displayable HTML. Kind of like HTML, but annotated to show which of > the multiple options for HTML to wikitext transformation should be > chosen on the return trip in order to preserve unchanged wikitext > precisely. > > That's what Wikia's editor does. It uses a subclass of the core > MediaWiki parser to generate HTML-like output which is richly > annotated with comments and custom attributes, allowing precise > round-trip transformation of unchanged text. > > The client side is not a generic HTML editor, rather it responds to UI > events by editing the intermediate DOM representation, using code > which is aware of the special structure of that document tree. > > Maybe there are remaining round-trip bugs, but there's no obvious > reason why they couldn't be fixed using this general approach. > Yeah that sounds good. I was unaware that Wikia had moved to this approach. >> So that's what I know about the issues when introducing FCKeditor to >> an existing wikitext 'codebase'. I hear it's fairly decent when used >> from the start, but I'm not familiar enough with it to comment on >> that. > > That's not what I hear. I hear that there were some teething problems, > especially related to round-trip conversion, but that those were > sorted out long ago. > > By the way, it's not FCKEditor. The server side seems to have been > rewritten from scratch by Wikia, and the client side has been extended > and patched. RTE is probably a good name for it, since that's what > they call it. > Well that just speaks to how ancient my experience with it is, I guess. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
