Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎A few questions: Nothing, really
Dodoïste (talk | contribs)
Line 670: Line 670:


: Change the pipe templates "<code><nowiki>{{!}}</nowiki></code>" to pipe characters "<code>|</code>" 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. — [[User:Richardguk|Richardguk]] ([[User talk:Richardguk|talk]]) 05:46, 31 October 2010 (UTC)
: Change the pipe templates "<code><nowiki>{{!}}</nowiki></code>" to pipe characters "<code>|</code>" 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. — [[User:Richardguk|Richardguk]] ([[User talk: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 [[Wikipedia:Manual_of_Style_(accessibility)/Data_tables_tutorial#Avoiding_nested_data_tables|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 [http://en.wikipedia.org/w/index.php?title=Template:Infobox/row&diff=390844907&oldid=370768345 recent correction of Template:Infobox/row]. Infobox made with {{t|infobox}} are now completely accessible; I wish all Infoboxes could be standardized using {{t|infobox}}.
::I am at your disposal to help you make this infobox accessible. Kind regards, [[User:Dodoïste|Dodoïste]] ([[User talk:Dodoïste|talk]]) 11:52, 31 October 2010 (UTC)


== New toy to play with &ndash; {{tl|Random-color}} ==
== New toy to play with &ndash; {{tl|Random-color}} ==

Revision as of 11:52, 31 October 2010

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.


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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • I don't think such a solution is feasible or practical for most of these links. Protonk (talk) 22:51, 30 September 2010 (UTC)[reply]
      • 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)[reply]
    • 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)[reply]
      • 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)[reply]
      • 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)[reply]

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)[reply]

  • 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)[reply]
    • 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)[reply]
      • Okay, where? (don't say RfC) Rambo's Revenge (talk) 23:53, 3 October 2010 (UTC)[reply]
        • 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)[reply]

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)[reply]

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)[reply]
The PDF icons are 16x16, is it just a case of doing this? Rambo's Revenge (talk) 15:20, 4 October 2010 (UTC)[reply]

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.

NB. This proposal has been listed at Template:Centralized discussionRambo's Revenge (talk) 12:01, 4 October 2010 (UTC)[reply]

  • 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)[reply]
  • Support, small improvement but useful nonetheless. It adds consistency with the similar PDF icon. Dodoïste (talk) 12:48, 4 October 2010 (UTC)[reply]
  • 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)[reply]
  • (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)[reply]
  • 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. EdokterTalk 13:31, 4 October 2010 (UTC)[reply]
  • (@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)[reply]
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)[reply]
  • (@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)[reply]
4000 is not much. If you do the analogous search for PDF you get 70,000. Hans Adler 14:15, 4 October 2010 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support Be bold and do it. Lugnuts (talk) 17:26, 4 October 2010 (UTC)[reply]
  • 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)[reply]
  • Support I think it is a good idea. Armbrust Talk Contribs 19:30, 4 October 2010 (UTC)[reply]
  • 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)[reply]
  • Weak Support per Cybercobra. If we can minimize the downsides... let's do it. Jclemens (talk) 04:09, 5 October 2010 (UTC)s[reply]
  • 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)[reply]
  • support seems really quite helpful, and the expressed downsides seem minor. Hobit (talk) 00:38, 6 October 2010 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
  • Support, a sensible proposal and sound idea, makes sense. -- Cirt (talk) 05:15, 8 October 2010 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • Comment-What about OpenDocument, ppt, image, executable, zip extensions?Smallman12q (talk) 16:54, 9 October 2010 (UTC)[reply]
  • 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)[reply]
  • Support Seems a good idea to me, would be helpful. Acather96 (talk) 07:19, 10 October 2010 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support – Useful and consistent. MC10 (TCGBL) 04:58, 30 October 2010 (UTC)[reply]

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)[reply]

  • 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)[reply]
    • 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)[reply]

      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
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)[reply]
  • 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)[reply]
    • More than you'd like to think. Author of User:PDFbot and WP:ChecklinksDispenser 16:40, 5 October 2010 (UTC)[reply]
      • Thats a possibly indeterminate number. :) enough to make URLs a bad first approximation? Protonk (talk) 17:06, 5 October 2010 (UTC)[reply]
      • ...or remove the existing PDF icon? Rambo's Revenge (talk) 17:08, 5 October 2010 (UTC)[reply]
    • 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)[reply]

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)[reply]

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).[reply]
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)[reply]

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)[reply]

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)[reply]
PDFbot already does that, its just it's a pain running the bot. — Dispenser 20:03, 9 October 2010 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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 (talkcontribs) 14:30, 19 October 2010 (UTC)[reply]
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)[reply]
A bot to fill in the format parameter is a much better solution. OrangeDog (τε) 15:43, 20 October 2010 (UTC)[reply]
But won't work because some links don't even use a citation template. Rambo's Revenge (talk) 15:50, 20 October 2010 (UTC)[reply]
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)[reply]
This proposal also won't work, as explained above. (wikt:status quo). OrangeDog (τε) 21:49, 23 October 2010 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

