Wikipedia:Village pump (technical)/Archive 33

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Disambiguation: namespace

Brilliant idea no?

Struck me a little while back. All pages with (disambiguation) on them could be moved to this namespace. They aren't articles, therefore shouldn't be in the same namespace. The same might be a good idea for redirects (Redirect:) Thoughts? -- Anonymous Dissident^Talk 12:52, 9 April 2008 (UTC)

Data users should get disambiguation pages and redirects together with articles. I think it would cause confusion and missing content for many data users if they were in different namespaces. PrimeHunter (talk) 15:02, 9 April 2008 (UTC)

Disambiguation pages are still articles; they simply state that there are several other articles with similar sounding names. EVula // talk // ☯ // 15:35, 9 April 2008 (UTC)

Oh no! Don't do that!! You'll open up the Georgia debate again! Hehe, but in all seriousness, disambiguation pages are useful to settle naming conflicts, because if two topics have (arguably :D) equally valid claims to a title, a disambig page is a nice neutral way to keep them both off the territory. And EVula's point is also valid: disambig pages provide useful, encyclopedic information, and hence should be considered part of the encyclopedic content. Happy‑melon 16:12, 9 April 2008 (UTC)

Ok, scratch that idea, it appears I wasn't considering all possibilities... It was late over here... :P -- Anonymous Dissident^Talk 21:25, 9 April 2008 (UTC)

Heh, I didn't even consider the conflict angle that Happy-melon mentioned; even if I had agreed with you initially, killing conflicts like that is definitely a worthwhile reason to keep them as-is. :) EVula // talk // ☯ // 16:14, 10 April 2008 (UTC)

Recent changes -- Namespace: User

Is it new that sorting recent changes for the user namespace gives (User creation log) results? I don't remember it being like that before, and it pretty much takes most of the usefulness of the sort away. If it's going to stay like this, is there any way to choose to ignore log results? --Onorem♠Dil 12:53, 9 April 2008 (UTC)

I seem to remember it always doing that. asenine ^t/_c 13:48, 9 April 2008 (UTC)

That is possible. Maybe it's just been an unusually active day for new accounts, or maybe I'm just completely off this morning. It seems like every time I've looked today, about 40 of the 50 results have been for account creation. Even if this isn't a new development, I think it would be nice to add the option to hide log results. --Onorem♠Dil 14:15, 9 April 2008 (UTC)

I never check the RC page here (as it moves too fast for me to catch anything), but I know account creation shows up on RC pages elsewhere I check (primarily Meta and Wikispecies). EVula // talk // ☯ // 15:52, 9 April 2008 (UTC)

Onorem: use Enhanced Recent Changes (option in Preferences). By the way, it's not sorting, it's filtering by namespace. —AlexSm 20:39, 9 April 2008 (UTC)

Thanks. This looks like it will be much easier to look through. (I knew sort wasn't really the right word. Not sure how I didn't come up with filter though...) --Onorem♠Dil 12:39, 10 April 2008 (UTC)

A protected unprotected page

Per discussion at Wikipedia:Administrators' noticeboard#Portal:Kentucky/On this day.../April 9 protected?, for some reason it won't let me create new subpages for my portal. Some people are able to, some aren't. Some are having these problems with IE; I'm having problems with it on Firefox. Portal:Indianapolis/On this day.../April 9 is also affected by the problem.--Bedford 16:45, 9 April 2008 (UTC)

Not sure what the deal is; I've created a blank page for April 9th so that it at least can be edited... EVula // talk // ☯ // 17:55, 9 April 2008 (UTC)

Should be fixed now. There was a regex at MediaWiki:Titleblacklist causing this. --- RockMFR 19:13, 9 April 2008 (UTC)

Moving a page on the watchlist

This is small but i think it is good now that when pages are moved, these show up on the watchlist as well. Btw, when did change happen? Simply south (talk) 17:05, 9 April 2008 (UTC)

I think it was done at about 23:00 (UTC). It was part of this revision. Woody (talk) 17:13, 9 April 2008 (UTC)

Gallery tags

I asked on the help desk, but they suggested I ask here. Regarding the <gallery> tags. I noticed that on the commons, the gallery makes itself as wide as possible for your browser window, but on wikipedia, it is a maximum of 4 columns. I know you can modify the number of columns using the perrow parameter, but this just screws up the page if you use a lower screen resolution. Is there a way to make wikipedia gallery tags resize to the screen? -mattbuck (Talk) 18:28, 9 April 2008 (UTC)

At the moment I believe that's done with some custom JS on Commons. If it's reasonably reliable, we can probably integrate that into MediaWiki proper. --brion (talk) 20:10, 9 April 2008 (UTC)

I hope it's soon. -mattbuck (Talk) 22:02, 9 April 2008 (UTC)

#ifexist limit

Is there a specific numerical limit to the number of uses of the #ifexist parser function in one page? Wikipedia:Template limits isn't clear on the issue. --Iamunknown 18:45, 9 April 2008 (UTC)

Yes there is. If you open the source of a wikipedia page you will see it reported. It currently says:

NewPP limit report
Preprocessor node count: 59/1000000
Post-expand include size: 52/2048000 bytes
Template argument size: 6/2048000 bytes
Expensive parser function count: 0/500

