Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Archives, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

External link icons proposal

This is something I've always thought and a brief discussion has pointed me here. Basically all PDFs give a symbol in links (http://www.example.pdf) instead of the diagonal arrow link thing (http://www.example.com/). I think xls should use {{XLSlink}} type icons instead (and equivalently for Word Documents, .doc) as they a user may be much more reluctant to open these links, may be technically restricted or otherwise. Also, let's face it. The |format= parameter in citation templates isn't utilised by everyone. Rambo's Revenge (talk) 15:19, 30 September 2010 (UTC)

I am fairly sure this has been discussed before. The PDF icon is defined at MediaWiki:Common.css. You can add the XLS icon with:

#content a[href$=".xls"].external, 
#content a[href*=".xls?"].external, 
#content a[href*=".xls#"].external,
#content a[href$=".XLS"].external, 
#content a[href*=".XLS?"].external, 
#content a[href*=".XLS#"].external,
#mw_content  a[href$=".xls"].external, 
#mw_content  a[href*=".xls?"].external, 
#mw_content  a[href*=".xls#"].external,
#mw_content  a[href$=".XLS"].external, 
#mw_content  a[href*=".XLS?"].external, 
#mw_content  a[href*=".XLS#"].external {
    background: url("http://upload.wikimedia.org/wikipedia/commons/b/ba/Page_white_excel.png") center right no-repeat;
    padding-right: 16px;
}

You can test by adding the CSS to Special:MyPage/skin.css. This link should have the icon: http://www.example.org/example.xls ---— Gadget850 (Ed) ^talk 16:13, 30 September 2010 (UTC)

I have amended the initial example from http://www.example.pdf/ to http://www.example.pdf because the presence of the trailing slash means that the URL doesn't end with ".pdf", which defeats the object of the example. --Redrose64 (talk) 16:16, 30 September 2010 (UTC)

Think this is a great idea...many of this types of links are sometimes considered dangerous and i would love to know in advance if this is the type of link i am about to click on.16:49, 30 September 2010 (UTC)

This seems helpful for DOCs (which are occasionally used as links or sources), but XLS is pretty rare and it would often be clear from context or description. Might as well have both though. Rd232 ^talk 16:56, 30 September 2010 (UTC)

That is the perfect solution and works brilliantly Gadget850. I think it's worth making this the default for everyone. You mention this being discussed before. If an elegant solution such as yours was so feasible, I'd be suprised to see anyone oppose it. Is there any disadvantage of having such a function which is already so universally used for PDFs? Rambo's Revenge (talk) 17:40, 30 September 2010 (UTC)

IIRC, it was opposed because "we should discourage linking to propriety formats" and there was no free icon. And you may have to write a detailed explanation why it's free. — Dispenser 19:27, 30 September 2010 (UTC)

• I def support making icons for .doc, .xls, and possibly other non-web formats default for users. Protonk (talk) 17:44, 30 September 2010 (UTC)
  • I've imitated what you did to give a code that works with .doc[1] Is it worth integrating docx & xlsx into those. Anything else common enough? Rambo's Revenge (talk) 19:36, 30 September 2010 (UTC)
• While I like that this makes it clear when a document is in one of these formats, it doesn't address the basic problem with using such proprietary-format sources. The vendor can render them unreadable practically overnight. We need to have them rendered into a more stable, more trustworthy, and more widely accessible format. PDF would suffice. If we need to do this then the links to such a stable format should be provided, if not in preference to the proprietary format, then at least in parallel to it. A WebCitation or link may be helpful in archiving the result, and List of PDF software suggests several converters. LeadSongDog come howl! 21:39, 30 September 2010 (UTC)
  • I don't think such a solution is feasible or practical for most of these links. Protonk (talk) 22:51, 30 September 2010 (UTC)
    • I second this and also don't think it's related to this proposal. Can we try and keep this specific proposal rolling as I don't wish for it to sink into obscurity. What would be the next steps? Rambo's Revenge (talk) 23:44, 30 September 2010 (UTC)
  • What is the issue with proprietary document formats? PDF did not become open source until 2008, and was well used here before that. DOCX, XLSX and other Office Open XML formats are an open standard. ---— Gadget850 (Ed) ^talk 06:33, 1 October 2010 (UTC)
    • The second "O" in OOXML is widely treated as a very bad joke in the open software community. While some parts of the format are disclosed, it doesn't come close to a fully open format. The fact that the vendor has a long history of embrace and extend tactics doesn't help. But the real issue is that their active content enables so many malware attacks that the formats are routinely blocked by firewalls. Still, you are correct that visibly marking them with their file formats is helpful to users independently of whether they consider the content to be safe to use. LeadSongDog come howl! 20:03, 1 October 2010 (UTC)
    • LeadSong is absolutely right. Providing the icons is less an issue of promoting open formats and more an issue of providing a convenience to users who (esp. if they are on linux or a mobile device) might want to know that the link target will appear as a format which they can't or won't read. I would prefer that external links all land on simple HTML, but that isn't the way of the world. Protonk (talk) 21:46, 3 October 2010 (UTC)

I have the CSS for XLS, DOC and RTF at User:Gadget850/ExternalLinkIcons.css. I will probably add DOCX, XLSX and others as I find icons. You can copy the CSS or import it by adding this to your Special:MyPage/skin.js:

importStylesheet('User:Gadget850/ExternalLinkIcons.css'); // Linkback: [[User:Gadget850/ExternalLinkIcons.css]]

---— Gadget850 (Ed) ^talk 16:40, 2 October 2010 (UTC)

• Excellent work Gadget850. Should we make this the default to all users? There seem to be no disadvantages to users so shall we boldly update MediaWiki:Common.css Rambo's Revenge (talk) 18:29, 3 October 2010 (UTC)
  • I think we ought to solicit a little more input before we make a wide ranging change like that. Protonk (talk) 21:44, 3 October 2010 (UTC)
    • Okay, where? (don't say RfC) Rambo's Revenge (talk) 23:53, 3 October 2010 (UTC)
      • Naw, it could be here. Just make a little sub-section to this one saying what you want to be changed, post a notice on the CSS talk page you want to change and put something up on WP:CENT. If we have our heads up our asses, people will tell us. Otherwise we can make the change and be cool. Protonk (talk) 23:55, 3 October 2010 (UTC)

Icons

After some fiddling, I find that the icons should be 16px wide and a max of 16px high, and must be bitmap. SVG will not work since the image is being called directly and not through ImageMagic that would convert it to PNG. Icons and are certainly open to more tweaking. ---— Gadget850 (Ed) ^talk 12:56, 4 October 2010 (UTC)

The icons are going to have to be smaller than the current size. They clip when the font size is reduced, as with {{reflist}}. ---— Gadget850 (Ed) ^talk 15:15, 4 October 2010 (UTC)

The PDF icons are 16x16, is it just a case of doing this? Rambo's Revenge (talk) 15:20, 4 October 2010 (UTC)

Proposal

I propose the contents of User:Gadget850/ExternalLinkIcons.css is added to MediaWiki:Common.css to supplement the existing PDF icon and indentify other formats (namely doc, docx, xls, xlsx, rtf, and txt) that are not html.

• Support (as proposer) Rambo's Revenge (talk) 11:48, 4 October 2010 (UTC)

NB. This proposal has been listed at Template:Centralized discussion — Rambo's Revenge (talk) 12:01, 4 October 2010 (UTC)

• I don't think it's a big deal, so unless someone brings up a good reason why this should not be done, go for it. /ƒETCHCOMMS/ 12:46, 4 October 2010 (UTC)
• Support, small improvement but useful nonetheless. It adds consistency with the similar PDF icon. Dodoïste (talk) 12:48, 4 October 2010 (UTC)

• Weak oppose as unnecessary CSS bloat. Some browsers will download the additional icons whether they appear in a page or not. All browsers will have to deal with the longer CSS files. We should not be using these formats in the first place, at least when we can avoid it, and certainly not appear to condone them by having special icons for them. Many users do not have the necessary software to open them. Those who do often do not normally use this software. For a user who does not normally use Microsoft Office or Open Office, and consequently has disabled their quickstart function (which bogs down a computer at startup), loading an Office document takes ages.

However, I would support one common warning icon for all proprietary formats that are prone to viruses and loading problems. Hans Adler 13:15, 4 October 2010 (UTC)

• (edit conflict) Support for easy identification of file formats and for consistency with the PDF icon. It might look small at first, but I'm sure the readers will benefit from this. ~NerdyScienceDude 13:16, 4 October 2010 (UTC)
• Oppose Links to these file are far and few between, and I feel it does not justify bloating common.css for these icons. PDF is by far the most linked document format (after HTML). This is a solution looking for a problem. — Edokter • Talk • 13:31, 4 October 2010 (UTC)

• (@Hans Adler) This isn't about whether we should use these formats (ideally we wouldn't use PDF either, and PDFs were also used long before they became open source) it is about warning users that they may not to click on a link because they might not be able to or take a long time to open. Often |format etc. is omitted.