Is it possible to get an old version of an image and use both versions?

I feel the old Belk logo should be in the article. Someone just changed File:Belk_logo.png rather than letting both be displayed in the article.Vchimpanzee · talk · contributions · 21:08, 22 October 2010 (UTC)[reply]

No in fact the old version should really be deleted as WP:CSD#F5: Unused unfree images. You would need to upload a fresh file and have a very strong rationale for including two non-free logos in an article. Rambo's Revenge (talk) 21:23, 22 October 2010 (UTC)[reply]
I have no knowledge of how to do that. I contacted the person whose name is on the old image but got no response. I'm not sure how to word this, but the article just seems incomplete if you don't have the old logo.Vchimpanzee · talk · contributions · 21:35, 22 October 2010 (UTC)[reply]
The image without the blue design is very likely {{PD-textlogo}}, it's just text. The one with the blue design may also not meet the threshold of originality (it's text plus three copies of a simple geometric shape), but a second opinion would probably be a good idea. Anomie 00:00, 23 October 2010 (UTC)[reply]
The old image perhaps would be PD-textlogo, but I would disagree with the new image being the same. While made up of simple shapes, the confluence of these shapes, in my opinion, becomes a complex form not covered by PD-textlogo. Huntster (t @ c) 00:23, 23 October 2010 (UTC)[reply]
I know we're getting into policy territory now, but are these last two comments helping make my case?Vchimpanzee · talk · contributions · 17:31, 23 October 2010 (UTC)[reply]
Yes, if the old logo is found to be PD-textlogo then it can be uploaded as a seperate image and put in the doucument (and being free it won't need to meet fair-use requirements). Suggest you ask for the second opinion as linked previously. Rambo's Revenge (talk) 17:35, 23 October 2010 (UTC)[reply]

Thank you. Done.Vchimpanzee · talk · contributions · 18:30, 26 October 2010 (UTC)[reply]

User:Magog the Ogre seems to believe it's okay to use both.Vchimpanzee · talk · contributions · 15:03, 27 October 2010 (UTC)[reply]

Suggestions

I am make three suggestions.

1- I want two thing from Wikipedia employees

I want the say of suggestions about Wikipedi. To do this, create a page. Wikipedia employees will read yhe suggestion and forward them to relevant units.

2- State name is continuous written in war, battle and event subjects in Wikipedia. But; races is not write. For example: Hunnic empire with ...... is fight in (date). Please write: Hunnic empire that mostly composed of Turks with ..... is fight in (date) or similiar. Race must emphasize by Wikipedia writer. for this, please notify the authors on this subject. Please missing paragraph should be added the race by Wikipedia volunteers. You should request the adding the races from Wikipedia volunteers

3- There is New section button in http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical). Plase change as New create subject or similiar. If this problems is available in other language Wİkipedia, please apply the this my suggestion to other languages Wikipedia

4-http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)

in left in Village pump page:

العربية Česky Español فارسی ქართული Қазақша Magyar Македонски Bahasa Melayu Português Русский Suomi Українська 粵語 中文

Village pump may be in other languages Wikipedia. FOr example: Turkish Wikipedia. http://tr.wikipedia.org/wiki/Vikipedi:Köy_çeşmesi Please add the links of other languages to left section. FOr example: Turkish

5- Some subject have 粵語 (languages). I think install language packs. PLease add information to top of website about this problem. This information must fixed. WHen I change pages, this information must not forget

Please five suggestion must be/available in other languages Wikipedia

—Preceding unsigned comment added by 85.96.145.54 (talk) 19:58, 25 October 2010 (UTC)[reply]

Ad 1. Almost everything regarding Wikipedia is done by volunteers like you or me (including deciding what the rules are). Wikimedia Foundation that runs Wikipedia has only a handful of employees and probably won't be able to deal with your suggestions (but that largely depends on what suggestion do you have in mind). If you still want to contact them, see Wikipedia:Contact us.
Ad 2. That's what links are for. Click on the link Hunnic Empire to find that … it wasn't mostly composed of Turks, mainly because no such nation existed at the time.
Ad 4. Those links link to technical Village pumps and it seems Turkish doesn't have one. Wikipedia:Village pump does contain a link to tr:Vikipedi:Köy_çeşmesi.
Svick (talk) 22:43, 25 October 2010 (UTC)[reply]