That means you can use a maximum of 500 ifexist calls in ANY page (that includes all ifexists in pages that are transcluded into the article). Yesterday it was accidently set to 100 for a while btw. --TheDJ (talk • contribs) 19:06, 9 April 2008 (UTC)

(e/c)The current limit of total expensive parser functions (currently defined as #ifexist and {{PAGESINCATEGORY}}) is 500. If you exceed the limit it will add the page to Category:Pages with too many expensive parser function calls and will display a warning on preview. You can see the number of expensive parser functions used on a page in the page HTML source - under the page content there will be a comment like "Expensive parser function count: X/500." Mr.Z-man 19:07, 9 April 2008 (UTC)

Ok. Thanks for the info and for updating the page (and thanks too to Patrick). --Iamunknown 21:53, 9 April 2008 (UTC)

Image syntax interacts with wiki table syntax

Resolved

I've encountered a difference in image syntax behaviour depending on whether or not the image is inside or outside a wiki table. I'm working on flag templates and would like to make the border conditional. Some flags (e.g. {{flagicon|Japan}}→) certainly need it, but others (e.g. {{flagicon|Nepal}}→) look goofy with it. I changed the template code to make the MediaWiki border tag conditional, but this solution does not work when the flag template is used inside a wiki table. For example, [[Image:Flag of Nepal.svg|22x20px|Flag of Nepal]] (note the double pipe, consequence of the border tag conditionally removed) results in but:

{|
| [[Image:Flag of Nepal.svg|22x20px|Flag of Nepal]]
|}

fails dramatically, as the size parameter is ignored and a full size image is displayed. This only happens when wiki table syntax is used; HTML tables work fine. That's not a viable workaround, and I think any solution that tries to make the pipe also conditional is likely to be quite awkward. Help appreciated. — Andrwsc (talk · contribs) 23:05, 9 April 2008 (UTC)

I can see the problem; the table parser sees the || as a cell seperator. Making the pipe condtional seems the only logical solution... (if I only knew how). Have you tried {{!}}? — Edokter • Talk • 23:16, 9 April 2008 (UTC)

The table parser is broken if it "sees" the double pipe inside the span of the image syntax. I'm reluctant to use {{!}} for now, but that may change if the bug isn't fixed. — Andrwsc (talk · contribs) 23:25, 9 April 2008 (UTC)

I just found a simple solution—a space character (e.g. [[Image:Flag of Nepal.svg|22x20px| |Flag of Nepal]] or [[Image:Flag of Japan.svg|22x20px|border |Flag of Japan]]). — Andrwsc (talk · contribs) 23:32, 9 April 2008 (UTC)

Edit summary focus change

Today, I'm noticing that when I tab from the edit window to the edit summary window, at least when doing section edits, my cursor has the /* section name */ part of the edit summary highlighted. If I start typing, I overwrite the section name. Previously, my cursor was simply at the end of the text and I could type and hit enter without thinking. Anybody else know what's going on? --Dhartung | Talk 23:38, 9 April 2008 (UTC)

This sounds like something browser dependent. Just hit end or right arrow before writing the edit summary. If you accidentally delete the section name first then you can probably restore it with Ctrl+z. PrimeHunter (talk) 00:18, 10 April 2008 (UTC)

I'm using the exact same browser I was yesterday. Something here changed. And I know how to work around it. The point is that I didn't have to before. --Dhartung | Talk 05:06, 10 April 2008 (UTC)

Do you use IE7? An update came out today, maybe that caused the change. I always click into the edit summary, so I can't tell you if it's changed for me or not. Franamax (talk) 06:07, 10 April 2008 (UTC)

Stranger yet, it has now changed back to the way it was before. Earlier part of the warning "Do not copy text from other websites without a GFDL-compatible license. It will be deleted. / Your changes will be visible immediately." was coming before the edit summary, now it's back down the page where it was, I think, before. I am using Firefox (2.whateverthelatestis), and I closed Firefox in between my two comments above but not since. --Dhartung | Talk 06:41, 10 April 2008 (UTC)

I had this happen too, but it was after a Safari update. *shrug* EVula // talk // ☯ // 16:11, 10 April 2008 (UTC)

Lining up indentations

I'm pretty sure this is something that's brought up constantly, but no one does anything about it because it would be more trouble than it's worth. Nevertheless, I thought I'd try again. Right now, there are three different ways to indent a paragraph, through a bulleted list (*), through a numbered list (#), or through straight indentation (:). And right now, none of those indentations line up with each other.

• See? Here's a bullet.

1. And here's a number.

And here's an indented paragraph.

That example isn't really a big deal, because I can't see a situation where you'd use a bullet and a number in close proximity like that. Where it does become a problem is in threaded discussion on pages such as AfD, or polls on talk pages, or anything where the first level of comments tends to be set off with a bullet. For example:

• Here's what I think. -- User:Foo
  • I agree. -- User:Bar
    • I also agree. -- User:Kéiryn
      • I strongly disagree. Let me write a really long paragraph explaining why. For example, the population of African elephants has tripled in the past decade. I don't know how you can ignore this as irrefutable fact.

      Also, Oregon is much more Idaho's Portugal than it is Washington's Mexico. -- User:Colbertfan000001

Note how Colbertfan's second paragraph doesn't line up properly with his first one? I've edited a bunch with each of the three most popular (I think) browsers, Firefox, IE, and Safari, and the problem is identical in each one. Can anything be done? -- Kéiryn ^talk 00:53, 10 April 2008 (UTC)

No I didn't notice. I thought that the one writing about the elephants forgot to sign and colbert was a different editor. Or yes I noticed that it made it hard to tell. In general it is often hard to tell.

When an editor splits their

Thoughts into separate paragraphs that they are all written by the same editor. 199.125.109.88 (talk) 01:51, 10 April 2008 (UTC)

The MediaWiki software produces simple clean html for these 3 things and then your browser controls the placement (I don't know whether there are html standards for that). I don't think the software should produce more complicated html in an attempt to get browsers to display it aligned, and I don't even know whether it's possible. PrimeHunter (talk) 02:20, 10 April 2008 (UTC)

Pity, though; this has bothered me as well. Not to mention all these errors that are often made in bulleted, numbered, or hybrid lists; these items are often used incorrectly. I wonder if the creation of these lists is analysed anywhere beyond the level of "asterisks produce bullets, double asterisks produce indented bullets". Waltham, The Duke of 02:36, 10 April 2008 (UTC)

On second thought, there may be things going on I don't know about so don't trust my post. PrimeHunter (talk) 02:51, 10 April 2008 (UTC)

• If you're willing to have the paragraphs run together and look ugly in the Wikimarkup itself;

  Then you can line the paragraphs up on the displayed page.

1. It seems to work

   with numbered lists to.

2. And doesn't screw up the numbering. --barneca (talk) 03:12, 10 April 2008 (UTC)

Huzzah! <p> tags! I knew the problem wouldn't be fixed, but I also had a feeling that if I asked, someone would show me the workaround. Thanks so much! -- Kéiryn ^talk 14:00, 10 April 2008 (UTC)

I use <p> tags. Keep in mind that : is not supposed to be abused as indentation, in principle. This is all just set by the CSS, anyway. The margins could be changed at MediaWiki:Monobook.css easily enough; it's been discussed before more than once. Note that the ordered-list indentation needs to be fairly large to give enough room for lists that run into two (or even three) digits. —Simetrical (talk • contribs) 14:14, 10 April 2008 (UTC)

Error in Template?

Resolved

{{OH-Project}} has something strange about it which is causing every talk page it is placed on to appear in Category:WikiProject banners with quality assessment (which should only contain template description pages). dramatic (talk) 10:15, 10 April 2008 (UTC)

Fixed. Happy‑melon 13:34, 10 April 2008 (UTC)

Thanks dramatic (talk) 17:50, 10 April 2008 (UTC)

Strange error on page

On Peekskill (Metro-North station), a weird error message Expression error: Unexpected > operatorExpression error: Unexpected = operatorExpression error: Unexpected < operator shows up in the infobox. It seems to go away if you edit out the number of passengers, but I see no reason why this is the case. *Dan T.* (talk) 00:50, 11 April 2008 (UTC)

I tried this and put in pass_pct=0 just to give it a number. Now it's put in a green bar, but the red seems to have gone away. Please fix! Franamax (talk) 01:06, 11 April 2008 (UTC)

It appears to be a problem with a template used (probably as part of the infobox template) to present the percentage change in ridership, which is unable to cope with the absence of a figure there. On another unrelated issue pertaining to rail station articles, some of them, including Yonkers (Metro-North station), have a really awkward overlap of their various infoboxes and route boxes, at least in my browser (Mozilla SeaMonkey under Windows XP). Is there anything that can be done about this? *Dan T.* (talk) 02:17, 11 April 2008 (UTC)

Expression error problem fixed now (Template:Rail pass box). The overlap problems can be fixed by adding {{clear}} (or maybe {{-}}?) before the route box templates. --- RockMFR 02:30, 11 April 2008 (UTC)

eddy current sensors and optical sensors

Hi,

   I want to know about Eddy current sensors and Optical sensors in detail.

Their construction,working,features,advantages. Now it's not available in wikipedia. So anybody pls help me.

A quick look at the Eddy current article led me to the Eddy-current testing article, which led me to an outside page titled An introduction to Eddy Current Testing theory and technology which has some info on that. -- Boracay Bill (talk) 01:57, 11 April 2008 (UTC)

Preferences - Prompt me when entering a blank edit summary

I would find the "Prompt me when entering a blank edit summary" much more viable to have enabled if it didn't prompt on an auto-generated summary such as /*Section*/ - If I want to replace that I will, but I do want to avoid submitting completely blank summaries. Also, an option for a javascript dialog triggered onsubmit would work better here - more immediate for the user and less load on the server. I often hit save then flick to another page, and several times lately have realised much later that an edit is still awaiting a summary or re-save. dramatic (talk) 03:52, 10 April 2008 (UTC)

Why not just get in the habit of always entering an edit summary so people know what your edit was about? Franamax (talk) 03:57, 10 April 2008 (UTC)

I try to, but there are times when what I would type is exactly what the automated subject would say (with the exception of the /* */)dramatic (talk) 10:15, 10 April 2008 (UTC)

The /*Section about something*/ is a blank summary. It is just showing everyone what section you are editing. You are supposed to add your reason for the edit after that. 199.125.109.96 (talk) 21:08, 10 April 2008 (UTC)]

Was staying quiet, but thanx IP, just the section name is really not informative, what exactly were you doing in that section? Adding, removing, clarifying, categorizing? It really does help for those others reviewing the history and watchlist, eventually a trust situation builds - I recognize this user name and I recognize the task, I don't have to check 'cause I know that edit is reliable. Now I can concentrate my reviews on new arrivals and uninformative summaries. The more info the better! Franamax (talk) 23:58, 10 April 2008 (UTC)

I have found the option fairly useless for that very reason Dramatic. _(1 == 2)^Until 00:02, 11 April 2008 (UTC)

So when you click to edit a section and the wiki software automatically supplies the section name in un-bold purely as an indication of the particular section you clicked on, you consider that to be sufficient collaborative notice to everyone else as to what your intentions were? Why not just go with an automatic summary "Changed wikipedia article"?? Franamax (talk) 00:51, 11 April 2008 (UTC)

Love it. Most of my edit summaries are "add". Seriously, as a frequent recent change patroller, what I focus on are the edits with no edit summary, so I would not want any way of automating an edit summary other than what section someone was messing with to be implemented. When I am looking back through history to find out when and why and who changed a particular factoid it is very helpful to have the section listed in history. 199.125.109.104 (talk) 17:23, 11 April 2008 (UTC)

Search trivia

Ok, I'm finally fed up with the new(ish) lump of text that appears at the top of Special:Search when no exact match is found. It's the bit that goes "no page with that title exists / you can search again... or you can request that the page be created". What need I add to my monobook.css to get rid of it? Happy‑melon 16:08, 10 April 2008 (UTC)

In the HTML source, it looks like that text is not enclosed in a -div- and has no id or name tags or any other unique attributes, so I'm thinking you're out of luck... Franamax (talk) 18:46, 10 April 2008 (UTC)

That's what I feared. Any chance a passing dev could wrap it for me? </follorn hope> :D Happy‑melon 18:55, 10 April 2008 (UTC)

You can ask on MediaWiki talk:Noexactmatch. --Splarka (rant) 07:34, 11 April 2008 (UTC)

Added '<div id="msg-noexactmatch">'. --Random832 (contribs) 14:07, 11 April 2008 (UTC)

Thanks!! Happy‑melon 17:22, 11 April 2008 (UTC)

Renaming the Image: namespace

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Currently, any type of media uploaded to the wiki is put into the Image: namespace. As such, we currently have pages like Image:Human whistling.ogg. This is clearly inaccurate, as Ogg Vorbis files contain video and sound; they are not images.

Proposed: We "rename" the Image: namespace to File:. Using $wgExtraNamespaces, all current uses of Image: would still work, as would any uses of File:. Direct links, such as Image:Example.png would automatically link to the File: URL. It would allow for [[Image:Example.png]], [[:Image:Example.png]], [[File:Example.png]], and [[:File:Example.png]] to all work together, without breaking any page histories or causing any issues. It would be very similar to the way WP: currently works.

Other alternatives to File: are welcome in the discussion section, however note that Media: cannot be used due to it already being taken.

The proposed change would add the following code.

$wgExtraNamespaces = array(
	NS_IMAGE            => 'File',
	NS_IMAGE_TALK       => 'File_talk',
);

There is a bug for this filed in Bugzilla: number 44, though the majority of the comments in that bug are outdated.

--MZMcBride (talk) 20:56, 10 April 2008 (UTC)

Support

1. --MZMcBride (talk) 20:56, 10 April 2008 (UTC)
2. Calling sound and video files "Image" always did seem odd. I would prefer "Media", but as that isn't possible, "File" will do. Mr.Z-man 01:53, 11 April 2008 (UTC)
3. File works for me. MBisanz ^talk 01:55, 11 April 2008 (UTC)
4. Good idea. I too would prefer Media: if we could in any way wrangle the software into doing so, but File: isn't bad. krimpet✽ 02:02, 11 April 2008 (UTC)
5. Support - this would make it simpler and more straightforward to work with audio and video files. —Remember the dot ^(talk) 04:18, 11 April 2008 (UTC)
6. —Simetrical (talk • contribs) 14:25, 11 April 2008 (UTC)

Oppose

1. Can't really throw my support behind this idea until I know more about how this would affect how the English Wikipedia (which is the only site this proposal could affect) and its relation with Commons. I'm much more concerned about buggering everything than whether it makes sense to have audio files start with "Image:". EVula // talk // ☯ // 01:59, 11 April 2008 (UTC)
2. While this fix would work, it is not particularly elegant: every wiki running MediaWiki has this problem, so a proper fix would be to the MediaWiki software, not one isolated to our instance of it. I do not fully understand how the Media: namespace functions or how widely it is used (a quick search suggests "not very", and this is on the largest wiki in the world), but I think a much more elegant fix would be for the next version of MediaWiki to rename the Media: namespace to something else ("Direct:" perhaps?), and the Image: namespace to Media:, with appropriate redirects (Image: to Media:) set by default. A much more effective fix would be to implement the rename from Image: to File: (although I and I'm sure many other people would much prefer to be able to use Media:, this appears to be impossible) in the next MediaWiki release. This would fix the problem on every instance of MediaWiki in the world, which clearly maximises the benefit to all concerned, and would also eliminate any concerns like EVula rightly raises above: if this makes it impossible or even just difficult for us to work with commons (although my understanding is that it would not, I don't fancy taking the risk), then we've just created for ourselves a monumental, and unnecessary, problem. If done poorly, yes, it could be a breaking change, but (although as I say I am working on incomplete information) I'm sure it could, and would, be done with the minimum of fuss. To be honest, even if it were done unilterally, I don't think it would have that serious an effect, as the output of Media:Example.jpg and Image:Example.jpg are the most similar of any pair of namespaces (and I doubt (m)any bots or scripts would use the Media: prefix in preference to a direct URL link. As far as this proposal goes, however, I can't support a modification which creates a breaking discrepancy between en.wiki and other MediaWiki sites. Let's not forget that our content is used, for good and ill, by hundreds of other wikis, all of whom would be forced to imitate this change in order to ensure that their copies of our pages keep working on their installation of MediaWiki. In a nutshell: this would be a breaking change for downstream users of our content; fix it in MediaWiki instead. Happy‑melon 17:01, 11 April 2008 (UTC)

   A few problems with that. Wikimedia uses the development version and is the only production (as opposed to test) wiki website that I know of that does so, so when the change is made it would still have the compatibility problem with other sites until a new release is made and it would completely break all backwards compatibility (people who want to reuse our content on an older version could make the same config change as us to use "File" but they would have to do a lot more work to use "Media"). It would also break any current link to a Media: page as well. Mr.Z-man 17:42, 11 April 2008 (UTC)

   Upon reading the explanation below I realise that getting hold of the Media: namespace prefix is impractical. I still maintain that the problem needs to be fixed in mediawiki or not be fixed at all. Happy‑melon 17:48, 11 April 2008 (UTC)

Neutral

1. Leaning toward support - Why File: and not Media:? - jc37 23:03, 10 April 2008 (UTC)

   It's apparently taken, but this is the first I've ever heard of it. Did find something on it at mw:Manual:Namespace, though. EVula // talk // ☯ // 01:57, 11 April 2008 (UTC)

Discussion

• Sounds OK in principle. And while we are discussing the image namespace, could someone help explain the split between numbers for the allowed file types in the discussion at Wikipedia:Village pump (technical)#Image stats? Do we really have about 5500 ogg files? Is there really no way to distinguish between pure sounds and video files? And why do the numbers not match up - do we really have lots of phantom pages in the Image namespace? Carcharoth (talk) 22:30, 10 April 2008 (UTC)
• Replying to jc37 down here: Media namespace is used for downloading images (sorry, files!). Carcharoth (talk) 23:16, 10 April 2008 (UTC)
• Instead of renaming the whole namespace, which would be rather non-standard for MediaWiki wikis, two namespace aliases (in the manner of WP → Wikipedia) could be created if there is something to be gained from it. Not sure if this is the case. (Think of all the broken image regex, for example.) Gracenotes^T § 02:02, 11 April 2008 (UTC)

  • I'm having a difficult time figuring out what you're referring to. Are there currently scripts or bots that rely on the page text being [[Image:...]], and if so, wouldn't namespace aliases cause the exact same issues as a pseudo-rename? --MZMcBride (talk) 05:26, 11 April 2008 (UTC)

  • • I'd rather have a namespace alias than a complete rename. Both present regex-screwing-up issues, which would require to updates to various wiki-based software (Twinkle and AWB not the least of them). Gracenotes^T § 14:58, 11 April 2008 (UTC)
• For the record, the allowed uploads are currently png, gif, jpg/jpeg, xcf, pdf, mid, ogg, svg, djvu. It seems we don't have any djvus yet (mainly used for wikisource, I believe), but like pdfs, this is a file format that can include searchable and copyable text, and well as images (djvu is a kind of hybrid text/image format). For this reason, "File:" is probably more accurate than "Media:", since pdf and djvu files are better described as files than media. Possibly xcf as well, though I don't know enogh about that. Carcharoth (talk) 07:57, 11 April 2008 (UTC)
  • XCF is a form of image - Adobe Photoshop is to PSD as The GIMP is to XCF. MER-C 13:54, 11 April 2008 (UTC)
    • We don't like .pdf files! And at a brief skim of DjVu, it seems that it's just an image format which has special compression algorithms for text as well. So maybe it'd be more efficient than a .jpg or .png at storing text, but it's still just a posh image. Regardless, we have little or no need to store text as media files, so the Image: namespace is used (here at least) soley for media files. Happy‑melon 16:24, 11 April 2008 (UTC)
      • We might not like pdf files, but we have 1,557 of them. Can't that bit of the en-Wikipedia upload thingy be tweaked? Or do we keep it open so that anything useful can be transferred to wikisource? Carcharoth (talk) 17:33, 11 April 2008 (UTC)
• I get the overall gist, but can someone who actually understands explain properly what the Media: namespace is for, and why we need it/can't get rid of it?? Happy‑melon 16:26, 11 April 2008 (UTC)
  • Here's my stab at it: in MediaWiki, images are stored in a hierarchy of directories (folders) for easy access, and a database table exists correlating each image with the directory it's stored in. For instance, Image:NotreDameDeParis.jpg isn't actually stored along with articles, but at upload.wikimedia.org in the folder wikipedia/commons/a/a4/. To get from the name to the location, the database needs to be accessed. So, suppose you know an image is entitled Image:NotreDameDeParis.jpg, and you want the URL of the image itself. When an image is displayed on a page, it might not be the actual image, but rather a thumbnail version, which is probably not what you want. If you want to link directly to the image itself in wikitext, the best way is to include a link to Media:NotreDameDeParis.jpg, which is transformed by the parser into the a link to the URL of the image (try clicking on the link). This is useful, because the location /a/a4 isn't necessarily stable, so linking to it directly might cause a problem. The "Media:" feature applies not only to images but also to other sorts of files in the Image namespace. Template:Audio, for instance, uses this feature to link directly to, say, a pronouncation of a word, rather than going to the description page first. "Media:" isn't so much of a namespace as a feature, but either way, the name's already taken. Gracenotes^T § 17:08, 11 April 2008 (UTC)
    • Oh damn, you're telling me it's actually useful?!?! :D That's a real shame, because I don't think there's anyone here who would prefer to see the namespace renamed to File: than to Media:, but I guess you can't have everything. My argument above still stands - this is something that needs to be fixed for all MediaWiki users or not be fixed at all. Maybe in a big shakeup of the image system we can get the Media: namespace back :D Happy‑melon 17:44, 11 April 2008 (UTC)

"Result":

• Decided to ask brion if there might be any issues with this, since en.wikipedia has a tendency to be problematic no matter what you change in configuration. I'll just quote the response:

20:45 < brion> thedj: no need to propose it for enwiki, that's in my queue to do in the software
20:45 < brion> just remind us eh :)

So this will be done in the software if we remind the devs often enough :D --TheDJ (talk • contribs) 18:48, 11 April 2008 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

Extension:BypassSearch

I popped out Extension:BypassSearch, which adds a checkbox under the "misc" tab of "my preferences" to allow individual users to Go directly into editing a non-existent page instead of waiting for a search to complete (which can take seemingly forever during peak load) when using the left-hand search box. I figure it would definitely help in cases when someone knows that they want to create a new page or access a deleted page directly without messing around with the URI or adding to the load of the search servers.

Anyway, I wanted to see if people were interested in enabling it here. Cheers =) --slakr^\ talk / 14:26, 11 April 2008 (UTC)