That's the reason for my alternative proposal of one icon for all of these crappy formats that clueless secretaries use when asked to publish something on the web. Hans Adler 14:15, 4 October 2010 (UTC)

It might not be a good idea to employ ad-hominem attacks against those who chose to put content online using a file type that you dislike. Vanilla HTML is all very well, but sometimes there are quite good reasons for using proprietary formats. Especially when the intended audience was somebody other than wikipedians, as is often the case with content on the rest of the internet that we might want to cite. bobrayner (talk) 15:14, 4 October 2010 (UTC)

• (@Edokter) I disagree with the "solution looking for a problem". A wiki search shows the existance of many (>4000) with a few false positives of those including "format" and ".xls" and, seemingly, even more for .doc.

Rambo's Revenge (talk) 13:55, 4 October 2010 (UTC)

4000 is not much. If you do the analogous search for PDF you get 70,000. Hans Adler 14:15, 4 October 2010 (UTC)

That's a terrible search. Most of them I looked at contained "format PDF" and had "xls" in some other context. OrangeDog (τ • ε) 18:46, 19 October 2010 (UTC)

• Support I think it would be helpful. I do not consider the possibility of changing standards to be a big problem, since client software to read common proprietary formats (such as Word, Excel) is generally quite good at displaying documents written by a slightly earlier version of the software - the chances of any one cited item failing to be readable by a wikipedia user because of subsequent changes to the standard are, I think, much lower than the chances of the link failing due to vanilla linkrot (my brand-new laptop copes effortlessly with Excel spreadsheets that my team created in the 20th century). And even if it does fail, it's not Wikipedia's job to guarantee that every person must be able to read every cited document even to the extent of removing citations or substituting in less-than-ideal ones. The widespread use of universally-readable formats is a laudable goal, but in the real world there will sometimes be a better .doc or .xls out there, and most people browsing wikipedia will be able to read them; if you want to cater to those who cannot, maybe citing a second source would be better than removing the first choice. bobrayner (talk) 15:10, 4 October 2010 (UTC)
• Support. It's worth noting that those who oppose the use of these formats (for which there are valid reasons) should consider that ensuring that their use is identified might help reduce their usage. Making them more visible may encourage people to replace them with alternatives. Rd232 ^talk 15:21, 4 October 2010 (UTC)
• Support. About bloody time, too. If the best reference available is in Excel/Word format, the least we could do is to forewarn the readers of that. This has nothing to do with the "promotion" of proprietary formats.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 4, 2010; 15:42 (UTC)
• Weak Support Not strictly necessary, but I don't see much of a downside. --Cybercobra (talk) 15:59, 4 October 2010 (UTC)
• Support Be bold and do it. Lugnuts (talk) 17:26, 4 October 2010 (UTC)
• Support, as should be clear from my comments above. I also think we need to steer clear of "XYZ format is crappy, why support it" discussions. We don't support document formats in external links. We just link to what the source material is. If the source material exists only in .DOC (common for corporate or government sources), our provision of an indication is not a support of that format. It is simply a convenience to the reader. I can't speak to the technical issue of CSS bloat, but I don't feel bloat is a universal argument against changing the status quo. Protonk (talk) 18:49, 4 October 2010 (UTC)
• Support I think it is a good idea. Armbrust ^Talk _Contribs 19:30, 4 October 2010 (UTC)
• Support Not everyone has the capability to read DOC or XLS files. However, those icons should be linked to the article on the respective format. What if someone doesn't know what they mean? — Train2104 (talk • contribs • count) 02:19, 5 October 2010 (UTC)
• Weak Support per Cybercobra. If we can minimize the downsides... let's do it. Jclemens (talk) 04:09, 5 October 2010 (UTC)s
• Support will only help editors understand the abnormal links and it gives them the choice to click on certain types of links before hand.Moxy (talk) 05:59, 5 October 2010 (UTC)
• support seems really quite helpful, and the expressed downsides seem minor. Hobit (talk) 00:38, 6 October 2010 (UTC)
• Question Re: Hans Adler's mention of CSS bloat. How much additional data are we talking about that would need to be loaded, and how much of a potential loading speed decrease for users? Isn't there a new resource loader being written that is supposed to only load the things that each individual user needs to see? Also, are there any legal issues with making icons depicting these formats? Thanks!--Danaman5 (talk) 12:26, 6 October 2010 (UTC)
  • Comment For the css bloat, I'd say it wouldn't be significantly more than the audio and video link icon definitions in the monobook stylesheet, which I would guestimate to be around 1-2 kilobytes. As for the images and the formats they represent I would probably suggest using some sort of generic icon set since there are other similar file formats (.odt, .ods, .odp, etc.) out there too. --Dlrohrer2003 19:19, 6 October 2010 (UTC)
• Support, a sensible proposal and sound idea, makes sense. -- Cirt (talk) 05:15, 8 October 2010 (UTC)
• OPPOSE - because using icons of brands in an article is advertising - and that's not allowed in wikipedia. Spamelgoog (talk) 22:24, 8 October 2010 (UTC)

  Comment moved to correct place chronologically, also this was the users first Wikipedia space edit and the account was less than 10 hours old. Rambo's Revenge (talk) 22:34, 9 October 2010 (UTC)

• Comment-What about OpenDocument, ppt, image, executable, zip extensions?Smallman12q (talk) 16:54, 9 October 2010 (UTC)
• I don't really buy the CSS bloat argument. In the coming months Wikimedia wikis will be using ResourceLoader, which will make the argument even more spurious (or perhaps dubious, you pick). I can agree that these icons are kind of silly and rare, so I won't outright support this proposal, but I certainly wouldn't oppose it based on the current arguments put forward. Think of this as a mild way of saying don't worry about performance: if you like the icons (aesthetically) and think they should be there, support. If not, oppose. Keep it simple, Sally. --MZMcBride (talk) 22:13, 9 October 2010 (UTC)
• Support Seems a good idea to me, would be helpful. Acather96 (talk) 07:19, 10 October 2010 (UTC)
• Support. Seems like a decent proposal to me, and I don't see much of an issue with performance, especially not in the grand scheme of things. If it increases users' awareness of what they are about to click, then it is a good thing. — Huntster (t @ c) 09:08, 22 October 2010 (UTC)