Ad 5 - do you mean the list of languages that appears at the bottom the navigation area? This is located on the left-hand side of the standard skin. They are interlanguage links, and have to be added manually to each article. However a bot (computer program) will attempt to copy the interlanguage link from one language's article to all the other languages' articles. For example, if you link tr:BAR to en:FOO, then all the language articles that en:FOO links to will be linked back tr:BAR and tr:BAR will be linked to all those language articles. CS Miller (talk) 12:09, 28 October 2010 (UTC)[reply]

Internal links turn white when hovered over

Internal wiki links (like this one) occasionally disappear - or possibly turn the same color as the background - when hovered over. I've noticed this twice. It could be a Mediawiki problem, a problem with the new skin, a Firefox problem, a 7 problem, or (god willing) a problem with my computer that seems to only affect this website. Anyone else notice? Doc StrangeMailboxLogbook 19:42, 26 October 2010 (UTC)[reply]

I haven't--SPhilbrickT 21:55, 27 October 2010 (UTC)[reply]

Merging the history of two articles

Is it somehow possible to merge the history of two separate articles together? (Like if a copy-and-paste move has been done.) Or can they only remain divided? HeyMid (contributions) 20:58, 26 October 2010 (UTC)[reply]

Yes, but only admins can do it, Wikipedia:How to fix cut-and-paste moves. Mr.Z-man 21:31, 26 October 2010 (UTC)[reply]
Thanks for the link. HeyMid (contributions) 22:07, 26 October 2010 (UTC)[reply]

Wikipedia speed

Normally, this is the place where we complain about Wikipedia outages or sluggishness; well, it's extremely fast now. Of course, I can't tell whether that might be because of reduced load or any improvement, but it's so dramatic that I felt I should leave a note – in the hope of not spooking it. -- Michael Bednarek (talk) 09:19, 27 October 2010 (UTC)[reply]

One thing that has changed in the last few days is that the esams bits cache problem has been solved apparently.[2] Depending on from where you are accessing WP, that might contribute to better load times. --Morn (talk) 12:19, 27 October 2010 (UTC)[reply]

Does Google stop indexing deleted pages after a while?

I've had someone complaining on my talk page that a deleted page is ruining their reputation on the web, see Ankit Singh Gehlot. He doesn't like the fact that the deletion reason is visible. I'd like to tell him not to worry and that Google will stop indexing it very quickly but I don't know if that is actually true. Is there anything that we can do to help? Theresa Knott | Sort that Knee! 16:21, 27 October 2010 (UTC)[reply]

Google does have a web page on the topic: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164734RJH (talk) 21:40, 27 October 2010 (UTC)[reply]
OK so the noindex in the page means that next time Google crawls us the result should disappear right? So I can tell him to wait and it will sort itself out in a couple of weeks? Theresa Knott | Sort that Knee! 00:18, 28 October 2010 (UTC)[reply]
Google treats Wikipedia as a special case, to begin with it does not rely on usual crawling. The generic webmaster instructions thus do not apply. It is reasonable to expect that the page will eventually disappear from the index, but only Google knows how and when. I am in fact surprised that it did not disappear already, as otherwise Google picks up changes to WP pages in a matter of ~5 minutes. It may be that page deletions are treated as a potential temporary server failure, note that the Google search now gives a cached version of the article.—Emil J. 10:42, 28 October 2010 (UTC)[reply]

Template problem

Since the template {{Fb rbr header}} was modified to allow for use with all options up to 46 it appears to break after the 40th #ifexpr:. Is there a limit on the number of these that can be used in a template or is there some other reason for the problem occurring? Keith D (talk) 00:26, 28 October 2010 (UTC)[reply]

There are limits on template expansion. If you have an example of how the template breaks, post it in a sandbox or look at it in preview, and then look at the page source. In a comment (often somewhere near the bottom), there's a "NewPP limit report" that specifies how near to each of the limits in question the page has become; it's relatively rare for a page to hit the limits nowadays, but it can happen. See also Wikipedia:Template limits. --ais523 12:14, 28 October 2010 (UTC)
I have done it on the section that fails in an article with the following result
NewPP limit report
Preprocessor node count: 6288/1000000
Post-expand include size: 30457/2048000 bytes
Template argument size: 1642/2048000 bytes
Expensive parser function count: 0/500
Keith D (talk) 12:21, 28 October 2010 (UTC)[reply]
Hmm, that's nowhere near any of the limits, but there's nothing obviously wrong with the template (and in particular, no obvious reason why it would break at 40). Could you show me a specific example of what goes wrong? --ais523 12:28, 28 October 2010 (UTC)
You can see it on 2010–11 Hull City A.F.C. season but it happens on all the football season articles since the IP changed to allow it to be used for each number. Keith D (talk) 12:45, 28 October 2010 (UTC)[reply]
It appears as through there's a limit of 40 on nesting {{#if:}} statements. I've remved the nesting and it is now working. -- WOSlinker (talk) 13:03, 28 October 2010 (UTC)[reply]
Thanks for the fix. Keith D (talk) 20:07, 28 October 2010 (UTC)[reply]

