Wikipedia talk:Bug reports and feature requests

From Wikipedia, the free encyclopedia
Jump to: navigation, search
the Wikipedia Help Project  
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory. Or ask for help on your talk page and a volunteer will visit you there.
 ???  This page does not require a rating on the project's quality scale.
 ???  This page has not yet received a rating on the project's importance scale.

mobile bug[edit]

I don't care for registering on bugzilla, esp. Since I can't use my wiki acct, so I'll post it here. Someone else might pick this up, if not I don't really care. I was browsing the wiki article for Boris_(band) using the mobile interface on an iPod touch. I clicked 'disable mobile interface' at the bottom of the page (it's useless as it doesn't use the whole screen). It accepted the change then tried to redirect me to the original article, but seems to have screwed up the referred address. Solution: disable URL escaping or w/e on the layout setting processor. —Preceding unsigned comment added by (talk) 09:03, 4 December 2009 (UTC)


I just noticed that wiki markup for bold works but italics are rendering as plain/normal text in mobile site. Really affects reading where italics are used for emphasis or scare quoting. Either that or chrome is ignoring oblique rule. — Preceding unsigned comment added by Crazytonyi (talkcontribs) 06:52, 11 September 2013 (UTC)


I have tried to refactor the page, so that it may become actually useful. I removed all 'bugs' that were dealt with, that weren't bugs or weren't wikipedia-bugs. I also removed many 'bugs' that were reported just once, which may have been resolved.

It is my hope that now this page is a little cleaner, some of the admins/developers might actually find useful feedback here. -- Ec5618 19:14, 28 January 2006 (UTC)

There is a reason why Bugzilla was developed, and that is why the developers want you to use Bugzilla instead of this page. Bugzilla hooks up to the developer's IRC channel, it provides numerous facilities for marking bugs certain status, priority levels, and types, it has a much better search facility, and plus, each bug gets its own page. I think it's high time this page gets deprecated, deleted, and replaced with content that explains to users how to use Bugzilla, as well as giving short descriptions of fairly old bugs and links to appropriate Bugzilla entries. — Ambush Commander(Talk) 22:57, 4 February 2006 (UTC)
Good points, and at least now the confusion will end. I'm not very familiar with Bugzilla though, so perhaps someone else should write a brief introduction. At best, I may be able to set up a useable skeleton. -- Ec5618 00:32, 5 February 2006 (UTC)
It looks like Radiant went ahead and deleted it. I was hoping to delete after a suitable content substitute could have been developed... ah well. — Ambush Commander(Talk) 03:18, 5 February 2006 (UTC)
I've archived talk page content and also replaced main page with a how to use Bugzilla document. — Ambush Commander(Talk) 20:05, 5 February 2006 (UTC)

Are the page move watchlist bugs fixed?[edit]

The following section was deleted/blanked without any comment during the semi-recent refactoring of the main page, why? see here and I've included it below. Perhaps the main page should be archived properly so there is a record of when bugs are fixed? zen master T 02:13, 5 February 2006 (UTC)

I had Hubbert peak on my watchlist, when it was renamed to Hubbert peak theory the new article title was added to my watchlist but not the new title's talk page. So currently I receive the "unwatch" tab at the top for the article, but get the "watch" tab for the talk page, doesn't make sense. Perhaps this obfuscation was by design? zen master T 20:19, 27 August 2005 (UTC)

No status or fix for this? In case you care and this "bug" wasn't by design there are actually two separate bugs here: first, when an article is retitled/moved it completely disappears from your watchlist until someone edits it at its new location. Second, the new title's talk page is not automatically watched (but the new article itself is) so any future discussion after an article is renamed/moved will be missed (very convenient). zen master T 18:18, 23 November 2005 (UTC)
It seems that this page is dead. We might as well learn to live with all the fricking bugs that are all over the place, since no one apparently cares. I guess this was just the designated place for the people to vent or something.Tommstein 16:25, 24 November 2005 (UTC)

Restored above section from premature archivage. zen master T 20:49, 5 February 2006 (UTC)