I wouldn't use it, but it seems fairly harmless. Happy‑melon 19:25, 11 April 2008 (UTC)

I'd like a button to see "Most edits by" for each article

When looking at an article's revision history, It would be useful to me to click on a button to see which editors have edited the article the most.

When I come upon an article that needs cleanup, for example, sometimes I want to create a dialog with the editors that have worked on the article the most. Kingturtle (talk) 15:23, 11 April 2008 (UTC)

The external script page history statistics is helpful. –Pomte 15:38, 11 April 2008 (UTC)

TDS's Contribution Counter also does this, and uses the Toolserver. A user script could insert a button to the script in article history pages, or a link could be put into the MediaWiki message (a possible detraction to this is the load it might put on the toolserver). Gracenotes^T § 15:40, 11 April 2008 (UTC)

Also, consider that this might encourage people to own the articles and make lots of trivial edits instead of a few good ones. --slakr^\ talk / 15:46, 11 April 2008 (UTC)

"Contributors" tool on toolserver provides more info than the other toolserver tool, and can be linked directly (not sure this is possible with vs.aka-online.de). —AlexSm 15:59, 11 April 2008 (UTC)

I'd hate it. Yes, in itself it would be mildly interesting, but it would definitely cause ownership. --Yooden ☮

I'd like to see more done to discourage or even block ownership, like if you have edited an article 50 times you would be blocked from editing it until 50 other edits had been made. 199.125.109.104 (talk) 18:03, 11 April 2008 (UTC)