• Oppose: Showing icons might be nice, but basing that on extensions is bad. Only a subset of documents will have such extensions. A subset of this extensions will not follow your interpretation. Some of these will be fatally wrong.
  Checking and amending format entries is a far better solution. -- Tomdo08 (talk) 20:20, 25 October 2010 (UTC)

• Comment: People who want to check for file extensions, can always do this in the status line of the browser. On the other hand a wrong format designation is not distinguishable from a correct one. Following the proposal would be invalidating all format designations! -- Tomdo08 (talk) 20:33, 25 October 2010 (UTC)
• Support – Useful and consistent. —MC10 (T•C•GB•L) 04:58, 30 October 2010 (UTC)

Polls are evil, especially when ignoring the technical niceties of how the WWW works

I de-rail this bandwagon by noting, as no-one else has done so far (unexpectedly for the technical Village Pump, and also unexpectedly since we do have an encyclopaedia around here that sort of explains this stuff), that there's no such thing as a file extension in a URL. Internet media type is determined by the Content-Type: header in the HTTP server response. One could publish an image/jpeg object with a URL ending in ".xls" and it wouldn't make it a spreadsheet file. The little pictures are not determined by actual content type. They have no guarantee of being right for readers. You really are better off ensuring that every non-HTML external hyperlink has a |format=[[Portable Document Format|PDF]] or a |format=[[Microsoft Word|DOC]] parameter in the citation template or uses one of the external link file type templates. The right thing cannot be deduced from just the URL. For universally correct results, it has to be specified alongside the external hyperlink, from knowledge of what the thing being hyperlinked-to is. Uncle G (talk) 02:11, 5 October 2010 (UTC)

• How often is a URL used on WP that looks like an XLS or a DOC not one of those? I've never come across that, so I'd guess it's rare. Rd232 ^talk 07:57, 5 October 2010 (UTC)
  • On Wikipedia we'd have to measure. But in the world at large it's not rare. The tag ends of URLs not matching, when misinterpreted as filename extensions, the Content-Type: of the object are why Internet Explorer gained "MIME Handling Enforcement".

    "Internet Explorer MIME Handling Enforcement". Microsoft TechNet. Microsoft.

    Uncle G (talk) 17:14, 5 October 2010 (UTC)

    • It doesn't matter how common it is Out There, it matters how common it is In Here. How often do articles use such URLs? Generally, the type of thing we're talking about will be a source; a source that doesn't even get the extension right is quite likely not a reliable source. So in general, I would call it rare, and calling attention to the cases where such extensions are used would likely make it rarer still. Rd232 ^talk 10:20, 6 October 2010 (UTC)
      • That you still talk of "getting the extension right" indicates that you've missed the point. There is no extension to "get right". We really do have an encyclopaedia around here that sort of explains this stuff. Uncle G (talk) 01:52, 7 October 2010 (UTC)
        • Er, what? Of course there's an extension to get right - extensions haven't been abolished (albeit superseded by mimetypes where possible), and it remains true that a document ending in .XLS ought to be an Excel spreadsheet. Mimetypes schmimetypes, that's what people expect, not least because it's usually the case. Rd232 ^talk 11:58, 7 October 2010 (UTC)

You err there. Wikipedia should not use file extensions:

• Extensions never were reliable.
• Giving extensions a special meaning was always a bad idea.
• To ignore and remove extensions is good advice.
• Documents ending in ".XLS" do not ought to be an Excel spreadsheet.
• Most documents with this ending will be, admittedly - but the case is different for ".doc" for example.
• It's not what people expect. Some will, a lot know better, and most will expect nothing.
• Even if a lot of people will expect extensions to be something special, it still is a bad idea.
• I would like to challenge the notion that most citable documents have endings with your interpretation.
• Having a special ending is rather a bad sign for quality than a good one. More so if relying on such ending. Databases of citable documents will rather have just an URL - an uniform resource locator.
• Wikipedia does not have to be the leading edge in such matters, but it's not a good idea to make it an obstacle to changes to the better.
• Giving hints that might be severely wrong is not a good idea.

-- Tomdo08 (talk) 19:53, 25 October 2010 (UTC)

• I think if we were designing a security protocol, you would have exposed a serious hole. There is no requirement that the stated extension be declared in the given URL and no reason that a given URL be a final landing point (and not a redirect page). A more full featured solution would be to write a web crawler which follows external links, classifies the content and adds a tag. But we are merely adding a convenience icon. False negatives may produce confusion (resolved by the format tag), but false positives would be the only really disagreeable outcome for readers. And like RD 232 says, how many false positives have you discovered on the web? Protonk (talk) 15:51, 5 October 2010 (UTC)
  • More than you'd like to think. Author of User:PDFbot and WP:Checklinks — Dispenser 16:40, 5 October 2010 (UTC)
    • Thats a possibly indeterminate number. :) enough to make URLs a bad first approximation? Protonk (talk) 17:06, 5 October 2010 (UTC)
    • ...or remove the existing PDF icon? Rambo's Revenge (talk) 17:08, 5 October 2010 (UTC)
  • See above. This problem is why Internet Explorer has MIME Handling Enforcement. And this isn't discovering a security hole. This security hole actually existed, some several years ago. It is CVE-2001-0727 if memory serves correctly.

    It's a fairly good idea to learn from experience in these things, and the experience is that "extensions" (which are not in fact extensions at all, and were never intended to be) don't match content types, that this is widespread enough that IE has a specific mechanism to avert the problems that this causes with IE's cache, and that really it isn't a good idea to make these assumptions, lest one repeat an error that was discovered the same year that Wikipedia was launched. Uncle G (talk) 17:14, 5 October 2010 (UTC)

Question: would it be (a) possible and (b) desirable for a bot to check for mismatches of extensions and MIME type? Rd232 ^talk 10:21, 6 October 2010 (UTC)

Yes possible - but desirable? It certainly would be limited protection against abuse, since MIME types can change, and presumably we would only check once, and as Uncle G says the hole is fixed, and we would probably be finding mistake rather than attacks. Or if you mean to "icon" the urls better, then I'm not sure I see the advantage of "iconing" them, certainly with what look like Microsoft logos. As to the extent of .xls terminated urls, there seem to be about 8,730 articles (compared with some 307,000 for ".pdf") containing them which is small compared with the total number of articles, but large in absolute terms. However many of these are "references no one will ever check" e.g. a spreadsheet of populations for several hundred towns, ref'd in each of the several hundred articles. Rich Farmbrough, 04:19, 7 October 2010 (UTC).

I didn't envisage protection against abuse, an issue which seems somewhat distant from the origin of this thread. I envisaged mistake checking. At the least, it would give statistical data on the issue. Rd232 ^talk 11:58, 7 October 2010 (UTC)

Caveats

URLs for sites that us a query will not show an icon. For example, this New York Times article is a PDF:

http://query.nytimes.com/mem/archive-free/pdf?_r=2&res=9F00E6DE1E3CE633A25754C1A9659C946396D6CF

There are probably other ways in which an URL extension nay not be recognized or spoofed. ---— Gadget850 (Ed) ^talk 17:27, 9 October 2010 (UTC)

