Last modified: 2014-11-17 09:21:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 20812 - Wikisource: IPs unable to flag articles as "proofread"
Wikisource: IPs unable to flag articles as "proofread"
Product: MediaWiki extensions
Classification: Unclassified
ProofreadPage (Other open bugs)
All All
: Normal major with 7 votes (vote)
: ---
Assigned To: ThomasV
Depends on:
  Show dependency treegraph
Reported: 2009-09-25 19:38 UTC by Cecil
Modified: 2014-11-17 09:21 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Allows IPs in Proofread.php (849 bytes, patch)
2009-11-16 08:37 UTC, Buxul T.
Allow IPs in prrofread.js (148 bytes, patch)
2009-11-16 08:37 UTC, Buxul T.
Allow Q4 and IPs in proofread.js (482 bytes, patch)
2009-11-16 10:08 UTC, Buxul T.
Allow Q4 and IPs in ProofreadPage.php (1.28 KB, patch)
2009-11-16 10:09 UTC, Buxul T.

Description Cecil 2009-09-25 19:38:01 UTC
In German Wikisource each transcribed text has to be proofreaded by to people. Until yesterday IPs also counted as real people and had the right to proofread texts. With the update yesterday this function was switched of at German Wikisource despite a more than clear majority of users being against it.
The reasoning behind it this "feature" that was forced on us is that proofreading has to be done by two different persons and it can't be controlled that a person just doesn't change the IP-address and then controls a second time. It seems that somebody has forgotten one of the fundamental principles of all the projects of Wikimedia: Assume good faith.

German Wikisource is a very small project with an overviewable number of people working there. We trust each other to do the best for our project and not sabotage each other. We also accept that there are a few people in our project who want to stay anonymous and don't create accounts. It's there good right.

