Last modified: 2010-05-15 14:36:02 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 5409 - Don't show "show/hide patrolled edits" ("showhideminor") when patrolling is disabled
Don't show "show/hide patrolled edits" ("showhideminor") when patrolling is d...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.6.x
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-31 12:16 UTC by Rotem Liss
Modified: 2010-05-15 14:36 UTC (History)
1 user (show)

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


Attachments
Patch (9.93 KB, patch)
2006-03-31 18:17 UTC, Rotem Liss
Details
Patch v2 (9.94 KB, patch)
2006-04-04 10:44 UTC, Rotem Liss
Details

Description Rotem Liss 2006-03-31 12:16:07 UTC
When patrolling is disabled (for example, in the English Wikipedia, Commons,
Meta, Hebrew Wikiquote, Hebrew Wikisource, Hebrew Wikibooks, Hebrew Wiktionary
and Hebrew Wikinews - actually, in each project I use, although it's enabled in
the Hebrew Wikipedia), we however show "$4 patrolled edits" in "showhideminor",
and it's confusing. I suggest to create two system messages, becoming of
"showhideminor":
* "showhide"
* "showhidepatrolled"
when "showhide" doesn't include the "$4 patrolled edits" part, but
"showhidepatrolled" does, and to show them. (I don't want "showhideminor",
because this name is now not exact.)

I'm working on a patch. Because I can also change it in MessagesHe.php and I
think you cannot, I request that you won't fix that bug by patch of yourself.

I won't fix that bug in REL1_5 this time.

And two other things:
* "$5" should be included in Messages.php, like in MessagesHe.php now - it is
Bug #5009, and I will fix it here. Then it will be Resolved Worksframe. I don't
want to fix it there, because I will have to wait to the synchronization till I
will be able to fix this bug.
* We should swap the patrolled ($4) and my edits ($5) locations, because "my
edits" ($5) is similar to "registered users" ($3).

I think I will be able to create a patch in some hours. Please wait.

Thank you very much.
Comment 1 Rob Church 2006-03-31 12:48:01 UTC
(In reply to comment #0)
> * "$5" should be included in Messages.php, like in MessagesHe.php now - it is
> Bug #5009, and I will fix it here.
If CVS were working, the fix for this oversight would have been checked in by
now; I came across it myself when working on something else last night.

> * We should swap the patrolled ($4) and my edits ($5) locations, because "my
> edits" ($5) is similar to "registered users" ($3).
Don't swap parameter order in interface messages unless there's a real good
reason, since it will break a hell of a lot of wikis.

Comment 2 Rotem Liss 2006-03-31 13:16:57 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > * "$5" should be included in Messages.php, like in MessagesHe.php now - it is
> > Bug #5009, and I will fix it here.
> If CVS were working, the fix for this oversight would have been checked in by
> now; I came across it myself when working on something else last night.
Please don't, because then I will have to wait some hours, or one day, before I
will be able to create a proper patch here.
> > * We should swap the patrolled ($4) and my edits ($5) locations, because "my
> > edits" ($5) is similar to "registered users" ($3).
> Don't swap parameter order in interface messages unless there's a real good
> reason, since it will break a hell of a lot of wikis.
I think it won't, because we also replace the interface message names, so even
before MediaWiki default will be used to create it, it will be availlable.
Comment 3 Rob Church 2006-03-31 13:31:20 UTC
(In reply to comment #2)

[sigh]

1. You won't be able to submit a patch against CVS HEAD while CVS is down
regardless. And I couldn't care less about a third party patch, I would have to
edit the message to add functionality anyway.

2. Missed the entire point of the statement.
Comment 4 Rotem Liss 2006-03-31 13:40:08 UTC
(In reply to comment #3)
> (In reply to comment #2)
> 1. You won't be able to submit a patch against CVS HEAD while CVS is down
> regardless. And I couldn't care less about a third party patch, I would have to
> edit the message to add functionality anyway.

I can log in to the CVS (cvs login - my CVSROOT is the MediaWiki CVS - works,
but I didn't check the diff). Maybe the CVS for anonymous users is not down.

As for the second statement - what do you mean? I will have to create a patch
with "diff" anyway.

> 2. Missed the entire point of the statement.

Do you mean I missed etc., or you missed etc.?
Comment 5 Rotem Liss 2006-03-31 18:17:35 UTC
Created attachment 1488 [details]
Patch

The patch does what I've suggested, and although I didn't use
rebuildMessages.php in my installed Wiki (which has installed with
"showhideminor"), it didn't break it, just left behind the useless page
"MediaWiki:Showhideminor".

The patch is for CVS MAIN (HEAD) only - I won't create a patch for REL1_5.
Please check it in soon.

As for the non-English and non-Hebrew projects, they will need update their
language file; nowadays, this message will be shown in English for them.
Comment 6 Rotem Liss 2006-04-04 08:24:22 UTC
When I will be able to use Subversion (when understanding the commands, etc.), I
will create a new patch - I see you've added a new option, of hiding the
anonymous edits, and by the way fixed Bug #5009.
Comment 7 Rotem Liss 2006-04-04 10:44:38 UTC
Created attachment 1496 [details]
Patch v2

Updated patch, due to recent updates and the switch to Subversion.
Comment 8 Rob Church 2006-04-04 13:11:00 UTC
The bug is fixed in SVN HEAD, but I took the opportunity to clean up that
segment of code. I didn't want to hack in more stuff, so I split up the message
and did it in a nice clean fashion.

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


Navigation
Links