a bot could recognise common ones (and/or check mimetypes) and add the format= parameter to cite templates. Rd232 ^talk 18:54, 9 October 2010 (UTC)

PDFbot already does that, its just it's a pain running the bot. — Dispenser 20:03, 9 October 2010 (UTC)

Consensus?

Ext	Count
html	2890966
php	2038904
htm	1362586
asp	615023
pdf	594196
aspx	426159
cgi	251490
shtml	240630
cfm	199854
stm	174180
(digits)	166514
fcgi	154070
jsp	129049
dll	104817
pl	96219
jspa	51689
do	51288
jpg	42905
action	38570
ece	34938
jhtml	30602
sd	28798
gif	27233
txt	26790
story	21465
phtml	16065
xls	12199
php3	11746
doc	11673
dsml	11366
cms	10351
ashx	9697
jp	9613
dbml	9061
xml	8708
mp3	7460
exe	5184
asjx	5114
zip	4497
shtm	4396
php4	4294
app	3754
ssf	3622
article	3277
com	3037
csv	2981
sps	2665
py	2408
mspx	2327
xpd	2277
xhtml	2084
lasso	2063
qst	1896
zhtml	1889
prl	1860
mma	1804
pperl	1639
ppt	1497
136m	1442

I'm wondering if we have some sort of consensus here now (I'm also posting so this doesn't get archived). The proposal seems to have significant support, and despitie a couple of concerns about CSS bloat, it doesn't seem to be that much especially when considering MZMcBride's comments about WP:PERF and the impending ResourceLoader. Obviously (as proposer) I'm biased so I just thought I'd see if someone much less involved would agree with the above summary and we can then get this implemented. Rambo's Revenge (talk) 10:24, 14 October 2010 (UTC)

Well I'm opposed, as it's based on a flawed assumption (see Uncle G's section and the point about php/query served documents), we shouldn't really be using these links anyway, and there's no guard against it spiralling out of control with wars over who's pet format gets to have an icon. OrangeDog (τ • ε) 17:04, 17 October 2010 (UTC)

There is nowhere that says we shouldn't use these links. Next will we rule out offline sources such as books etc. that people can't access? Also spiral out of control like it has since PDFs were added back in 2006? Rambo's Revenge (talk) 00:00, 18 October 2010 (UTC)

I don't know, it's a LOT of bloat. Isn't it better to use explicit templates such as {{PDFlink}} that adds the icon ? That works wherever you use it, and it doesn't have any of the problems listed above. I've never really been a fan of these link icons. —TheDJ (talk • contribs) 14:30, 19 October 2010 (UTC)

The problem is people don't use templates or format parameters. I've definately clicked on a PDF link before unawares and began downloading a whole large file that I don't want. Rambo's Revenge (talk) 16:39, 19 October 2010 (UTC)

A bot to fill in the format parameter is a much better solution. OrangeDog (τ • ε) 15:43, 20 October 2010 (UTC)

But won't work because some links don't even use a citation template. Rambo's Revenge (talk) 15:50, 20 October 2010 (UTC)

Indeed. This proposal at least does something to make people aware, rather than sitting at the current status queue. May not be perfect, but nothing in this world is. — Huntster (t @ c) 09:07, 22 October 2010 (UTC)

This proposal also won't work, as explained above. (wikt:status quo). OrangeDog (τ • ε) 21:49, 23 October 2010 (UTC)

The limitations of this proposal are identical to those of the existing PDF icon which has been in use for 4 years. Also consensus seems to be for implementation. Rambo's Revenge (talk) 21:43, 24 October 2010 (UTC)

Indeed there seems to be. The poll above currently sits at 16 to 4 in favour...80%. — Huntster (t @ c) 20:09, 26 October 2010 (UTC)

First polling is evil. Second, the majority of votes were added before the major flaws were pointed out. OrangeDog (τ • ε) 22:56, 26 October 2010 (UTC)

Using cite templates with format parameter is good, but using a bot for automatic filling of the format parameter is bad, too: Extensions are ambiguous. -- Tomdo08 (talk) 20:27, 25 October 2010 (UTC)

Showing icons might be nice, but basing that on extensions is bad:

• Only a subset of documents will have such extensions.
• A subset of this extensions will not follow your interpretation.
• Some of these will be fatally wrong.

Checking and amending format entries is a far better solution. -- Tomdo08 (talk) 20:09, 25 October 2010 (UTC)

I'm a bit confused by your statement. Are you saying that having at least a large percentage of existing links to documents iconified is worse than having none? That the only viable solution is to have each link checked by hand? I apologise if I'm mis-interpreting, but these arguments seem a bit outlandish. — Huntster (t @ c) 20:06, 26 October 2010 (UTC)

So I'm here to provide fuel for the burn *.* campaign ;-). I wrote a tool to count all the extension from the 16.5 million external links and produce the table (right) after a few hours of playing around with OurSQL. The more recognizable extensions are in bold. There are nearly 50 times more links with the extension of .pdf than .xls or .doc.

We have definitions in MediaWiki:Common.js which override the default icon. Monobook and Vector use the following extension to style the link icon:

audio (blue speaker or musical note icon)

.ogg, .mid, .midi, .mp3, .wav, .wma

video (film strip or reel icon)

.ogm, .avi., .mpeg, .mpg

document (blue document or gray document icon)

.pdf

Notes: The match on .pdf? and .pdf# is done so linking to specific pages (example.pdf#page=3) or anchors will display correctly, it is generally not needed for other types of files. Acrobat (default for most people) web browser can take up to two minutes to load before rendering the PDF. Additionally, the major of PDFs are more than 0.5 MB and picture heavy ones can be over 100 MB. — Dispenser 04:21, 28 October 2010 (UTC)

What are all those exe links doing there? They should almost certainly be removed. OrangeDog (τ • ε) 22:30, 28 October 2010 (UTC)

Many of them are CGI programs on web servers (1,568 for zipinfo.com), but 316 seem to be regular .exe. Half of that link to http://elections.sos.state.tx.us/elchist.exe CGI program, some more appear to be Microsoft issued executable files, and other are from domains I generally don't recognized. — Dispenser 21:38, 2 November 2010 (UTC)

Firstly a very belated thank you to Dispenser for knocking together the very informative table on extension formats. As for depecting "." formats I still don't see evidence not do so. To me the facts are that most extensions do match (security threats and type II errors hardly seem applicable to the majority of readers/users). Furthermore, people fail to use the format parameter (or sometimes cite templates) and, like the PDF icon that has been around for years, we have a good way to inform readers that a link is potentially undesirable for them to open regardless of how the link is formatted. I've been advised in audited content work to add XLSlink which does a worse job of this idea. Surely making it automatic is beneficial in spite of above caveats. I'd also propose some form of icon for images is added in light of Dispenser's findings. Rambo's Revenge (talk) 00:40, 1 November 2010 (UTC)

Things like this are slow. These styling matches are relatively complicated matches and on pages with many links (think Barack Obama), and on older computers, you can probably notice the difference in HTML rendertime between them being there, and them not being there. I'm not against them per se, I just want everyone to really grasp the fact that the more complicated CSS matches we add, the slower pages will be become, especially to those not fortunate enough to have the latest hardware and software (think 3rd world countries). Complicated CSS adds up, just as complicated Javascript adds up. The more complicated a page becomes, the more users we are excluding from having a usable browsing experience. It's not the raindrop, it's the fact that at some point the drops will form a pool of water. The increase in client rendertime will affect every page and the benefit cases are 50x more rare than the PDF case (if one doc link per page, then 1 in 290 or so pages will have a match for a link with a .doc extension). Fixing "rare" cases is relatively expensive (It is why we often use inline css for templates, instead of adding it all to the main stylesheet [only has wikitable, infobox and warningboxes]). —TheDJ (talk • contribs) 01:10, 1 November 2010 (UTC)

Problem with diffs and empty lines

I just submitted the the following bug:

When viewing a diff that contains empty context lines (gray), those lines are not shown. This is due to all cells in that row having no content, which reverts the row height to zero. It used to show a thin gray line, but a change in diff.css (table.diff td {padding: 0px;}) made that disappear as well. Example in URL should show an empty line directly above "==Professional acting career==".

Having the following CSS in your own stylesheet restores the empty line: td.diff-marker {height: 1.5em;}

However, that is a hack; A better solution is not to have rows with all empty cells. At least one cell needs to have content, and all rows start with a cell with a diff marker; these are either empty, or contain a + or - sign. I suggest putting a non-breaking space ( ) in the empty diff marker cells. This will cause the row to have content and force the proper height automatically.

I wonder if there is any objection to applying this temporary fix in vextor.css (or common.css) until this bug is fixed. — Edokter • Talk • 20:56, 28 October 2010 (UTC)

Both ideas seem good. Only problem with an nbsp in the diff-markers, is that they are copy pasted along with the content. Might have some unforeseen effects for some people I guess. We could also use a ​ zero width space, that would be harder to see, but also more difficult to remove from copy pasted content I guess, because you wouldn't spot them in the first place. —TheDJ (talk • contribs) 00:44, 29 October 2010 (UTC)

I see zero-width spaces always as squares; it is not a widely supported character (it may also be zero-height), so that may cause more trouble then a simple nbsp. The nbsp being copied is not much of a problem; the plus- and minus signs also get copied. But it could be replaced by any neutral character. — Edokter • Talk • 11:22, 29 October 2010 (UTC)

I just realized who made the change in SVN :) Thanks DJ. As a side suggestion: could the hyphen be replaced with −? Also, how can I check if a revision is live here? — Edokter • Talk • 00:21, 30 October 2010 (UTC)