199., that's a dire solution in search of a dire problem. -Jéské ^{(v^_^v X of Swords)} 18:11, 11 April 2008 (UTC)

http://wikidashboard.parc.com/ does this. --Random832 (contribs) 18:13, 11 April 2008 (UTC)

Out of the thousands of active Wikipedians the SPAs are a small but very bothersome few. I've run into only three so far. I'm sure they mean well, but they are an absolute nuisance. I would guess there are less than 100 all together, but then I rarely edit any of the fluff articles that would be most likely to attract them - all the pop articles. 199.125.109.104 (talk) 18:24, 11 April 2008 (UTC)

SPAs attack more than pop-culture articles; see WP:ARBMAC. -Jéské ^{(v^_^v X of Swords)} 18:25, 11 April 2008 (UTC)

This would be a fantastic addition to the Toolbox section on the left, but only if it's in the form of a user script (and not a gadget). I don't know where the concerns of ownership are coming from; we're talking about contacting editors who potentially have much experience with an article for the express purpose of helping to improve said article. That's a very positive collaborative feature; I don't think anyone would be using it to say "oh, look at me, I've edited this a lot!" Aside from the fact that nobody would care, let's look at the two ways this could happen: they are making positive contributions, or they are vandalizing. If it's the former, it's a net gain for the project; if it's the later, they'd get blocked anyway.
However, it's not the sort of thing that the average user would need, which is why I don't think it needs to be a gadget. EVula // talk // ☯ // 18:30, 11 April 2008 (UTC)

