Re: [Wikitech-l] "Reject" button for Pending Changes
On Sun, Jun 27, 2010 at 11:11 PM, Rob Lanphier wrote: > I just don't think there's a clean way to reject an intermediate pending > revision. Accepting? Sure, wonderful, that will work well. There's a > reasonably strong argument for encouraging acceptance of intermediate > revisions as part of the review process (so long as it always involves > comparison to the latest accepted revision). But encouraging undo on > intermediate revisions leaves things in a really weird place. And that's in the cases when the undo is even possible. If there are three unreviewed edits P1, P2, P3 in order, it may be impossible to undo P2 without simply reverting to P1, which loses the content of P3. That is a situation we do not want to encourage. I view all this as a strong reason not to have an "reject" button. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier wrote: > "Unaccept" seems suitably rare that I think we should consider a > confirmation screen which shows the effect of unaccepting (i.e. a diff > between the latest accepted revision and the penultimate accepted revision). > Does that seem like a reasonable enough failsafe to keep this from being > used unintentionally? This seems beneficial even in the case where the > reviewer knew they were hitting "unaccept". I had the impression that "unaccept" does not add a new revision to the page, it simply removes the db entry that the revision in question was "accepted". Is that wrong? There are two reasons why that ''should'' be the behavior: (1) If I go back and "unaccept" a revision from two days in the past that was mistakenly accepted, I should not have to edit the page again to restore the previous content. (2) "Accept" does not add a revision to the page, and "unaccept" should only undo what "accept" does. That is, the sequences "accept => unaccept " and "unaccept => accept" should be able to be iterated as many times as desired, leaving everything in exactly the same state apart from log entries. - Carl ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On 28 June 2010 12:19, Carl (CBM) wrote: > On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier wrote: >> "Unaccept" seems suitably rare that I think we should consider a >> confirmation screen which shows the effect of unaccepting (i.e. a diff >> between the latest accepted revision and the penultimate accepted revision). >> Does that seem like a reasonable enough failsafe to keep this from being >> used unintentionally? This seems beneficial even in the case where the >> reviewer knew they were hitting "unaccept". > > I had the impression that "unaccept" does not add a new revision to > the page, it simply removes the db entry that the revision in question > was "accepted". Is that wrong? That's correct, but from the point of view of someone only viewing accepted versions it will be like a revert. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On 28 June 2010 04:11, Rob Lanphier wrote: > I had forgotten that "undo" might possibly actually do something useful in > this context. That said, let's recap what has happened so far. > > You start with accepted revision A1, and have pending revisions P1, P2, and > P3. Once the user rejects P1, lets assume that that creates a new pending > revision P4 that is the result of that undo. Now what? If they then review > the diff between P1 and P2, they might mistakingly accept P2, even though it > still contains the delta between A1 and P1. We could ask them to review the > diff between P1 and P4, but that's now an aggregate of the P1P2 delta and > the P2P3 delta, sans the A1P1 delta. > > I just don't think there's a clean way to reject an intermediate pending > revision. Accepting? Sure, wonderful, that will work well. There's a > reasonably strong argument for encouraging acceptance of intermediate > revisions as part of the review process (so long as it always involves > comparison to the latest accepted revision). But encouraging undo on > intermediate revisions leaves things in a really weird place. Ah... you're right. I hadn't thought things through carefully enough. Ok, how about alternative D? D: 1) Display diff between A1 and P1. 2) P1 is rejected. Nothing happens to the database at this point, the rejection of P1 is just remembered somewhere. 3) Display a diff between A1 and "P2 minus A1P1 delta" (that can be created temporarily using the undo feature) 4a) If that diff is rejected, display a diff between A1 and "P3 minus A1P2 delta" (or equivalently, "P3 minus A1P1 delta minus P1P2 delta"). 4b) If that diff (in 3) is accepted, display a diff between "P2 minus A1P1 delta" and "P3 minus A1P1 delta". 5) Continue in what I hope is the obvious fashion, because I'm thoroughly confused! 6) Create a revision equal to that latest accepted pseudo-revision and mark it as accepted. This will be a mess to program (and no, I'm not volunteering!), but it should be very intuitive for the reviewer. If at any time the undo feature can't create one of the pseudo-revisions (the ones in quotes), you just fail gracefully. What do you think? PS The aspirin is in the second drawer on the left! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions in questions of skin?
Hey Martin, You've written to the MediaWiki technical list, which probably is not the right place for this discussion. You may instead want to write the Wikipedia-L mailing list, which focuses on issues that affect Wikipedia as a whole. The page for this list is https://lists.wikimedia.org/mailman/listinfo/wikipedia-l. Cheers! --zak ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions in questions of skin?
2010/6/28 Zak Greant (Foo Associates) > > You may instead want to write the Wikipedia-L mailing list, which > focuses on issues that affect Wikipedia as a whole. The page for this > list is https://lists.wikimedia.org/mailman/listinfo/wikipedia-l. Foundation-l would be even better: https://lists.wikimedia.org/mailman/listinfo/foundation-l -- אָמִיר אֱלִישָׁע אַהֲרוֹנִי Amir Elisha Aharoni http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions in questions of skin?
> You've written to the MediaWiki technical list, which probably is not > the right place for this discussion. Sure it is. It is a question to the System administrators by the community (or parts of it). Discussing it in the community itself won't help answering the question. foundation-l might be a bit better than wikipedia-l, but still it is a very concrete and legitimate question: "Will the system administrators change the default skin for a wiki, provided there is an consensus by the wiki community?" A simple "Yes" or "No" would suffice. (I'd argue that changing the skin to vector is a strategic decision by WMF and cannot be overruled by local communities - but that's something a system administrator has to decide.) Regards, CoE signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions in questions of skin?
> (I'd argue that changing the skin to vector is a strategic decision by > WMF and cannot be overruled by local communities - but that's something > a system administrator has to decide.) > I'd say the system administrators will do as the foundation (board perhaps? or some other organ) says. Having different looks on different wikipedias is raising some identity questions, but I'd say that the simple fact that right now en.wiki looks in a way and smaller wikis look differently is a hint that the problem is not that serious. I'm really curious about the outcome of this discussion, be it here or not :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions in questions of skin?
Hoi, Wikimedias development is centred on one skin. This used to be monobook and it is now vector. The question if a community may elect to be conservative / retro / different ignores this issue. There will be some effort to maintain other skins as well but as history has shown, bit rot will creep in. New functionality will not be designed to work with other skins. As it is there is very little communities can ask to be implemented for them. A good example is the Babel extension that is wished for by many communities. Thanks, GerardM On 28 June 2010 19:58, Strainu wrote: > > (I'd argue that changing the skin to vector is a strategic decision by > > WMF and cannot be overruled by local communities - but that's something > > a system administrator has to decide.) > > > > I'd say the system administrators will do as the foundation (board > perhaps? or some other organ) says. > > Having different looks on different wikipedias is raising some > identity questions, but I'd say that the simple fact that right now > en.wiki looks in a way and smaller wikis look differently is a hint > that the problem is not that serious. I'm really curious about the > outcome of this discussion, be it here or not :) > > ___ > 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] Wikisource bugs
There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed. ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper. People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Reject" button for Pending Changes
On Mon, Jun 28, 2010 at 8:13 AM, Thomas Dalton wrote: > Ok, how about alternative D? > > D: > > 1) Display diff between A1 and P1. > 2) P1 is rejected. Nothing happens to the database at this point, the > rejection of P1 is just remembered somewhere. > 3) Display a diff between A1 and "P2 minus A1P1 delta" (that can be > created temporarily using the undo feature) > 4a) If that diff is rejected, display a diff between A1 and "P3 minus > A1P2 delta" (or equivalently, "P3 minus A1P1 delta minus P1P2 delta"). > 4b) If that diff (in 3) is accepted, display a diff between "P2 minus > A1P1 delta" and "P3 minus A1P1 delta". > 5) Continue in what I hope is the obvious fashion, because I'm > thoroughly confused! > 6) Create a revision equal to that latest accepted pseudo-revision and > mark it as accepted. > > This will be a mess to program (and no, I'm not volunteering!), but it > should be very intuitive for the reviewer. If at any time the undo > feature can't create one of the pseudo-revisions (the ones in quotes), > you just fail gracefully. > > What do you think? > Hi Thomas, I think this may be the way we could have done this if we were designing the feature from scratch (and it may be something to consider for a major rewrite, should we embark on that), but given the scope of changes we should probably make at this point, I'm guessing we'll probably need to table this particular suggestion. In general, I think you're touching on what is (what I think) is the really common desire here, which is that if people go through the trouble of reviewing a diff, and it's bad, they want some way of flagging a delta as bad, rather than implicitly rejecting it through jumping through some hoops. However, as Gregory would point out, that's just not the way the software is currently designed. I think we should still figure out the best way(s) to accommodate this desire, but I hesitate to go so far as adding a new flag in the database for rejected revisions. It wouldn't hurt to document this as an alternative for a possible redesign, though. PS The aspirin is in the second drawer on the left! Thanks, I'll need it ;-) Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-determination of language versions inquestions of skin?
"Gerard Meijssen" wrote in message news:aanlktimbfwbz3nlb-aaqcywbsmg3igxmv2zuq3roe...@mail.gmail.com... > Hoi, > Wikimedias development is centred on one skin. This used to be monobook > and > it is now vector. The question if a community may elect to be conservative > / > retro / different ignores this issue. There will be some effort to > maintain > other skins as well but as history has shown, bit rot will creep in. New > functionality will not be designed to work with other skins. Why not? Isn't the whole *point* of a skinning system that users can choose which skin to use *without* affecting functionality? Otherwise, it's not a skin, it's a different user interface. If Gerard is correct and only the 'current' skin is supported, then all other skins should be removed from the software (including monobook). Conversely, as long as they remain part of the software, they should be supported. It is absolutely bonkers to ship with unsupported features, particularly for such a critical element as the user interface. - Mark Clements (HappyDog) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How to to replace output of SpecialPage (for use as SPARQL endpont)?
Is it possible (and if so, how to) totally replace the output from a Special page (including the sending headers etc)? That is, can I use a SpecialPage as a SPARQL Endpoint and have it output pure RDF/XML (or similar) if a SPARQL query is sent to it via POST, while if not, it should just display the SpecialPage including a form for submitting a SPARQL query. Samuel -- Samuel Lampa --- Biotech Student @ Uppsala University GSoC Student @ Semantic MediaWiki --- E-mail: samuel.lampa[at]gmail.com Mobile: +46 (0)70-2073732 Blog: http://saml.rilspace.org Twitter: http://twitter.com/samuellampa --- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to to replace output of SpecialPage (for use as SPARQL endpont)?
On Mon, Jun 28, 2010 at 8:19 PM, Samuel Lampa wrote:
> Is it possible (and if so, how to) totally replace the output from a
> Special page (including the sending headers etc)?
>
> That is, can I use a SpecialPage as a SPARQL Endpoint and have it output
> pure RDF/XML (or similar) if a SPARQL query is sent to it via POST,
> while if not, it should just display the SpecialPage including a form
> for submitting a SPARQL query.
>
It sure is! In your execute() method, you'll want to call $wgOut->disable().
This'll turn off the regular page display output at the end of request
processing, and give you a chance to take over and do whatever you like, eg
sending appropriate HTTP headers and output directly.
The traditional example I always like to use is Special:Export in the core
code. If you bump down a bit past the initialization code and input
validation, you'll see this code that's called just before we're actually
doing the XML output:
if ( $this->doExport ) {
$wgOut->disable();
// Cancel output buffering and gzipping if set
// This should provide safer streaming for pages with history
wfResetOutputBuffers();
$wgRequest->response()->header( "Content-type: application/xml;
charset=utf-8" );
You should always be sure to set the content-type correctly; and if
outputting XML or HTML, be sure to include a charset header.
The wfResetOutputBuffers() bit isn't required in most cases, but if you're
outputting a *lot* of data it can help to let you stream output directly to
the downloader. (By default, buffering is used to apply gzip encoding and
send a Content-Size header. This is usually good, but means that all your
output has to be built and stored in memory before it actually gets sent to
the client... potentially a problem if you're streaming out fifty thousand
revisions of [[Hurricane Katrina]]!)
When you're doing your raw output, you can go ahead and do 'print' or 'echo'
directly if you like -- you're now in control. ;)
As a general note -- always be careful of your output to make sure you're
applying proper escaping when generating HTML or XML; raw output can be a
security risk if input isn't sanitized properly.
-- brion vibber (brion @ pobox.com)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikisource-l] Wikisource bugs
On 06/28/2010 11:25 PM, Birgitte SB wrote: > Are you thinking of some bugs in paticular? I would like to see what > has already been said at bugzilla if you have the numbers. Force now to look, I'm surprised to find there really are only a few reported bugs in the ProofreadPage extension. Some of the bugs I've long waited for to be fixed are instead in the PDF/Djvu page extraction, which is not part of ProofreadPage, https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 https://bugzilla.wikimedia.org/show_bug.cgi?id=23326 I have a long time frustration with how over-complicated ProofreadPage is with its extra namespaces, new tags and dozens of parameters that each newcomer needs to learn, and it spilled over yesterday when I registered https://bugzilla.wikimedia.org/show_bug.cgi?id=24168 If there are more bugs, they should be reported in Bugzilla. But what also really needs to be done is to reconsider if ProofreadPage really needs to be all this complicated. Maybe I should register that as a bug? I wish to clarify that my first post should not be read as a personal attack on ThomasV. We all want Wikisource to improve and grow, and we're working together towards that goal. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to to replace output of SpecialPage (for use as SPARQL endpont)?
Ah, there we go! :) Obviously didn't search the right places. Thanks!
Samuel
On 06/29/2010 03:07 AM, Brion Vibber wrote:
> On Mon, Jun 28, 2010 at 8:19 PM, Samuel Lampawrote:
>
>
>> Is it possible (and if so, how to) totally replace the output from a
>> Special page (including the sending headers etc)?
>>
>> That is, can I use a SpecialPage as a SPARQL Endpoint and have it output
>> pure RDF/XML (or similar) if a SPARQL query is sent to it via POST,
>> while if not, it should just display the SpecialPage including a form
>> for submitting a SPARQL query.
>>
>>
> It sure is! In your execute() method, you'll want to call $wgOut->disable().
> This'll turn off the regular page display output at the end of request
> processing, and give you a chance to take over and do whatever you like, eg
> sending appropriate HTTP headers and output directly.
>
> The traditional example I always like to use is Special:Export in the core
> code. If you bump down a bit past the initialization code and input
> validation, you'll see this code that's called just before we're actually
> doing the XML output:
>
> if ( $this->doExport ) {
> $wgOut->disable();
> // Cancel output buffering and gzipping if set
> // This should provide safer streaming for pages with history
> wfResetOutputBuffers();
> $wgRequest->response()->header( "Content-type: application/xml;
> charset=utf-8" );
>
> You should always be sure to set the content-type correctly; and if
> outputting XML or HTML, be sure to include a charset header.
>
> The wfResetOutputBuffers() bit isn't required in most cases, but if you're
> outputting a *lot* of data it can help to let you stream output directly to
> the downloader. (By default, buffering is used to apply gzip encoding and
> send a Content-Size header. This is usually good, but means that all your
> output has to be built and stored in memory before it actually gets sent to
> the client... potentially a problem if you're streaming out fifty thousand
> revisions of [[Hurricane Katrina]]!)
>
> When you're doing your raw output, you can go ahead and do 'print' or 'echo'
> directly if you like -- you're now in control. ;)
>
> As a general note -- always be careful of your output to make sure you're
> applying proper escaping when generating HTML or XML; raw output can be a
> security risk if input isn't sanitized properly.
>
> -- brion vibber (brion @ pobox.com)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
--
Samuel Lampa
---
Biotech Student @ Uppsala University
GSoC Student @ Semantic MediaWiki
---
E-mail: samuel.lampa[at]gmail.com
Mobile: +46 (0)70-2073732
Blog: http://saml.rilspace.org
Twitter: http://twitter.com/samuellampa
---
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to to replace output of SpecialPage (for use as SPARQL endpont)?
... and many thanks for the additional hints. Will surely come handy as the aim is to be able to use the endpoint for (batchlike) RDF export too. Samuel On 06/29/2010 03:07 AM, Brion Vibber wrote: > You should always be sure to set the content-type correctly; and if > outputting XML or HTML, be sure to include a charset header. > > The wfResetOutputBuffers() bit isn't required in most cases, but if you're > outputting a*lot* of data it can help to let you stream output directly to > the downloader. (By default, buffering is used to apply gzip encoding and > send a Content-Size header. This is usually good, but means that all your > output has to be built and stored in memory before it actually gets sent to > the client... potentially a problem if you're streaming out fifty thousand > revisions of [[Hurricane Katrina]]!) > > When you're doing your raw output, you can go ahead and do 'print' or 'echo' > directly if you like -- you're now in control.;) > > As a general note -- always be careful of your output to make sure you're > applying proper escaping when generating HTML or XML; raw output can be a > security risk if input isn't sanitized properly. > -- Samuel Lampa --- Biotech Student @ Uppsala University GSoC Student @ Semantic MediaWiki --- E-mail: samuel.lampa[at]gmail.com Mobile: +46 (0)70-2073732 Blog: http://saml.rilspace.org Twitter: http://twitter.com/samuellampa --- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource bugs
This email highlighted and remind me of a couple of issues, 1. The indexing functionality and how it fails for transcluded pages; which is integral to ProofreadPage when it transcludes working pages into the main namespace for display. https://bugzilla.wikimedia.org/show_bug.cgi?id=18861 (thanks to MZMcBride for helping me track this down) 2. The support around djvu files in general, which is improved, though still lacking in the extension, see https://bugzilla.wikimedia.org/show_bug.cgi?id=8480 Both of which have an impact for WS, though not exclusive to the site. Regards, sDrewth On 28 Jun 2010 at 23:22, Lars Aronsson wrote: > There is a lot of potential in Wikisource, but it depends > heavily on the ProofreadPage extension and it has several > bugs that are reported but don't get fixed. > > ThomasV is the main developer and perhaps he is the only > maintainer? It would be in the interest of the Wikimedia > Foundation to assign a salaried developer or two into > developing a more robust framework for Wikisource, either > by improving the existing extension or by integrating > some or all of its functionality into MediaWiki proper. > > People everywhere have a need to make some PDF (or Djvu) > document available on a website, page by page, with the > ability to add categories and talk pages. This ability > is what the ProofreadPage extension adds to MediaWiki. > In my mind, it is as essential as the support for uploading > JPEG images and automatically generating thumbnails. > Adding multipage documents to a wiki should be a far more > common need than adding mathematical equations. > > > -- >Lars Aronsson (l...@aronsson.se) >Aronsson Datateknik - http://aronsson.se > > > > ___ > 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