Fixed in r75658. Since it may take a while for it to go live, I still want to implement the temporary fix. — Edokter • Talk • 20:37, 29 October 2010 (UTC)

Done in monobook and vector. Added a to-do box on both talk pages. — Edokter • Talk • 21:47, 29 October 2010 (UTC)

I'm just curious about this

If the English Wikipedia has now been edited 422,480,253 times (I used {{subst:NUMBEROFEDITS}} to produce this number), then why are the oldid-numbers of the most recent versions just above 393,500,000? --Theurgist (talk) 23:22, 28 October 2010 (UTC)

I'm not too sure, but I think the {{NUMBEROFEDITS}} feature counts some actions (maybe log actions?) that the oldid number does not take into account. The disparity between the two figures has been gradually increasing over the last five years. Graham87 02:35, 29 October 2010 (UTC)

Lies, damned lies, and statistics. ;-)

I know that certain actions (like page moves and page protections) will register a new entry in the revision table. Perhaps they don't increment oldid? I can't investigate now, but I suppose that could be the source of a large percentage of the offset. --MZMcBride (talk) 03:35, 29 October 2010 (UTC)

Hmmm, it seems that this diff indicates that page protections increment oldid. This diff indicates the same thing for page moves, AFAICT. Graham87 14:48, 29 October 2010 (UTC)

Do null edits increment oldid? —DoRD (talk) 15:28, 29 October 2010 (UTC)

"A null edit will not record an edit, nor make any entry in the page history or in Recent Changes, etc." from WP:NULL. Killiondude (talk) 18:46, 29 October 2010 (UTC)

No new message banner?

Is it just me, or has the 'new message' banner disappeared in the last couple of days? I have some CSS set on mine to reposition it, but nothing that should interfere with it entirely. Still, I don't seem to be getting any banner when I get a new message. --Ludwigs2 00:12, 29 October 2010 (UTC)

Only way to know wehter it is your CSS is to disable it and try again. — Edokter • Talk • 00:38, 29 October 2010 (UTC)

I've disabled it. would someone care to send me a test message? (please, not everyone - lol). --Ludwigs2 18:36, 29 October 2010 (UTC)

I've sent you one; noting it here mostly to avoid flooding your page with more. — Gavia immer (talk) 18:44, 29 October 2010 (UTC)

Got it, and that works, so it must have been something with my CSS. I'll look into that, thanks. --Ludwigs2 19:08, 29 October 2010 (UTC)

---

Ah, reopening this briefly, because I discovered the cause of the problem. I work on a Mac using Safari, and what happened is that (because of a flurry of messages) my user talk page crept into Top Sites. After that, every time Top Sites would rebuild its page cache it would check my user talk page, which would cause the wikipedia software to cancel the message notification. Since Top Sites and other RSS like things are becoming more prevalent, would it be worth looking into software modification so that the message banner is only removed when user actually visit the page in an appropriate browser? I assume that could be done just by checking the request headers.

I've resolved the problem on my end simply by banning my user talk from Top Sites, so this is more of a general question. --Ludwigs2 15:04, 30 October 2010 (UTC)

Category Verification

If I add a category, say [[Category:University of Warwick alumni]], to an article then I have no in-preview way to know if that is an existing category until I save. I have to search in a separate web browser, or save and see if it's red. Can the categories be included in the previews? — Fly by Night (talk) 21:40, 29 October 2010 (UTC)

Seems to work for me, look at the very bottom of the preview page (past the edit form, the disclaimers, and so on). Anomie⚔ 01:56, 30 October 2010 (UTC)

Yes, I see that too. What would be nice, though, in case there are any developers watching, would be if the software automatically notified you at the "Save" stage if you'd added a red link or category, and gave you the chance to correct it before the edit goes live (an even nicer touch would be if it notified you that you'd added a link that goes to a disambiguation page, and offered you a drop-down list of dsisambiguated titles to choose from, which it would then substitute in the wikitext automatically - ah, but we can dream.)--Kotniski (talk) 13:03, 30 October 2010 (UTC)

Ah, I can see! It's right at the very bottom isn't it? Wouldn't it be better to include it in the main preview section of the page? — Fly by Night (talk) 16:46, 30 October 2010 (UTC)

Spoiler-related proposal

A proposal to make the link to the general disclaimer more prominent in the standard Vector skin by putting it into the sidebar.

From the original proposal:

Wikipedia does not tag spoilers in articles, and instead the content disclaimer for the site warns that Wikipedia may contain spoilers for works of fiction. In the default skin the link to the disclaimers is not very prominent. Should its prominence be increased, and if so in what way and by how much?

There is presently general agreement to alter the sidebar so that the general disclaimer should have more visibility. As this is a site-wide change it's best to have wide discussion.

Some technical comments on implementation would be particularly appreciated, particularly by those familiar with Mediawiki:Sidebar.

Please join the discussion at Wikipedia talk:Spoiler#RFC:_Change_prominence_of_site_disclaimer_link_in_default_skin. --TS 19:39, 29 October 2010 (UTC)

Page tabs

In the File: namespace (using the current new Vector theme), we used to have tabs like (in the respective colours):

1. For a file that exists: File, Discussion, Read, Edit, View history
2. For a file that doesn't exist: File, Discussion, Create

   These tabs were then changed to:

3. For a file that exists: File, Talk, Read, Edit, History
4. For a file that doesn't exist: File, Talk, Edit