You have a very optimistic view on your fellow editors. Even without the widget discussed here I had three very ugly encounters where editors defended their articles beyond reason. In one case, the former owner quit Wikipedia after his article has been blemished by me. --Yooden ☮

For some reason I'm never sad to see them go. The dashboard above is fun to use. Loads very slowly though, like Wikimap. Interesting that the dashboard is a product of Parc. Pretty notable research group there. If I'm not mistaken they invented the mouse (computer mouse). It's interesting that they find Wikipedia useful to work on, instead of say inventing something else new. 199.125.109.104 (talk) 19:32, 11 April 2008 (UTC)

Optimistic? Wow, of all the things I've been called, that certainly isn't one of them. :) Problems with ownership are totally separate from this tool; it has existed long before the script was set up, and it will continue to exist regardless of whether the tool gets a shortcut or not. I'm not saying that the script will end ownership; I'm only saying that its primary use can be for collaboration.
Oh, and if we lose combative editors, we're better off. EVula // talk // ☯ // 20:41, 11 April 2008 (UTC)

friendly/twinkle not working

I can't get either to work, and i followed the instructions to the letter. Anyone care to look at my monobook and see if they can find my rookie mistake? merci! Jepetto (talk) 17:00, 11 April 2008 (UTC)

what browser are you using? β^{_{command 2}} 17:09, 11 April 2008 (UTC)