Wrong inter-wiki links

Resolved
 – Thanks, Δ and Anomie. Apologies to any bots I've maligned. TFOWR 15:13, 28 October 2010 (UTC)[reply]

This bot edit, and similar ones in the articles recent history. On the face of it, it's bots doing their job well - adding an inter-wiki link from Nick Robinson to fr:Nick Robinson. However... the bots are all wrong: fr:Nick Robinson is un acteur américain. en:Nick Robinson is a British journalist and political editor for the BBC. Several different bots have made this mistake. Is there a quick and easy way to prevent this? TFOWR 14:51, 28 October 2010 (UTC)[reply]

Ive fixed it, you just need to go to frwiki and remove the link to enwiki. ΔT The only constant 14:58, 28 October 2010 (UTC)[reply]
But why was it linked to enwiki in the first place? Surely that needs to be fixed, instead of having to manually do so. Aiken (talk) 15:00, 28 October 2010 (UTC)[reply]
That would be human error [3] not much we can do about that. ΔT The only constant 15:02, 28 October 2010 (UTC)[reply]
(edit conflict) A careless human, apparently. For future reference, in general when this sort of interwiki problem occurs you have to go and fix it on every wiki involved. Otherwise the bots will usually re-make the error. Anomie 15:04, 28 October 2010 (UTC)[reply]

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 (&nbsp;) 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. EdokterTalk 20:56, 28 October 2010 (UTC)[reply]

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 &#8203; 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 (talkcontribs) 00:44, 29 October 2010 (UTC)[reply]
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. EdokterTalk 11:22, 29 October 2010 (UTC)[reply]
I just realized who made the change in SVN :) Thanks DJ. As a side suggestion: could the hyphen be replaced with &minus;? Also, how can I check if a revision is live here? EdokterTalk 00:21, 30 October 2010 (UTC)[reply]
Fixed in r75658. Since it may take a while for it to go live, I still want to implement the temporary fix. EdokterTalk 20:37, 29 October 2010 (UTC)[reply]
Done in monobook and vector. Added a to-do box on both talk pages. EdokterTalk 21:47, 29 October 2010 (UTC)[reply]

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) [reply]

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)[reply]
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)[reply]
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)[reply]
Do null edits increment oldid? —DoRD (talk) 15:28, 29 October 2010 (UTC)[reply]
"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)[reply]

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)[reply]

Only way to know wehter it is your CSS is to disable it and try again. EdokterTalk 00:38, 29 October 2010 (UTC)[reply]
I've disabled it. would someone care to send me a test message? (please, not everyone - lol). --Ludwigs2 18:36, 29 October 2010 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
Alright thats weird, it was black just a few hours ago... ;) Changed the above proposal. Rehman(+) 10:33, 30 October 2010 (UTC)[reply]
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)[reply]
 Done. Rehman(+) 09:19, 31 October 2010 (UTC)[reply]

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 (TCGBL) 05:17, 30 October 2010 (UTC)[reply]

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

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)[reply]

Like this? mgiganteus1 (talk) 12:59, 30 October 2010 (UTC)[reply]
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)[reply]

"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)[reply]

Their block-log says they've never received any... strange. ╟─TreasuryTagduumvirate─╢ 15:49, 30 October 2010 (UTC)[reply]
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. ╟─TreasuryTagYou may go away now.─╢ 15:50, 30 October 2010 (UTC)[reply]
Troll was blocked in July 2004. See[4]. 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)[reply]
(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)[reply]
Here's the very first page of logs that use our current logging system, from December 2004. Graham87 16:19, 30 October 2010 (UTC)[reply]
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)[reply]

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) [reply]

That's a global lock. You'll find the log on meta[5]. 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)[reply]

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)[reply]

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. EdokterTalk 17:28, 30 October 2010 (UTC)[reply]
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)[reply]
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 templatesTheDJ (talkcontribs) 17:47, 30 October 2010 (UTC)[reply]
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)[reply]
Maybe Wikipedia:Don't worry about performance or Wikipedia:Template limits? PrimeHunter (talk) 00:39, 31 October 2010 (UTC)[reply]

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? Shannontalk contribs 17:51, 30 October 2010 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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: 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 (talkcontribs) 08:06, 31 October 2010 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

...yes, but I highly don't recommend it. What's the point? sonia 10:36, 31 October 2010 (UTC)[reply]
Nothing, really. HeyMid (contributions) 10:39, 31 October 2010 (UTC)[reply]