For an editor who frequently works within the File: namespace, the new colouring could be quite misleading and wastes valuable time. In sample 4, I propose:

• The recolouring of the current black "File" tab back to red. Alright, now it seems to be red...
• Renaming the blue "Edit" tab to "Create" as it was before. If this needs too much work across multiple namespaces, then at least recolour it to red.

-- Rehman⁽⁺⁾ 02:32, 30 October 2010 (UTC)

The "File" tab appears in red for me for non-existent files on the Vector theme. — This, that, and the other (talk) 10:18, 30 October 2010 (UTC)

Alright thats weird, it was black just a few hours ago... ;) Changed the above proposal. Rehman⁽⁺⁾ 10:33, 30 October 2010 (UTC)

It seems that the change you suggest may be non-trivial from our end. I suggest filing a bug at Bugzilla. — This, that, and the other (talk) 09:05, 31 October 2010 (UTC)

 Done, created bugzilla:25722. Rehman⁽⁺⁾ 09:19, 31 October 2010 (UTC)

Testing skin

Is there a way to create a skin test that looks like mw:Help:Extension:ParserFunctions? What I am asking is whether it is possible to create a #switchskin: ParserFunction like so:

{{#switchskin:
  |monobook=text displayed if Monobook is used
  |vector=text displayed if Vector is used
  |#default=text displayed if any other skin is used
}}

This would be useful to display different versions of CSS in different skins, as skins vary greatly in CSS implementation. It could also be used to display a different message to different skin users. —MC10 (T•C•GB•L) 05:17, 30 October 2010 (UTC)

Proposed features of Wikipedia's software can be submitted over at Bugzilla. — Blue-Haired Lawyer ^t 14:25, 30 October 2010 (UTC)

Created bugzilla:25729. —MC10 (T•C•GB•L) 19:18, 31 October 2010 (UTC)

List of most widely used templates

Resolved

Hi tech guys. :-) To begin one of the most important jobs on the to-do list of the Wikipedia:WikiProject Accessibility, I need to have a list of the most widely used templates. The top 200 will do, as a starter. But on the long run, I bet we will have to review the top 1.000. Does anyone knows how to get such a list? Or is a bot owner willing to make this list? Kind regards, Dodoïste (talk) 12:51, 30 October 2010 (UTC)

Like this? mgiganteus1 (talk) 12:59, 30 October 2010 (UTC)

Heh, 8 minutes and I get an answer already. Tech guys sure are quick, thanks. :-)

This is exactly what I was looking for. ^_^ And it's updated regularly by a bot. How handy. :-) Dodoïste (talk) 13:12, 30 October 2010 (UTC)

"Hidden" blocks

Shouldn't notice of all blocks be on the user's contributions page? As an example, http://en.wikipedia.org/w/api.php?action=query&list=allusers&aufrom=Troll&auprop=blockinfo says that User:Troll is blocked and gives a block reason, but the user's contributions page does not say this. Is this because an oversighter attempted to delete the block reason? PleaseStand ^(talk) 15:46, 30 October 2010 (UTC)

Their block-log says they've never received any... strange. ╟─TreasuryTag►duumvirate─╢ 15:49, 30 October 2010 (UTC)

Oh, no: the link you provided shows which users with a name starting Troll have ever been blocked: they're all Troll78 and Troll like the wind and things, but not actually Troll (talk · contribs) itself. ╟─TreasuryTag►You may go away now.─╢ 15:50, 30 October 2010 (UTC)

Troll was blocked in July 2004. See[2]. It's a very old block and there was a bug around for ages which meant some blocks didn't show up in block logs. I'd put it down to that. It can also happen when a user is suppressed or globally locked, but that doesn't seem to be the case here. -- zzuuzz ^(talk) 16:09, 30 October 2010 (UTC)

It's likely that Special:Contributions only follows Special:Log/block. As you can see from Special:Log/block, it only goes back to December 2004. However, Special:BlockList goes as far as February 2004. I think that the users are blocked based on Special:BlockList (or Meta's block and lock logs). HeyMid (contributions) 16:50, 2 November 2010 (UTC)