firefox 2. i mean, i understand whats going on and all, just can't get it to come up. its as if wiki is just overlooking monobook. Jepetto (talk) 18:18, 11 April 2008 (UTC)

Are you using the monobook skin ? Otherwise adding it to your monobook.js won't work :D --TheDJ (talk • contribs) 18:38, 11 April 2008 (UTC)

See? i knew it was a rookie mistake. thanks for the help! Jepetto (talk) 18:55, 11 April 2008 (UTC)

"Edit lead section" button disappear after purge

I have chosen to add an [edit] link for the lead section of a page through "my preferences". I found that whenever I purge, the "Edit lead section" button disappears! I am using Firefox 2.0.0.13, and hope that somebody can solve this problem. --Quest for Truth (talk) 17:59, 11 April 2008 (UTC)

I just noticed that it happens for me, too. I'm using Safari 3.0.4 on a Mac. I'd say it's something to report to the author, rather than it being a browser issue. EVula // talk // ☯ // 18:32, 11 April 2008 (UTC)

Thank you for your reply! It confirms that it should not be a browser issue, but rather a "bug" in the system. I report the problem here simply because I do not know to whom I should report. If anyone knows the author of this button please tell me or just help me to report this problem to this author. --Quest for Truth (talk) 18:38, 11 April 2008 (UTC)