I think the hint was to go to Bugzilla and see if there was already a bug, and if not, file a bug for it. — Ambush Commander(Talk) 20:51, 5 February 2006 (UTC)
I got that hint but listed reasons why a status of bugs should be kept within Wikipedia. Perhaps you missed that when you completely refactored the page which blanked active discussions that you were involved in, see here. FYI: In case you didn't notice I've also moved your refactoring to Wikipedia:How to report a bug and restored the previous archive/bug status page. zen master T 21:01, 5 February 2006 (UTC)
That was the hint. ;-) Ah well, I shall be more explicit in the future. I am not questioning the validity of the bug or any of that, but this simply is the wrong place to report it.
Most policy pages, when they go out of use, are not deleted, they simply are slapped with an inactive tag, warning people not to edit the time. Most of the time, these tags are effective. However, this has not been the case for this page.
After the tag was first added (by Brion Vibber, our lead developer), there have been no less than 20 edits to the page, five of which involved the submission of a new bug. People just don't like to read, huh?
I believe that this page would serve us best as information on how to report bugs, and in order to prevent misunderstandings, the previous bugs on the page should be permanently archived in the history, or, alternatively, a subpage. Leaving the page as a bug status page is not helpful, because it requires developers to come to this page and say, "Hey, this bug is fixed!" instead of simply closing a bug on Bugzilla after marking it FIXED.
In the mean time, you should fix the {{Shortcut}} tag and link to the how to report a bug page on this page, but I still believe that this page should have the bug reporting information. — Ambush Commander(Talk) 21:16, 5 February 2006 (UTC)
You haven't actually responded to my list of reasons why bugs should be kept self containted within Wikipedia proper? If Mediawiki software can handle an encyclopedia it is more than capable of functioning as a bug system. There are countless pages within Wikipedia that have custom access controls and various systems and people watching them to prevent vandalism, a bug system is no different. All aspects of Wikipedia should be reported and handled internally to ensure integrity, to do otherwise violates the entire concept of Wiki and collaborative development. Bug reports into bugzilla can and should be gleaned from user comments if MediaWIKI developers really and truly want to continue using bugzilla (a non wiki system). Wikipedia is by far the most heavily used Mediawiki site, it stands to reason that Mediawiki developers keep close tabs with what goes on here and are not solely focused on bugs reported into bugzilla as you and others excessively imply/claim. Are you a developer or do you make a habit of speaking for them? Forcing wikipedia users to go to bugzilla only decreases the awareness of bug information. Disparate information locations and instituationalized redundancy are not a benefit to wikipedia and collaborative development. At the very least Wikipedia should have a Wikipedia:Bug status page that succinctly lists all currently active bugs (and recently closed bugs and common pitfalls/FAQ), but if certain people are uninterested in fixing bugs such as the page move watchlist bugs (intentional obfuscation?) then it probably won't matter. zen master T 23:58, 5 February 2006 (UTC)
I actually agree with what was the basic premise of this page. I recently decided to refractor this page, and had hoped that the page could find volunteers to actually provide feedback on ongoing issues.
Perhaps we shouldn't have so easily given up on this page. -- Ec5618 00:12, 6 February 2006 (UTC)
I agree, would you be interested in trying to resurrect this page? I still think there should be a place within Wikipedia for users to report issues, this info can then be used to generate bugzilla bug reports, and/or add to the FAQ of common pitfalls and would be any easily searchable historic guide of the sorts of problems users run into. zen master T 05:53, 6 February 2006 (UTC)
I can understand your viewpoint, and this is probably the most obvious solution. Indeed: this has popped up in multiple places (i.e. meta:MediaWiki extensions and meta:MediaWiki feature request and bug report discussion). Both, if you notice, have notices warning users to use Bugzilla.
So... with your issues. If Mediawiki software can handle an encyclopedia it is more than capable of functioning as a bug system. You're right: it is capable of functioning as a bug system. But is it the best choice? (of course, that rhetorical question is up for debate, what I'm really trying to say is "Just because you can use the wiki, you shouldn't, if there is a better tool out there") (but is Bugzilla a better tool?) (and can both work in tandem?)
There are countless pages within Wikipedia that have custom access controls and various systems and people watching them to prevent vandalism, a bug system is no different. I believe what you are trying to say is that the concept of wiki has been stretched to accomodate other things like discussion, dictionaries, news reporting, source text repositories, common image file repositories, etc. But if you think about this, and then think about how these project's configuration for the software is different (how many times has an actual "forum" system for discussion has been proposed, what are some inefficiencies in Commons that could have been corrected by more specific software?) They do work, but many times it's not to full potential. A lot of the time, this is because there is no alternative. But there is a better way (reference to the 2005 Democratic Response)
All aspects of Wikipedia should be reported and handled internally to ensure integrity, to do otherwise violates the entire concept of Wiki and collaborative development. Bug reports into bugzilla can and should be gleaned from user comments if MediaWIKI developers really and truly want to continue using bugzilla (a non wiki system) - Then why do we have a MetaWiki? :-) And as regards to the fact that Bugzilla is a non-wiki system, well, the development process for the software also is un-wiki. The developers are under no obligation fulfill your freature requests. But we've got the next best thing: open-source software.
I think you are somewhat confusing Bugs and Feature Requests/Implementation Details (which do get lumped together all the time). Say, for instance, clicking my contributions doesn't bold the link up top. That's a bug. The real behavior seems simple: make sure it gets bolded when it happens. It actually is a bit of a problem to fix. Would it belong on this page? Of course not!
But take the single login bug. The actual implementation of the solution is complicated, and there is great variance in opinions on how exactly to fix it. Thus, meta:Single login has risen up for the transparent communication process through wiki. But notice how it is on meta, not on Wikipedia. Why?
Wikipedia is by far the most heavily used Mediawiki site, it stands to reason that Mediawiki developers keep close tabs with what goes on here and are not solely focused on bugs reported into bugzilla as you and others excessively imply/claim. As in Wikipedia you mean multilingual Wikipedias, right? French Wikipedia, German Wikipedia, they all also have their say on software issues, no? After all, they all use MediaWiki. But, of course, we should put this stuff on English Wikipedia! Because English Wikipedia is special! En.Wikipedia simply is the wrong place for the "end-all-be-all-bug-reporting-place" (it can have it's own bug facilities), but this really belongs to meta. Or Bugzilla.
As to whether or not the MediaWiki developers keep close tabs here, they do! Check out Wikipedia:Village pump (technical), or alternatively, Special:Contributions/Brion_VIBBER.
Are you a developer or do you make a habit of speaking for them? Aww... you're being unfair! :-) It's not a binomial categorization, but yes, I try to speak for the developer's so that they can do the coding. Besides, every action the developers have made (such as the original deprecation notice on this page, by Brion Vibber, and the comments by Rob Church) say "USE BUGZILLA!"
Being a developer myself (just not on MediaWiki (and even then, sort of, I've submitted a few patches and written a bit of documentation)), I have a bit of insight into the development process. I also have been reporting bugs for Mozilla Firefox, and I see a lot of bugspam happen over at that Bugzilla. It drives the developers nuts. (this argument is a bit sparse, so feel free to ask for elaboration)
Forcing wikipedia users to go to bugzilla only decreases the awareness of bug information. Disparate information locations and instituationalized redundancy are not a benefit to wikipedia and collaborative development. These are two very different concerns, both valid. True, forcing users to go to Bugzilla does decrease awareness. If it prevents bugspam, it's a good thing :o) But when there is a bug, it doesn't take very much for a user to ask around and get pointed to the best place. Remember, they still have to find this page.
Regarding the second concern, you might think that it was an argument against this page. If you think about it, Bugzilla has been around a lot longer, and it could be this page that is the disparate information location and redundancy that is not a benefit. (there are other arguments, but I think this suffices)
At the very least Wikipedia should have a Wikipedia:Bug status page that succinctly lists all currently active bugs (and recently closed bugs and common pitfalls/FAQ) There are 1000+ open bugs on Bugzilla, and 4887 total bugs ever filed. Redundancy is bad. A common pitfalls/biggest bugs FAQ would be a good idea though.
if certain people are uninterested in fixing bugs such as the page move watchlist bugs (intentional obfuscation?) then it probably won't matter. Trust me, the developers do care. But they care about a lot of things, and if you can make their life easier by using Bugzilla and reducing the number of places they have to watch, please do that. Is bugzilla:2580 relevant?
This comment is way too long, and if you read it all, I thank you. This I believe. — Ambush Commander(Talk) 02:03, 6 February 2006 (UTC)

I agree the word "bug" may be an insuffient word to describe issues listed on this page. For repeated example after the software "upgrade" last summer the watchlist was changed to where very important information, such as the renaming of an article, no longer shows up on the page designed to "watch" for changes which makes one wonder if that change was intentional for the purpose of obfuscation (not a "bug" in that case). I agree the Mediawiki developers should perhaps primarily monitor bugzilla, however, all Wikipedia users should have one central place to report and monitor bugs self contained within that site. Surely Wikipedia has their own staff of developers and admins separate from the Mediawiki software developers? I've commented elsewhere previously on the need to have one unified namespace, having disparate meta, dictionary, quote, news and encyclopedia sites makes potential obfuscation easier. Bug spam is the exact same spam problem that is already dealt with on Wikipedia on a massive scale. I did not mean other language Wikipedias above, I meant the Mediawiki software does not exist in a vacuum, developers of the software are highly likely to be keeping close tabs on the most popular site that uses that software (Wikipedia). Though, since you mentioned it does wikipedia's instance of bugzilla or the Mediawiki developers even support or speak other languages such as French and German, that point seems to be against your position, the language issue is actually a reason for each Wikipedia site to have their own list bugs and issues their users have encountered. Also, many Mediawiki sites install their own custom extensions and "hacks" which are obviously specific to that site, forcing everyone to one central bug reporting location in that likely case is unwise. Following the principle of full disclosure and ease of accessibility for as many users as possible all information that is relevant or potentially relevant to the use of Wikipedia should be listed somewhere on Wikipedia. zen master T 05:53, 6 February 2006 (UTC)

When it comes to software issues, the hierarchy is actually quite simple. You have the core MediaWiki installation, and then extensions in the form of extra wiki markup and special pages. The Bugzilla is set up to make this very explicit, if you notice, there is a product description page for MediaWiki, and then MediaWiki extensions (like Cite). Wiktionary and Wikisource could be using the same extension: Bugzilla makes this explicit, splitting up the issues into each project doesn't.
Bugspam is not the same as Wikipedia vandalism. Bug spam is users harassing developers trying to get a feature implemented or a bug fixed. I was trying to pre-empt a flood of clueless users submitting "bad bugs" as the visibility of Bugzilla increased, forgive me if I was ambiguous.
My point is this: there is no reason for a central bug reporting place on English Wikipedia. Yes, there is a place for a central feature request place (but that probably belongs on Meta), yes, there is a place for a FAQ of longstanded bugs (but that is not what this page was previously, and it also may be more appropriate on Meta). The How to Use Bugzilla seeks to provide full disclosure, by telling users upfront how to find and report bugs. It should be, I argue, supplemented with a FAQ listing the most frequently reported bugs. — Ambush Commander(Talk) 19:56, 6 February 2006 (UTC)
You misinterpret my point, the bug reporting place on English Wikipedia should only include issues as reported by users of English Wikipedia -- French, German and other non-English sites would have their own bug report or bug status areas. How to use an external bug system is not an explanation for why that information can't (also) be kept on the site where the bug or issue occurs. The most commonly reported bugs aren't necessarily the most important, the watchlist feature not working as it did previously is a very serious issue and as many users of Wikipedia as possible should be made aware of it. zen master T 20:52, 6 February 2006 (UTC)
Okay, I've misinterpreted your point. I still think the new interpretation is a bad idea, unfortunantely. ^_^" I am going to ask for a few more clarifications, if you don't mind. What exactly is the "information" that "can't (also) be kept on the site)? Also, I tested your bug, and it does seem to exist. I don't know why you won't file it yourself, so I'm going to go out and do it for you.
If the bug causes the software to not work as expected, and could cause problems for users but would remain mostly latent so they would not notice until it's too late, then why would they find this page before they notice the bug? So then, they ask around, and then a knowing user either points them to Bugzilla, or they point them to this page. Then they mill around, say "We really need to fix this bug," vent their frustrations on the talk page, and the developers still never find out. They go to Bugzilla, they file a duplicate bug, and the developer goes, "Hmmm.. haven't ten other users already reported that? DUPLICATE!"
Or, we could have a nice, user friendly page, telling them how to search Bugzilla before filing bugs, some short synposes of the major bugs, and no indication that they should ever place their frustrations on this page.
Better yet, we could edit MediaWiki:Watchdetails to notify people of the caveat on the watchlist. There are many other possibilities. What are the other bugs? — Ambush Commander(Talk) 21:49, 6 February 2006 (UTC)
The information is the bug information, all issues a website is experiencing should be listed somewhere on that site, especially for a wiki open collaborative site. I did report it here on Wikipedia, I didn't report it to the developers because it probably wouldn't matter since I considered the "bug" was most likely intentional given all the page renaming/title controversies around that time (also all the other reasons listed above).
The most likely first thing a wikipedia user is going to do if they encounter a bug is search wikipedia for info on, or other examples of and workarounds for, that bug. Venting about the bug on a random wikipedia discussion page is better than discouraging any mention of the bug or issue within wikipedia. I've worked with bugzilla a lot and the wiki concept is a better system for managing bugs especially because of the fact that it keeps bug information about a site specific to that site (if the site is a wiki). Listing bug information within one site in no way diminishes the ability to file a bug in an external bug system, I would argue that actually spreads bug information more effectively (eventually). The fact that so many duplicate bugs are filed into bugzilla should be taken as an impetus to have an easily accessible bug status page in many locations that concisely summarizes all currently know issues. zen master T 22:33, 6 February 2006 (UTC)
A related bug is the fact that discussion page vs article page watching (watchlist) can get out of sync. In some cases, if the article is renamed after maybe you clicked watch for the discussion page rather than the article, you could be watching the article but not the discussion page (or vice versa). I've loaded to the discussion page of an article and gotten the "watch" tab but received the "unwatch" tab for the article, very confusing. Maybe this one has been fixed, haven't confirmed it recently. zen master T 22:33, 6 February 2006 (UTC)

Something real silly (read confusing) is happening. Is it just me, or did Zen-master just get banned? — Ambush Commander(Talk) 01:51, 7 February 2006 (UTC)

Shoot me, but...[edit]

I still think that the page should mostly be how to use Bugzilla, and then with a list of bugs supplementing it. With Zen-master banned (for one year, mind you), and without any major opposition, I have reverted it back to the other version. — Ambush Commander(Talk) 01:56, 7 February 2006 (UTC)

Is there any reason you're so cheerful about it? As it happens, I oppose your change. The Wikipedia:How to report a bug page was a great compromise, which allowed this page to continue to showcase known issues. For one, this might allow Bugzilla to run more efficiently. For another, it might help users with problems at their end, in a respectful tone (as you may be aware, bugzilla responses are not the most friendly). You have said a lot above, but nothing to explain removing these bug reports. I'll not revert. Please do it yourself, or make a really good case. -- Ec5618 02:08, 7 February 2006 (UTC)
"BugZilla responses are not the most friendly"
Well, if you ask a stupid question... Rob Church (talk) 17:50, 10 February 2006 (UTC)
Well, it doesn't look like I'm going to get away with this, but here's what. I wouldn't mind if this page was a list of major bugs and a place for users to vent frustrations. However, we don't have an exact implementation of that idea, and I'm fairly certain that I was able to convince Zen-master that the page, as it currently stood, was not good. The How To page is a better solution, and the showcasing of known issues may have been the best solution. However, I reiterate, we don't have a page showcasing known issues. There are 1000+ open bugs on Bugzilla, and each them may be valid. I've archived the old reports, but they need to be rewritten in a more objective fashion.
I'm sorry. I didn't mean to come off as cheerful or declaring victory because zen-master got blocked. — Ambush Commander(Talk) 02:34, 7 February 2006 (UTC)


OK, excuse the tone here but these little arguments have gone on long enough. I shall now address:

  1. The reason we don't use the wiki to track bugs
  2. Where we do track bugs
  3. What to do when one finds a bug
  4. Recommended course of action
The reason we don't use the wiki to track bugs

MediaWiki is a wiki engine and is designed for collaborative editing of freeform documents. Wikimedia uses it to organise encyclopaedias; dictionaries, and other free information resources.

MediaWiki is not designed to track bugs. It is not an effective tool for doing so. It doesn't have the elements we need to track bugs, dependencies, keep tabs on duplicates, states and statuses, assignees, etc. In short, it's not up to the job of helping us work.

It's not designed to be. We use BugZilla because that is designed to track bugs.

Where we do track bugs

All bugs, feature requests, and requests for changes to the site configuration need to be posted on our BugZilla at Core developers subscribe to a mailing list for, and receive updates and status reports on, bugs and so forth. It's all in one neat place. We can organise things, mark priorities, and generally co-ordinate the coding, running and tweaking of the site.

What to do when one finds a bug
  1. Be sure it's a bug
  2. Post it on the bug tracker at
Recommended course of action

Each of these little "bug reporting" pages needs to be tagged as deprecated. Redirect them all to one single page, containing a brief (or this) explanation of the reasons we use the tracker. Or redirect to instructions on how to use it. It doesn't matter.

Please bear in mind

With one exception, none of the developers are paid for their work. We have people from a range of ages, skills, backgrounds and geographical locations. Brion's a professional software developer from California. Tim's a Ph.D. student from Australia. I'm a pre-degree student from the UK. There are lots of us, but we all

  • Have lives
  • Have other priorities, at times
  • Do this through some altruistic channel

We cannot and will not be expected to watch six thousand little pages. We already deal with thousands of requests, bug reports, etc. each and every day. I doubt we particularly mind (else we wouldn't do it) but we have set out the ground rules. This is how it has to be. We can't keep Wikipedia and the like as an Alexa top 15 (or is it higher now?) web site, and keep track of things, and organise ourselves, without a little co-operation.

All we've asked for is for people to use a bug tracker. Is it so hard?

Thank you. Rob Church (talk) 01:22, 10 February 2006 (UTC)

Nobody knows what "deprecated" means in this context. Usually it means "to put down," or "to insult." 04:34, 10 February 2006 (UTC)
Phased out. Obsolete. Rob Church (talk) 13:48, 10 February 2006 (UTC)
I understand that at some point, this page was where users came to make sure they had found a bug, in part to prevent users from complaining about problems at their end. -- Ec5618 13:56, 10 February 2006 (UTC)
This page is now obsolete and should not be used to report bugs or request features. We are not guaranteed to see them, and we are not obliged to even think about responding to them. Rob Church (talk) 17:49, 10 February 2006 (UTC)

Stopping spammers from finding my e-mail address at Bugzilla[edit]

Is there a way to prevent Bugzilla: from reporting my e-mail address for everyone to see? I figure spammers will find it fast. Will (Talk - contribs) 05:11, 14 December 2006 (UTC)

There's lots of services out there that offer throw-away email addresses. — Edward Z. Yang(Talk) 05:58, 15 December 2006 (UTC)

Moving to meta[edit]

Any reason the bulk of this documentation shouldn't be moved to meta? the wub "?!" 16:55, 10 January 2007 (UTC)

If you checked the page history, you'll notice that a long time ago, this page was used as a dumping ground for random bug reports and feature requests from English Wikipedia, much to many developer's dismay. Anyway, there was substantial opposition to nuking the page, so I rewrote it pointing users to the right place.
In short: probably not. — Edward Z. Yang(Talk) 21:18, 10 January 2007 (UTC)
Pah, I don't need to check the page history - I remember those days. It certainly doesn't seem that long ago... am I turning into an "oldtimer"? Anyway great job on the rewrite, I just think it should be on meta to avoid duplication. the wub "?!" 00:24, 11 January 2007 (UTC)

cookies logging in[edit]

i know this isnt where im supposed to be with this, but i dont know where i am supposed to be, and bugzilla isnt opening. but i cant log in to wikipedia cause it says i have cookies disabled, which i have not, this problem keeps coming back from time to time. what could i do? lygophile 15:58, 16 March 2007 (UTC)

The appropriate place to ask a question like this is not this place or Bugzilla but Wikipedia:Village pump (technical). I'm sure some folks over there will be able to help you. Be sure to also say what your browser is. — Edward Z. Yang(Talk) 17:11, 16 March 2007 (UTC)

Cancel the account[edit]

Hi. I may want to cancel my account. Can I do it? Jet (talk) 22:14, 22 July 2007 (UTC)


I've noticed that Wikipedia:Bugzilla and Wikipedia:Bug reports seem to cover the same information. Anyone opposed to a merge of these or have another idea? --- RockMFR 07:02, 13 August 2007 (UTC)

Support merge. Certainly, GDonato (talk) 21:53, 8 September 2007 (UTC)
Why not. Since Bugzilla seems to have been around longer, we should probably use that one as home-base. — Edward Z. Yang(Talk) 00:39, 11 September 2007 (UTC)
I support merge. RS1900 06:07, 12 September 2007 (UTC)
I wouldn't suggest doing the merge as the Wikimedia bug reporting and Bugzilla are two completely different subjects which just happen to be about the same program. The Wikipedia:Bugzilla page should only be used to address information relating to the program itself, while the Wikipedia:Bug reports page should be used to address information regarding the bug reporting process for wikimedia projects.
--Knightcon 22:39, 10 November 2007 (UTC)


There is a request on talk page of Special:Prefixindex for Special:Suffixindex. I have to second that request. This will be invaluable for finding the noun part of names that have various adjectives. I'm thinking "X logic," "X philosophy," etc.

This may not be the right place to request this, however, this is perhaps the appropriate audience? I was recommended to this area. Be well and thanks for your work. Greg Bard 03:20, 18 September 2007 (UTC)

Wikipedia:Village pump (technical) is a good place if you want fast feedback. You should also file a bug at Bugzilla. --- RockMFR 03:55, 18 September 2007 (UTC) grep is a recently improved tool that allows you to search text strings anywhere they appear in the article name, or the title in any name space. GregManninLB (talk) 15:05, 26 April 2008 (UTC)

Sulfuric Acid[edit]

It shows "한국어" under pages in other languages like 6 times.--§ Eloc § 22:27, 24 September 2007 (UTC)

Fixed. --- RockMFR 23:31, 24 September 2007 (UTC)

Login not working.[edit]

At first I thought I forgot my password. I put my login name in the field as instructed,

"If you have an account, but have forgotten your password, enter your login name below and submit a request to change your password."

but then it says it is not a valid email address. I put in my email address and reset the password, but it still won't work. --Gbleem 08:57, 2 December 2007 (UTC)


It would be great if the current logo had an image of a bug - see locust - added to it (to look like it was eating the flower). Drum guy (talk) 16:58, 27 April 2008 (UTC)

Or Image:Empis livida (aka).jpg. Drum guy (talk) 23:07, 14 August 2008 (UTC)

Why are Bugzilla email addresses public?[edit]

I, and many others, can't report bugs because we don't want our email addresses public. I don't want my real name public either. Every Bugzilla report or comment shows the email address of the poster. Why can't use unified login instead? It is a site.

Some people say that we can use a throwaway email address and a fake Bugzilla login name. I already use several email addresses. One for email lists, one for personal use, and one for Wikipedia and other activism. I only check the email list one a few times a month or less. I check the personal one once a week. My friends mainly contact me through the email address I use for Wikipedia and other activism. My relatives use the phone mainly, and occasionally my personal email address.

I don't want a throwaway email address just for bugzilla because I will rarely use it or check it. So what good does it do for me or Bugzilla?

Why not use anonymous login? Wikipedia succeeded when it went from "expert" editing (by people using their real names) to broad editing by anyone whether logged in or not. Bugzilla will do better too with unified login or other anonymous login.

I use the Firefox browser. I have the same bug-reporting problem with Firefox. They probably did not hear about many problems with the beta versions of their Firefox 3 browser due to using bugzilla as their main form of bug reporting. See

I have not upgraded to Firefox 3 due to problems they introduced with Firefox 3. I use Firefox 2 still. I have tried reporting the problems on their forums, but just like at Wikimedia one has to use Bugzilla if anyone is to pay some real attention.

I appreciate that the developers have limited time, and that some are unpaid, but I also have limited time, and work on this unpaid. We are in this together, so let's work together better. Please let me report bugs, suggestions, and possible solutions. --Timeshifter (talk) 00:47, 6 September 2008 (UTC)

Strongly agreed. I appreciate the tip, tho, and will use a throwaway email address. --Chriswaterguy talk 19:25, 2 December 2008 (UTC)
I'm wondering: What problems did you identify in Firefox 3? Maybe it's something that I could vote for on the Mozilla Bugzilla for you. —Remember the dot (talk) 19:48, 2 December 2008 (UTC)
Sorry, I didn't see your reply sooner. I am "penlamp" in this Mozilla forum thread that covers the various slow bookmarking problems in Firefox 3:
See also the linked threads.
There are some reports on Mozilla bugzilla. My impression from reading the MozillaZine forums and Bugzilla is that the new database-driven Firefox 3 bookmarking software (SQLite) is unbelievably buggy. Reminds of why so many websites are going back to plain HTML from database-driven and/or dynamic websites. --Timeshifter (talk) 04:55, 25 December 2008 (UTC)

(unident) Here is a MediaWiki-related bug reporting system that does not expose the email addresses. See:

It links to:

and the account registration page:

Both name and mail are optional on that registration page.

MediaWiki+FCKeditor is a WYSIWYG text editor for wikis, and is in beta-testing at Wikia and elsewhere. See:

Sorry but ...[edit]

I'm not going to create a bugzilla account just to tell what I hope you already know. Especially if you're going to expose my email address and name.

So PRINTING ISN'T WORKING - if I print preview a page, I see a single blank page. If I select the printable version, I see what I'd expect, but again, if I print preview it, I see a blank page. I discovered this at and tested on another random page before reporting.

I'm running Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20060911 SUSE/ Firefox/ Yes, I know it's old but (a) it used to work fine and (b) this is such a major breakage. FWIW, I'd guess it's some CSS change you've made; it usually is. —Preceding unsigned comment added by (talk) 08:57, 26 May 2009 (UTC)

Quick bar[edit]

Hi. I'm left handed and I've only noticed that cologne blue and classic or one other has the option to change the quickbar from left to right and fixed or moveable. Given that I mostly use modern and occasionally mono, would it be possible to be able to add the quickbar option for modern so the navigation bar can be moved to the right hand side. I think you should give people this option for all skins givne that some people are left handed and might find it more natural to have it on the otherside. I also think there should be a shrinkable option on the nav bars like we have with big templates for instance as if we could conveniently shrink the task while reading or at least have the option to this would ease useability I think. Also for the task bar on modern does it have to be so wide? There is at least a centimetre gap, it could be trimmed easily by 1-2 centimetres. Dr. Blofeld White cat 13:41, 19 July 2009 (UTC)

Grey Bar[edit]

A grey bar continues to appear (off & on) on top of pages I go to, even when I'm checking my contributions history, talk history etc. It appears just below the project page, discussion, edit this page, new section, history, move, watch directives. Is this phenominom happening to others? GoodDay (talk) 19:13, 8 January 2011 (UTC)

Is it possible to simplify the manipulation of mathematical formulas? Am I in the right place?[edit]

As for the first question:

It may be too pretentious to ask this, but my request is: why doesn't somebody simplify the use of Latex* in Wikipedia? Currently, one needs to type "math" between the signs < and >. This seems unnecessarily time-spending. Generally, mathematicians use a simple dollar symbol ($).

(I think almost all mathematicians know what I am talking about, though no doubt this doesn't apply to laymen who simply like mathematics)

Of course the impulsive adoption of such easily-typeable symbol would cause a nightmare, since many people would have trouble trying to print the common dollar symbol. However, the time mathematicians would save seems to be quite big (in my view). I have myself had some trouble trying to understand Wikipedia's system (but I concede that this may be my fault). Anyway, the number of bothered users is, I think, huge. This ultimately must lead to distortion of the proper mathematical style, causing the suppression of formulas for the sometimes more cumbersome verbal explanations.

In conclusion, I ask the possibility of use the sign $ as a simple access to Latex in the mathematics portal.

As for the second question:

I understand to be a "problem with the software", and more specifically a feature request. Through the "Contact us" page, I've got here. However, I still do not see clearly whom I should contact. What else can I do?

Thank you for the attention!

  • Actually, I don't know whether I am talking about "Latex" or "Tex" (I don't understand much of computers). — Preceding unsigned comment added by (talk) 02:22, 6 July 2011 (UTC)
You might want to discuss this here: Wikipedia:Village Pump. In particular; Wikipedia:Village pump (technical). --Timeshifter (talk) 11:24, 28 November 2011 (UTC)

Assyrian Syriac Wikipedia problem[edit]

Hi every one i have a problem with the documentation green box in our wikipedia it's not working properly for some reason i have tried so many things you can see it herܩܠܒܐ:Documentation/core . our problem is with green box and the border of fmbom aswell. thanks every one for the help in advance. Man2fly2002 (talk) 02:49, 3 March 2012 (UTC)

Please ask in if this is still a problem. --Malyacko (talk) 17:01, 16 December 2012 (UTC)

Sandbox for Bugzilla comments[edit]

Bugzilla:39828 - Sandbox for testing links, including MediaWiki-style internal links, within Bugzilla comments. Tests have been done there for various link formats. You can see for yourself what works by clicking the links there and seeing where they go.

Do not add more comments to this Bugzilla thread unless absolutely necessary. Add new comments only to test types of links not already tested in the Bugzilla thread. For more info see:

Grabbing results via AWB's "wikisearch" list provider does not always workd and this might be a Mediawiki problem[edit]

I was reported to me on my talk page that in some wikipedias, AWB's "wikisearch" list provider gives 0 results. I confirmed that I get results in en, el, ru, zh but not in ar. Ma reported that gets not results in and ERJANIK reported the problem for hy (confirmed by myself) and later reported as fixed.

I suspect that this weird bevahiour in getting results via list providers maybe the result of Mediawiki bug. What do you think?

PS @Reedy, Rjwilmsi: I bet you are interested in this one. -- Magioladitis (talk) 08:28, 21 September 2014 (UTC)