Wikisource basically has two tasks: transcribing text (which is more and more done by OCR) and proofreading text. Therefor IPs are now actually more or less forbidden to participate at Wikisource. I never saw a consensus for discriminating IPs by not allowing them to work in a Wikimedia-project. Therefor I request that this unrequested, unwished and unaccepted "feature" will be treated as a bug and switched of at German Wikisource as fast as possible to prevent more damage. We don't want to loose valuable users.
Comment 1 Martin Seidel 2009-09-25 22:00:30 UTC
Allowing IPs participating by anonymous editings is another of the fundamental principles. This useless restriction is absolutly unacceptable.
Comment 2 joergens.mi 2009-09-26 07:34:08 UTC
Please remove this contraproduktiv restriction which is clearly against the basic thoughts on
all wiki-projects. I know several of this ip's in the real life, they wanted to be anonymus
by private reasen, and are upset about this restriction 
Comment 3 joergens.mi 2009-09-26 08:27:52 UTC
A small Addendum to my comment
They know that they are more anonymus by using an nickname, but the don't want use a nickname.
Everybody should be free to participate and not to be urged to do something. If they are 
urged to do so they tipically leave.  And the silly comparison with flagged revisions, used
somewhere else is simply false. They can participate even in wiki's which are using flagged revisions
(de ws don't use this feature), but they are forbidden to participate here.
Comment 4 ThomasV 2009-09-26 10:00:38 UTC
IPs are allowed to participate : they can proofread and correct articles. 
What you request is to let them flag an article as "proofread".

This would dramatically change the current 'double proofreading' system, 
because it relies on proofreading by two different users (unless the IP 
is using a fixed adress, and is whiteisted somewhere).

I would like to see a community consensus on this, outside of
A similar proposal was made 3 months ago at and received no support
Comment 5 joergens.mi 2009-09-26 13:02:58 UTC
To give a direct replay to this comment of ThomasV, the only person I know which wants to exclude IP'S from the proofreading process ist the developer of this extension ThomasV. He didn't get any positive feedback for his position in the article mentioned by him. 

You schould also see the discussions in the german wikisource. I'm sorry, but these comments are in german. for the last update, when there is interesst in the older problems we had, I can serch for the discussions in the german language ws scriptorim.

The same type of discussion we hav every time when there is an code change by ThomasV in his extension Proofread.  Everytime the only way we get information about code changes is when feateures dosn't work any longer, because of buggy, mostly untestet code  or by ThomasV intention. That is the reason I can't call his code changes updates.  

Comment 6 Cecil 2009-09-26 16:45:37 UTC
Also a reply to ThomasV: IPs can't proofread. Proofreading is a very concentrated reading of the text, comparing it systematically with the scan of the original work and then confirm that this meticulous reading was successfully done. Anything else is just spotting an error and correcting it. So you disabled them to do proofreading since they can't confirm it anymore by changing the status. And why should they do it if it is nothing worth anyway. It takes a lot of time and still two people with accounts have to do it too. So nobody benefits from it (unless you would call 3 rounds of correcting a benefit) but a lot of wasted time.

If somebody really wanted to sabotage the proofreading system, then he could also just create a sockpuppet. Nobody would ever be the wiser unless he makes it very obvious. Since there is no 'own work' included in proofreading we would never be able to guess that it is the same user with just two accounts. That's something that can be done in Wikipedia by comparing writing-style, typical grammer errors and stuff, but it is impossible in Wikisource since the writing-style is the one of Schiller, Goethe, Rilke, the brothers Grimm or some translator.

And yes, this similar proposal received no support in your way of counting, as you obviously don't count the reporter. But it also received no oppose in my way of counting since you are the programmer. That does not make you more important then the reporter of a proposal. This was a 1:1-situation and no consensus to forbid IPs to participate. And I'm sure if the reporter would have announced his proposal somewhere it would have gotten a lot of support. Most of us on de.WS spend our time with working on old texts and not doing meta-work by checking around on other projects, so we don't see them.
Comment 7 ThomasV 2009-09-27 07:20:32 UTC
I understand your point: you want IPs to be able to indicate that they 
proofread the text. 

I will not implement the solution you propose, because it implies to remove 
the double proofreading system, and because this would affect all other 
wikisources; such a radical change should at least be discussed with 
them beforehand.

The double proofreading system of the extension is not meant to be secure 
or sockpuppet-proof. It is just meant to be unambiguous. If we remove the 
current restriction on double proofreading, then users could make their 
own interpretation of the meaning of the buttons, and this would break 
the system.

If there is local consensus at, I suggest you configure your wiki 
so that IPs can indicate they proofread a page. The germans used to do 
this with a template before I introduced this buttons system. This should 
still work. Using local javascript, you guys can even create buttons linked 
to this template, so that IPs will not notice any difference.

Comment 8 Cecil 2009-09-27 18:01:44 UTC
What do you mean with radical change? This existes until a few days ago when you just implemented something else without a consensus. You don't need to implement the solution. It already exists since several years and you changed it without any consensus.

Can you show us one case of miss-use on German Wikisource? Just one to show us that your dictatorship has at least a root? There never was any problem with IPs when it came to proofreading. They are a part of our community while you treat them like dirt, like cheaters, like people who are not to be trusted at all. That is disgusting. It is called discrimination what you are doing. 
Comment 9 Thomas Bleher 2009-10-22 06:18:12 UTC
For anyone looking into this, the code in question was added in r52508.
It should be very easy to make this configurable, assuming of course that different communities want to handle this differently.
Comment 10 Buxul T. 2009-11-13 10:17:23 UTC
This patch for ProofreadPage.php Revision 58865 should solve the problem:

<       if (!$wgProofreadPageAllowIPs) {
<             if( ($old_q != $q) && $wgUser->isAnon() ) {
<                 $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
<                 return false;
<             }
<       }
>         if( ($old_q != $q) && $wgUser->isAnon() ) {
>             $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
>             return false;
>         }

and then you must set $wgProofreadPageAllowIPs=true in LocalSettings.php

I can't test it, because I don't have an running installation of ProofreadPage.
Comment 11 Buxul T. 2009-11-13 10:23:15 UTC

<     global $wgOut, $wgUser, $wgProofreadPageAllowIPs;
>     global $wgOut, $wgUser;
<       if (!$wgProofreadPageAllowIPs) {
<             if( ($old_q != $q) && $wgUser->isAnon() ) {
<                 $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
<                 return false;
<             }
<       }
>         if( ($old_q != $q) && $wgUser->isAnon() ) {
>             $wgOut->showErrorPage( 'proofreadpage_nologin', 'proofreadpage_nologintext' );
>             return false;
>         }
Comment 12 joergens.mi 2009-11-14 23:36:00 UTC
This seems to be the solution, we have been begging for in the german wikisource.

Could anyone be so polite to help Buxul T. to test it and if it's ok activate in wikisource.

I think it would be usefull to set the default for $wgProofreadPageAllowIPs to false.

This wouldn't change anything for the existing projects. And the projects, which wants to deviate
can set this to true. 

Comment 13 Buxul T. 2009-11-16 08:37:26 UTC
Created attachment 6788 [details]
Allows IPs in Proofread.php
Comment 14 Buxul T. 2009-11-16 08:37:57 UTC
Created attachment 6789 [details]
Allow IPs in prrofread.js
Comment 15 Buxul T. 2009-11-16 08:41:52 UTC
After testing my older patches on a ProofreadPage-Mediawiki Installation I must admit, that this first patches don't work. Now I uploaded two new patches for Proofread.php and proofread.js and in my installtion they work.

There must still be set $wgProofreadPageAllowIPs=true in Localsettings.php to use these patches.
Comment 16 Buxul T. 2009-11-16 10:08:55 UTC
Created attachment 6790 [details]
Allow Q4 and IPs in proofread.js
Comment 17 Buxul T. 2009-11-16 10:09:19 UTC
Created attachment 6791 [details]
Allow Q4 and IPs in ProofreadPage.php
Comment 18 Buxul T. 2009-11-16 10:12:12 UTC
The Patches 6790 and 6791 allow in addition to 6788 and 6789 the setting to quality level 4 to sysops, so that moving from older projects to PR2 is possible.

There must be set $wgProofreadPageAllowQ4=true in LocalSettings.php additional to $wgProofreadPageAllowIPs=true

I tested this patches in my local installation and there it work.
Comment 19 ThomasV 2009-11-16 10:26:10 UTC
Sorry but I will not add those patches. 
Please check the discussions from last month in the mailing list about that decision.
Comment 20 joergens.mi 2009-11-16 17:44:36 UTC
Can anyone verify that the solutions of Buxul T. will work and find an developer to add this to the code.

As ThomasV clearly states here, he isn't willing -  in my opinion for very personal reasons -  to add these more than usefull extension to this script.
Comment 21 gustavf 2009-11-16 17:52:20 UTC
Please add this fix to the code
Comment 22 Platonides 2009-11-16 18:08:11 UTC
So, after much digging, the relevant post seem to be
Comment 23 Buxul T. 2009-11-16 18:41:46 UTC
and there ThomasV said:

"Even if I am not willing to program an extra solution for,
I know that some admins are perfectly able to program the
solution they want. They do not need me for that. They know it."

And now I have wrote the patch and he is not willing to implement it. Very bad behaviour.
Comment 24 joergens.mi 2009-11-16 19:11:14 UTC
I think Buxul T. solution is a general one. It will fit on all projects. 

And it  gives the '''communities the choice''' to decide in which way they want to act. 

There is no problem that the communities which wants to stick to ThomasV opinion and ideas, can keep them by setting these two variables to false (which should be the default!). 

Communities which want to deviate, have now the possibilites to do so. 
* They can transfer old already proofread twice projects to this extension without additonal unneeded work. Buxul T. implementation to restrict this to admins sounds to be a good idea.
* They can allow ip's to proofread, because the haven't had any harm by ip's up to now. If there will be big problems in the future (I hope not) the community can decide to switch back to the ip restricted setting.
Comment 25 Michail Jungierek 2009-11-16 20:54:43 UTC
If this this patch is technical ok, i see no reason why this patch will not included. Other communities haves other criteria. German wikisource wants that any user can change the status of a page. Where is the problem?
Comment 26 ThomasV 2009-11-17 06:22:58 UTC
Buxul : you misunderstood what I said. When I wrote in the 
ML that admins can program the solution they need, I 
was referring to local javascript, and to the solution 
implemented by user xarax 2 years ago.

If something can be achieved through local configuration, 
I do not see why I should add it to the core of the 
extension, especially when other subdomains do not want it.
Also, it will be much easier for you to develop and maintain 
code locally.

Just check how the quality buttons worked at 
before I introduced the pagequality system: categories 
were added to the pages by local javascript. This should 
still work. Using local javascript, you can add the 
categories you want to the pages you want. 

Please note that this solution does not require a robot;
My suggestion to use a robot was intended to facilitate 
migration of already proofed texts, and is interesting 
only if wants to stay in the common pagequality 
system. However, if wants IPs to be able to mark 
pages as proofread, then they do not want to use the 
common pagequality system. 
Comment 27 joergens.mi 2009-11-17 15:01:32 UTC
I find it very interesting how ThomasV is arguing about 9 lines of code, which would improve the extension. And his arguments, that if someone else would do it will be ok - we have misunderstood him we are only allowed by him to do it the second best way.

He is arguing that a user Xarax can do this for us whith a lot more of java script code. I'm sorry Xarax isn't active as an user anymore (we are quite unhappy about that, only Bot-activities can be seen within in the last 6 month). A experienced programmer - a person who we are laking at the moment - should write a lot of code to circumvent the obstacles, it must be tested in the real environment including removing the bugs, we haf bad experiences about that. 
And his argument other subdomains don't want it (which one? french community should be clear - or?). If you look at the communications,in total more people are arguing for enhancing the extension then against. 

Here you have a list of the communities working with proofread

The biggest curiousity is ThomasV introduced a big change in the extension without talking to a lot of communities. We must learn it the hard way, by notifying that things which had run good for quite a long time, won't run anymore suddenly. I think most of the communites didn't know up to now, what had happened and therefore don't take part in the communication. (I don't think that a lot of communites are converting multithousand page projects to Proofread 2). 