Fixed, thank you for brining this to my attention. Don't forget to WP:BYPASS. —AlexSm 20:02, 11 April 2008 (UTC)

Looks like it works. I just used the purge link at User:EVula/admin (which is also what I used in my testing above), and while it still disappeared on the first click, all I had to do was shift-refresh on the purged page and voila, there was the link. Thanks! EVula // talk // ☯ // 20:43, 11 April 2008 (UTC)

Image stats

Can anyone help out with some media stats? The total number of media files (ie. everything in the "Image:" namespace) is given at Special:Statistics. The current total is 772,759 (there is also a magic word that I can't find at the moment). This also includes dupes of Commons images that are kept here and not deleted (for various reasons, though most are in fact deleted, I think). Trying to assess the split between free and non-free can be done if you assume that: (a) all images have license templates, and that the lists at User:BetacommandBot/Free Template Useage and User:BetacommandBot/Non-Free Template Useage cover all the relevant templates in use. I've pasted the data at those two pages into an Excel spreadsheet, and the total, as of 8th April 2008, are, 360,125 free images and 282,264 non-free images. Add those together, and you get a total of 642,389. I would like to know what the missing 130,370 media files are (whether they are all sounds and video clips, or whether there are lots of images knocking around without license tags or using license tags not tracked by BetacommandBot), so my questions are:

• (1) Is there a list or category of orphaned images, similar to Special:LonelyPages for articles? Answer: Special:UnusedImages.
• (2) What are the sound file formats and how many of these files are there on Wikipedia? Partial answer: ogg is the audio file format. Numbers unknown, as ogg includes both audio and video. Some numbers available below.
• (3) What are the video clip file formats and how many of these files are there on Wikipedia? Partial answer: ogg is the wrapper for the video formats. Numbers unknown, as ogg includes both audio and video. Some numbers available below.
• (4) More generally, what are the allowable filename extensions and what numbers are they present at in the 772,759 total? Partial answer: png, gif, jpg, jpeg, xcf, pdf, mid, ogg, svg, djvu. The split between the numbers is not known. Some numbers available below.

Any and all answers gratefully received. Thanks. Carcharoth (talk) 18:45, 8 April 2008 (UTC)

A good portion of the missing images are probably images using a License template that I am not checking. β^_command 18:54, 8 April 2008 (UTC)

Does Category:Image copyright tags contain all the copyright tags (apparently there are 400 there), or will there be others? For example, I found Category:Image namespace templates, but that doesn't seem to include the sound and video stuff. Wikipedia:Media help and Wikipedia:Creation and usage of media files. The latter has the list of filenames I was looking for: "jpg, jpeg, png, gif, svg, and ogg". I now realise that .ogg is used for both sound and videos. It took me ages, but I also found Category:Ogg files. Only 72. Are there not more than that? Are the others on Commons? Carcharoth (talk) 19:10, 8 April 2008 (UTC)

Also, the Wikipedia and Commons upload screens say the permissible filenames are: "png, gif, jpg, jpeg, xcf, pdf, mid, ogg, svg, djvu." Does that mean that Wikipedia:Creation and usage of media files needs updating to includes xcf, pdf, mid, and djvu? Carcharoth (talk) 19:14, 8 April 2008 (UTC)

What about image pages that only have the "featured" tag or something like that? ie. image pages with the actual images on commons. Are these counted by the stats perhaps ? --TheDJ (talk • contribs) 19:39, 8 April 2008 (UTC)

That is one possibility. Another is ones where the image is on Commons, but a local copy has been kept and not deleted. Anyone have any ideas how to count these two categories of "images" that will show up in the image namespace. Carcharoth (talk) 13:16, 9 April 2008 (UTC)

I answered one of my questions. Special:UnusedImages. Anyone have answers to the other ones? Carcharoth (talk) 13:16, 9 April 2008 (UTC)

Thanks to Betacommand for running an SQL query to get an approximate answer. These approximate figures as of 10 April 2008, are

• png: 107,633
• gif: 50,158
• jpg: 498,505
• jpeg: 5520
• xcf: 16
• pdf: 1,557
• mid: 134
• ogg: 5,550
• svg: 7,880
• djvu: 0

For comparison, the total number of media files, at approximate the same time (within a few hours or so) was 775,671. The total from Betacommand's figures is 676,953. A discrepancy of 98,718. Anyone have any idea why there is such a big discrepancy? Finally, it is interesting to note that we have around 5500 audio/video files. Obviously Category:Ogg files is woefully incomplete. Carcharoth (talk) 22:23, 10 April 2008 (UTC)

Carcharoth, I when I get a chance (~6 hours) Ill see what I can find out. β^{_{command 2}} 17:08, 11 April 2008 (UTC)

Thanks to Betacommand for getting the data. At the time he obtained the data, the total number of files, according to Special:Statistics, was 776,088. Betacommand's total was 784,623 - an excess of over 8,000. Not quite sure why that excess is there, but the breakdown by the filetypes listed above was:

• png: 127,514
• gif: 52,651
• jpg/jpeg: 588,902
• xcf: 16
• pdf: 1567
• mid/midi: 150
• ogg: 5,549
• svg: 7,947
• djvu: 0

Those are the allowed filename extensions, and total 784,294 files. There are a further 327 files with extensions that are supposedly not allowed. These are: pgn (3); dxb (1); dia (4); sgf (2); fig (4); bmp (26); sxd (0); wav (171); xls (83); sxi (0); graffle (8); and jpe (25). Not sure what some of those filename extensions mean - I've linked where possible, and left unlinked where I couldn't find any article. Carcharoth (talk) 21:48, 12 April 2008 (UTC)

the extra numbers could be caused by MySQL duplication with file extension capitalization. β^{_{command 2}} 22:09, 12 April 2008 (UTC)

No Edit Summary When Adding a New Section

This "feature" may be intentional: When adding a new section (using the "+" tab), there is no field in which to enter an Edit Summary. If that's intentional, then fine. What that means is whenever I issue a warning on some user's talk page (usually for vandalism), if it's the first warning of the month, then ordinarily I would use the "+" tab to create a new section. However, without being able to enter an edit summary, I won't use the "+" tab. Instead, I'll use the "edit this page" tab and create a new section using the double-equal sign trick.

The reason I always want to enter an edit summary is in case the vandal removes my warning (which is allowed under the rules), there is still a record of the warning, which I quote in the edit summary. Therefore I favor edit summaries even for new sections, but I can work around it if it's intentional that they are omitted. Thanks. --Art Smart (talk) 16:02, 9 April 2008 (UTC)

Yes, I think it is intentional; when adding a new section, it automatically adds an edit summary with the section title you entered and "new section".   jj137 (talk) 17:12, 9 April 2008 (UTC)

Indeed, the edit summary is whatever you name the section, in the form of a link to the section on the page and a "new section" declaration; makes spotting such edits much easier to find in contrib pages, histories, and watchlists. Here's an example of it in action.[1] EVula // talk // ☯ // 17:44, 9 April 2008 (UTC)

Thanks for the clarification. However, I'll just use my workaround, since user warnings are supposed to have the month and year as the new section heading. An edit summary of "new section - April 2008" isn't nearly as informative (to me at least) as

issued {{subst:uw-v2}} warning for *1991 - tony horrocks and james heeley, English school boys

as seen here for example. Also, the user is allowed to remove warnings from his/her talk page, but can't remove edit summaries, so I always want my warning in the edit summary itself. Thanks again for the clarification. --Art Smart (talk) 16:35, 12 April 2008 (UTC)