Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by PrimeHunter (talk | contribs) at 12:52, 15 January 2012 (→‎Sortable table with header spanning several rows: using border color to hide the border). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 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 (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org.

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

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213


Improved move functionality

This suggestion is prompted by an ANI section involving contentious moves: please stick to technical issues here.

When moving a page, normal mortals can move back to an existing redirect as long as it has not been edited. However, we are encouraged to add an appropriate {{R *}} template if available when creating a redirect. This means that anyone doing the move conscientiously may end up with a status only an admin can revert.

I suggest extending the move function with the opportunity to edit and preview the new redirect before it is is saved. This would mean that the mover could specify the initial redirect contents without creating a barrier to a subsequent reversion.

Since moves are much less common that normal edits, the increase in complexity of the operation would not be an issue. --Mirokado (talk) 20:27, 1 January 2012 (UTC)[reply]

Slightly alternate suggestion: Can a pull down/tick box be added for the common R templates to be added to the "old" page at the same time it is converted to a redirect?
- J Greb (talk) 20:47, 1 January 2012 (UTC)[reply]
Another idea: would it be possible to have the move function recognize diacritical letters in either the "from" article name or the "to" article name, so that a page move ban could be applied to an editor, making it impossible for him to move articles in either direction (from a name using diacritical letters, or to such a name), but to allow other moves? HandsomeFella (talk) 20:57, 1 January 2012 (UTC)[reply]
It would also be great if this function also could stop an editor with such ban from posting RMs for the same purpose. HandsomeFella (talk) 20:59, 1 January 2012 (UTC)[reply]
That may be a bit too finely aimed. Especially since diacritics are not the only R related moves an editor may be banned from making. - J Greb (talk) 21:03, 1 January 2012 (UTC)[reply]
  • As it's such a rare instance, I'm having trouble seeing that this otherwise good idea really pays for the MediaWiki dev work needed in terms of the business value it gives afterwards. Is this really just the project's most dev-expensive single-editor topic ban?
OTOH, anything that encourages the prominence of appropriate categorization and the {{R *}} templates is a good thing. I'm forever having to revert GF edits where edits have removed categorization from redirects, "because redirects shouldn't be categorized". Andy Dingley (talk) 16:08, 5 January 2012 (UTC)[reply]
  • I strongly support the proposal. As a moderately active patroller of WP:RM and believer in the value of redirect tagging, I live in fear of being dragged off to ANI whenever I edit a newly created redirect. Favonian (talk) 15:33, 9 January 2012 (UTC)[reply]

The Find sources template is currently linking to the main Google News site, sans the search criterion

The {{Find sources}} template is currently linking to the main Google News site, sans the search criterion. Here's an example:

Hopefully a solution can be found for this matter. Northamerica1000(talk) 08:36, 6 January 2012 (UTC)[reply]

Oh, crap. Why must Google keep changing the query syntax? --Redrose64 (talk) —Preceding undated comment added 18:50, 6 January 2012 (UTC).[reply]
I've requested a change of the template. If you could take care of it, that'd be great. Goodvac (talk) 18:57, 6 January 2012 (UTC)[reply]
 Done --Redrose64 (talk) 20:51, 6 January 2012 (UTC)[reply]

Find sources template– fixed, but includes PR press releases, announcements etc.

  • Comment - The template is functional again, but at this time doesn't automatically disinclude public relations press release coverage in searches as it did before. Is there any way to reinstate these parameters? Northamerica1000(talk) 08:29, 7 January 2012 (UTC)[reply]
    • The &as_src=-newswire+-wire+-presswire+-PR+-release+-wikipedia portion of the query hasn't been working for a while. The link would always redirect to a url without the &as_src... portion. The only option I see is to add -newswire+-wire+-presswire+-PR+-release+-wikipedia directly to the query, yielding a link like this, which is rather clunky. In my opinion, it's not worth it, as it's not difficult to recognize newswire sources just by looking at the result snippet. Goodvac (talk) 08:48, 7 January 2012 (UTC)[reply]
      • Many new and newer users may not be aware that public relations press releases and announcements are unsuitable for use as reliable sources, and then may unknowingly incorporate these types of sources into articles. I think that including the information above in the search parameters to omit PR sources is better than nothing, as this would function to significantly prevent this type of ongoing problem from recurring continuously. The "clunkiness" of the search criterion is outweighed, in my opinion, by the benefits of including these parameters in the search function of the Find sources template. Up to about 1-1/2 to 2 weeks ago, the Find sources template functioned in this manner, coded to help omit unreliable sources. Hopefully it won't continue to exist in a (now), unfortunately deprecated state. Northamerica1000(talk) 13:22, 11 January 2012 (UTC)[reply]
        • As a blanket statement, "public relations press releases and announcements are unsuitable for use as reliable sources" is blatantly incorrect. These are entirely reliable as primary sources for the fact that the issuer made the statements contained in the press release. They may also be sufficiently reliable for uncontroversial facts and figures pertaining to the issuer.
          I have no opinion on whether "PR sources" should or should not be excluded from the default search to focus the results on sources that are more likely to be generally reliable and/or are more likely to support WP:N (which requires sources independent of the subject). Anomie 14:15, 11 January 2012 (UTC)[reply]
        • No, it stopped omitting press releases long before you started at AfD.
          Some of my comments above are faulty. Compare this regular search with [1]. The extra exclusion terms have no effect on the search. &as_src=-newswire+-wire+-presswire+-PR+-release+-wikipedia added to the new query syntax doesn't redirect (example: [2]), but it also has no effect on the search. I'll try to find another way. Goodvac (talk) 18:48, 11 January 2012 (UTC)[reply]

Toggle NOGALLERY

Is there a way (a script) to toggle __NOGALLERY__ e.g. in subcategories of Category:Wikipedia files with the same name on Wikimedia Commons? --Leyo 14:33, 6 January 2012 (UTC)[reply]

I just found User:Splarka/togglegallery.js (discussed here), but it does not work for me. --Leyo 12:56, 9 January 2012 (UTC)[reply]

Construct wanted with optional <ref> tag around {{cite web}}

Resolved
 – for me -DePiep (talk) 11:08, 9 January 2012 (UTC)[reply]

I want to create a template that produces a {{cite web}} reference, and with the option: inline OR footnote. Footnote requires the <ref>..<ref/> tags (and more elsewhere on the article page), inline does without. So, to me first step, code should look like this: {{#ifeq:{{{do_fn|}}}|yes|<ref>}}{{cite web|title=&tc}}{{#ifeq:{{{do_fn|}}}|yes|<ref/>}}. But it doesn't work. Every ref-tag starts a reference literally from }} on, or is not processed as a tag. I tried &lt; and also subtemplate param pass-though. I can read & understand the three <includeonly> things up to a level, but could not use them in this (tag <> brackets involved). I am familiar with a template stack (template T:A calls T:B calls T:C). Any ideas? Any good existing example templates in this? Use my my sandbox example) -DePiep (talk) 23:16, 6 January 2012 (UTC)[reply]

I tried {{#ifeq:{{{do_fn|}}}|yes|<ref>{{cite web|title=&tc}}</ref>|{{cite web|title=&tc}}}} in User:PrimeHunter/sandbox. Repeating the whole cite web may not be elegant but it seems to work. PrimeHunter (talk) 23:37, 6 January 2012 (UTC)[reply]
re PrimeHunter. Actually, the code I wrote here is untested muckup (handwritten, hence the </ref> mistake). I myself am developing in my home sandboxes /1 /2 /3 (and /10 as testcases) (see my base): the neighbourhood kids love it. -DePiep (talk) 00:54, 7 January 2012 (UTC)[reply]
Me more to your point, PrimeHunter: a working solution, but entering the {{cite web}} and all the params twice, indeed, may be too much. I'll try a different solution first. -DePiep (talk) 09:17, 9 January 2012 (UTC)[reply]
First, note that the closing tag is </ref> not <ref/>. Then, I would suggest using the {{#tag:}} parser function - have a look at how {{sfn}} does it - that is essentially {{#tag:ref|{{harvnb}}}} with some clever stuff to merge duplicate refs. --Redrose64 (talk) 23:46, 6 January 2012 (UTC)[reply]
{{refn}} is a simpler example of #tag:ref. It also illustrates how you must handle an optional name for #tag:ref. ---— Gadget850 (Ed) talk 00:09, 7 January 2012 (UTC)[reply]
I will check this out. Interestingly, I expected <includeonly> stuff tricks, but this is really a new route to discover. -DePiep (talk) 00:54, 7 January 2012 (UTC)[reply]

Concluding: answered into a working thing. Had to use the magic word {{#tag:ref}} because of subtemplates (though nested references are not used), and had to use PrimeHunter's conditional suggestion because the ref tag is optional (I could reduce the double code to an acceptable level). Thanks.-DePiep (talk) 11:08, 9 January 2012 (UTC)[reply]

Please don't. It makes things more complicated for bots and scripts that try to process references in wikitext to have a profusion of templates that insert reference tags, as the bot/script can no longer just look for <ref>...</ref> and {{#tag:}} to find them but must take into account everyone's random template that saves them typing a handful of characters. Anomie 03:34, 7 January 2012 (UTC)[reply]
Still I will. Producing good references is more important than greasing the bots. -DePiep (talk) 03:42, 7 January 2012 (UTC)[reply]
Can't you just have it auto-subst? - Jarry1250 [Deliberation needed] 14:07, 7 January 2012 (UTC)[reply]
subst: is another complicated process to me. But if that were a solution, I'd surely research and try. This option and examples was not explicated here. -DePiep (talk) 21:23, 7 January 2012 (UTC)[reply]
Anomie is right. DePiep, you usually talk a lot of sense, but I'm having great difficulty trying to understand what exactly is the point or benefit of this template. I really don't want to see this sort of template horror without a very good reason. --NSH001 (talk) 15:35, 7 January 2012 (UTC)[reply]
The reasoning for such a template is not the topic here. T=Tech. Actually, I spend a lot of time to phrase the question right. I am proud of it, and it served getting good answers. NSH001, since you already support Anomiex's outcome, why should we discuss anything? -DePiep (talk) 21:12, 7 January 2012 (UTC) ce -DePiep (talk) 21:23, 7 January 2012 (UTC)[reply]
I could be persuaded if a good enough reason is given. Trouble is, I can't even imagine how this template might be useful. In addition to Anomie's point, the cite templates are complicated enough already, and kill page loading times on pages with more than about 50 of them. They really need to be simplified (or re-written in some more efficient language), not have any more overhead added to them. --NSH001 (talk) 21:43, 7 January 2012 (UTC)[reply]
Fair enough, and I was shortwording to Anomie. Now, the reason or need for my baby template (which is not part of my Tech question here) is that it will help providing many and good references. Until now, in the topic I want to use it, I have not seen a single one complete reference, and inline/footnote workings are bad. Also, because of the numbers and situations involved, it is templateable. If bots don't get it -- sorry for them. Who is leading?
And, to show that I do know about bad automation: somewhere else I removed my own thing [3] from a template. -DePiep (talk) 22:02, 7 January 2012 (UTC)[reply]
Sometimes the best answer to "How do I do X?" is "Don't." It seems to me that it would be more clear all around for a template like the one you've described to be used as <ref>{{template}}</ref> rather than something like {{template|ref=yes}}. Anomie 06:35, 8 January 2012 (UTC)[reply]
You mean footnote style only, and dropping the option to use the web cite inline? -DePiep (talk) 13:09, 8 January 2012 (UTC)[reply]
This is surely stating the obvious, but if you want it inline, just write {{template}} instead of <ref>{{template}}</ref>. You can easily find examples in the form of bulleted lists in many (most?) Featured Articles. --NSH001 (talk) 20:19, 8 January 2012 (UTC)[reply]
That I got, but it would defy the purpose of my template. I wrote: "I want to make a template such and so", and your answer is "don't, it's template horror, unless you convince me". There is something in the reasoning that doesn't help this talk. -DePiep (talk) 09:03, 9 January 2012 (UTC)[reply]

Quirky log in/log out

Has anyone else noticed that when logging in or out there are plus signs where you would expect underscores in the URLs? – Allen4names 07:45, 7 January 2012 (UTC)[reply]

Any gadgets or user scripts active ? It might have something to do with Account_Creation_Improvement_Project, but then i think it is browser dependent, because I don't experience the problem I think. Which skin are you using, what browser ? —TheDJ (talkcontribs) 20:53, 8 January 2012 (UTC)[reply]
I use Twinkle and HotCat. The browser I am using is Mozilla Firefox 3.6.24 and the log out URL is https://en.wikipedia.org/w/index.php?title=Special:UserLogout&returnto=Wikipedia%3AVillage+pump+%28technical%29. Using Chromium 15.0.874.106 the log in URL is https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page&campaign=ACP3. I use the default (Vector) skin. Does this help you figure out what is going on? – Allen4names 07:14, 9 January 2012 (UTC)[reply]

Redirect templates not being rendered

The text from {{R *}} templates no longer seems to be being rendered on redirect pages. Example R from alternate spelling: AK47]. Example: R from misspelling homogenous. I'm sure it used to render - I'm not imagining that am I? SpinningSpark 14:47, 7 January 2012 (UTC)[reply]

They did use to render, but this has been changed for a while now. Ucucha (talk) 15:11, 7 January 2012 (UTC)[reply]
I don't recall them showing on a normal page view. However, I've only been using these templates for about a year, so if it was changed, it was either the change to MediaWiki 1.17 (Feb 2011), or earlier than that, when they stopped. They do still show on page diffs though, see here for example. --Redrose64 (talk) 16:26, 7 January 2012 (UTC)[reply]
It has been a very long time. According to comments on Template:Bug, it stopped working in August 2004. Anomie 17:11, 7 January 2012 (UTC)[reply]
File:AK-47 redirect.JPG
The AK47 redirect as Armbrust sees it.
They are rendered, but they now trasclude hidden categories. Armbrust, B.Ed. Let's talkabout my edits? 12:20, 8 January 2012 (UTC)[reply]
The text of the template has not been rendered in your screenshot. I am sure I have seen this much more recently than 2004, I would not have been very interested in behind-the-scenes stuff on Wikipedia back then. Possibly I saw the template subst'd in edit mode rather than rendered. SpinningSpark 12:40, 8 January 2012 (UTC)[reply]
There was some other text? Well at least the categorization works. Armbrust, B.Ed. Let's talkabout my edits? 19:41, 8 January 2012 (UTC)[reply]
It appears for me when looking at a diff, say [4] Chris857 (talk) 19:46, 8 January 2012 (UTC)[reply]
Yes, I see it too in diff. That must be where I have seen it before. SpinningSpark 20:09, 8 January 2012 (UTC)[reply]

Show contributions from CIDR range?

Expected this to exist, but archives/Google didn't do much for me:

Is there a tool that shows all contributions from a particular IP range / CIDR block (obviously pertaining only to unregistered users)? It seems this can be done for block history, but not edit histories. Conceptually its quite simple: Just enumerate all the IP addresses in the block, query the API for their individual contributions, then aggregate and visualize in some way. Would be a valuable for tool for anyone trying to audit the IP contributions of their organization. Thanks, West.andrew.g (talk) 20:45, 7 January 2012 (UTC)[reply]

Preferences → Gadgets → Allow /16 and /24 – /32 CIDR ranges on Special:Contributions forms. PrimeHunter (talk) 22:22, 7 January 2012 (UTC)[reply]
For more info about this see Help:User contributions. This does work once you've enabled the gadget (ignore the "No changes were found matching these criteria." text), e.g. Special:Contributions/163.1.0.0/16. - Pointillist (talk) 22:34, 7 January 2012 (UTC)[reply]
Toolserver has a better one not limited to multiples of 8, but it's been broken for a long time.Jasper Deng (talk) 22:27, 7 January 2012 (UTC)[reply]
Pretty trivial to recreate if anyone wants me to. - Jarry1250 [Deliberation needed] 13:09, 11 January 2012 (UTC)[reply]

Being logged out unexpectedly

I have found that I am being logged out unexpectedly, sometimes, seemingly, after only being logged in for a short time. I often have several browser windows with several tabs on each open simultaneously.

  1. Is there a maximum set time that the Wiki software(MediaWiki?) allows you to stay logged in for, and
  2. Does it log you out if inactive (not actually editing) for a certain time?
  • Browser: Google Chrome, version: "16.0.912.63 m"
  • O/S: Windows Home Premium, Version 6.1 (build 7600)

- 220 of Borg 01:14, 8 January 2012 (UTC)[reply]

Do you have the little box checked at login? "Remember my login on this browser (for a maximum of 30 days)" It should have nothing to do with how much actual editing you do.
Sometimes it has to do with if your browser is set to accept the Wikipedia cookies.
That said, I think there are sometimes hiccups in the system. I can be logged in for months without being booted out. And then I get booted out in the middle of an edit.

Hope this helped a little. Maile66 (talk) 01:44, 8 January 2012 (UTC)[reply]

I do not have that box checked. In fact I was arbitrarily logged out just a few minutes ago. I usually find out when the pop-ups don't work. Very annoying.
Is this correct?
Answering my own question, it seem YES:
  • " The time limit is half an hour. Yes, clicking preview regularly will restart the timer, but I got frustrated with such things long ago and decided that the security problems with associated "remember password" weren't really that bad. Do you think it would help if it were, say, an hour? There's a trade-off between convenience and security -- perhaps half an hour is a bit too far to the security end for our case. -- Tim Starling 10:59, Sep 20, 2003 (UTC)." Who is "employed by the Wikimedia Foundation as a developer and system administrator."
    (found HERE in Wikipedia:Village pump/Archive M)
Thank you Maile66 for your assistance- 220 of Borg 05:29, 8 January 2012 (UTC)[reply]
Related: If we log in while using a secure connection (https); even if we check the "Remember me.." box; if we then visit a page without using a secure connection (http), we may find we are no longer logged in. Easy to forget. I will occasionally Google search for info, and follow a link back to WP, only to find the link was "http", and I'm suddenly missing all my scripts and show up as an IP. If it wasn't for my user scripts making my WP UI so different to the default, I probably wouldn't even notice.
The moral of this tale of woe is: log in on both a secure (https) and an insecure (http) connection to pick up cookies for both. fredgandt 05:44, 8 January 2012 (UTC)[reply]
I thought the moral was "Install HTTPS Everywhere". Anomie 06:37, 8 January 2012 (UTC)[reply]
Firefox extension. I'm Chrome plated. I'd have thought it would make sense (for WMF) to redirect to https (where available) on all page loads anyway. It's so easily done. fredgandt 07:25, 8 January 2012 (UTC)[reply]
That comment by cesarb sounds like rubbish to me. I've often logged in, done nothing for several hours, and returned and am still logged in. What I have noticed is that if I have the edit window open, begin editing, do nothing for an hour or so, continue editing and attempt to save, it complains that my session data has been lost. This is not the same as being logged out.
A related thread was raised on 28 Dec 2011 which might help. --Redrose64 (talk) 18:46, 8 January 2012 (UTC)[reply]
Glad to read your perspective, Redrose64. I was at a loss about the 30-minute time limit mentioned above. I've been editing with Wikipedia for 5 years, and I'd never before heard of the time limit. There have been times when I've edited from a public computer and did not check the "remember me" box, but I don't think I got booted out for any reason while using the public computer. Maile66 (talk) 19:10, 8 January 2012 (UTC)[reply]
There's hope for Chrome, at least. Anomie 22:36, 8 January 2012 (UTC)[reply]

Request for Comment - Article Feedback Tool

Hey guys. We've just opened a Request for Comment on the Article Feedback Tool, version 5. Amongst other things, we're looking at anti-spam and anti-BLP vandalism measures, so as much participation as is possible would be most welcome :). Hope to see people there! Okeyes (WMF) (talk) 11:13, 8 January 2012 (UTC)[reply]

Request for comment on technical feasibility and desire/horror etc. of idea in development. fredgandt 13:57, 8 January 2012 (UTC)[reply]

Will this get fixed automatically?

I had to do this. Will all the pages pointing to the wrong name be automatically updated to the new one? If not, is there a tool for this? Maury Markowitz (talk) 22:01, 8 January 2012 (UTC)[reply]

Your page move has left a redirect behind. Pages pointing to the old name will automatically link to the new: try clicking Claris Homepage and compare to clicking Claris Home Page. There are no double redirects, so no further action is necessary, either by yourself or a bot, see WP:NOTBROKEN. --Redrose64 (talk) 23:10, 8 January 2012 (UTC)[reply]
Redrose is correct, but bear in mind, for the future, that there are some exceptions. One is redirects in navboxes, which should be replaced so that the link shows in bold on the relevant page (see WP:NOTBROKEN). Another is if the page moved is itself a disambiguation page, then this may leave links incorrectly pointing to a dab page, which must be cleaned up. --NSH001 (talk) 23:20, 8 January 2012 (UTC)[reply]
The links will work with the redirect but the old text will continue to be displayed. If you want to display Claris Home Page instead of Claris Homepage in an article then the source of the article must be edited. There are semiautomated tools to make such tasks easier, for example Wikipedia:AutoWikiBrowser. PrimeHunter (talk) 03:08, 9 January 2012 (UTC)[reply]

Section linking does not work for me

You may need to look at this post in edit mode to see the coding issue I'm trying to illustrate

According to instructions,

displayed text

is supposed to link to the section with "displayed text"

But for me, it doesn't work as expected.

For instance,

If I copy the illustration, put double brackets and don't put in an extra space before "Health" ("| Health") the result is

[effects of particle pollution]

It displays " effects of particle pollution"

as a link, but when clicked that link does not go to the "health effects" section, but only to the top level article "Particulates"


As an experiment,

Health effects of particle pollution

Returns a link that looks as it should,

(It says "Health effects of particle pollution")

But when you click on it, it does not actually go to the health effects section. It goes to the general article, i.e., the same as if the link were just Particulates. — Preceding unsigned comment added by Ocdnctx (talkcontribs) 02:49, 9 January 2012 (UTC)[reply]

It looks like you're confusing external and internal link syntax. Both an external link like Health effects of particle pollution ([http://en.wikipedia.org/wiki/Particulates#Health_effects Health effects of particle pollution]) and an internal link like Health effects of particle pollution ([[Particulates#Health effects|Health effects of particle pollution]]) work for me; the second form is preferable. Ucucha (talk) 02:53, 9 January 2012 (UTC)[reply]
Just to clarify further, "page name" in wikilinks means the page heading and not the url. The article is linked with Particulates and the section with Particulates#Health effects. PrimeHunter (talk) 03:00, 9 January 2012 (UTC)[reply]
There are two kinds of link: internal and external, see Help:Link.
Internal links have double square brackets, the page name not preceded by the http://en.wikipedia.org/wiki/ part, and use a pipe character to separate the link from the displayed text.; furthermore, the link target must be somewhere within the Wikimedia Foundation's projects (of which the English Wikipedia is one).
External links have single square brackets, a full URL (to almost anywhere), and use a space to separate the link from the displayed text.
If the two syntaxes are mixed, as with [[http://en.wikipedia.org/wiki/Particulates#Health_effects|Health effects of particle pollution]], the MediaWiki software does its best to resolve one way or the other. Primarily, the presence of a http: immediately after a square bracket causes the external link syntax to be used, so that two things happen: (a) the URL is considered as extending up to the first space; and (b) the outer pair of square brackets are taken as plain text.
In an internal link, the displayed text is separated from the link target by a pipe, as in [[page name#section name|displayed text]]. But for a titled external link, the title is separated from the link by a space, so in a link constructed as [http://en.wikipedia.org/wiki/Particulates#Health_effects|Health effects of particle pollution], the first space is before the word "effects", so the link is to http://en.wikipedia.org/wiki/Particulates#Health_effects|Health - but on the page Particulates, there is no section whose name is exactly Health effects|Health, so in the absence of a matching section, it defaults to the top of the page. Such links should be formed without the pipe, i.e. [http://en.wikipedia.org/wiki/Particulates#Health_effects Health effects of particle pollution]. However, as already noted, links to pages within Wikipedia should not be constructed using the external link syntax, so this one should be [[Particulates#Health effects|Health effects of particle pollution]], with double square brackets and a pipe. --Redrose64 (talk) 11:59, 9 January 2012 (UTC)[reply]

Problem with sorting in wikitable

The article List of countries by external debt has a large wikitable that is sortable according to the fields. When I clicked the arrow beside "rank" in the left-most column, instead of rendering 1, 2, 3..., instead it gave back 1, 10, 100, 101, 102...109, then to 11, then to 110, 111, 112.... In short, it didn't sort it to ascending order. Descending order also doesn't work. The 5 other fields do work though. I tried purging the page but it didn't solve the problem. I'm using Internet Explorer 8. Can others use other browsers such as Firefox or Chrome to see if the problem still persists? Shuipzv3 (talk) 04:17, 9 January 2012 (UTC)[reply]

The entries that are marked with rank "&#151;" switch the column to alphabetical sorting. Use {{nts}} to fix. Prodego talk 04:22, 9 January 2012 (UTC)[reply]
So the trick is to tag the numbers with {{nts}}, like this: {{nts|1}}? Shuipzv3 (talk) 04:38, 9 January 2012 (UTC)[reply]
Yes, on every one but the dashes. That should fix it. Prodego talk 04:45, 9 January 2012 (UTC)[reply]
Thank you for the help. Shuipzv3 (talk) 04:52, 9 January 2012 (UTC)[reply]
You could be clever and do the dashes as well with {{ntsh}}. So for example, the EU is between ranks 1 and 2. So if you made it "{{ntsh|1.5}}&#151;" the dashes would sort correctly too. Prodego talk 04:59, 9 January 2012 (UTC)[reply]

I thought the dashes denote the state not being a country, and also the title of the article itself says it is about "countries". For example: EU - only a organisation, not a whole country; Hong Kong - part of China; West Bank - limited recognition in the world; Aruba - belongs to Holland; Greenland - Denmark. Shuipzv3 (talk) 05:08, 9 January 2012 (UTC)[reply]


Help:Sorting#Sort modes says sort mode is determined by the first row. This is not true currently and that's why the reported table at [5] failed. All the first three tables at Help:Sorting#Examples also fail for me currently. They sort alphabetically every time instead of numerically. It appears that if any row has alphabetical sort mode then the whole column is sorted alphabetically. Here is a simpler example:
numbers
10
11 this text currently forces alphabetical sort no matter which row it is in
12
9
The same table without the text sorts correctly numerically :
numbers
10
11
12
9
Either sorting code is buggy or the documentation (and many existing tables in articles) should be changed. PrimeHunter (talk) 15:25, 9 January 2012 (UTC)[reply]
Something is amiss. This table used to be sortable (I think), but is not now. --SPhilbrick(Talk) 16:16, 9 January 2012 (UTC)[reply]
Perhaps it worked before, but the table is broken, since it didn't use actual tableheaders, but styled tablecells, which is also an accesibility issue. See fix. —TheDJ (talkcontribs) 16:40, 9 January 2012 (UTC)[reply]
Thanks for the fix. I'm not quite following, but may not need to. I have other versions of similar tables, I'll try the fix myself in the other places. Thanks again.--SPhilbrick(Talk) 16:44, 9 January 2012 (UTC)[reply]
In essence, the cells within table rows are of two types, "header cells" (in HTML terms, <th>...</th> elements) - these are typically boldfaced and centred by default, and "data cells" (in HTML terms, <td>...</td> elements) - these are typically normal weight and left-aligned by default. The two types of cell are declared using two slightly different methods: if an exclamation point is used, this creates a header cell; and if a pipe character is used, this creates a data cell. In the past (before MediaWiki 1.18) it was sometimes the practice to create something that looked like a header cell by actually declaring a data cell, and then applying the bold/centred styling to it, and the sorting would still work. As from MediaWiki 1.18 (October 2011), for a sortable table to work, the first row must consist entirely of header cells (whether styled or not). --Redrose64 (talk) 20:13, 9 January 2012 (UTC)[reply]
Correct, though I should mention that the 'practice' was a unadvised/bad and the fact that the old tablesorter worked with an 'accident of history' and not so much a feature :D —TheDJ (talkcontribs) 22:07, 9 January 2012 (UTC)[reply]
(e/c) The documentation is not up to date with the current behavior indeed. The cause is that the new method to fix sorting on table cells works with HTML5 data attributes, but Wikipedia has not yet been switched to HTML 5. This causes this deviance from the documented behavior. When 1.18 was launched, HTML5 was promised to follow suit, but this has again not yet come to fruition. Once HTML5 is finally enabled, the new method to force a sorting will be by using a data attribute on the columnheader. Most sort templates can then be removed and deprecated from all the articles. —TheDJ (talkcontribs) 16:20, 9 January 2012 (UTC)[reply]
Thanks for the explanation. I realize plans can change but does anybody know a current estimate of when this will happen? The timeline influences what should be done to the documentation and possibly done to identify and fix existing tables. PrimeHunter (talk) 16:47, 9 January 2012 (UTC)[reply]
I think that the behaviour of sortable tables (how it's decided whether a given column is to be sorted alphabetically or numerically) changed with MediaWiki 1.18, October 2011. --Redrose64 (talk) 20:13, 9 January 2012 (UTC)[reply]
The intention of the new table sorter was always to change how sorting worked.
  • One of the primary reasons to introduce it in the first place, was the option to define for a column what type of content the sorter should expect there, making it possible to do away with the ugly hack of having to use those nts/dts etc sort templates.
  • A column with an 'undefined' sorttype, would then have 'autodetection', but this detection, unlike earlier, is always based on the detected type of the 1st row (Even after sorting the same column multiple times), falling back to alphanumeric sorting for all cells if one of the cells in the column, does not adhere to the detected type of the 1st row.
However because the HTML5 deploy was pulled, the new column datatype-setting doesn't work, and the documentation was therefore not yet corrected with the new information. This means that indeed the documentation is providing the information of the 'old' autodetection, not of the 'new' autodetection.
But really we should just get a move on with HTML5 mode. bugzilla:27478. —TheDJ (talkcontribs) 22:07, 9 January 2012 (UTC)[reply]
OK, I expect to update Help:Sorting tomorrow if nobody beats me to it. By far the most common issue for editors is numeric versus alphabetic. Just to make sure I get it right: Until HTML5 is deployed at an unknown time, there is no method to achieve numerical sort if any of the sorted cells contain anything other than a number? PrimeHunter (talk) 23:55, 9 January 2012 (UTC)[reply]
Fixing Help:Sorting is more complicated than I thought. I have started a rewrite of sort modes at User:PrimeHunter/sandbox2 but experimentation shows it still has many things not matching current sorting. For example, after some confusion I noticed that empty cells are apparently allowed in numeric sorting if and only if there are at least 5 number cells:
4 numbers and 1 empty cell gives string sorting
11
8
9
10
5 numbers and 1 empty cell gives numeric sorting
11
8
9
10
12
PrimeHunter (talk) 03:15, 11 January 2012 (UTC)[reply]
Inspection of the source code shows the following; The autodetection code looks at the first 5 rows. These first 5 rows need to be consistent in their type, otherwise the fallback type of "alphanumeric" sorting will be used. So that explains the effect you are pointing out above. —TheDJ (talkcontribs) 22:45, 11 January 2012 (UTC)[reply]
Thanks! Further testing indicates it is the first 5 rows with a non-empty cell in the column. Empty cells are allowed as long as 5 cells with the same sort mode are reached before the first non-empty cell with other sort mode. Some or all of the 5 rows can be hidden.
5 hidden rows with a pure number gives numeric sorting
0
0
0
0
0
12 Drummers Drumming
11 Pipers Piping
10 Lords-a-Leaping
9 Ladies Dancing
4 hidden rows with a pure number gives string sorting if the 5th row is non-numeric
0
0
0
0
12 Drummers Drumming
11 Pipers Piping
10 Lords-a-Leaping
9 Ladies Dancing
The new sort code only cares about the first 5 rows in the source and not where the current sorting has placed them, so it should always keep working after sorting. So we can just tell people to place 5 hidden rows at the start? It sounds ugly but I guess we could make templates to place the hidden rows, with parameters giving the number and sort mode of the columns. Any idea whether this hack with 5 hidden rows will be stable until HTML5 is deployed, or it could break at any time if the sort code is updated? PrimeHunter (talk) 00:14, 12 January 2012 (UTC)[reply]
Euh, why not just continue using sort templates, until the HTML5 mode is introduced ? —TheDJ (talkcontribs) 22:35, 12 January 2012 (UTC)[reply]

Balatonfüred#State_Hospital_for_Cardiology's misuse of template Template:Convert/Dual/LoffAoffDxSoffT

Help needed from a clever technician, please.

Balatonfüred#State_Hospital_for_Cardiology is a mess (not my doing!).

Please could a whizz-kid correct it? I'll watchlist it, & learn from the correction.

Many thanks in advance, Trafford09 (talk) 16:41, 9 January 2012 (UTC)[reply]

 Done after a few tries. -- John of Reading (talk) 18:18, 9 January 2012 (UTC)[reply]
Cheers for that, John. Trafford09 (talk) 18:48, 9 January 2012 (UTC)[reply]

Can't add to watchlist

Just tried to add 2 articles pages to my watchlist, got "An error occurred while changing your watchlist settings for "Elim Pentecostal Church".". I was able to add a user talkpage successfully. I've this problem before. Using Firefox 10. Dougweller (talk) 18:02, 9 January 2012 (UTC)[reply]

I think that there's some problem with the servers. When I access any page, it loads sufficient content to display the page properly - but the spinny thing never stops, and the status bar continues to show "Read en.wikipedia.org", until I click to something else, or hit Escape. Also, when saving, it takes a seemingly long time to go through. --Redrose64 (talk) 20:28, 9 January 2012 (UTC)[reply]
I've just done eight (of a planned 18) - each one was merely a "click edit - paste in a ref - click save" but it still took 30 minutes. That's almost 4 mins per save. I might get the other 10 done by 22:00 UTC. --Redrose64 (talk) 21:25, 9 January 2012 (UTC)[reply]
I'm also experiencing long lags when saving my edits (using Firefox). Jezebel'sPonyobons mots 21:42, 9 January 2012 (UTC)[reply]

Where are you located? US, Europe...? I noticed my edit to this page took a while to save, but not if I made an edit to my sandbox. Try making an edit there, and let me know if you experience slowness there. Prodego talk 21:45, 9 January 2012 (UTC)[reply]

I'm on the West Coast of Canada and it's slow regardless of where I make the edit; that being said I cannot completely discount that the lag may be on my end as opposed to a wiki server issue. Jezebel'sPonyobons mots 22:10, 9 January 2012 (UTC)[reply]

Wikipedia is deathly slow when saving an edit (West Coast US here). Killiondude (talk) 22:53, 9 January 2012 (UTC)[reply]

England. --Redrose64 (talk) 23:15, 9 January 2012 (UTC)[reply]

I've noticed some slowness, but it seems to have improved for me somewhat in the last 10-15 minutes. --Bongwarrior (talk) 00:00, 10 January 2012 (UTC)[reply]

In northern Michigan, have not seen the slowness. Chris857 (talk) 03:41, 10 January 2012 (UTC)[reply]
Takes 4 minutes to save in Missouri. (Show me!) --64.85.214.19 (talk) 17:55, 11 January 2012 (UTC)[reply]

Slow

Is the wiki slow for anyone else right now? Edits go through, but they don't bring me back to the page — it just stays at the edit window. Ten Pound Hammer(What did I screw up now?) 23:48, 9 January 2012 (UTC)[reply]

look up one thread :) --Jezebel'sPonyobons mots 23:50, 9 January 2012 (UTC)[reply]

Request for comment at Idea Lab

Over here I posted a suggestion for how we could improve oversighting by adding request for oversight functionality to MediaWiki. More comments and suggestions would be appreciated. causa sui (talk) 17:43, 10 January 2012 (UTC)[reply]

Where have the search by namespace options gone

When I do a search now, it has suddenly taken on the "dumber" appearance that is in use at Commons, and I am no longer able to check boxes to search various namespaces... Why has the search feature been rolled back to this older version? - ʄɭoʏɗiaɲ τ ¢ 18:46, 10 January 2012 (UTC)[reply]

Hmm? I'm still seeing them. Special:Search and then you click on the "Advanced" tab. Unless I'm confusing it with something else. elektrikSHOOS (talk) 18:50, 10 January 2012 (UTC)[reply]
"Advanced" is the one you want (though "Everything" will also get the job done if you're sufficiently specific about what you want, I suppose). And the one at Commons looks the same to me...? --Izno (talk) 18:56, 10 January 2012 (UTC)[reply]
For some reason, it's reverted to the old behaviour: to get the namespace selector, you need to click "Advanced". I think "Advanced" became the default method in about October 2011 (MW 1.18?). However, I have noticed that Preferences is no longer used to fill in the "Advanced" selections. --Redrose64 (talk) 19:16, 10 January 2012 (UTC)[reply]
Template:Bug Anomie 21:07, 10 January 2012 (UTC)[reply]
Fix should be live now. Anomie 22:04, 12 January 2012 (UTC)[reply]

Forced to enter a captcha each time I tag something for speedy deletion

Hi, I am having an issue where it is forcing me to enter a captcha each time I tag a page for {{db-c1}} speedy deletion. It's claiming that I've added an external link which is why it's forcing me to enter a captcha, except there are no external links being added. Take a look at Category:2012 United Nations Security Council resolutions, where literally my only edit was to add "{{db-c1}}" at the top. I looked through the template and all links appear to go to Wikipedia, so I'm not sure why it's claiming I'm adding an external link. This is hindering my speedy deletion tagging and highly discouraging me from doing any further speedy deletion work (I've done quite a bit, see my contribs and deleted contribs) if I have to enter a captcha each time. And yes, before anyone mentions it, I know that creating an account will fix this issue, however I prefer to edit anonymously. I'm not sure if there's a problem with the template or what, but it is very silly that I would have to enter a captcha for each speedy deletion tagging. The encyclopedia that anyone can edit, so long as their tolerance for captcha entering is extremely high. 69.59.200.77 (talk) 23:15, 10 January 2012 (UTC)[reply]

While I do not have a good solution based upon your stated preferences, I can explain where the external link is hiding. The template {{db-c1}} calls upon another template, {{Db-meta}}. {{Db-meta}} in turn contains a line near the bottom instructing administrators to check links, page history, and logs before deletion. The template then suggests using several search engines to check for additional information. This suggestion contains embedded external links to Bing. I am starting a discussion at Template talk:Db-meta to see what potential solutions are available. --Allen3 talk 23:45, 10 January 2012 (UTC)[reply]
I've reverted the addition of the Bing link as a temporary measure.  An optimist on the run! 09:56, 11 January 2012 (UTC)[reply]
Per my reply there, you would need to have an addition made to the interwiki map. Graham87 10:41, 11 January 2012 (UTC)[reply]

User stats

Hi

I may have missed something here, but did the user stats links from the top tab drop-downs get removed?

I now only have:

  • User logs >
  • Blocks >
  • Contributions
  • SUL status
  • Userspace
  • E-mail user
  • User groups
  • Rights changes

Thanks Chaosdruid (talk) 02:11, 11 January 2012 (UTC)[reply]

That is not the normal composition of those menu's. Are you perhaps using some sort of gadget or userscript ? —TheDJ (talkcontribs) 07:57, 11 January 2012 (UTC)[reply]
Is it this that's missing? In which case, check Preferences → Gadgets → Add page and user options to drop-down menus on the toolbar. --Redrose64 (talk) 12:39, 11 January 2012 (UTC)[reply]
The list I have given is for only one tab, the User tab - I use Vector.
It appears on the right: Read|Edit|Heart-icon(Wikilove)|TW(Twinkle)|User|Page
I have a few scripts running, but not the Haza one, however this is the first time this has happened. Although I am not aware of exactly when it disappeared, I last used it around Christmas Eve.
Also, if I tick "Add page and user options to drop-down menus on the toolbar." in the appearance section of "Gadgets" I get no user tab but 2x Page tab: Read|Edit|Heart-icon(Wikilove)|TW(Twinkle)|Page|Page Chaosdruid (talk) 17:00, 11 January 2012 (UTC)[reply]
It appears I was mistaken, when scrolling to the very top the Haza script is indeed the first one in my custom javascript list! Chaosdruid (talk) 17:09, 11 January 2012 (UTC)[reply]

Article Feedback Tool office hours

Hey guys! As always, the AFT5 team will be holding an office hours session this Friday at 19:00 UTC in #wikimedia-office. Hope to see you all there :). Okeyes (WMF) (talk) 12:30, 11 January 2012 (UTC)[reply]

Disambiguation

Hello!

I would like a little bit of help regarding disambiguation pages. In case of Budapest there is a primary topic, and there is a separate disambiguation page. My question is, how can you disambiguate on the newly created pages (since the last major clean-up) without checking all the articles that link to the Budapest page? Thanks in advance--Istvánka (talk) 12:49, 11 January 2012 (UTC)[reply]

I don't know a way but you could try asking for tips at Wikipedia talk:WikiProject Disambiguation. PrimeHunter (talk) 14:27, 11 January 2012 (UTC)[reply]
Thanks! Done that!--Istvánka (talk) 14:45, 11 January 2012 (UTC)[reply]

Migration of {{gradient}} to {{linear-gradient}}

With the release of Webkit2 (534) over six months ago, Safari (since 5.1) and Google Chrome (since 10) now support the CSS3 proposed parameter format, making all browser that support gradients parameter-compatible. In that light, I created {{linear-gradient}} that supercedes and will eventually deprecate {{gradient}}. This means that the old Safari and Chrome browsers that only support the legacy -webkit-gradient CSS property are not supported by {{Linear-gradient}}. However the new template offers a great deal more flexibility then the old template, which was very limited by the legacy parameter format.

The new template makes it possible to have an unlimited number of color stops and specify any starting position.

The old template now maps to the new one to provide backward compatibility, but will be obsolete in the near future. This is a bit of a trade-off, but it is one that is future-proof which is the better option in the long run. Edokter (talk) — 13:21, 11 January 2012 (UTC)[reply]

Very nice. fredgandt 20:48, 11 January 2012 (UTC)[reply]

Missing section edit links on a diff

Does anybody see section edit links here? Prior to today, a page diff where the current version was one of the two versions being compared would show section edit links, whereas a diff where neither revision was current would not show section edit links. At some point between 12:24 UTC and 17:24 UTC today, section edit links stopped being shown on all diffs. Within that timeframe, I made this posting, preparatory to which I amended a setting in Preferences → Gadgets. I am pretty sure that I returned my settings to the previous state, but is there something I might have inadvertently altered and overlooked? --Redrose64 (talk) 20:12, 11 January 2012 (UTC)[reply]

When I'm logged out, I see the edit links on my talk page, but not on this page. Ucucha (talk) 20:41, 11 January 2012 (UTC)[reply]
Curious. I also get them for the first of your diff links but not the second - whether logged in or out. I note that your two links have slightly differing syntax (&diff=curr vs. &diff=cur), but when I try adding or removing an "r" this makes no difference. My own talk page shows no section edit links, whether I use the form with cur or the form with curr (and right this minute I got an orange "You have new message" box, containing the form with cur), whether logged in or logged out. I guess that since logging out has no effect, it's not my prefs but something that's happened at system level. Where would I find a list of patches that went live today? --Redrose64 (talk) 21:19, 11 January 2012 (UTC)[reply]
Not sure what the easiest way is, but this at least shows the most recent change for each file and directory in 1.18wmf1. I suspect r108622 may have something to do with it. That cur/curr is also curious; I wonder whether it's intentional that MediaWiki apparently emits both forms. Ucucha (talk) 21:37, 11 January 2012 (UTC)[reply]
Actually, I'm not sure MediaWiki itself emits "curr" anywhere; at least I can't reproduce any place where it does. Ucucha (talk) 21:45, 11 January 2012 (UTC)[reply]
bugzilla:33671. Ucucha (talk) 21:59, 11 January 2012 (UTC)[reply]
Thanks for reporting this. I came to ask about the same thing.   Will Beback  talk  05:47, 13 January 2012 (UTC)[reply]
I've noticed this too (and only just now noticed this thread as somehow I unwatched this page...). ♫ Melodia Chaconne ♫ (talk) 14:53, 13 January 2012 (UTC)[reply]
Thank goodness others have noticed and reported this. Seems to have started happening about two to three days ago (like others have reported here). Really annoying that edit section links no longer appear for diffs on the current version of a page. Gary King (talk · scripts) 18:55, 13 January 2012 (UTC)[reply]

Proposal to add on-wiki reporting system for oversight

Problem

The process of submitting edits for oversight or revision deletion is complicated by the Streisand Effect: in order to obtain the fastest possible administrative action, users are tempted to post offensive or libelous revisions to public noticeboards such as WP:AN/I or the IRC channel. But this practice is discouraged since it draws more attention to the content we were trying to hide.

Additionally, we can safely assume that many Wikipedia editors do not know how to suggest that an edit be oversighted, or in high-speed recent changes patrolling, don't do it simply out of momentum and a desire to quickly move on to the next task.

The tension between the ease of reporting libellous/illegal content and not wanting to draw additional attention to it may lead to legally dubious content getting reverted but not deleted and additional legal liability for the Wikimedia Foundation.

Solution

Implement a flag where any autoconfirmed user can flag a revision for oversight and/or revision deletion. It would then be put into a queue visible only to oversighters / admins. Provided that the tool were sufficiently trafficked, this would achieve the goal of increasing visibility to those carrying the appropriate tools without encountering the Streisand effect.

Discussion

I don't know what it would look like and haven't given it much thought past that. Thoughts? causa sui (talk) 23:50, 5 January 2012 (UTC)[reply]

Looks like a solid idea to me. --Izno (talk) 05:10, 7 January 2012 (UTC)[reply]
The idea seems good to me. Perhaps in addition to an "undo" button, there could be a "report for oversight" button. It might be good enough to get this implemented in Huggle and Twinkle. WhatamIdoing (talk) 05:37, 7 January 2012 (UTC)[reply]
That (a button like the "Undo" button) is pretty much what I had in mind. Huggle and Twinkle could implement the reporting more comfortably than MediaWiki could, but I'm not sure how the other half would work. Where would the reported revisions go? The purpose of the proposal is that the reported revisions would be visible only to oversighters / admins, but I don't think Twinkle and Huggle could make that happen. Anyway, what's the next step for this? I've never suggested a feature like this before. causa sui (talk) 18:51, 9 January 2012 (UTC)[reply]
That's a good question. I think oversight requests are mostly sent in e-mail; perhaps the button could be basically a Special:EmailUser link (pre-filled with some sensible text and a diff).
As for making it happen, I think that I'd start with a note at WT:RFO, with invitations to both Twinkle and Huggle folks (on their main talk pages) to join in. The folks at WP:VPT might also be interested. WhatamIdoing (talk) 20:27, 9 January 2012 (UTC)[reply]
Well, WT:RFO is a redirect to WP:RFO, presumably to prevent people from posting requests for oversight to the talk page. Facepalm Facepalm I can post a request for comment to WP:VPT and see what happens. causa sui (talk) 17:39, 10 January 2012 (UTC)[reply]
I should have checked. Another option is to post something to the talk page for the oversight policy. WhatamIdoing (talk) 18:42, 10 January 2012 (UTC)[reply]
I think this is smart thinking. A one click solution to an otherwise complex issue. I've only requested oversight for a few edits, and each time have emailed the request (which was dealt with quickly). It would however be simpler and quicker if we could just click a flag button and have it all taken care of for us.
  • Potential problem would be the abuse of the button. Possible solution would be that only editors with a track record of say at least 500 edits would see the button. Those editors would by then know enough about the content and policies to use the button wisely.
  • How would it work? Maybe a simple solution could be to add the diff to a category that only oversighters can view. A better system would be to (by means of PHP) send an automated email, as if done by an editor making an email request.
If this were implemented well, I'd like to see the current system of reporting deprecated and eventually done away with completely, thus removing maintenance workload and some of the potential for Babs to get upset. fredgandt 10:04, 11 January 2012 (UTC)[reply]
Well, I floated this in #wikimedia-dev and some idlers pointed me to Multimedia:Flows, which seems like a developer's version of the same idea. If we are reasonably confident that devs wouldn't be tarred and feathered for implementing this, it may just be a matter of finding one. causa sui (talk) 18:54, 11 January 2012 (UTC)[reply]
All changes to the MediaWiki software that surprise a power user result in users boiling the tar and collecting feathers. That's what always happens when power users discover that they aren't in control. WhatamIdoing (talk) 23:13, 11 January 2012 (UTC)[reply]

Moved

So far, I'm encouraged by the response; all of the feedback I've got on this proposal is positive. On the suggestion of a few people in #wikimedia-dev, I moved the discussion over here to get some more view points on if and how this could be concretely implemented. Some prior suggestions:

  1. Start with adding functionality to Huggle and Twinkle.
    Doesn't work because of the critical need for the revisions reported for oversight to be visible only to users with the appropriate tools. Front-end solutions cannot accomplish this.
  2. Add a gadget.
    Similar to above, this cannot be accomplished with Javascript.
  3. Implement a MediaWiki extension
    Probably the best and only solution. Similar to the "undo" button, regular editors would be able to flag any revision for oversight and mediawiki will automatically notify the appropriate users.
Questions

Questions that linger for me are:

  1. We might need a way to know if the revision had been reported already, to prevent excessive re-reporting of the same revision.
    • This could be accomplished with software (the extension automatically declines to report it),
    • Or simply a warning that the revision has already been reported and asking for confirmation that the user really wants to submit a duplicate report.
  2. Oversighters might want a way to respond to the report (i.e., "Thanks, I suppressed this", "Go away, you're a troll").
  3. Once a user hits the button, how should the extension do the reporting?
    • It could send a form email with a link to a revision to oversight-en-wp@wikimedia.org as WP:RFO already indicates.
    • Or, the extension could include a ticketing system similar to Multimedia:Flows. Flows would also have potential uses outside of oversight.

Other questions or comments about implementation? Suggestions for how to move forward? causa sui (talk) 21:06, 11 January 2012 (UTC)[reply]

  • Comment If the term "oversight" is shown as a link akin to "undo" on watchlists, history lists, etc. it will need clear and concise explanation because it's not at all obvious. The uninitiated may believe it to be synonymous with "review", i.e. "this edit needs the considered opinion of another editor", something like Pending Changes. If that belief is held, all sorts of edits will get so marked (I'm primarily thinking unsourced edits to BLPs here) which do not actually require WP:OS attention. There are not many oversighters - I count 35 - and they will not wish to be swamped with trivia that any editor - including the anons - can sort out. --Redrose64 (talk) 21:31, 11 January 2012 (UTC)[reply]
    Good point. Maybe it should be something like "Report abuse" with a boilerplate explanation shoved in the user's face briefly explaining what counts and what doesn't before they hit "Submit". Or better yet, there could be a list of radio buttons with preset acceptable rationales for oversight, and the user has to pick one before hitting "Submit." Finally, wherever we would be tempted to use "oversight" in a user-facing way, we should instead talk about "suppression" since that's less likely to be confused with editorial oversight. causa sui (talk) 21:38, 11 January 2012 (UTC)[reply]
  • I think it could be done in Huggle or in Javascript, actually; it seems plausible that a notification sent to the email list using Huggle/JS would be possible, but IANAProgrammer. Alternatively, a private wiki could be set up? Otherwise, I think an extension is probably going to be necessary.

    This is definitely an ability we would want to restrict to a certain user group, possibly rollback or otherwise. On the point of wording of the link, "oversight" is definitely not the word we'd use, and I'm not sure "abuse" comes across correctly. "Report" seems right, but I'm not sure how to specify that the edit needs to be flagged for copyvio or for underage editing or whatnot as opposed to content disputes and such ("Flows" looks like something that could handle that, but I suspect its a far way off). --Izno (talk) 23:14, 11 January 2012 (UTC)[reply]

    The big problem the proposal is trying to solve is that new(er) users don't know how to report, or might not remember to, or might not be able to remember/find WP:RFO, etc. Limiting it to rollbackers completely defeats the purpose. Originally, I'd suggested we restrict it to autoconfirmed users, but I can't get behind restricting it to the people who need it the least. If it's abused, the abusers can be blocked - and if the abuse is too widespread for the oversight team to handle (which I doubt), we can restrict it then, or just turn it off. causa sui (talk) 23:27, 11 January 2012 (UTC)[reply]
    Are we sure we want newer users able to report something like that? That's seems like a very serious question to me, and I would personally answer in the negative. There's a limit to the amount of information we can ask new(er) people to absorb, and I don't think that this would be an effective little bit for something to do. YMMV.
    As a question, how many false positives does the list get currently? I would expect that number to be zero. How much would it go up by if we're letting the masses have at it? Just some thoughts. --Izno (talk) 00:03, 12 January 2012 (UTC)[reply]
    Yeah, I think this is something we would have to judge after we'd had some experience with it. This would doubtlessly increase the number of false positives, but it may also greatly increase the number of true positives. Only oversighters will know how many false positives are worth one true positive, and we'll only know what the actual results are once we get this implemented. I for one think it's worth a shot. FWIW, I shot an email to AUSC about this, which was then forwarded to oversight-l. Hopefully some oversighters will chime in with their opinions. causa sui (talk) 00:43, 12 January 2012 (UTC)[reply]
  • I don't understand why using Huggle or Twinkle to send e-mail wouldn't work; it's basically just automation of what we're doing manually right now. Additionally, clicking the button could automatically undo the edit, which is a perfectly fine (and I believe normally recommended) temporary action to take (as it hides the information from casual readers while we're waiting for an oversighter to have a look). Additionally, by tying it to automation tools like that, we've got extra leverage for preventing abuse: casual editors don't use those tools, and we can revoke access to anyone who abuses them. WhatamIdoing (talk) 23:18, 11 January 2012 (UTC)[reply]
    Adding this functionality to huggle and twinkle is probably a good, albeit independent, idea. Most people using those tools probably know what oversight is and how to use it, but they also edit very fast and might not report something unless Huggle had a button for it. There's no reason it shouldn't be in Twinkle either, just for convenience sake. But see above for my view on restricting casual editors from access. causa sui (talk) 23:27, 11 January 2012 (UTC)[reply]
  • All this will do is give the oversighters lot more crap to sort though. It would be a good idea, if users and administrators knew what should be oversighted and what shouldn't. But they don't. Prodego talk 06:28, 15 January 2012 (UTC)[reply]
  • I have no objections to tools and scripts being created or enabled to automatically send an email to the Oversight OTRS queue with a link to the problem edit (and, I hope, a summary explaining *why* it is a problem); in fact, I think it's a brilliant idea and fully support it. I do, however, object to an on-wiki queue or list of such links that is visible to anyone other than oversighters. In my opinion, it will create the very Streisand effect that this is intended to reduce. We really want to draw attention from the entire admin corps to edits requiring suppression? I am really, really uncomfortable with that idea. Risker (talk) 06:32, 15 January 2012 (UTC)[reply]
I think the "oversighters/admins" and "queue" part may be inexperience about who should check oversighted material and how it works. (Hint to proposer: not admins). AGF this was attempting to be fair and inclusive in light of little direct experience of oversighting work, and easily fixed in the proposal. FT2 (Talk | email) 07:25, 15 January 2012 (UTC)[reply]
  • In principle this would be nice - a wide range of users (of some kind) have a "report for oversight" button that pops up a warning/confirmation dialog, then if agreed, suppresses (=oversights) the edit and puts it in the usual process for oversighters. Oversighters may leave it oversighted or reinstate. The button would not allow any access to oversight, it just suppresses the item (which vanishes for them as well) and reports it for review.
The problem -- most users don't understand what is oversightable. Even if we tried to say "defamation and personally identifiable info" many users would misconceive the first part, and click the button on contentious but not defamatory posts, or legitimate personal information in articles. We can undo everything but in autoconfirmed hands this is too wide, would get very contentious and very disruptive, be used to play games, and start disputes. Autoconfirmed is no-go.
Such a button could be given to rollbackers/admins, because 1/ they probably have sufficient experience (or enough clue to read the relatively simple manual and understand the button), 2/ likely to "get" not to press it if they don't understand it, and 3/ their tools and trust are specifically granted to cover work such as antivandalism already, which this extends. The bit could be removed if someone insisted on repeatedly misusing it. On that basis it probably works. If not, Risker's idea where it's reported but not auto-suppressed is also workable. FT2 (Talk | email) 07:15, 15 January 2012 (UTC)[reply]
FT2, I do not think you are talking about what is being proposed. There is nothing in the proposal that says that the edit will be suppressed; it says it will be flagged and go into a special queue visible to admins and oversighters. I would absolutely oppose any proposal that gives anyone other than oversighters authority to suppress an edit. It is my personal opinion that revision-deletion is extremely overused already; there is no way I would support expanding the ability to make edits "invisible" any further than it already exists. Risker (talk) 07:48, 15 January 2012 (UTC)[reply]

Article Feedback Tool - additional test deployment

Hey guys,

Just keeping you in the loop; we're going to be testing another change to the Article Feedback Tool on starting today, January 11. So far, we've done a bit of small-scale experimentation with the actual design of the tool, as announced on the blog, the village pump, and on various mailing lists. This has all been on a tiny fraction of articles (~22k total articles, about 0.6% of the English Wikipedia), and a lot of really useful data has been gathered without bothering the vast majority of editors or readers. Ideally, that's what we'd aim for with all tests :).

Even with Wikipedia readership reaching half a billion users per month, the feedback form its current position (at the end of the article) doesn’t see a whole lot of activity. In this test, we’ll be experimenting with a more prominent way to access to tool. When a user loads the page with the test version of the Article Feedback Tool, they will see an “Improve this article” link docked on the bottom right hand corner of the page (please see this for a mockup). Since this link is docked, it will stay with the reader while they’re reading the article. The introduction of this link will undoubtedly increase the amount of feedback. We need to, however, understand how it affects the quality of the feedback. We genuinely don't know what the impact will be, which is why we're doing these tests :). As with the last tests, it'll be on a very small subset of articles and probably won't be noticed by most people.

If you do encounter it, and it does bug you, you can turn it off just by going into Preferences > Appearance > Don't show me the article feedback widget on pages. If you've already ticked this option, the new link shouldn't appear at all; please do let me know if it does. We are working on a way to disable it "in-line" as well so you can simply dismiss the link without going to preferences.

We’ll also be doing some preliminary analysis on whether such a prominent link cannibalizes editing behavior. The team is very aware that the new link may compete with the edit tab and section edit links. Since the test version of the tool is deployed on a limited number of articles, we will only get a rough read on how much, if any, cannibalization takes place. Per our research plan, we’ll continue to monitor the tradeoff between giving feedback and editing.

If any of you have any questions, please don't hesitate to contact me or drop a note on the talkpage.

Thanks! Okeyes (WMF) (talk) 21:25, 11 January 2012 (UTC)[reply]

Feedback Dashboard Deployment, Jan. 11

Hi guys!

Just wanted to let you know that we have deployed a new version of MoodBar and the Feedback Dashboard. This version contains the following changes:

  1. MoodBar feedback posts are now listed within a user's contributions log
  2. We have added a "Top responders" leaderboard to the Dashboard
  3. There is now an "Unanswered" filter for feedback dashboard
  4. Minor feedback dashboard UI changes

We had planned to include technology to detect for concurrent editing of responses, but were forced to pull back on it due to the fact that MediaWiki 1.19 has been 'frozen' and the concurrency code requires changes in MediaWiki core. This feature is important to MoodBar feedback, we are considering migrating this feature into MoodBar extension temporarily then move it to core once 1.19 gets branched.

As always, your thanks should go to Rob Moen and Benny Situ for the coding and to Roan Kattouw for code review. Ian Baker wrote a lot of the concurrency code (not deployed, but soon).

Please direct any questions or comments to Wikipedia:New editor feedback.

Thanks! --Jorm (WMF) (talk) 21:44, 11 January 2012 (UTC)[reply]

Widescreen Margins

I tried searching, but couldn't find an answer to my question. I have a widescreen monitor, and want to adjust my personal CSS accordingly. How do I make the increase the size of the margins to make the site easier to read?

Gwsk55970 (talk) 00:31, 12 January 2012 (UTC)[reply]

Everyone tends to have their own idea on how to accomplish this sort of thing. Here is my personal suggestion, which you can add to Special:MyPage/skin.css:
#bodyContent { max-width: 90%; }  #mw-head { right: 10%; width: 90%; }
Adjust the percentages to suit. The "right" and "width" settings under "mw-head" should add up to 100% for best results. This will probably only work under Vector skin. — This, that, and the other (talk) 06:07, 12 January 2012 (UTC)[reply]
Another possible way:
body { margin:10px 100px 10px 100px !important; }
This creates a buffer around the whole body of the document (page) of 10px at the top, 100px at the right (clockwise) etc. Adding that it is !important may not be required, but wouldn't hurt to add (just in case). fredgandt 12:06, 12 January 2012 (UTC)[reply]

An IPv4 Risk During IPv6 Deployment?

I've been researching the state of IPv6 transition. I think I see a potential problem for WP, and after searching the VP archives I haven't seen it discussed, so I'm bringing it up here.

One of the deployment strategies being recommended is Large Scale NAT (LSN, formerly called Carrier-grade NAT and known as Stateful NAT64 to the IETF). Under this scheme, if a customer of an IPv6-only service provider wishes to access an IPv4-only server, or any server which cannot be reached via an all-IPv6 path, the service routes the connection through a NAT device which translates the IP headers between IPv6 and IPv4. Conceptually, this is similar to what currently happens in the NAT routers used by home or small office networks, except that the protocol header fields are translated as well as the addresses.

The problem I see is in the length of time an IPv4 address gets allocated to the customer's node. At present, most IP addresses are coming from home/small office routers which are normally allocated a WAN-side address by DHCP, and this allocation persists for days. (In fact, if I'm not mistaken many ISPs dedicate these IP addresses to their customers, since there's little opportunity for multiplexing them anyway.) In the LSN scheme, on the other hand, the address is allocated from an ISP's pool dedicated for this purpose, and persists only for the length of the TCP session, after which it is available for reallocation to another customer. Hundreds or thousands of people will be sharing this pool, and if any of them has to go through LSN to get to Wikipedia, they all will.

The implications for WP are that (1) we may see sudden jumps in the number of connections using dynamic IPv4 addresses as such ISPs switch over to IPv6, and (2) these addresses will be shared by huge numbers of people.

And the risk? Imagine the consequences of blocking a vandal at one of these addresses. Now imagine the consequences of chasing him through the pool, or of trying to rangeblock him.

Of course, this will only be a problem for providers that use LSN (dual-stack providers, like Comcast, don't need it) and only if they don't have a good all-IPv6 path to Wikipedia. It may also be possible to "tunnel" through IPv4 parts of the path; I'm fuzzy on that aspect. But if not, can we quantify this risk? How can we mitigate it? Unconventional (talk) 07:33, 12 January 2012 (UTC)[reply]

There's no doubt IPv6 will be a huge challenge for the Wikipedia community. As you mention, IPv6 addresses are vastly more dynamic than IPv4 addresses (even without LSN, I believe ISPs are being allocated huge address pools for allocation as dynamic IPs). Not only that, when Wikimedia itself switches to IPv6 (as it inevitably will), the entire namespace of IPv4 user talk pages will become obsolete on all 1000 or so Wikimedia projects, and administrators will have to learn how to use IPv6 range notation. The devs will have to weigh up whether IPv6 addresses are even worth using as a means of tracking anonymous edits (given how long they are, and how often most will change), although I don't see any obvious alternatives.
As for the more immediate problem this poses, WP:RBI is designed for this sort of situation. It requires vastly greater resources than "(range-)block and be done with it", but will probably become increasingly necessary, given the changes taking place in global networking. — This, that, and the other (talk) 09:54, 12 January 2012 (UTC)[reply]
Just to clarify, I'm talking about hundreds or thousands of people (the entire customer base of certain ISPs) being crammed into relatively small blocks of IPv4 addresses (small because they're in short supply and highly reusable) — that is, a high ratio of anons to IPv4 addresses seen. No matter how dynamic IPv6 addresses may be, the corresponding ratio will be infinitesimal, so not the same problem — although it might cause the opposite problem, namely, that an IP block is completely ineffectual. (If that happens, we may as well forget about IP blocking at all, at least until the transition is over and end-to-end connectivity becomes the rule.) -- Unconventional (talk) 14:09, 12 January 2012 (UTC)[reply]
I think the worst case scenario is a wider use of semi-protection. Of course, if a vandal is determined enough we could end up protecting half the site before they get bored and leave... I'm also a little worried about autoblocks, which will start to do a lot more collateral damage. --NYKevin @900, i.e. 20:35, 12 January 2012 (UTC)[reply]
See my section below on IPv6.Jasper Deng (talk) 18:11, 13 January 2012 (UTC)[reply]
Rangeblocking would still be possible, in my opinion. As for talk pages, I've proposed giving each subnet an individual talk page. The only real static parts of an IPv6 address are its routing prefix.Jasper Deng (talk) 06:22, 14 January 2012 (UTC)[reply]

SVG translation

Hey all. I have some news that all of you familiar with SVGs will be interested in. Recently, I have worked on developing two related things:

  • A "lang=xx" syntax for SVG embeds (example: [[File:Example.svg|thumb|lang=de]]). This would be passed to the renderer (in our case rsvg), and would result in the SVG's systemLanguage property being set to that code. systemLanguage is used for conditional rendering; a good example of its application for translating SVG files can be found here. Thus translations are stored within the SVG, but not in a hacky way-the spec was designed with this is mind. We already generate thumbs by size and (in the case of TIFFs and DjVu files) by page number, so this would be a minor addition in that regard.
  • A special page to allow for the easy translation of files within this system. An example of what it looks like at present can be found at File:TranslateSvg.ogv (note that the misalignment of the text is a problem with the underlying SVG and not with the translation).

Taken together, these would represent a massive improvement on our current system for SVG translation, which involves uploading a new file in each language; moving a graphic to improve the SVG then requires numerous different edits and uploads (one for each language). I welcome your comments (both technical and non-technical) - #2 in particular is still in the "hacky early prototype" stage. My current list of things to look into: default translations; different fonts for different character sets; whether the system could cope with supermassive SVGs. Regards, - Jarry1250 [Deliberation needed] 11:11, 12 January 2012 (UTC)[reply]

Weird weird template problem

My demo page for this is at User:Masem/vgtest.

In the vg infobox, we have a collapsable list template for the release dates. This appears to have recently broke (one member identified it working right in November, so we have a time frame), in that in for articles that have this (see Blaster Master for the staring example) dates will "fall out" of the collapsed list. This I can confirm looking at the HTML source generated from WP: the list is not part of the collapsable element div.

The above page is my attempt to distill down to the basic problem. There are five cases:

  • First, is basically what we use. Replicates the problem as described.
  • Second, replace the call of the {{video game release}} template with the actual HTML code generated (to my eyes, it appears completely balanced/proper HTML). The show/hide buttons no longer work, and looking for the code that should be there, shows it absent from the HTML.
  • Third, remove the CSS on the ul element generated by the above step: same problem as the second test
  • Fourth, remove the anchor from the linked element (but leaving the ul CSS code): same problem as second test
  • Fifth, remove both ul CSS and the anchor. Works as expected

I have no idea what's going on here. To confound that, when I tried debugging with Special:ExpandTemplates, the first case works as expected there; the 2nd, 3rd, and 4th case still fail, and the 5th case is fine.

Any idea what's going on here? --MASEM (t) 14:52, 12 January 2012 (UTC)[reply]

(ec)And I just double checked, pulling the {{collapsible list}} calls out from the infobox, and get the same behavior on the page and at ExpandTemplates as described as if they were in the infobox. So it's nothing from the complex infobox template interfering with it. --MASEM (t) 15:09, 12 January 2012 (UTC)[reply]
I see that the <a>...</a> tag is being used in some examples. The MediaWiki parser will strip this straight away. --Redrose64 (talk) 15:07, 12 January 2012 (UTC)[reply]
Ok, that's understandable (for security reasons), but there is still code outside the A tag (examples 2 and 3) that should be there that isn't in the HTML source, and this doesn't explain example 4 either where there's no A tag at all. --MASEM (t) 15:09, 12 January 2012 (UTC)[reply]
I think the behavior you see with Special:ExpandTemplates may be caused by HTML Tidy not being run on ExpandTemplates output. I notice that Template:Collapsible list opens two divs and closes only one; I wonder whether that might cause the HTML to become messed up, leading Tidy to attempt to correct it. Ucucha (talk) 15:20, 12 January 2012 (UTC)[reply]
Actually, the inner diff is closed. Ucucha (talk) 15:21, 12 January 2012 (UTC)[reply]
Yea, both divs are closed on collapsible. As well as ul and li elements. --MASEM (t) 15:23, 12 January 2012 (UTC)[reply]
It turns out it was Template:Video game release, which was emitting a bare </li>. Fixed. Ucucha (talk) 15:28, 12 January 2012 (UTC)[reply]
Yea, that got it, though the bare HTML version examples above are giving weird results still (not that I care specifically for this format, just want to make sure that's why). --MASEM (t) 15:31, 12 January 2012 (UTC)[reply]
That's because you have an = in the value of the unnamed parameter. You can fix it either by putting |1= or by replacing the bare equals sign with {{=}}. Ucucha (talk) 15:37, 12 January 2012 (UTC)[reply]
Also {{{|=}}} works, and doesn't add to template calls like {{=}}fredgandt 16:01, 12 January 2012 (UTC)[reply]
  • Passing "=" in unnamed parameters: I changed User:Masem/vgtest and verified Example 2 will work okay now with "style{{=}}" in the unnamed parameter. As noted above, it is safer to explicitly number the first unnamed parameter as "|1=NES..." rather than "|NES..." to allow an equal-sign "=" inside the parameter for the style=xx directive. -Wikid77 16:57, 12 January 2012 (UTC)[reply]
  • Keep it simple for WP:ACCESS: Although the question was about the CSS-styled show/hide collapsible sections, I want to remind people to avoid complex infoboxes, and just link to "(see: [[#Releases|Releases]])" (as a lower section of the article) with header "Releases" where each release, plus date, should be listed for WP:Accessibility of sight-impaired users, and to improve search-lookup where Google or Bing or wikisearch might not find the release-date info inside a collapsible section. I don't want to rant about these search/sight limitations, but just a reminder. -Wikid77 16:57, 12 January 2012 (UTC)[reply]
    • We're careful on that. The bulk of release date info borders on trivial but necessary data ("ok, it was released for the 360 in the US on this date, but on the 360 for europe 2 days later, and on the ps3 in the US a week later, and..."); if its simple, we don't recommend the collapsed list, and regardless, the general release period is to be repeated in the lead. --MASEM (t) 17:03, 12 January 2012 (UTC)[reply]

Fastest route to page move vandalism?

Suppose I'm an experienced troll, looking to run up a new sock for some page-move vandalism. This account: GermanSpeaker (talk · contribs) seems to have done it within a day. The edits, such as they were, consisted almost entirely of adding a negative "not" to sentences (so either manual, or a grammatically skilled 'bot); they were reverted and warned immediately.

I'm unfamiliar with the rights needed to permit page moves - but this one looks to have been premature. As we are AIUI, requiring an edit count before allowing this, does this mean that our count and account age limits are set too low? Or if this was a "trusted" account, by edit count, can we improve our definition of "edit" so as to exclude those with immediate reversio, such as here (the edit counter seems to do this much).

The fall out from page moves are more difficult to reverse than simple edit vandalism. Particularly in this case where the article talk page and associated redirects were then deleted as G8 too. I bet this particular vandal is laughing at the trouble he has caused. Andy Dingley (talk) 15:38, 12 January 2012 (UTC)[reply]

Pages that are not move-protected merely need either the autoconfirmed right or the confirmed right; the former is automatic based on number of edits and a timespan, the latter merely requires you to convince an admin that you can't wait for four days. --Redrose64 (talk) 16:15, 12 January 2012 (UTC)[reply]
Further: although the user made their first edit yesterday, the account was registered three months ago. By racking up four edits yesterday (one of which has been deleted), and a further eleven today, they gained the autoconfirmed right to allow a page move. --Redrose64 (talk) 16:24, 12 January 2012 (UTC)[reply]
  • Registered vandals are very rare: While any sneaky vandalism can be frustrating, the most-common vandalism is by IP-address editors (which unfairly taints all IPs as suspicious). So worrying about the registered-username vandals is like complaining about a leaking bathtub on the R.M.S. Titanic (which sank 100 years ago this April). The best clue with registered users has been the red-linked usernames (again another possible stereotype), so watch the contribs of any red-linked username. The bigger danger from the registered users is "registered advocates" who POV-push their agenda in numerous articles or talk-pages. Then, possible registered trolls have been questioned about making irritating comments to stir the drama when they get bored of simply writing an encyclopedia (yawn). So the people to beware are those with hundreds of edits which slant text or drive good editors to seek sanity elsewhere. If you see people get frustrated, then offer some support along the way. -Wikid77 17:43, 12 January 2012 (UTC)[reply]
  • They now appear to be IP-socking to repeat just the same edits 188.23.190.15 (talk · contribs). Note also the names "GermanSpeaker" and an Austrian ISP. If anyone here is an admin, feel free... Andy Dingley (talk) 19:41, 12 January 2012 (UTC)[reply]

Help with date format parameter in a ref within a template

Resolved
 – Redrose64 (talk) 20:49, 12 January 2012 (UTC)[reply]

Hello VP(t).

Could a template/parsing specialist help me with a problem that I've described on my talkpage?

Thanks

HandsomeFella (talk) 18:56, 12 January 2012 (UTC)[reply]

I fixed it using a parser function. --Redrose64 (talk) 20:49, 12 January 2012 (UTC)[reply]

Alignment of infobox labels

Resolved
 – WOSlinker (talk) 21:00, 14 January 2012 (UTC)[reply]
Unresolved
 – Fix reverted by EdokterRichardguk (talk) 03:10, 15 January 2012 (UTC)[reply]
Resolved
 – By adding a load in inline style to Infobox officeholder/Office and Infobox officeholder/Personal data -- WOSlinker (talk) 10:11, 15 January 2012 (UTC)[reply]

I've recently switched from Windows XP/IE7 to Windows 7/IE9. Since the switch, I've noticed that the labels in many infoboxes (e.g. the instance of {{Infobox officeholder}} in Abraham Lincoln) are centred in the left-hand column of the infobox, rather than being left-aligned as they were previously. Questions:

  • Does everyone else see the same thing, or am I just "special"?
  • Has it always been like this, and I'm only just seeing it now due to my change of OS/browser? or
  • Has there been some recent change to some underlying template which has caused this?

Thanks. DH85868993 (talk) 02:51, 13 January 2012 (UTC)[reply]

Yes they are centered in Vista/IE9, but the are still left-aligned in FF 9.0.1. This is probably a browser specific issue with IE. Ruslik_Zero 17:16, 14 January 2012 (UTC)[reply]
Double check compatibility mode would be my first guess. --Izno (talk) 20:24, 14 January 2012 (UTC)[reply]
I've added some extra code in Mediawiki:Common.css to make the alignment work in IE9. Not sure why it wasn't working before but it is now. (May need to shift+resfesh once to see). -- WOSlinker (talk) 20:58, 14 January 2012 (UTC)[reply]
Not fond of the 'solution'; the text is left-aligned inline, just to solve this problem in IE8(!). Oh well... It's time to restructure infobox anyway, as I have been meaning to do for years now. Edokter (talk) — 21:56, 14 January 2012 (UTC)[reply]
Thanks, all. DH85868993 (talk) 23:15, 14 January 2012 (UTC)[reply]
This seems to have affected {{Infobox country}}. Reverting for now and have it fixed with the next infobox update. Edokter (talk) — 01:43, 15 January 2012 (UTC)[reply]

See also previous discussion at MediaWiki talk:Common.css/Archive 12#Table header inheritance in IE8, where AoV² proposed:

th { font-weight:bold; text-align:left; }
tr:first-child th, th:only-child { text-align:center; }

Richardguk (talk) 03:10, 15 January 2012 (UTC)[reply]

Well, the problem seems to be that IE doesn't have TH or TD elements inherit the align:left from the table, but applying align:left to the TH directly in CSS overrides the HTML attribute align="center" used in the infobox. A good fix would be to adjust the infobox to use inline CSS instead of the HTML attribute, or define a class to indicate a row or cell that should be centered and use that. But in the mean time, would browsers support something like this?
.infobox th { text-align:left; }
.infobox th[align=center] { text-align:center; }
(and the same for align="right", if anything uses that). Anomie 03:32, 15 January 2012 (UTC)[reply]
Even if they did, a recent revision to mediawiki (not sure which) has made it so html presentational attributes render to the user as css inline styling. Not sure if that applies to "align" as I can't find the bug. --Izno (talk) 03:56, 15 January 2012 (UTC)[reply]
Interesting, and does apply to "align", but not live here yet. Seems to have been added in r94465 and enabled in MediaWiki by default in r98053. Also, according to the release notes, it depends on $wgHtml5 being enabled. Anomie 04:09, 15 January 2012 (UTC)[reply]
I've fixed the specific issue with Infobox Officeholder by adding a load of inline style. Infobox country has the same issue though with everything centered. -- WOSlinker (talk) 10:15, 15 January 2012 (UTC)[reply]
All styling will have to be moved to Common.css eventually. Edokter (talk) — 11:05, 15 January 2012 (UTC)[reply]

IPv6 complications

Contrary to what the page at Wikitech (search for "IPv6 deployment" on wikitech.wikimedia.org) says, we clearly are not ready for IPv6 enabling, in my opinion. My idea (talk page) shows that it'll be a lot of trouble. However, it'll at the same time solve a lot of our problems. Comments on the idea's talk page are welcome.Jasper Deng (talk) 04:50, 13 January 2012 (UTC)[reply]

Could you insert the issues to bugzilla or here (no big essay just a list of real problems we need to deal with, prepare sw for) please Thank you Petrb (talk) 14:41, 13 January 2012 (UTC)[reply]
I don't know how to use Bugzilla; my particular issues are with CheckUser. See the bottom of the essay (User:Jasper Deng/IPv6#Unresolved issues).Jasper Deng (talk) 18:08, 13 January 2012 (UTC)[reply]

Wikitable sortable with tnavbar-header

Hello.

There seems to be a problem with the new sort ascending/descending design for wikitable sortable.

If you have a template with such a table within it, and place a tnavbar-header at the top in order to make view/discuss/edit of the template immediately available in articles transcluding the template, it does not work. When clicking any of the links, it only performs the sort.

See for example this template: Template:2008 Summer Olympics United States men's volleyball team roster.

{{2008 Summer Olympics United States men's volleyball team roster}}

Right-clicking works, however.

HandsomeFella (talk) 14:05, 13 January 2012 (UTC)[reply]

I have never seen this setup before... Navbar was never designed for stand-alone tables, but for navboxes and infoboxes. Edokter (talk) — 15:48, 13 January 2012 (UTC)[reply]
It worked before the change of the design of wikitable sortable. And the tnavbar-header template has a parameter that allows for a (column) heading. HandsomeFella (talk) 18:16, 13 January 2012 (UTC)[reply]
The name parameter can provide a caption on any block level element, including table headers and cells. I have just never seen one in combination with a sortable table before. Sortable headers look for click events on the entire header, capturing all clicks. That means it is incompatible with navbar. The only solution is to move it to a non-sortable cell, or outside the table. Edokter (talk) — 19:11, 13 January 2012 (UTC)[reply]
Try adding a caption row, and putting the v-d-e links in there. Caption rows are typically placed between the table start {| and the header row, thus:
Name Date of birth Height Weight Spike Block 2008 club
--Redrose64 (talk) 20:25, 13 January 2012 (UTC)[reply]
That doesn't quite work either. Navbar is a block element; the table caption is not, so Tidy ends up kicking it out of the table. Edokter (talk) — 20:32, 13 January 2012 (UTC)[reply]
Thanks for the tip, but I'm contemplating using Template:View instead, putting it to the right of the "presentation sentence", like this:

The following is the American roster in the men's volleyball tournament of the 2008 Summer Olympics.[1][2]

Name Date of birth Height Weight Spike Block 2008 club

— Preceding unsigned comment added by HandsomeFella (talkcontribs) 20:47, 13 January 2012 (UTC)[reply]

 Done Changed the template(s). HandsomeFella (talk) 16:00, 14 January 2012 (UTC)[reply]

Problems with display of WP

Past few days, Chrome, Mac OS Lion, there have been increasing problems. Level 2 headings not bolded and small font-size. Sometimes thumbnails are tiny. Some buttons tiny. I've followed the instructions for clearing my browsing data. Still the same. Tony (talk) 10:05, 14 January 2012 (UTC)[reply]

See one section below. Edokter (talk) — 17:09, 14 January 2012 (UTC)[reply]

Problem with font size on WP

Today I am finding the font size of WP pages is much larger than for other pages from other sites. Although I can fix this problem by adjusting the font size on Firefox 9.0.1 using Tools/Options/Content, that is pretty inconvenient when you switch between sites. I've tried clearing the browser cache, but that changed nothing. What is my problem? Brews ohare (talk) 16:59, 14 January 2012 (UTC)[reply]

You have zoomed the page while on Wikipedia. Firefox remebers this setting per site. Just press CTRL-0 (zero), or go to View > Zoom > Reset. Edokter (talk) — 17:06, 14 January 2012 (UTC)[reply]
Just encountered the same problem and I am certain I didn't zoom the page whilst being on Wikipedia. However, your advice (CTRL-0 (zero)) worked. Thanks. Cheers, --Ekki01 (talk) 17:47, 14 January 2012 (UTC)[reply]
Are you sure you didn't accidentally touch the scroll-wheel while honding down CTRL? Happens all the time... Edokter (talk) — 17:57, 14 January 2012 (UTC)[reply]

I am pretty sure. But anyway, if it happens again I know how to fix it. --Ekki01 (talk) 18:03, 14 January 2012 (UTC)[reply]

Hey, thank you. CTRL-0 fixed the problem. I had no idea what had happened. Brews ohare (talk) 18:05, 14 January 2012 (UTC)[reply]
There are several ways of zooming in or out in Firefox - View menu → Zoom is one; Ctrl & + or Ctrl & - is another; rolling the mouse wheel when holding Ctrl is a third. There may be more tucked away. Ctrl & 0 always restores 100% zoom. --Redrose64 (talk) 19:29, 14 January 2012 (UTC)[reply]

Log in at English Wikipedia only

I can't log in locally! Why not? How can I do it?--89.110.14.211 (talk) 21:25, 14 January 2012 (UTC)[reply]

Are you saying that you can log in elsewhere? If so, where, and under what user name? --Redrose64 (talk) 21:46, 14 January 2012 (UTC)[reply]
I can log in at all Wikimedia projects together, but I can't log in at one of them only, being logged out at others, because there's not a box for it. Earlier, there were 2 boxes: the 1st was "Remember me (up to 30 days)", and the 2nd was for logging in locally. But now I can see the 1st one only.
I think, my username doesn't matter. Sorry for bad English.--89.110.14.211 (talk) 22:14, 14 January 2012 (UTC)[reply]
If I remember correctly, the checkbox was titled something like "Log me in on all WikiMedia projects"; there certainly isn't anything resembling that any more. It seems as if Special:UserLogin has been altered. I'm afraid that I can't find how that page is built up, nor where the components are. All I can tell is that the components have names like customusertemplate-ACP2-login. --Redrose64 (talk) 22:59, 14 January 2012 (UTC)[reply]
Thank you! I really did talk about "Log me in on all WikiMedia projects" checkbox on Special:UserLogin. My English is not perfect:)
I want to know, is that a temporary bug, or a purposeful alternation? And if that's a purposeful alternation, could I see the relevant discussion on Meta?--89.110.14.211 (talk) 00:29, 15 January 2012 (UTC)[reply]

Article Feedback tool is displayed when prompted to confirm a purge.

The Article Feedback tool is displayed when prompted to confirm a purge. I believe this is a bad idea, and furthermore, a minor bug that should be fixed, so it only is shown when a user is viewing the page itself. Any comments?  Hazard-SJ  ㋡  21:29, 14 January 2012 (UTC)[reply]


Good Articles

How are good articles linked to the language bar at the left. I have noticed that Macbeth is a good article in Latin, but it does not appear to show this on the link from the english page. Is this automated or can I change it?--Gilderien Talk|Contribs 21:31, 14 January 2012 (UTC) (edit conflict twice)[reply]

This isn't automated. You would do it by adding {{Link GA|la}} just above the interwiki links at the foot of the article. -- John of Reading (talk) 21:39, 14 January 2012 (UTC)[reply]
(edit conflict) It's the presence of a {{link GA}} or {{link FA}}, so if an article is a Good Article on the Latin Wikipedia, you'd expect to find a {{link GA|la}} on the English page. Some of the bots that maintain the interlanguage links also maintain these templates. If you are adding them manually, they should go after the categories but before the ILLs. --Redrose64 (talk) 21:44, 14 January 2012 (UTC)[reply]
Thanks, will be doing in about ten seconds.--Gilderien Talk|Contribs 21:45, 14 January 2012 (UTC)[reply]

Recursive category search by title

I know I've seen this before, on toolserver or elsewhere, but I can't find it now. Say I want to search category "Physics" and it subcats, x levels deep (realizing that the recursion has to stop somewhere because categories aren't that pristine), for articles containing the word "theory". Can anyone point me in the right direction? Thanks, Riggr Mortis (talk) 21:36, 14 January 2012 (UTC)[reply]

Edit summary section link character

Resolved
 – Reboot fixed the localised issue.

The edit summary section link character seems to have been changed from the old arrow (→) to something that isn't rendering for me. I'm not overly concerned and know why it isn't rendering, but wonder if it might be better to choose a character that is more likely to render for all users (if it doesn't render for me, it follows that other users may see the same little box). fredgandt 21:50, 14 January 2012 (UTC)[reply]

Chrome? Restart it. Other browser? Restart it also. Not helping? Reboot. (The arrows are quite standard characters that should render for anyone.) Edokter (talk) — 22:00, 14 January 2012 (UTC)[reply]
Not been changed? Just my Chromey having a bad day? Ah. Thanks Efredgandt 22:03, 14 January 2012 (UTC)[reply]
Mhmm. Reboot while walking the dog fixed it. Computers eh!? Sassafrassarassa... fredgandt 23:59, 14 January 2012 (UTC)[reply]
Chrome has this sometimes. Its unicode component is slightly wonky. Edokter (talk) — 01:46, 15 January 2012 (UTC)[reply]
Well this is only the second issue I've had with Chrome, so I'm nowhere near complaining. The other issue is that checkboxes vanish occasionally (the fix for which is to call up the same page using IE, toggle between the browsers, then close IE), but that only happens twice a year anyway. It's going to take more than an arrow not rendering to put me off.  fredgandt 02:11, 15 January 2012 (UTC)[reply]

Sortable table with header spanning several rows

On Global Hunger Index, the ranking table is sortable but the arrows on the header line do not sort the corresponding table. It seems to be because of the first two header cells spanning two lines and shifting the column index. Something like :

Column 1 Other columns
Column 2 Column 3 Column 4
1 B 4 11
2 C 9 12
3 A 2 21

The arrows on column 2 sort according to the values of column 1, the arrows on column 3 sort according to column 2, and so on.

Is there an elegant solution or should the table layout be modified ? Koxinga (talk) 06:35, 15 January 2012 (UTC)[reply]

I think you have to modify the layout. This uses border coloring to effectively hide the border above "Column 1":
Other columns
Column 1 Column 2 Column 3 Column 4
1 B 4 11
2 C 9 12
3 A 2 21
PrimeHunter (talk) 12:52, 15 January 2012 (UTC)[reply]
  1. ^ 2008 Official Results Part Two: Hockey – Wrestling, LA84 Foundation.
  2. ^ "USA indoor team announced". Nbcolympics.com. 15 July 2008. Retrieved 13 June 2009. {{cite web}}: Check date values in: |accessdate= and |date= (help)