(EC: I didn't notice the reply above, oops!) The block log for Troll (talk · contribs) does not appear in the user's contribs page because he/she was blocked before our current log system was introduced. That user was blocked in July 2004; see Wikipedia:Block log/Archive2 and search for the term "Troll" with the quotes. Graham87 16:14, 30 October 2010 (UTC)

Here's the very first page of logs that use our current logging system, from December 2004. Graham87 16:19, 30 October 2010 (UTC)

Of course you are also right Graham. If in any doubt, any existing blocks can always be found in Special:BlockList. There are still some blocks from 2005-2007-ish which still aren't recorded in the block log. -- zzuuzz ^(talk) 16:34, 30 October 2010 (UTC)

What explains Troll Account Troll Account (talk · contribs · count · logs · page moves · block log) though? That one is considerably newer. PleaseStand (talk) 20:28, 30 October 2010 (UTC)

That's a global lock. You'll find the log on meta[3]. Admins can see the block reason if they attempt to change the block: "crosswiki abuse, globally locked & hidden<!--[[m:User:StewardBot|bot]]-->" -- zzuuzz ^(talk) 20:41, 30 October 2010 (UTC)

automatically setting a parameter

How do I extract the first word from {{PAGENAME}} and place it into the variable (or parameter, I'm not sure what the right name is) {{{year}}}? __meco (talk) 17:00, 30 October 2010 (UTC)

Mediawiki does not have the concept of 'variables' that one can assign values to; they are all read-only. Parameters are variables that are set when a template is called; they pass information, but you cannot store information in them. — Edokter • Talk • 17:28, 30 October 2010 (UTC)

Are you saying that the title of a page cannot be parsed to a template other than wholesale? __meco (talk) 17:38, 30 October 2010 (UTC)

Correct. Though there is a hack in the form of {{First word}}. Usage of this template is however an expensive operation, and developers have stated that the observed behavior is a hack that might break at any point in time and should not be relied upon. And that goes for all templates in Category:String manipulation templates—TheDJ (talk • contribs) 17:47, 30 October 2010 (UTC)

I saw a link to a page about expensive template calls, but I don't remember what it was. Do you know what it is? __meco (talk) 18:24, 30 October 2010 (UTC)

Maybe Wikipedia:Don't worry about performance or Wikipedia:Template limits? PrimeHunter (talk) 00:39, 31 October 2010 (UTC)

I'm not ure that was it, but those links are certainly relevant to the topic. __meco (talk) 17:48, 1 November 2010 (UTC)

Bar graphs

Is there any way to create a bar graph using wiki syntax? Specifically I am trying to create flow charts for the Missouri River article. Currently I am using timelines but this leaves me to choose between either cfs or cumecs, but I need both. Any suggestions? Shannon^talk _contribs 17:51, 30 October 2010 (UTC)

No there is not other way than using <timeline> tag or creating an image, which is what I'd do. Svick (talk) 18:19, 30 October 2010 (UTC)

Slow

I want edit a my text. http://en.wikipedia.org/w/index.php?title=Talk:Romanos_IV_Diogenes&action=edit&section=3. I change some information. I click save page. New page is open but not save. similiar page to this page http://en.wikipedia.org/w/index.php?title=Talk:Romanos_IV_Diogenes&action=edit&section=3 is open. Again I save page. But this page is very slow open. changes is save. Please save more fast changes. More fast —Preceding unsigned comment added by 78.185.137.98 (talk) 21:45, 30 October 2010 (UTC)

Nested templates and nested tables

I am currently working on a template ({{User:Matthew25187/Infobox tram network}}) that produces a standard table. In addition to several general sections, this template also supports up to 4 sections which will all look the same, for which I decided to create a helper template ({{User:Matthew25187/Infobox tram network/Tram network era}}). The helper template should generate the script for a collapsible child table which is embedded within a cell in the main table. By itself, the helper template appears to work fine.

The problem is that the helper template is not being evaluated when called from the main template. It appears that the parameters passed to the helper template from the main template are being interpreted as part of the table and the remainder of the call to the helper template is being embedded in the output of the main template as plain text (see Example section at User:Matthew25187/Infobox tram network/doc#Example). I'm guessing this has something to do with a misinterpretation of pipe symbols as table cell delimiters instead of template parameter delimiters but can't see precisely where it is going wrong. This occurs on both IE8 and Safari 5. Any ideas? --Matthew25187 (talk) 04:52, 31 October 2010 (UTC)

Change the pipe templates "{{!}}" to pipe characters "|" for the calls to the helper template in User:Matthew25187/Infobox tram network. The pipe template is only needed where something should not be parsed as a template parameter separator (usually where a table is nested within a template argument). But in this case, you do want the helper template to be called with each of the parameters listed, so the plain pipe is needed to separate them. — Richardguk (talk) 05:46, 31 October 2010 (UTC)

An infobox is a data table. And for accessibility, it is very important to not produce nested data tables. See Wikipedia:Manual of Style (accessibility) and it's dedicated subpage Data tables tutorial#Avoiding nested data tables.

Plus, the rows of the table are unsemantic: there is no row header to be associated to the corresponding data cells. See the recent correction of Template:Infobox/row. Infobox made with {{infobox}} are now completely accessible; I wish all Infoboxes could be standardized using {{infobox}}.

I am at your disposal to help you make this infobox accessible. Kind regards, Dodoïste (talk) 11:52, 31 October 2010 (UTC)

New toy to play with – {{Random-color}}

This is the closest thing to a true random color generator that can currently be created on the MediaWiki platform. The source code is below:

<includeonly>#</includeonly>{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>NUMBEROFEDITS:R}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}
{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>NUMBEROFFILES:R}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}
{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}
{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>NUMBEROFARTICLES:R}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}
{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>NUMBEROFUSERS:R}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}
{{<includeonly>subst:</includeonly>#switch: {{<includeonly>subst:</includeonly>#expr:{{<includeonly>subst:</includeonly>NUMBEROFPAGES:R}} mod 16}} |0=0|1=1|2=2|3=3|4=4|5=5|6=6|7=7|8=8|9=9|10=A|11=B|12=C|13=D|14=E|default=F}}

Correct usage would be like this:

<span style="border:1px solid {{Random-color}};background:#dde;">pretty colors</span>

The following box should have a different border color each time you refresh the page.

pretty colors

Feedback is welcomed. Cheers, Access Denied 05:20, 31 October 2010 (UTC)

Doesn't seem to work. I tried refreshing several times, even clearing the cache, and it always came up in gunmetal gray. --Trovatore (talk) 09:19, 31 October 2010 (UTC)

Not working here either, but not suprisingly, as those variables are only updated when the page or template is re-cached. See if you can play with {{rand}} instead. — Edokter • Talk • 12:13, 31 October 2010 (UTC)

What connection does generating random colours have to the building of an encyclopedia? Phil Bridger (talk) 00:25, 1 November 2010 (UTC)

Indeed, this toy would seem at best a waste of time, at worst a MOS violation and undue page complexity. OrangeDog (τ • ε) 16:53, 1 November 2010 (UTC)

Userpage beautification!!! Killiondude (talk) 02:00, 2 November 2010 (UTC)

Edit on arrival

I propose a simple new option in Preferences where upon selection, clicking on any page would drop the user straight to the editpage mode, instead of loading the page normally. Rehman⁽⁺⁾ 07:44, 31 October 2010 (UTC)

This feature might be better suited for a userscript gadget. Not many people would use it, and too many options in the preferences will work confusing for users. —TheDJ (talk • contribs) 14:22, 31 October 2010 (UTC)

Enable Navigation popups. Hover over a link, then select actions → edit. You can even right click and select open in new tab. ---— Gadget850 (Ed) ^talk 14:43, 31 October 2010 (UTC)

Four tilde

1- http://en.wikipedia.org/w/index.php?title=Talk:Romanos_IV_Diogenes&action=edit&section=new

There are remember to sign your posts by typing four tildes(~.~~.~) text in this page and similiar talk pages. Plase not write the sign your post expression. Because; the sign can be understood wrong. People think Am I append the signature?. Please not write the sign your post expression

2- http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit&section=new

http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit&section=29

There are – — ‘’ “” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ √ ← → · § Sign your posts on talk pages: ~(4 tilde)~.~~ Cite your sources:

in bottom of page

Plase not write Sign your posts. You must not use the this expression in any page. Plase completely remove the this expression from Wikipedia. Please write the Add 4 tilde (~.~~.~) (Within point) to the end of your post. and also would be more descriptive. Because; people can not know the what do 4 tilde.

Plase put the this warning to top of page within sign your posts

Please you must create all my suggestions in other languages Wikipedias —Preceding unsigned comment added by 78.185.201.64 (talk • contribs) 08:06, 31 October 2010 (UTC)

We can't change what other language Wikipedias do. We're also unlikely (or able) to completely remove a phrase from Wikipedia. Given that you didn't sign that post, I'm going to assume that you haven't understood something. Typing ~~~~ will sign your post. It's the easiest but not the only way. In summary then - please sign your posts. OrangeDog (τ • ε) 16:49, 1 November 2010 (UTC)

A few questions

1. Regarding time zones (CEST and CET), is it possible to make it so that the time still matches, although it switches from CET to CEST? (Halloween today, so we've turned our clocks back 1 hour.)

2. Is there any tool available to see how many times like a particular template has been transcluded? Also possible to see how many times a template has been substituted?

/HeyMid (contributions) 09:32, 31 October 2010 (UTC)

Regarding 2, transclusions can be counted using Special:Whatlinkshere and unchecking links and redirects. Don't think substitution-counting is possible. sonia♫ 10:06, 31 October 2010 (UTC)

Oh yeah, what am I talking about? Obviously I meant substituted templates, as the transcluded ones are listed there. However, what if some transclusions are removed? Can they still be found? HeyMid (contributions) 10:16, 31 October 2010 (UTC)

Also, is it possible to make an editnotice for an editnotice for your user page? If so, how do I do so? HeyMid (contributions) 10:28, 31 October 2010 (UTC)

...yes, but I highly don't recommend it. What's the point? sonia♫ 10:36, 31 October 2010 (UTC)

Nothing, really. HeyMid (contributions) 10:39, 31 October 2010 (UTC)

I don't understand what you mean by "time still matches". Do you mean server time? It is always on UTC, which does not take summer time. (Additionally, I'm fairly sure you mean "switches from CEST to CET"). Regarding your second question, some substituted templates (for example, {{subst:AfD}}) have tracking categories or use things like {{Void}} to track usage, but in general I am not aware of any way to track substituted templates. Perhaps an off-wiki tool exists, such as on the toolserver? Intelligentsium 00:21, 2 November 2010 (UTC)

Perhaps an off-wiki tool exists, such as on the toolserver? That's what I thought. HeyMid (contributions) 19:46, 2 November 2010 (UTC)

There is no reliable way to count substituted templates. (Does it still count if somebody changes the substituted text a little? What if the template changes?) But many templates that should be substituted add hidden code (like <!-- Template:Some template -->) to the pages, which could be counted from the database dump. Also, some templates which should be transcluded add Category:Pages with incorrectly substituted templates when they are substituted. Svick (talk) 21:04, 2 November 2010 (UTC)

HotCat updated

I have updated our gadget HotCat to a new version as used on Commons. Some new features.

• Possible to make multiple category changes
• More translations
• Support for sortkeys
• Quick child or parent categorization

Please read the documentation for information on the new options. —TheDJ (talk • contribs) 14:34, 31 October 2010 (UTC)

If you experience any problems with the new version of the gadget, please leave a message at Wikipedia talk:HotCat‎. Lupo 22:34, 31 October 2010 (UTC)

E-mail suggestion

info-en-q@wikimedia.org

info-en-q@wikimedia.org e-mail adress is available in some pages. For example: http://en.wikipedia.org/wiki/Wikipedia:Contact_us/Article_problem/Factual_error_(from_subject)

Please add the Please write English text to pages which be have to info-en-q@wikimedia.org e-mail adress. Please open parenthesis and write Plase write English text into of paranthesis

Please add this suggestion to all languages —Preceding unsigned comment added by 88.235.238.98 (talk) 19:15, 1 November 2010 (UTC)

Given that this is the English Wikipedia, the page in question is written in English, and "en" is in the email address, I don't see how someone could not conclude that English should be used. --Cybercobra (talk) 21:43, 1 November 2010 (UTC)

Login with Firefox

I can't login with the new Firefox(version 3.6.12). I get the message "Login error There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please hit "back" and reload the page you came from, then try again." Seem okay in other browsers. Any ideas? Regards, SunCreator ^(talk) 23:34, 1 November 2010 (UTC)

Been running the same version for a while with no problems so it doesn't seem to be that. Rambo's Revenge (talk) 23:53, 1 November 2010 (UTC)

I've had that issue once or twice. It's so infrequent I figured it's a weird server glitch. DC T•C 00:51, 2 November 2010 (UTC)

Thank you. It's working now. It seems the process is somewhat of a cookie overload and I may of blocked some of them. Regards, SunCreator ^(talk) 01:20, 2 November 2010 (UTC)

New special page?

I just discovered that Wikitravel has a special page that we don't: Special:Mytalkpage, which is analogous to Special:Mypage both there and here. Two questions — (1) Besides leaving a note at Bugzilla, is there anything we could do to ask for its implementation? (2) If so, what? Nyttend (talk) 23:57, 1 November 2010 (UTC)

Special:Mytalk works fine both here and on Wikitravel. Svick (talk) 00:04, 2 November 2010 (UTC)

I've never before seen that link; thanks. Nyttend (talk) 00:08, 2 November 2010 (UTC)

Me too. Rehman⁽⁺⁾ 00:38, 2 November 2010 (UTC)

'Database server lag' message - should it be in minutes?

I've just got this message looking at my watchlist: 'Due to high database server lag, changes newer than 2,070 seconds may not appear in this list.. I think the lag itself is just a glitch. I'm more concerned with the message though: now I can figure out that 2,070 / 60 = 34.5 minutes, but it seems a bit unnecessary to have to do the maths. Presumably the message only appears if the expected lag exceeds a given amount, so unless this is set very low (<60s?) wouldn't it be better expressed in minutes in the first place? Just a thought... AndyTheGrump (talk) 02:27, 2 November 2010 (UTC)

I would assume that anyone who knows what database lag is also knows how to divide by 60. Besides, if it's in minutes then it'll never go over 9000. OrangeDog (τ • ε) 14:34, 2 November 2010 (UTC)

Strange glitch has been bothering me lately.

The standard toolbar (The one that goes Bold, Italic to <ref /ref>, {{ Cite }}) occasionally loses all the buttons to the right of Horizontal line, and I need to refresh the edit page to get them back.--occono (talk) 03:26, 2 November 2010 (UTC)

Firesheep security issues

This new publicised Firesheep brings up some security issues. The possibility of others taking over your Wikipedia session when your logged into a public Wifi(with no security set) is now very real. I suggest that the E-mail options of Special:Preferences requires a password to confirm the change otherwise your password can be changed by changing your email address and requesting a new password, thus taken over your account completely. Regards, SunCreator ^(talk) 12:59, 2 November 2010 (UTC)

If this sheep is for real, then ultra strong support for this proposal. I am currently using my home wifi; wondering if anyone could do the dew right now... Rehman⁽⁺⁾ 13:30, 2 November 2010 (UTC)

You can also use the HTTPS server. Then no one can highjack your session regardless of how you connect. Just make sure you get the secure-only cookie then viewing images will not send your session cookie. HumphreyW (talk) 13:47, 2 November 2010 (UTC)

Using only a secure HTTPS connection is a good idea, see https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page. I did not realise that https was currently supported by Wikipedia. Regards, SunCreator ^(talk) 14:21, 2 November 2010 (UTC)

Yet the secure server is mentioned every single time you visit the login page. —TheDJ (talk • contribs) 00:04, 3 November 2010 (UTC)

Rehman, if you are using home wifi you can turn WPA encryption on besides it's less likely other people will be accessing your wifi point. The case I was highlighting above is for people accessing Wikipedia with wifi in a public place like in public cafes, for example Starbucks. Regards, SunCreator ^(talk) 14:26, 2 November 2010 (UTC)

I've got WPA on. Thanks for the info, I thought you meant all wifis... ;) Kind regards. Rehman⁽⁺⁾ 14:29, 2 November 2010 (UTC)

Okay, my lack of clarity, it's not all wifis, only on unsecured ones. Editing to clarify that. Regards, SunCreator ^(talk) 14:36, 2 November 2010 (UTC)

For those who haven't seen it, Firesheep was also discussed on Wikitech-l last week, as summarized in the Signpost. Regards, HaeB (talk) 15:05, 2 November 2010 (UTC)

You should always use the secure server when editing from a network that is not under your control like a public wifi network, especially if you're an admin or other privileged account. Possibly even just for reading, since the articles you read may suggest private information. From a secure home network you're relatively safe, but routers can still eavesdrop on your traffic en route, so you might use it all the time just to be safe. Dcoetzee 01:08, 3 November 2010 (UTC)

Image scalers

What happened with the connection to the image scalers at about 13:50 UTC?[4] At the same time, the load on the upload squids went up, too.[5]. Currently, no thumbnails are served for me. Lupo 14:17, 2 November 2010 (UTC)

If i understand correctly, the NFS connection between the scalar and the fileservers went down, causing congestions due to requests that take long to time out. —TheDJ (talk • contribs) 23:59, 2 November 2010 (UTC)

XCF files

We have a few .xcf files on English Wikipedia[6] XCF is probably quite useful on Wikimedia Commons, but I don't see why we allow them to be uploaded here because the mediawiki software doesn't have a renderer for XCF. I think the free files should be moved to Commons, and non-free files like This file may be deleted at any time. replaced with a svg. John Vandenberg ^(chat) 22:09, 2 November 2010 (UTC)

Now we are gonna make a in what file formats are allowed to be uploaded to what wikimedia project ? Why further complicate it for people ? I don't see the point in this. It's a file. Transfer it if you want but I see no reason whatsoever to disallow uploading a free and valid fileformat solely on the English Wikipedia. —TheDJ (talk • contribs) 23:54, 2 November 2010 (UTC)