I think you should also read this comment here


p.s. we want to use the the page quality system but without beeing overruled. We believe in the wiki system and assume good faith (AGF) by the people which are contributing.

Comment 28 John Mark Vandenberg 2009-11-19 15:31:21 UTC
Please provide unified diffs using "diff -ur old/ new/"

More fundamentally, I think it is necessary for the Proofread Page extension to not include access control.  It should probably use the userCan hook, and let another extension implement access control.

I would prefer to see a matrix that defines what user groups are able to perform tasks at various stages.

The following would prevent IPs from proofreading pages.

  $wgGroupPermissions['autoconfirmed']['proofread'] = true;
  $wgProofreadPageStageProtection['*'] = array( 'proofread' );

The following would prevent IPs from validating pages.

  $wgGroupPermissions['autoconfirmed']['validate'] = true;
  $wgProofreadPageStageProtection[3] = array( 'validate' );

It should be possible to add a sysop-only fourth stage with:

  $wgGroupPermissions['sysop']['finalise'] = true;
  $wgProofreadPageStageProtection[4] = array( 'finalise' );

Another approach would be:

  $wgProofreadPageMaxStage['anon'] = 1;
  $wgProofreadPageMaxStage['autoconfirmed'] = 3;
  $wgProofreadPageMaxStage['sysop'] = 4;
