Wikipedia:Village pump (technical)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
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.
Frequently asked questions (see also: Wikipedia:Technical FAQ) Click "[show]" next to each point to see more details.
|
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:/upwiki/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)
- 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)
- 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)
- 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)
- 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)
- 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 don't think such a solution is feasible or practical for most of these links. Protonk (talk) 22:51, 30 September 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)
- Okay, where? (don't say RfC) Rambo's Revenge (talk) 23:53, 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)
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)
- 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)
- (@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)
- 4000 is not much. If you do the analogous search for PDF you get 70,000. Hans Adler 14:15, 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
- 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)
- Support. While not a perfect solution, it is much better than the status quo, unlike it has been claimed above. This solution catches most of the cases, which is enough. Titoxd(?!? - cool stuff) 02:23, 5 November 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)
- 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)
- 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)
- 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".
- 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)
- You err there. Wikipedia should not use file extensions:
- 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)
- More than you'd like to think. Author of User:PDFbot and WP:Checklinks — Dispenser 16:40, 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 |
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)
- 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)
- 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)
- This proposal also won't work, as explained above. (wikt:status quo). OrangeDog (τ • ε) 21:49, 23 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)
- But won't work because some links don't even use a citation template. Rambo's Revenge (talk) 15:50, 20 October 2010 (UTC)
- A bot to fill in the format parameter is a much better solution. OrangeDog (τ • ε) 15:43, 20 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)
- 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)
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)
- I understand what you are saying but surely that argument goes two ways. Won't older computers also want to identify and not open document links etc. as they are large and can crash browsers etc. Rambo's Revenge (talk) 23:28, 4 November 2010 (UTC)
- If people are concerned they can look at the extension. Unless the extension doesn't match of course. OrangeDog (τ • ε) 09:37, 5 November 2010 (UTC)
- The extension is not always visible. In fact unless there is a status bar in Firefox you wouldn't be able to see it at all (unless you opened/saved/bookmarked it and then examined that). Not very likely for users. The point is an icon makes a visual impact of beware you might not want/be able to open this. The casual user isn't examining every url/extension they click on. Rambo's Revenge (talk) 22:51, 5 November 2010 (UTC)
- If people are concerned they can look at the extension. Unless the extension doesn't match of course. OrangeDog (τ • ε) 09:37, 5 November 2010 (UTC)
- I understand what you are saying but surely that argument goes two ways. Won't older computers also want to identify and not open document links etc. as they are large and can crash browsers etc. Rambo's Revenge (talk) 23:28, 4 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)
"Hidden" blocks
Shouldn't notice of all blocks be on the user's contributions page? As an example, http://en.wikipedia.org/enwiki/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)
- 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)
- (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)
- Here's the very first page of logs that use our current logging system, from December 2004. Graham87 16:19, 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)
- Maybe Wikipedia:Don't worry about performance or Wikipedia:Template limits? PrimeHunter (talk) 00:39, 31 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)
- 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)
- 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)
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)
- What connection does generating random colours have to the building of an encyclopedia? Phil Bridger (talk) 00:25, 1 November 2010 (UTC)
Four tilde
1- http://en.wikipedia.org/enwiki/w/index.php?title=Talk:Romanos_IV_Diogenes&action=edit§ion=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
There are – — ‘’ “” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ √ ← → · § Sign your posts on talk pages: ~(4 tilde)~.~~ Cite your sources: Cite error: There are <ref>
tags on this page without content in them (see the help page).
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)
- 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
- Perhaps an off-wiki tool exists, such as on the toolserver? That's what I thought. HeyMid (contributions) 19:46, 2 November 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)
- Nothing, really. HeyMid (contributions) 10:39, 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)
- 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)
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)
- I've never before seen that link; thanks. Nyttend (talk) 00:08, 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)
- Perhaps it's a browser-related issue? Do you have a recent version?—RJH (talk) 19:20, 3 November 2010 (UTC)
- It has affected me across mulitple computers and browsers. I thought getting rid of some gadgets and moving to the new skin might have fixed it, but it's been happening again.
- It's still happening. --occono (talk) 03:00, 5 November 2010 (UTC)
- It has affected me across mulitple computers and browsers. I thought getting rid of some gadgets and moving to the new skin might have fixed it, but it's been happening again.
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)
- Yes, somehow I had come to the mistaken belief that login with the secure server was only making your login secure and now I realise it keeps your session secure. So folks, always use the secure server. Regards, SunCreator (talk) 22:57, 3 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)
- 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)
- 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)
- I've got WPA on. Thanks for the info, I thought you meant all wifis... ;) Kind regards. Rehman(+) 14:29, 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. A little-known fact is that other language versions of Wikipedia are also available via the secure server (e.g. https://secure.wikimedia.org/wikipedia/fr/wiki/). Dcoetzee 01:08, 3 November 2010 (UTC)
except for... using interwikis kicks you back out... Choyoołʼįįhí:Seb az86556 > haneʼ 01:20, 3 November 2010 (UTC)scratch that... nobody ever bothered to install the secure.js @ nv... done now, works. If somebody reads this from a smaller wiki and it doesn't work, you need to copy Mediawiki:Common.js/secure.js and the "import"-line. Choyoołʼįįhí:Seb az86556 > haneʼ 01:38, 3 November 2010 (UTC)
- Why does the web site info box in Firefox say "Your connection is only partially encrypted and does not prevent eavesdropping" for secure.wikimedia.org? That doesn't sound very secure to me. --Morn (talk) 12:11, 3 November 2010 (UTC)
- Because our images are not available over the secure connection. —TheDJ (talk • contribs) 13:29, 3 November 2010 (UTC)
- Then the suggestion to use secure for reading WP is a little useless. If I can see the images your browser is loading, in many cases I can easily guess which page you are visiting. Many of our articles have images that are linked only once or twice from the English WP. Also, if Firefox reports the connection to be insecure, this might deter people from using secure, just as it should. Any hope that this issue will be fixed or is this due to images being stored on Commons? --Morn (talk) 14:13, 3 November 2010 (UTC)
- Your cookies are not sent to the image upload server, making you well protected from session hijacking. It's just that the browser cannot know that (older browsers actually didn't even consider non-secure images a problem). If you pour a lot of money in the sys admin team of the foundation, so that they have a lot of time to spare, then this will be fixed. —TheDJ (talk • contribs) 14:27, 3 November 2010 (UTC)
- Then maybe there should be a clearer description of secure that points out that while it does protect against session hijacking, it does not currently offer truly private browsing. I see there is an explanation at Wikipedia:Secure_server, but it seems a bit too technical and disorganized. Perhaps that page needs Template:Nutshell at the top? --Morn (talk) 15:02, 3 November 2010 (UTC)
- Your cookies are not sent to the image upload server, making you well protected from session hijacking. It's just that the browser cannot know that (older browsers actually didn't even consider non-secure images a problem). If you pour a lot of money in the sys admin team of the foundation, so that they have a lot of time to spare, then this will be fixed. —TheDJ (talk • contribs) 14:27, 3 November 2010 (UTC)
- Then the suggestion to use secure for reading WP is a little useless. If I can see the images your browser is loading, in many cases I can easily guess which page you are visiting. Many of our articles have images that are linked only once or twice from the English WP. Also, if Firefox reports the connection to be insecure, this might deter people from using secure, just as it should. Any hope that this issue will be fixed or is this due to images being stored on Commons? --Morn (talk) 14:13, 3 November 2010 (UTC)
- Because our images are not available over the secure connection. —TheDJ (talk • contribs) 13:29, 3 November 2010 (UTC)
- Why does the web site info box in Firefox say "Your connection is only partially encrypted and does not prevent eavesdropping" for secure.wikimedia.org? That doesn't sound very secure to me. --Morn (talk) 12:11, 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)
- And then apparently some failing processes on the upload servers logged their failures, and filled the disks with the logs.[6] sq51 still has a full disk.[7] Lupo 11:35, 3 November 2010 (UTC)
- I'm not sure if you're referring to my problem, but I uploaded new versions of File:Mitsubishi Celeste.JPG and File:DodgeArrowGS-rear.jpg and they're not showing up in any format besides the original. No thumbnails, no resizes. Should I just sit back and wait or should I upload them again? ⊂| Mr.choppers |⊃ (talk) 17:29, 4 November 2010 (UTC)
- For two days unable to alter image size, increase or decrease, in infoboxes. Been advised to wait for how long????REVUpminster (talk) 19:42, 4 November 2010 (UTC)
- It seems they are working on it at Commons. --Saddhiyama (talk) 21:43, 4 November 2010 (UTC)
- Now working at "275px and 300px but not 250pxREVUpminster (talk) 12:42, 5 November 2010 (UTC)
XCF files
We have a few .xcf files on English Wikipedia[8] 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 File:Old Weather logo.xcf 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)
- Maybe because it's not rendering? Just a thought. This is an encyclopedia, and keeping files that aren't renderable doesn't seem to be a part of its scope. Commons is more of a more "if it's freely licensed and a file, we'll take it" nature. Killiondude (talk) 05:20, 3 November 2010 (UTC)
- Exactly. We even have a CSD for it - Files that the MediaWiki software is unable to read or generate resized thumbnails of. OrangeDog (τ • ε) 11:06, 3 November 2010 (UTC)
- I see no reason why we cannot host free formats that can be useful. The only reason to upload an xcf, is to upload something in the original format, so that others can recreate images based on your actions. such seems perfectly reasonable, and it not at all like what CSD F2 should be tackling. In that case, we have some high res PNGs that we could be deleting. —TheDJ (talk • contribs) 13:32, 3 November 2010 (UTC)
- It is in scope, if it concerns for instance a restoration of an image that is PD in the US, but not in the country of origin (not allowed on Commons). The file is perfectly renderable, what you guys mean is that it cannot be used inline in articles, because the software can't make automatic thumbs of it. But nothing stops you from downloading, creating a new rendering and uploading a new PNG based on the original files. The point of these kinds of files is often exactly this. XfD .xcf files that you think no longer serve a purpose, move to Commons files that are allowed on Commons. —TheDJ (talk • contribs) 13:47, 3 November 2010 (UTC)
- It's not renderable by MediaWiki, which is why it is out of scope. For the same reason uploaded .doc or .txt files are removed, even if they are free and relevant. OrangeDog (τ • ε) 16:42, 4 November 2010 (UTC)
- You advocate forcing future photo-restoring editors to start from scratch when we could easily provide them an easily-editable format from which to make improvements? Bad idea, IMO. Doc and txt files are a different matter, because they're text which can be better stored as wikitext for our purposes. Anomie⚔ 17:40, 4 November 2010 (UTC)
- No, I advocate moving them to Commons, as does the OP. OrangeDog (τ • ε) 19:04, 4 November 2010 (UTC)
- You mean the Commons that chooses to abide by national copyright rules unlike English Wikipedia, which often happily ignores copyright on works outside the US if it is pre 1923 ? Not everything fits on Commons. —TheDJ (talk • contribs) 21:41, 4 November 2010 (UTC)
- Nor here. OrangeDog (τ • ε) 09:39, 5 November 2010 (UTC)
- You mean the Commons that chooses to abide by national copyright rules unlike English Wikipedia, which often happily ignores copyright on works outside the US if it is pre 1923 ? Not everything fits on Commons. —TheDJ (talk • contribs) 21:41, 4 November 2010 (UTC)
- No, I advocate moving them to Commons, as does the OP. OrangeDog (τ • ε) 19:04, 4 November 2010 (UTC)
- You advocate forcing future photo-restoring editors to start from scratch when we could easily provide them an easily-editable format from which to make improvements? Bad idea, IMO. Doc and txt files are a different matter, because they're text which can be better stored as wikitext for our purposes. Anomie⚔ 17:40, 4 November 2010 (UTC)
- It's not renderable by MediaWiki, which is why it is out of scope. For the same reason uploaded .doc or .txt files are removed, even if they are free and relevant. OrangeDog (τ • ε) 16:42, 4 November 2010 (UTC)
- Exactly. We even have a CSD for it - Files that the MediaWiki software is unable to read or generate resized thumbnails of. OrangeDog (τ • ε) 11:06, 3 November 2010 (UTC)
- Maybe because it's not rendering? Just a thought. This is an encyclopedia, and keeping files that aren't renderable doesn't seem to be a part of its scope. Commons is more of a more "if it's freely licensed and a file, we'll take it" nature. Killiondude (talk) 05:20, 3 November 2010 (UTC)
This looks like an entirely a theoretical problem - the xcfs listed in that search are mostly on Commons, and the few that are on en could be moved there. If they are acceptable on Commons, they should be moved to Commons of course... However Commons cannot host certain files due to copyright issues, which en.wikipedia can host (those that are PD in US but not country of origin) and its possible that restoration work on such images will involve xcf files. If that happens its probably something to ignore, after all these files do still have an encyclopedic use - even if they can't be included in articles. Note also that if you upload a jpg thumb over the xcf you get a viewable jpg File:Henry Cuyler Bunner.xcf with the xcf in the history - that dodges the clause of F2.--Nilfanion (talk) 12:06, 5 November 2010 (UTC)
- I'd recommend not uploading a jpg over the xcf like that. It's misleading to the reader, it's liable to be moved to the .jpg name by a well-meaning editor who isn't aware of that trick, and it's quite possible the devs may at some point remove the ability to do this just as it is currently not possible to upload a jpeg with a .png extension. Anomie⚔ 16:13, 5 November 2010 (UTC)
Question about qantity of categories in english Wikipedia
I am currently in the process of writing a paper about Wikipedia Categories. Ive done most of my research using Wikipedia API to get approximate numbers and to analyze categories structure. But i also want to know how many categories does Wikipedia has at the moment, and i just cant find this information. I could, of course, just install a previous Wikipeda DB dump and make a query to cout all categories, but that is an overkill. And using API for that would take too much time and strain Wikipedia servers.
So i am asking this question here: How many categories does Wikipedia have and is there a place where this info is posted or could be extracted from? i've beed told on the help desk that this can be done with magic words, but the required functuion seems to be disabled at the moment. Is there another way? --DSUmanskiy (talk) 11:21, 3 November 2010 (UTC)
mysql> select count(*) from page where page_namespace = 14; +----------+ | count(*) | +----------+ | 638834 | +----------+ 1 row in set (16.30 sec)
- That answer your question? ΔT The only constant 11:33, 3 November 2010 (UTC)
- It does! Thank you very much:)--DSUmanskiy (talk) 11:59, 3 November 2010 (UTC)
- Here's another place that's got the info -- Wikipedia:Database reports/Page count by namespace -- WOSlinker (talk) 15:02, 3 November 2010 (UTC)
- That's a rather interesting page since with the old revisions you can graph the growth by namespace. — Dispenser 08:00, 4 November 2010 (UTC)
- Wow! Thats pretty nice! Thank you? --DSUmanskiy (talk) 20:54, 5 November 2010 (UTC)
- Here's another place that's got the info -- Wikipedia:Database reports/Page count by namespace -- WOSlinker (talk) 15:02, 3 November 2010 (UTC)
Pages removing themselves from Watchlist
I added Wikipedia:Village Pump (proposals) to my watchlist and three days later it somehow managed to change to unwatched. I rewatched the page, and it moved back to unwatched 10 hours later. I readded it and it became unwatched two days later. I then readded it and it stayed on my watchlist until today (about 5 days). I just readded it to my watchlist. What is wrong with Watchlist? I haven't removed it myself. It has happened to other, non=article space pages. Thanks, --Alpha Quadrant talk 13:36, 3 November 2010 (UTC)
- Do you use AWB? OrangeDog (τ • ε) 16:38, 4 November 2010 (UTC)
Templated Link & Category splitting & General Background for a Wikia-Project
Hi, I hope that I can ask my Questions here, even if they dont refer to wikipedia itself, but an wikia project. But the tehnics shouldbe the same?
However. I have gut two questions to ask. First of all: Does somebody know what to do, if I want to use a lage background image for the main background (the background that cannot be more in the background, behind the wikia main frame). And this Image shall vary its size, depending on how large the screen setting is set. Also, when scrolling up or down, the background shall stay where it is, meaning don't scroll alongside wth the wikia frame. I do know that it is possible with html. I'm not the Admin in this Wikia Project, but I shall say how it works. Is HTML being used for such Wikia settings?
The other one should work with wikipedia, too... I have got a problem with a template... I wrote this template:
{| class="toccolours" style="float: right; clear: right; margin: 0 0 1em 1em; width: 225px" |- !style="background:#beb998"|{{PAGENAME}} |- | {| style="background: #ffffff; width: 225px; margin: 0 auto;" [...] Blabla (some lot more written here I spared out here now...) [...] |- style="vertical-align: top;horizontal-align=" |'''Typ'''|| {{#if:{{{Typ|}}}|{{{Typ}}} [[Kategorie:{{{Typ}}}]]|[[Image:Warning Yellow.svg{{!}}19px{{!}}Bitte ergänze den Typ des Zauberspruchs.]]<includeonly> [[Kategorie:Unbekannter Zauberspruchtyp]]</includeonly>}} [...] |}|}<noinclude>
Now, If you write any Word behind |Typ= if you use the template, a category and link is generated there later. My Problem is, that i want to generate automatically two, three or even four links and kategories if I write more words behind this |Typ= . It would be possible, that every word is generated for its own as a category and link.
E.g. If I write: |Typ=Door, Chair, I want to have Links Generated for Door and one for Chair, not one Link for [[Door, Chair]], same for the category. One for each, not one for both together... What shall I change? I tried loads of things, but at the end I dind't find out what to do there... As I said, its also possible that each word gets a category and link, even an if or and or or or whatever. I could also use something different than the , ... Hope someone can help =) Greetz Marc 134.93.45.143 (talk) 16:25, 3 November 2010 (UTC)
- Regarding your second question, you could use several parameters, e.g.
Typ1
,Typ2
, …, each of them adding a category of its own, if it is set. Svick (talk) 22:59, 3 November 2010 (UTC)- Thanks, the background cannot be solved, as I found out (cause we don't have server access) and you helped for the second one thx =) —Preceding unsigned comment added by 79.220.53.45 (talk) 19:11, 5 November 2010 (UTC)
Fundraiser notice
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sometimes, this button is come in top of Wikipedia:
Please read: A personal appeal from Wikipedia founder Jimmy Wales
1- Please apply the button in image to other languages Wikipedia and all websites of Wikimedia Foundation (http://www.wikimedia.org/). But; need that be in their own language.
2- Please apply the button in image to all languages of all websites of Wikimedia Foundation. But; need that be in their own language. 88.235.117.4 (talk) 18:41, 3 November 2010 (UTC)
- It's being dealt with at meta & foundation. This is the English wikipedia; it has nothing to do with other language editions. Thank you. Choyoołʼįįhí:Seb az86556 > haneʼ 18:48, 3 November 2010 (UTC)
Adding a photo
Commons has a new photo of Emma Bull but I can't figure how to add it to her article. Can someone do that?--filceolaire (talk) 23:02, 3 November 2010 (UTC)
- Done by User:Keith D, see this diff. – ukexpat (talk) 16:59, 4 November 2010 (UTC)
LaTeX \int
Compare with , [generated from "Compare <math>\int \int_X \int_Y^Z</math> with <math>\int_X \int_Y \int_Z</math>,
"], and note the line breaks before and after the second part. What is happening? --Rumping (talk) 10:49, 4 November 2010 (UTC)
- The second example is rendered using HTML, albeit in a convulted way (in a table??). You could force it to render as PNG like this: \,\!\int_X \int_Y \int_Z: . — Edokter • Talk • 11:40, 4 November 2010 (UTC)
- This bug occurs whenever large operators are used with subscripts but no superscripts. Another example is .—Emil J. 11:46, 4 November 2010 (UTC)
Strange rendering on image gallery on Safari
Something odd is happening with the rendering of text in an image gallery. When the text goes onto a third line the enclosing text is displayed with a wide shadowed right border and only the top of the third line of text is displayed. I don't know if this is a browser dependant issue, I'm using the latest Safari on Mac.--Salix (talk): 15:26, 4 November 2010 (UTC)
- That shadowed area is supposed to be a scrollbar. It looks like Safari (or OS X's graphics toolkit) can't handle rendering such a short scrollbar, it draws the trough but no arrows or scroller. Anomie⚔ 16:24, 4 November 2010 (UTC)
- We are talking {{Gallery}} template here, not the actual stock gallery code. The scrollbar is due to deviating line-height. That screws up Safari. —TheDJ (talk • contribs) 20:16, 4 November 2010 (UTC)
- Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=33557 —TheDJ (talk • contribs) 21:00, 4 November 2010 (UTC)
- I don't think that bug is related. I can reproduce the problem scrollbar in an offline test page that just puts some text in
<div style="width:20ex;height:3em;overflow:hidden;overflow-y:auto">
, no line-height adjustment anywhere. Anomie⚔ 23:03, 4 November 2010 (UTC)
- I don't think that bug is related. I can reproduce the problem scrollbar in an offline test page that just puts some text in
- Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=33557 —TheDJ (talk • contribs) 21:00, 4 November 2010 (UTC)
- We are talking {{Gallery}} template here, not the actual stock gallery code. The scrollbar is due to deviating line-height. That screws up Safari. —TheDJ (talk • contribs) 20:16, 4 November 2010 (UTC)
Creating a link from a radio button
If I wanted to create a link for the:
preferences >> appearance >> skin
where a person clicks a link and their skin changes, how would I go about doing this?
so for example, MonoBook, the radio button coding is:
- <input name="wpskin" type="radio" value="monobook" checked="checked" id="mw-input-skin-monobook" />
I have read over Manual:Parameters to index.php and am not sure how to plug in these values.
Thank you so much! Adamtheclown (talk) 16:13, 4 November 2010 (UTC)
- If you're wanting to give them a link to view a particular page in a different skin (as done by the "preview" links in WP:SKIN#Screenshots), use useskin. If you're wanting to actually change their preference, there is no way. Anomie⚔ 16:29, 4 November 2010 (UTC)
- Is there a way to use this to view a page as a logged out user would see it?
- Lemmiwinks2 (talk) 02:40, 6 November 2010 (UTC)
Warning template not showing icon
The warning triangle isn't showing in Template:Uw-delete3. What's wrong? __meco (talk) 18:52, 4 November 2010 (UTC)
- There appears to be a problem with thumbnails on the image servers. We are seeing similar questions on the Help Desk. I am sure it will be fixed soon. – ukexpat (talk) 19:02, 4 November 2010 (UTC)
Picture not displaying properly
For http://en.wikipedia.org/wiki/David_James_(South_African_actor) the picture is not loading; it's been displaying fine for a week. The permissions for the picture has been approved and the ticket recorded (or however you say it) so it's not a permission issue. When you click on the picture box, the picture page loads but not the thumbnail on that page. Help! I'm very new to Wiki so I'm lost. There were no new edits done between times when it was displaying properly and now. I tried both Explorer and Firefox and neither works. —Preceding unsigned comment added by Bobbyandbeans (talk • contribs) 01:48, 5 November 2010 (UTC)
- I've seen many articles like that lately. Probably some server issue that will be fixed soon ;) Rehman(+) 02:06, 5 November 2010 (UTC)
- God I hope so ... he's going to be looking at it tomorrow and I said it was done and brilliant! It was brilliant before today! *sad face* Thanks for the reassurance, I'll try to be patient.Bobbyandbeans (talk) 02:27, 5 November 2010 (UTC)
Proposed tools launched
I've created a new project page Wikipedia:Proposed tools designed for contributors to propose new ideas for tools to help edit and administrate Wikipedia and recruit interested developers. If you have a tool idea you've been thinking of proposing but aren't sure how to get in touch with developers, or if you're a developer with a complex tool idea but don't have the time to implement it all yourself, or if you just want feedback on your idea, please use the process described there to add it. If you're a developer who would be interested in evaluating and possibly working on proposed tool ideas, please add the page and any subpages of interest to your watchlist. I'm also welcoming feedback on the discussion page regarding the Proposed tools process itself and how it can be improved. Thank you! Dcoetzee 02:41, 5 November 2010 (UTC)
Odd login problem
I've been contacted by Concertphotos (talk · contribs), formerly Festivalphotos (talk · contribs), whose username was changed. He gets "Login error. There is no user by the name "Concertphotos". User names are case sensitive. Check your spelling, or create a new account." when he tries to log in. He has (once) successfully used the account but has since consistently gotten this message. I've offered the usual suggestions about spelling, trying different browsers, clearing caches, etc., and they seem to be sufficiently clued that they've tried the obvious remedies themselves. They can't get into Commons or svwiki either. Does anybody have any ideas? The login sequence is definitely not my area of expertise. I've suggested just creating a new account, but thought I'd see if there's a known issue. Acroterion (talk) 03:55, 5 November 2010 (UTC)
- When I tried to login under the name "Concertphotos", the error i got was "Login error Incorrect password or confirmation code entered. Please try again." And that is expected. Are you completely sure he is entering the correct user name and that he is logging to the English Wikipedia? He can't login to commons or svwiki, because the account doesn't exist there, it is registered only here (see [9]). Svick (talk) 21:21, 5 November 2010 (UTC)
- He's apparently managed to log in. Since he's interested in photography I'll get him to log in to Commons while logged in here for SUL purposes. Acroterion (talk) 22:06, 5 November 2010 (UTC)
How to automate?
There's a fair number of article (perhaps 150 or so) such as Alexis Hornbuckle, with a link to a WBCA All-America list, a scorebook, or MVP award, or some combination. Because the WBCA revamped their site, all the links are dead.
I know the location of the new link. For example the dead link should go to this
Is there a way to make all these changes without doing every one manually? --SPhilbrickT 18:03, 5 November 2010 (UTC)
- If you know what the system is (i.e. rules to translate old links to new ones), you could try using AWB. Svick (talk) 21:55, 5 November 2010 (UTC)
- OK, I'll check that out.--SPhilbrickT 22:49, 5 November 2010 (UTC)
Table background colour depending on entry
Hi @ all. It's me again and I search for a possibility to write a template for a table in such a way, that it automatically chosses the background colour accoring to the entry for the field.
Meaning: The table will only get 3 kinds of thing written for the area of interest: That's * -10% * -5% and * 0%
Depending on what is written in the text, the background coulour of the boxes shall use an according colour. Meaning: all table boxes with -10% written in shall use the colour code #dddddd for its background. All boxes with -5% shall use the colour code #dafbff, all ones with 0% written in it shall use the colour code #dbffda... Is that possible e.g. using an #if command?
Hope someone can help, greetings Marc 79.220.53.45 (talk) 19:20, 5 November 2010 (UTC)
- You can write a template to do that, see [10] for the code and [11] how to use it. Svick (talk) 22:11, 5 November 2010 (UTC)
Why does monobook have a white background all of a sudden?
This is weird, and it's only in article space. Is it a glitch or just something I never noticed before? Access Denied – talk to me 23:14, 5 November 2010 (UTC)
- Which background ? The article namespace content area has always been white. Perhaps you mean the background image behind the content areas ? You might have a broken copy in your browser cache, because it shows up just fine for me. —TheDJ (talk • contribs) 01:16, 6 November 2010 (UTC)
- Oh, it's always been white. Must have either forgot or never noticed. Access Denied – talk to me 01:25, 6 November 2010 (UTC)
overlapping lines
Template:Opinion paints the background around the text to whatever color you choose for the background but
if you set your line height to 1 then
it has the surprising effect of painting right over the dangling parts (gjpqy) of the text on the line above.
i.e. the top part of one line overlaps the bottom part of the line above.
If you put the text into a table and set the background to some color then it doesnt do this.
Do any of you guys see any way of modifying fontcolor so that it doesnt do this
(or some way of setting somekind of line height attribute in my css to prevent lines from overlapping?)