Comment 29 Hesperian 2009-11-19 23:53:40 UTC
As I understand it, Thomas objects to this proposal and patch because the new <pagequality> tag integrates the various language domain implementations, allowing the automatic maintenance of pages like <>. This page compares the progress of different domains, and therefore must use the same metric for each domain. Otherwise it is useless. The proposed patch changes how progress is measured for a single domain, and thus would invalidate the entire integration. This is why Thomas opposes it.

The choices, then, are:
1. Thomas could patch all of the domains... but this would require consensus across all of them, not just de.wikisource;
2. de.wikisource can withdraw from the integrated page quality system and fix their problem. No patch is needed for this; they need only revert their local Javascript to a version that does not use the <pagequality> tag.
Comment 30 joergens.mi 2009-11-20 12:18:16 UTC
I agree with Vandenberg's proposal. His point that there is no need for an alternative Access Control System is very important. We schould have one and exactly one user access control system. 

Therefore from my point of view. 
- There should be the possibility for IP's to contribute as before. 
- At least Admins should have the right to set the proofread level according to the needs, for converting older already proofreaded projects to the proofread extension. No curious / buggy workarounds by bots.
- Only one User access-system. Exactly speaking the access control system which is implemented in the mediawikisw  (userCan)

@Snottygobble, we don't have to fix aproblem we have. We want the unheralded change of the last update deactivated or changed to a community selectable access system. 

What I find funny, the we, who were the cutting edge in proofreading - as ThomasV statet - in Wikisource should be the bad guys which don't understand what happens (Is there a possibility that we have more experience, because we doing this job longer than most of the other projects?). The allegation that we are complaining because the other are luckily stepping up to us is ridiculous. The french and english wikisource have overhauled us a long time ago in some numbers. Nobody of us is complaining about that. Far from it, we are happy that all wikisources are coming up to a high level of quality. 


Comment 31 Hesperian 2009-11-20 14:01:25 UTC
"We want the unheralded change of the last update deactivated." You've been told, repeatedly, that you don't need a patch applied in order to achieve this. Simply revert your javascript back to a version that uses your old page quality template, instead of the <pagequality> tag. This will give you precisely what you want. It will also effect the removal of de.wikisource from the global statistics pages; but this is not unreasonable, given you will have rendered your statistics incommensurable by opting for a different approach to validation.

Please bear in mind that this is a bug tracking system, and what is considered fair comment here is very different to what might be acceptable on Wikimedia discussion pages or the mailing lists. Comments here should be directed towards explaining or resolving the bug.

Note You need to log in before you can comment on or make changes to this bug.