Wikipedia:Village pump (technical): Difference between revisions

Help

From Wikipedia, the free encyclopedia

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 21:05, 5 March 2014

Table of contents
First discussion
End of page
New post

Shortcuts

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security

wikimedia.org or filed under the "Security" product in Bugzilla.

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

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 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

Searchbox is broken & Search is overloaded

When I enter anything into the Searchbox, the searchpage comes up instead of bringing me to the page in question, this happens whether I enter a page name, a redirect name, or a shortcut name (yes, I have spelled it properly. It's also become case sensitive, saying the page I entered doesn't exist if I use a different case (say all lower case when the shortcut is all upcaps) - 76.65.129.222 (talk) 07:29, 14 February 2014 (UTC)[reply]

Also, I suspect as a result of this bug ("feature") it appears that the search engine is now extremely bogged down. In the wee hours of the day, searchbox keeps failing by saying it is overloaded. -- 76.65.129.222 (talk) 07:37, 14 February 2014 (UTC)[reply]

Exact error message welcome, plus browser information (for the first part). --AKlapper (WMF) (talk) 13:46, 14 February 2014 (UTC)[reply]

(My IP has rolled over). Today, it doesn't seem overloaded, but there's a persistent error. If I enter WP:USA into the searchbox, it will return:

An error has occurred while searching: The search backend returned an error:

And anything I type into the searchbox whatsoever always goes to the searchpage. If I enter WP:VPT into the searchbox I get

There is a page named "Wikipedia:VPT" on Wikipedia

with a list of results

I am using Firefox 27 (versions newer than this version appear to be incompatible with other software I have, but this behaviour of Wikipedia did not occur before I posted this message, it worked fine in FF27 previoiusly) -- 70.50.151.11 (talk) 23:34, 14 February 2014 (UTC)[reply]

This is also happening with WaterFox 18 and PaleMoon 24 -- 70.50.151.11 (talk) 08:51, 15 February 2014 (UTC)[reply]

Is this some issue that Wikipedia is now requiring JavaScript? (it does not work even with JS on) -- 70.50.151.11 (talk) 05:07, 20 February 2014 (UTC)[reply]

The 'action' of search without Javascript is always full search yes. If it were 'go', then it would not be possible to reach the 'full text' search. —TheDJ (talk • contribs) 12:17, 20 February 2014 (UTC)[reply]

Why? It was previously possible - if an article exactly matched, then you were taken there, otherwise you were taken to the search page. If you wanted full text search where an article matched, you clicked on the magnifying glass, then searched. 192.12.81.1 (talk) 15:32, 20 February 2014 (UTC)[reply]

Also, typing a tilde ('~') in front of a search forces a full text search instead of jumping straight to an article title. (I normally search from the browser address bar, where this function still works.) – PartTimeGnome (talk | contribs) 22:23, 20 February 2014 (UTC)[reply]

You are incorrect. The action of "search" was to "go" to the page you typed in (without JS on). The change is very recent, in worked the day before I filed this, and the day I filed this, it broke. I suspect the search engine overload is caused by this change. A prominent (search for other uses) should instead be included as a top link (similar in appearance to what you get when you follow a redirect) to lower the server loading, so that when you go somewhere you're not wanting, you get to go to the searchpage that way. The overloaded searchpage is annoying as well, having to reload search several times to get results is not a good thing. If the searchbox were restored to just "go" to the page you want, it would take up less server resources than listing all the possible pages you might want.

Also, even with JavaScript on, it isn't working. -- 70.50.151.11 (talk) 01:50, 21 February 2014 (UTC)[reply]

Article wizard also broken

Resolved

Any idea what change from Wikipedia brought this about? I notice that the styling for Wikipedia:Article_wizard is also broken across multiple browsers. The buttons for "Write an article now (for new users)", "Request an article be written on a topic", "Create something else (for advanced users)" are invisible. I assume this has occurred at the same time the searchbox broke. -- 70.50.151.11 (talk) 11:39, 18 February 2014 (UTC)[reply]

Indeed, I see the same thing on the article wizard. The links are using white-on-white text, though I can't see where that text colour is being set. Since I know where to click, I can still click the links though they aren't visible. You can reveal the links by pressing Ctrl+A to highlight the whole page. I've linked to this discussion from the article wizard's talk page. – PartTimeGnome (talk | contribs) 23:00, 18 February 2014 (UTC)[reply]

Any solution should work with JavsScript off. I don't see why embedded styling into the template wouldn't work... -- 70.50.151.11 (talk) 06:43, 19 February 2014 (UTC)[reply]

I'm guessing it is something to do with MediaWiki talk:Common.js#Fixing Template:clickable button, although the buttons show up fine for me (even when logged out). I made some edits (and some null edits) to a few pages, can you check if it is still an issue? — {{U|Technical 13}} ^{(t • e • c)} 23:15, 18 February 2014 (UTC)[reply]

@PartTimeGnome: What browser/OS are you using? When I test Article Wizard on my machine (Firefox and Chrome on OSX) as well as Firefox and IE7 on Windows, I still see the full blue buttons. Steven Walling (WMF) • talk 00:06, 19 February 2014 (UTC)[reply]

Opera 12.16 on openSUSE Linux. Others below have now identified that the button styling relied on JavaScript, which I have also disabled. – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)[reply]

I confirm this, Firefox 23.0.1, Win 7, javascript off. Enabling scripts from wikimedia.org makes the button background appear. 192.12.81.1 (talk) 15:07, 19 February 2014 (UTC)[reply]

@Edokter, Anomie, S Page (WMF), Kaldari, Sage Ross (WMF), Helder.wiki, and Superm401: As participants in the linked discussion, do you have any ideas here? — {{U|Technical 13}} ^{(t • e • c)} 15:37, 19 February 2014 (UTC)[reply]

JavaScript is required, otherwise, you end up with a white 'button' (just a span really) with white text. The better course is to use {{clickable button 2}} directly instead of {{blue button}}, as it constructs the link differetly and handles the font color better (as seen above). — Edokter (talk) — 15:57, 19 February 2014 (UTC)[reply]

Yes, if JS is turned off that's your issue, since we're conditionally loading the style with JavaScript. There are alternatives if that's causing many people problems, so we can find a different solution. Steven Walling (WMF) • talk 22:09, 19 February 2014 (UTC)[reply]

Yes, alternatives are needed. User experience should degrade gracefully if JavaScript is disabled. White-on-white text is not graceful... (If it's essential for performance reasons to reduce the CSS that is sent to browsers, perhaps the parser could detect markup in the pages that indicates additional resource loader modules to load with the page?) – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)[reply]

@Edokter, Technical 13, and Steven (WMF):, for now I suggest rolling back Steven's change to {{blue button}}, since it doesn't play well without JavaScript (without JS you get the white coloring without the blue background). That will fix the immediate issue. However, I agree that {{clickable button 2}} works better. With that, the button is on the inside, which means it overrides the link's coloring. No explicit #FFF is needed. Without JavaScript, it simply looks like a link. So if that's okay (link appearance with no JS), Article Wizard can use {{clickable button 2}}. See my test version of {{Article wizard/button wizard}} at [1].

{{blue button}} could also be rewritten to behave like {{clickable button 2}}, or even call it when a link is specified. Superm401 - Talk 22:22, 19 February 2014 (UTC)[reply]

Done self-reverted for now. Steven Walling (WMF) • talk 22:26, 19 February 2014 (UTC)[reply]

I'm not sure if it was T13's changes or Steven's revert, but the buttons now appear fine for me, both logged in and logged out. – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)[reply]

Search algorithm and search engine issues

I'll note that the search algorithm seems faulty. franklin underwood does not show Franklin Underwood as a result in the first page of results. However, previously, the go to page function that used to work would directly bring up the "Franklin Underwood" article, now you'd have to click past the first page of results to even know it exists (and would probably assume that it doesn't exist, since it didn't show up at the top of the results) ; the WPUSA error can be seen with [2] -- 70.50.151.11 (talk) 03:49, 21 February 2014 (UTC)[reply]

Franklin Underwood was created yesterday and has not been indexed by the search engine yet. See Help:Searching#Delay in updating the search index. The go to page function doesn't use the search index. It works for me and goes to Franklin Underwood when I enter franklin underwood in the search box at the top right below Log in/out. The second search box at Special:Search has different functionality. It adds &fulltext=Search to the url. This prevents the go function and is intentional. Which search box are you using? The top right box has a drop-down box saying "containing..." (at least in my browser). If that is activated then &fulltext=1 is added and this also disables the go function. I don't know whether there is any difference between &fulltext=Search and &fulltext=1. It appears &fulltext=x for almost any x (other than 0) disables go. PrimeHunter (talk) 04:25, 21 February 2014 (UTC)[reply]

The WP:USA error happens when I enter it into the searchbox (the box thing underneath log-in) and it happens if I use the search page. The resultant result page is the same regardless of whether I access the search page or use the search box. Indeed, for the last week, anything entered into the searchbox underneath "log-in" is exactly the same as using the search page. I assume a Wikipedia update changed the behaviour of the searchbox to be identical to the searchpage. -- 70.50.151.11 (talk) 07:32, 21 February 2014 (UTC)[reply]

PrimeHunter, re-read some of the earlier discussion above. Like me, 70.50 has JavaScript disabled in their browser, so they do not see the "containing..." pop-up. Previously, searching with the box under "Log in" with JS disabled could immediately go to an article with a matching title. 70.50 is reporting that this recently changed such that a search is always a full text search if JS is disabled, and there is no option for the normal "go" behaviour. This is using the default Vector skin. I'm using Monobook where the search still defaults to "go" as previously. – PartTimeGnome (talk | contribs) 17:45, 22 February 2014 (UTC)[reply]

OK, I also get no "go" in Firefox and Vector when JavaScript is disabled. I don't know how it has behaved previously. There is apparently disagreement about that so maybe it depended on something else. Franklin Underwood has now been indexed by search so the article is the first search result on franklin underwood. The below search box has a Go button which works for me with JavaScript disabled, but that isn't very helpful when the normal Vector search box works differently. PrimeHunter (talk) 19:38, 22 February 2014 (UTC)[reply]

Yup, that's more like the Monobook search box, which also has separate "Go" and "Search" buttons. – PartTimeGnome (talk | contribs) 20:14, 22 February 2014 (UTC)[reply]

To clear up some confusion:

Behavior of the Vector search box is not related to the behavior of the search backend
Behavior of the Vector search box is also not related to the behavior of the search box above, nor any other search box anywhere else on any page

Vector's search box uses 'Go' mode by default when the user has JavaScript enabled and a browser capable of rendering the search suggestions; otherwise it uses the fulltext search mode. This is intended and a caused by a recent change: https://gerrit.wikimedia.org/r/#/c/82100/ – previously it always used 'Go' mode.

This behavior was discussed fervently on the changeset I linked above; in the end I was convinced that this is a better solution. The change was also announced in the second-to-last (I think) tech news posted here. If you disagree, please file a bug. Matma Rex talk 20:22, 22 February 2014 (UTC)[reply]

Wikipedia:Village pump (technical)/Archive 123#Tech News: 2014-07 says: "The Vector search box was changed to fix old display and accessibility issues; for example, you can now use full-text search even if you have disabled JavaScript." To me, that formulation sounds like it was about giving a search choice like if you have JavaScript, and not about replacing the existing 'Go' mode. PrimeHunter (talk) 21:45, 22 February 2014 (UTC)[reply]

That's a horrid change. It's probably contributing to overloading the search engine as well. Instead the change should have just added a line like when you follow a redirect and it says redirected from X, to have an option of a fulltext search. Or you could add separate search and go buttons to Vector. What's more it doesn't work per my WP:USA search example that breaks the search engine. -- 70.50.151.11 (talk) 08:10, 23 February 2014 (UTC)[reply]

I also think it's an annoying change, but many users didn't know how to make a full-text search when there is a pagename match. The current WP:USA error is general for full-text searches. You encounter the error due to the change, but it isn't caused by the change. With JavaScript enabled I get "An error has occurred while searching: The search backend returned an error:", whether I select "containing..." or use Special:Search or click "Search" in the above box, or click https://en.wikipedia.org/w/index.php?title=Special%3A&search=WP%3AUSA&fulltext=Search. It also happens for all other tested namespace:USA searches, for example talk:USA, portal:USA, category:USA. In past periods I have gotten that error message for a lot of searches, but it varies. PrimeHunter (talk) 14:04, 23 February 2014 (UTC)[reply]

Except now I, and people like me, will never find out if such a page exists, because the search engine is broken. It effectively ceases to exist, since no results occur. All such pages disappear from existence to all users who end up at the searchpage. So the new "feature" is a bug, since it makes finding some pages impossible. If the change were instead instituted as a pair of buttons on Vector, one for search and one for go, then this problem wouldn't be a problem. And acessing fulltext search could be expressed in a different manner, as I suggested, it could look like following a redirect, where small text indicates you followed a redirect, instead small text would indicate "To search for alternate topics, click here" or somesuch. -- 70.50.151.11 (talk) 04:50, 24 February 2014 (UTC)[reply]

The current error message on full-text search of WP:USA is a bug, but normally you are told of a pagename match in bold above the search results. For example, WP:VPT gives me: There is a page named "Wikipedia:VPT" on Wikipedia. This feature is case sensitive after the first letter but if you searched on another letter case then the first search result should normally be the page when it has been indexed by search – usually within a day. I also think there should be a Go option somewhere users can find. Here is one they wouldn't find but you can bookmark it: https://en.wikipedia.org/wiki/Wikipedia:Your_first_article#Title_for_your_new_article. You can also add ?useskin=monobook to any page, for example https://en.wikipedia.org/wiki/Special:BlankPage?useskin=monobook. PrimeHunter (talk) 14:07, 24 February 2014 (UTC)[reply]

It looks like you are aware of a similar problem, but here's my experience: I entered "Outside a Small Circle of Friends" into the search box. It doesn't exist, so I should make it a redirect to Outside of a Small Circle of Friends. But I can't, because it says "An error has occurred while searching: The search backend returned an error: ". It happens on three different browsers on three different computers (Windows 8 and XP), but only when logged in. Art LaPella (talk) 19:21, 27 February 2014 (UTC)[reply]

I get the same error on any tested search containing "small", including a full-text search of small alone. Whether logged in or out, it only happens when searching more than mainspace, for example Multimedia: https://en.wikipedia.org/w/index.php?title=Special:Search&search=small&fulltext=Search&profile=images&redirs=1. I guess you have more than Article at Special:Preferences#mw-prefsection-searchoptions. There are several workarounds to create a page, for example making a red link Outside a Small Circle of Friends. PrimeHunter (talk) 12:45, 28 February 2014 (UTC)[reply]

Yup, thank you.

Done Art LaPella (talk) 16:03, 28 February 2014 (UTC)[reply]

Page creator tool

The page creator tool is still down, any idea what is up with it? Giant Snowman 18:41, 23 February 2014 (UTC)[reply]

Cyberpower678 would know. πr² (t • c) 17:35, 24 February 2014 (UTC)[reply]

@C678:, any clue at all please? Giant Snowman 18:43, 27 February 2014 (UTC)[reply]

It was working yesterday. I have absolutely no idea why that is happening. I'll have to take a look later today.—cyberpower ^Chat_Absent 20:49, 27 February 2014 (UTC)[reply]

This tool seems to be working now, but toollabs:xtools/pages has some warnings on it ("Notice: Undefined index: lang in /data/project/xtools/public_html/pages/i18n.php"). I assume you also know that pcount shows an error. In a somewhat-related piece of (future) news, Special:Contribs (and API list=usercontribs) will soon have an option to show only page creations (thanks to request by Scott), although excluding redirects will not be possible. πr² (t • c) 05:35, 2 March 2014 (UTC)[reply]

FYI @C678:, @PiRSquared17: this is still not loading for me. Could it because I have created nearly 4,000 articles and it is therefore too big to load? Giant Snowman 12:29, 5 March 2014 (UTC)[reply]

Possibly. I'm drawing up design plans for an all new edit counter which will have the articles created count in it. I plan to work on it with the upcoming spring break.—cyberpower ^Chat_Absent 14:22, 5 March 2014 (UTC)[reply]

Tool is now working, atm.—cyberpower ^Chat_{Temporarily Online} 17:47, 5 March 2014 (UTC)[reply]

Perfect, cheers! Giant Snowman 18:33, 5 March 2014 (UTC)[reply]

Sortable columns

Template:Floruit/doc#Parameters claims that {{fl.|n}} will sort correctly in tables, whereas {{fl.}} n won't. But, unless I'm missing something, both Col 1 and Col 2 in that table sort incorrectly (i.e. 1066, 1956, 1510), if you click on the arrows next to the column names. Has something gone wrong with either {{fl.}} or Wiki-tables? It Is Me Here ^{t / c} 13:18, 25 February 2014 (UTC)[reply]

In [3] code was copied without updating the documentation. The parameter sortable=yes is in the dcumentation for {{circa}}. PrimeHunter (talk) 13:06, 26 February 2014 (UTC)[reply]

OK, template documentation fixed. It Is Me Here ^{t / c} 14:19, 28 February 2014 (UTC)[reply]

Actually, sorry, I have another question. Does {{Marriage}} work in the same way? It Is Me Here ^{t / c} 01:01, 1 March 2014 (UTC)[reply]

No, {{Marriage}} has no sortable option. Are there situations where this would be useful? It sounds inappropriate to me to make a sortable table of somebody's marriages, almost like you make fun of how many they have. Just list them in chronological order. PrimeHunter (talk) 03:20, 1 March 2014 (UTC)[reply]

New editing interface

I hate the new editing interface. It becomes impossible to edit templates. Is there any way I can turn it off. ~EDDY ^{(talk/contribs)}~ 02:12, 27 February 2014 (UTC)[reply]

Like I literally cannot add File:US Navy 111111-N-OK922-242 Michigan State University center Adreian Payne scores against the University of North Carolina during the Quicken Loans.jpg to Adreian Payne because I can't edit the Infobox. ~EDDY ^{(talk/contribs)}~ 02:35, 27 February 2014 (UTC)[reply]

What new editing interface are you referring to? WP:VE or something else? Jackmcbarn (talk) 02:36, 27 February 2014 (UTC)[reply]

No, because I would have had to set my preferences to Visual Editor. Maybe it's the iPad. The interface makes brown boxes around templates, and the contents of the template do not actually show up on the screen, just the fact there is one. If I click, sometimes I can edit the template, but most of the time it cannot be done. ~EDDY ^{(talk/contribs)}~ 03:34, 27 February 2014 (UTC)[reply]

Does it happen if you log out? PrimeHunter (talk) 04:07, 27 February 2014 (UTC)[reply]

It doesn't happen if I'm logged out, if that's what your asking. It only happens when I'm logged on. Every time I go to edit something with a template, the old {{ formatting goes on for about 2 seconds before reverting to the new TEMPL box. ~EDDY ^{(talk/contribs)}~ 23:08, 27 February 2014 (UTC)[reply]

I don't know what this "new TEMPL box" is ... do you think that you could please provide a screenshot? See WP:WPSHOT for how. --Redrose64 (talk) 23:23, 27 February 2014 (UTC)[reply]

If it doesn't happen when you are logged out then it sounds like something in your account. User:Editorofthewiki/monobook.js imports many scripts. Is your skin MonoBook? Does it happen in Vector, for example in https://en.wikipedia.org/w/index.php?title=Adreian_Payne&action=edit&editintro=Template:BLP_editintro&useskin=vector? PrimeHunter (talk) 00:08, 28 February 2014 (UTC)[reply]

Alright I played around with my preferences and it went away. It must have been something that was added automatically to my account. ~EDDY ^{(talk/contribs)}~ 01:31, 28 February 2014 (UTC)[reply]

Videos only play in line if over 800px wide

At 320px wide, this video plays in a pop out player.

Play the video on the right and a video player pops up. If I set the video thumbnail to an unreasonable 801px, the video will play in line. Why is this? No other video embeds on any other website behaves like this. - hahnch e n 02:47, 27 February 2014 (UTC)[reply]

Video playback breaks depending on video placement

Goto Dustforce and view the same video. Not only will a pop up player appear, it will appear wrongly sized. On Firefox, the video still plays, on Chrome it does not. - hahnch e n 02:53, 27 February 2014 (UTC)[reply]

Well, we are not like other websites. You can file a bugreport with this information in bugzilla, if the behavior is undesireable. Keep into account though, that other uses might have other usecases and needs, so perhaps there is a reason it works like that.. The problem on Dustforce article, i cannot reproduce, it might have something to do with your skin, gadgets or userscripts. Try playing it while being logged out. —TheDJ (talk • contribs) 18:30, 27 February 2014 (UTC)[reply]

I initially saw the problem too. A purge fixed the problem on Dustforce. — Edokter (talk) — 19:23, 27 February 2014 (UTC)[reply]

Null edits do fix the issue. I just fixed this on Bobby Bumps. It's still broken in Milan Cabrnoch. Does this need to be raised as a bug? Is it a parsing issue or playback issue? - hahnch e n 21:25, 27 February 2014 (UTC)[reply]

A purge is not the same as a null edit, they have different effects. A purge cause the page to rebuild and update the server cache. A null edit may trigger a rebuild, but not update the cache. This issue is purely caused by the cache not being updated after an edit. — Edokter (talk) — 23:41, 27 February 2014 (UTC)[reply]

A null edit does everything a purge does plus some other stuff. A purge updates the cache, and a null edit updates the cache and the links/categories/etc. tables. Jackmcbarn (talk) 02:04, 28 February 2014 (UTC)[reply]

Misplaced signature

I've noticed some problematic that I think I can reproduce. If I compose some text in an external editor, paste that text into a talk page, then click on the icon to add a signature, it sometimes out the sig at the beginning rather than the end, even though the blinking cursor is at the end of the pasted text.

With some experimentation at User:Sphilbrick/sandbox I see that if I just paste the text, the sig goes in the right place, but if I type a colon or two, then paste, then click on the icon, it places the sig in the wrong place. (Mozilla Firefox)

Has anyone else observed this? Any suggestions?--S Philbrick (Talk) 21:48, 27 February 2014 (UTC)[reply]

Addendum; just tried in Chrome and it did not happen, so it may be browser related.--S Philbrick (Talk) 21:50, 27 February 2014 (UTC)[reply]

The signature button always inserts the sig at current cursor position. If the cursor is at some position other than the end, the sig will not be added at the end. In Windows browsers, use Ctrl+End to position the cursor at the very end of a lengthy edit window. --Redrose64 (talk) 22:22, 27 February 2014 (UTC)[reply]

I understand. However, I can clearly see the cursor blinking at the end of the inserted text, while the sig goes at the beginning. I was going to offer to provide a screen shot, but the two options I have for taking screenshots do not show the placement of the cursor. I just tried this in IE, but it did not happen in IE. It isn't a lengthy edit window, my example has only three words. I note it does not happen if I include the spacing colons in the copied text, but I often compose my message, then open the edit window to determine how many colons I need, add them, then paste the text and then click on the sig symbol. I suppose I can change my habits, but that won't be easy.--S Philbrick (Talk) 22:35, 27 February 2014 (UTC)[reply]

If it helps, the problem is not specific to the signature icon. If I open the edit window, type a couple colons, paste some text, and then click on bold, it places the bold markup at the beginning. The same thing happens if I try the italic button, or try to add a link. The cursor is blinking at the end of the inserted text, but the link is add at the beginning of the entire section, before the section headings.--S Philbrick (Talk) 22:49, 27 February 2014 (UTC)[reply]

Sphilbrick are you using any scripts that affect the editing window such as wikEd or VE? — {{U|Technical 13}} ^{(t • e • c)} 23:27, 27 February 2014 (UTC)[reply]

I have wikEd enabled, but I'm not using VE.--S Philbrick (Talk) 00:15, 28 February 2014 (UTC)[reply]

Good question. I turned off wikED, and the problem did not happen. I turned it back on, and it did. So very likely wikEd related.--S Philbrick (Talk) 00:23, 28 February 2014 (UTC)[reply]

Happens to me all the time and I can't nail down a set of steps to reproduce it every time or a way to explain it to Cacycle in a bug report. Perhaps you will have better luck. — {{U|Technical 13}} ^{(t • e • c)} 00:37, 28 February 2014 (UTC)[reply]

I can now reproduce it regularly. You have to manually type the colon, paste some text, then click the icon in Firefox, with wikEd enabled. If the colon is part of the copied text it won't happen. If you type in the text, it won't happen. If you move the cursor someplace, then back, it won't happen. For some time, I was frustrated, because it happened some times, and not others, but I was able to reproduce it 20 times today.--S Philbrick (Talk) 03:07, 28 February 2014 (UTC)[reply]

Server-side code for getting user options

I'm was updating documentation on User talk:Howcheng/quickimgdelete.js, and I noticed that my script installation instructions are specific to the Monobook skin, which is no longer default. What I wanted to do was put the user's skin in the link instead (i.e., something like [[Special:Mypage/{{#useroptions:skin}}]]), but I don't know how to get at the user options using server-side code (it's part of mw.user.options in Javascript). Anyone know how to do this? Thanks. —howcheng {chat} 11:16, 28 February 2014 (UTC)[reply]

I don't think there's any way to do what you want, since it would fragment the cache. Why not just reference Special:MyPage/common.js? Or enwiki has a script to make Special:MyPage/skin.js go to the right place. Anomie ⚔ 11:33, 28 February 2014 (UTC)[reply]

Perfect, that's what I was looking for. —howcheng {chat} 16:56, 28 February 2014 (UTC)[reply]

Blocking problem

Tracked in Phabricator
Task T63942

I just went to block a user for spam username. I always use the 'Block user' facility in the sidebar. I clicked on indefinite - OK. I then went to 'Reason' and instead of the full list, I was offered seven 'Common block reasons', none of which was spam username'. The 'Warn' feature on the top toolbar worked fine - full list available. Is this a glitch, or has someone somewhere decided that we must now type in our reasons instead of having a full pulldown list as well as having the option to customise individual cases? Peridon (talk) 12:14, 28 February 2014 (UTC)[reply]

Working fine for me (IE11, Windows 7) Black Kite (talk) 12:57, 28 February 2014 (UTC)[reply]
MediaWiki:Ipbreason-dropdown hasn't been edited in a month. Must be a glitch. I was tempted to block you as a spam username, just to demonstrate :-) Nyttend (talk) 13:28, 28 February 2014 (UTC)[reply]
FYI, "The 'Warn' feature on the top toolbar" is actually a WP:Twinkle function, unless I'm mistaken. Anyways, both that and the block-user page work fine for me. ☺ · Salvidrim! · ✉ 13:49, 28 February 2014 (UTC)[reply]

This is weird. All the reasons are there in 'Edit block reasons', but when I click on the pulldown reasons box, I get seven reasons only. I've made no changes to anything recently, and other than editing the reasons in 'Edit block reasons', I can't find a way of changing the display. I'm on XP Pro, Firefox 20, and Monobook. I've restarted the browser (which automatically deletes history). I haven't tried standing on one leg and whistling Rule Britannia yet... Peridon (talk) 14:05, 28 February 2014 (UTC)[reply]

This is a regression in 1.23wmf15, tracked in Template:Bug. The fix was backported to 1.23wmf16 last night (early morning UTC), but it wasn't realized this existed in 1.23wmf15 as well. I plan to deploy the fix to 1.23wmf15 in a few minutes. BJorsch (WMF) (talk) 14:13, 28 February 2014 (UTC)[reply]

I wish I knew what that meant, but grateful thanks for it.... Peridon (talk) 14:16, 28 February 2014 (UTC)[reply]

It pulls the block reason from your interface language preference instead of enwiki's (which are assume are both English, though), and it seems the two sets of reasons don't match, hence the discrepancy. ☺ · Salvidrim! · ✉ 14:18, 28 February 2014 (UTC)[reply]

Back almost to normal now. (It opens to the bottom of the list, not the top. Fine for me - I use that end more anyway...) I'd just looked at the bug link and worked out that it might have something to do with me being on Brit English. Peridon (talk) 14:24, 28 February 2014 (UTC)[reply]

Thanks to you, I just realized there are actually three English user preference options (en, en-CA and en-GB). I didn't know that! I'm kind of afraid of changing to en-CA though, despite being Canadian... not sure what exactly would be different. But at least now we know the en-GB default block reasons are different from enwiki's standard ones for some unfathomable reason. ☺ · Salvidrim! · ✉ 14:50, 28 February 2014 (UTC)[reply]

Try it. You can always come back out as I did while investigating this. (Went into Vector to see if it was a glitch in Monobook. Came back out quick again feeling cold. I suppose Vector might look better in a California summer, but in a GB winter, no thanks...) Peridon (talk) 15:03, 28 February 2014 (UTC)[reply]

Vector suits my Canadian Winter perfectly. I'll give en-CA a shot! ☺ · Salvidrim! · ✉ 15:30, 28 February 2014 (UTC)[reply]

There are indeed three language variants, but when the "normal" (en - English) messages are updated, the British-English and Canadian-English messages are not usually updated to suit. I'm British, and I find it easiest to use "en - English". After all, the language setting does not affect variants like colour/color in article text. --Redrose64 (talk) 16:05, 28 February 2014 (UTC)[reply]

Is the user-language-dependent data editable in MediaWiki space like wiki-language-dependant data is? ☺ · Salvidrim! · ✉ 16:47, 28 February 2014 (UTC)[reply]

I don't know if the en variants all use the same one, but the en-gb one I get is editable. Judging by the edit history, I'd say it's all one and the same. I think French might have two variants - fr and fr-ca - but don't quote me... Peridon (talk) 20:44, 28 February 2014 (UTC)[reply]

Each en variant is treated as if it were a separate language. Users who select en-GB or en-CA won't see messages that were only customised in en. Admins can edit the messages for non-default languages by adding a slash followed by a language code to the relevant MediaWiki-namespace page title. – PartTimeGnome (talk | contribs) 23:37, 28 February 2014 (UTC)[reply]

Before this bug occurred, the block reasons were always in the wiki language, regardless of the blocking admin's language. There was never any point in customising the block reasons for other languages, so it wasn't done. That, and as Redrose64 pointed out, admins tend not to edit the messages for non-default languages anyway. – PartTimeGnome (talk | contribs) 23:37, 28 February 2014 (UTC)[reply]

Peridon above said: "It opens to the bottom of the list, not the top. Fine for me - I use that end more anyway." I'm glad Peridon's happy, but I'm not. Not only don't I like it, but, more important, it's not normal behavior for a drop-down. Is it going to be fixed (sorry Peridon)?--Bbb23 (talk) 16:17, 2 March 2014 (UTC)[reply]

Kings of Wales family trees

Can someone sort out why the chart at Kings of Wales family trees does not display properly? Thanks. Ghmyrtle (talk) 15:06, 28 February 2014 (UTC)[reply]

What's wrong with it? --Redrose64 (talk) 16:06, 28 February 2014 (UTC)[reply]

The question was originally asked at WT:WALES. I looked at the page and have the same problem - the text is mostly squashed up at the top and bottom of the screen, overlaps with other text, and bears no relationship to the boxes in which the text should fit. I'm on Google Chrome. To a non-techie like me, there seemed no obvious way to fix it. Ghmyrtle (talk) 16:31, 28 February 2014 (UTC)[reply]

PS: Just checked on Internet Explorer - it seems to work fine on that. Ghmyrtle (talk) 16:34, 28 February 2014 (UTC)[reply]

Looks fine on Firefox 20 - apart from the last two baronets not being connected to anything. Could be a Chrome problem. Peridon (talk) 16:55, 28 February 2014 (UTC)[reply]

Looks OK to me too on Firefox 27.0.1. I also connected the last row of baronets based on the family relationships in the linked articles.

Do other articles that use the family tree template look OK to you on Chrome, or are they all broken? That would help narrow down the problem. Take a look at Coppola family tree, {{Family tree}}, {{Walton family tree}}, Roosevelt family. – Jonesey95 (talk) 19:49, 28 February 2014 (UTC)[reply]

They all have the same problem for me on Chrome, but in a less extreme form as the trees are much smaller. Ghmyrtle (talk) 20:00, 28 February 2014 (UTC)[reply]

To give you an idea of how it looks on Chrome Version 33.0.1750.117m. Tried different zoom levels and it all gives the same result. It shows up perfectly fine in Firefox 27.0.1 for me also. ☺ · Salvidrim! · ✉ 20:27, 28 February 2014 (UTC)[reply]

Gordon Bennett! That's a mess. All the above trees look fine to me in Firefox 20. I haven't got Chrome except on one mobile. Peridon (talk) 20:39, 28 February 2014 (UTC)[reply]

I get the same issues with the trees linked above by User:Jonesey95, although on a smaller scale for obvious reasons. ☺ · Salvidrim! · ✉ 22:58, 28 February 2014 (UTC)[reply]

This is a Chrome bug, this was previously discussed on Template talk:Familytree#Rendering issue. Matma Rex talk 23:14, 28 February 2014 (UTC)[reply]

Giving the collpased table row a height (even 1px) will force Chrome to display those rows properly. — Edokter (talk) — 23:27, 28 February 2014 (UTC)[reply]

Firefox check(ed)

Can someone with Firefox check here to see if the headers are grey in the middle? Trying to rule out my PC. If others see it too, then I discovered a major bug in Firefox involving linear gradients with transparent stops. — Edokter (talk) — 15:18, 28 February 2014 (UTC)[reply]

All the headers seem fine to me. Honestly though, I prefer the tables. Supernerd11 :D Firemind ^_^ Pokedex 15:29, 28 February 2014 (UTC)[reply]

You tested with Firefox, right? (Which version?) To be clear, the headers are not supposed to be grey in the middle. I actually found a bug report here. — Edokter (talk) — 15:46, 28 February 2014 (UTC)[reply]

27.0.1, the most up to date one. The headers are just the usual black on the gray lines, the text itself is the same as anywhere else on the Wiki. Supernerd11 :D Firemind ^_^ Pokedex 16:08, 28 February 2014 (UTC)[reply]

With Firefox 27.0.1 I see white at left, grey in the middle, and transparent at right. In Chrome 33, Opera 12.16 and Safari 5.1.7, it's a gradual fade from white to transparent, no grey. In IE8, it's the same colour all the way across - the background colour for the box. --Redrose64 (talk) 16:18, 28 February 2014 (UTC)[reply]

That is what I thought; the grey is not supposed to happen. I found a workaround though, but it's still a serious bug; can't use transparent in gradients. — Edokter (talk) — 16:47, 28 February 2014 (UTC)[reply]

In Firefox 20, I'm getting black text on a coloured ground deepening left to right. Looks fine. Peridon (talk) 17:00, 28 February 2014 (UTC)[reply]

Does it maybe have something to do with what you're on (tablet/PC/whatever)? I'm on a Windows 8 tablet and, much as it sucks, I'm getting the same as Peridon. Supernerd11 :D Firemind ^_^ Pokedex 17:07, 28 February 2014 (UTC)[reply]

"coloured ground" doesn't tell me much. I have implemented a workaround, so you should see the headers on a background that fades from white on the left to the background color on the right (with no grey in between). It is a rendering bug in Firefox; the original reporter uses Ubuntu. — Edokter (talk) — 17:51, 28 February 2014 (UTC)[reply]

For reference: User:Edokter/gradient shows the bug quite clearly. — Edokter (talk) — 17:53, 28 February 2014 (UTC)[reply]

That's very clear. I get gray all over the middle in Firefox 27 and no gray at all in Safari 6.1.1, both on Mac OS 10.8.5. Whatamidoing (WMF) (talk) 18:37, 28 February 2014 (UTC)[reply]

A ground is, in heraldry and other art work, a background. A coloured ground is what's under the black text I see in those headers. At the left, they're white or near white. At the right, they're the colour of the ground of the box below them on the page, grading deeper as you go right. In Firefox 20, I get no grey. I've no idea what colouration is normal for the main page as I never go there. (Sorry to all those who work on it - I just don't need to go to it...) Peridon (talk) 19:10, 28 February 2014 (UTC)[reply]

It appears your test link no longer shows the bug, since you've changed your CSS to work around it. User:Edokter/gradient does though.

Your analysis on User:Edokter/gradient#Cause isn't quite correct, BTW: the problem isn't that Firefox is supposed to somehow be using the color from an adjacent stop, it's that Firefox is doing the gradient in non-premultiplied RGBA rather than premultiplied RGBA. See Example 23 at http://dev.w3.org/csswg/css-images-3/ for images and details. Anomie ⚔ 23:32, 28 February 2014 (UTC)[reply]

Yes, I did mention twice I fixed it. Nice find on that page though; I will link to it. — Edokter (talk) — 11:31, 1 March 2014 (UTC)[reply]

Call for project ideas: funding is available for community experiments

I apologize if this message is not in your language. Please help translate it.

Do you have an idea for a project that could improve your community? Individual Engagement Grants from the Wikimedia Foundation help support individuals and small teams to organize experiments for 6 months. You can get funding to try out your idea for online community organizing, outreach, tool-building, or research to help make Wikipedia better. In March, we’re looking for new project proposals.

Examples of past Individual Engagement Grant projects:

Organizing social media for Chinese Wikipedia ($350 for materials)
Improving gadgets for Visual Editor ($4500 for developers)
Coordinating access to reliable sources for Wikipedians ($7500 for project management, consultants and materials)
Building community and strategy for Wikisource (€10000 for organizing and travel)

Proposals are due by 31 March 2014. There are a number of ways to get involved!

Hope to have your participation,

--Siko Bouterse, Head of Individual Engagement Grants, Wikimedia Foundation 19:44, 28 February 2014 (UTC)[reply]

Notifications no longer showing link to diff

My Notifications menu used to show a link to a diff when someone thanked me for an edit. Right now, it looks like:

"Username" thanked you for your edit on Foobar

69 minutes ago

The username is linked. The article name is not linked.

I believe that the article name used to be linked and that there used to be a "show edit" link after the "XX minutes ago" statement.

Sometimes people thank me for an edit that I made a while ago, and I want to be able to see the edit. Now I have to manually type the article name or search my edit history instead of clicking a helpful link. That's not helpful.

Am I remembering this correctly? Is it just me? How can I get this useful link back? – Jonesey95 (talk) 21:23, 28 February 2014 (UTC)[reply]

Such a link did indeed exist, and now is no longer there. However, you do not have to search your edit history or the article name. There still is a link to the edit in question, it's just invisible. If you click on the message at any place except the linked username, you get taken to the diff. AddWittyNameHere (talk) 21:51, 28 February 2014 (UTC)[reply]

Thanks for the tip. How are people supposed to know about this invisible feature? I'm a pretty clever person who has been using the web for 20 years, and I didn't figure that out. Isn't it better UI etiquette to just put a link where a link should be? Or, to phrase my question in a more confrontational and WP-traditional way that often makes me sigh, was there a consensus discussion that resulted in this change? – Jonesey95 (talk) 00:47, 1 March 2014 (UTC)[reply]

You're welcome, by accident (at least, that's how I figured it out), yes it would be, no clue if there was any discussion or consensus. AddWittyNameHere (talk) 02:49, 1 March 2014 (UTC)[reply]

For me, the links to both "your edit" (the diff) and page name still exist. This is for all such notifications which are on my notification page (i.e. both recent, 1 hour ago, and past). The entire notification changes color on hover, but is not linked. Now we just need to figure out what the difference in configuration is. I like those links as they currently are. I would not want to see them go away. Off the top of my head, I do not think of anything special I am doing to get the links. I am using the vector skin.

Ahhh... I would bet you two are using MonoBook, or other non-vector skin. In Vector the notifications are only a complete separate page which includes those links. In MonoBook the primary access appears to be a popup (activated by left-click) which does not have these links. In MonoBook, the notifications page can be opened in a new tab/new window (context menu, middle click, or select "All notifications" link at the bottom of the pop-up) which does include the links. — NOPE, not correct.

Ok, that is interesting. When I changed back to using Vector the behavior changed such that it was similar to what I experienced in MonoBook (i.e. the popup window is now the result of a left click on the notification icon). Thus, this appears to be an "enhancement" which had not updated for me until I changed skins. They have not removed the links, just not (yet?) implemented them on the new popup. We look at it as a removal of the links because the popup provides an interface that looks very similar to what we are used to seeing. Thus, we have not recognized that the popup is the new thing.

So, for the moment, the easiest way to get to the desired links is to either click on the entire notification in the popup or bring up the full notifications page. — Makyen (talk) 03:38, 1 March 2014 (UTC)[reply]

"In MonoBook the primary access appears to be a popup " eh no, that is the primary access method in ALL skins. If the popup doesn't show for you, then likely you have broken javascripts in User:Makyen/vector.js. —TheDJ (talk • contribs) 11:50, 1 March 2014 (UTC)[reply]

You appear to have missed my statement that the popup became primary for me in Vector upon changing back to Vector after testing MonoBook. For a time it was possible for me to see the two different behaviors simultaneously in Vector depending on if a tab had been reloaded after testing MonoBook. Given that my User:Makyen/vector.js page did not change, this implies that my not seeing it in Vector until after switching back from MonoBook was a caching issue wrt. the source of the JavaScript enabling the popup, not an issue with my User:Makyen/vector.js page. Further, a brief check of that page, to which you linked, would have shown that it is completely blank and that the only time it has ever had any content was for 12 minutes on December 11, 2013. Currently, all of my user JavaScript customizations are in common.js specifically so they are common across the various skins. — Makyen (talk) 20:48, 1 March 2014 (UTC)[reply]

For what it's worth (not completely understandins some of the stuff above...), I get a full window on Monobook (en-gb), with a normal link to the page, and a little link after the time ago counter to the actual diff. Peridon (talk) 09:57, 2 March 2014 (UTC)[reply]

OCSP checking on en.wikipedia.org fails

If "When an OCSP server connection fails, treat the certificate as invalid" is checked at the Firefox options menu, Wikipedia is not reachable. 87.78.121.142 (talk) 01:20, 1 March 2014 (UTC)[reply]

Well, presumably your browser is having trouble reaching the OCSP server, which is not Wikipedia's fault. There's a good chance other HTTPS-only sites like Facebook would also be inaccessible while this error is occurring. — This, that and the other (talk) 08:55, 1 March 2014 (UTC)[reply]

API question

Hi, I've been trying to query the API for a list of new pages in the mainspace. I've been attempting to add the &redirect= parameter so that redirects don't show up in my query, but they don't seem to get resolved. Is there another way I can do this? Thanks, --Jakob (talk) 02:35, 1 March 2014 (UTC)[reply]

Have you tried playing with the options and narrowing down your query in the Special:ApiSandbox any yet? If not, you may want to try it. If you have and still can't figure it out, it is likely that if you post your query here, someone can point you in the correct direction. Happy editing! — {{U|Technical 13}} ^{(t • e • c)} 02:39, 1 March 2014 (UTC)[reply]
The parameter is &redirects=, not &redirect=. Anomie ⚔ 00:27, 2 March 2014 (UTC)[reply]

@Technical 13 and Anomie: That still only tags redirects as such, not remove them from the query. --Jakob (talk) 16:19, 5 March 2014 (UTC)[reply]

Perhaps the &apfilterredir=nonredirects is what you are looking for... Special:ApiSandbox#action=query&list=allpages&format=json&apnamespace=0&apfilterredir=nonredirects&aplimit=10?

Perhaps the &rcshow=!redirect is what you are looking for... Special:ApiSandbox#action=query&list=recentchanges&format=json&rcnamespace=0&rcshow=!redirect&rclimit=10&rctype=new?

There are more possible things you could mean, which is why I asked you to post your current query if you were going to ping us for further assistance... — {{U|Technical 13}} ^{(t • e • c)} 16:38, 5 March 2014 (UTC)[reply]

Scroller in location map

Can someone help me with the large location map at List of power stations in Sri Lanka? I want that image to be half the height, with a scroller on the image part (excluding the caption). I tried {{Tall image}} and <div> stuff; I can't seem to be getting it right... Reh man 08:06, 1 March 2014 (UTC)[reply]

Scrollers are bad. They don't really work in print for instance. Suggest to think of another position for this image inside the article. —TheDJ (talk • contribs) 11:45, 1 March 2014 (UTC)[reply]

Yeah, you're right. It also doesn't work well on mobile. Didn't think of those. Just for knowledge though, is there a way to do that? Reh man 14:12, 1 March 2014 (UTC)[reply]

What's the purpose of this map? The measure of "major" seems inconsistent: the map shows Mampuri Wind Farm (30MW) and Udawalawe Dam (6MW) but not Embilipitiya (100MW) or Colombo Port (60MW). If you're just trying to give a general impression, the map can be smaller and doesn't need the location names. It's difficult to distinguish the marker colors even on a large map. You could use letters instead, e.g. copies of File:NYCS-bull-trans-C.svg, File:NYCS-bull-trans-G.svg, File:NYCS-bull-trans-H.svg, File:NYCS-bull-trans-S.svg, File:NYCS-bull-trans-W.svg customized with relevant colors. Or perhaps you could size the existing markers in proportion to the plant capacity, in which case you really should include all plants above a minimum capacity. That would certainly make the map more meaningful. - Pointillist (talk) 15:07, 1 March 2014 (UTC)[reply]

The map isn't complete, that's why it's missing some power stations. (I'm adding them as I verify the plant itself, I have a feeling some are greatly different to the capacity stated). The marker size is a nice idea, but it wouldn't go well near the Laxapana area (would be too crowded). But I agree markers need changing; will work on it soon... Right now, the map just shows the types of power stations and their locations over relief detail. Reh man 15:34, 1 March 2014 (UTC)[reply]

Maybe semi-transparent tinted SVG circles, sized by capacity, would look good. Then the overlaps would be more intensely colored. - Pointillist (talk) 15:56, 1 March 2014 (UTC)[reply]

Whether SVG or not, overlapping a semi-transparent coloured area on another doesn't intensify colours - if anything, it makes them more muddy. This is because the saturation is decreased. --Redrose64 (talk) 11:07, 2 March 2014 (UTC)[reply]

Overlapping partially opaque filled shapes

Well, what I had in mind was an increase in saturation, like the image on the right. This is assuming the overlapping shapes are the same color and that SVG rendering is being done in the browser, which is not Wikipedia's way. So it's not going to work unless it is prepared offline, which eliminates the advantages of map co-ordinates. Even if it had worked it would also have required you to lay down all the circles once in opaque white and then again in semi-opaque color. So it was a rotten approach [sorry] though muddy colors were the least of its problems! - Pointillist (talk) 15:42, 2 March 2014 (UTC)[reply]

It intensifies in your demo because all four circles are exactly the same fill colour - #F0E. Muddiness in the overlap happens when the hues are different; the Sri Lanka map uses pushpin markers of five different hues. Try your demo again, but with each circle a different hue, retaining opacity="0.4" - try it also with the circles layered in different orders. The overlap area will vary. --Redrose64 (talk) 16:43, 2 March 2014 (UTC)[reply]

Mmm, as I said, it assumes the overlapping shapes are the same color. In the current context I think the main problem would be the low capacity Mampuri Wind Farm immediately adjacent to the large Lakvijaya Power Station. I expect all the plants around Laxapana are hydro-electric so would have had the same color. But this is flogging a decomposing carcase.... - Pointillist (talk) 17:09, 2 March 2014 (UTC)[reply]

Re "Download as PDF" function

I have continually experienced problems when trying to use the service "download as PDF".

Firstly, the process is totally incapable of dealing with template:cite journal etc. Even when only using raw text (i.e. no templates at all) as references, I just tried again now to convert a page into a PDF, and the pdf has 50 references when the original page it has been rendered from has 52. References disappear, and I cannot see any reason for this.

Who can I ask about this issue please?

Many thanks for your attention in this matter, Lesion (talk) 15:19, 1 March 2014 (UTC)[reply]

I found what was wrong, and I am surprised that this leads to the reference not being rendered.

The first instance of a named reference must be the full reference (i.e. <ref name=blahblah2009>blahblah</ref>), and the subsequent instances of the ref may be shortened <ref name=blahblah2009 />

BUT, if the first instance of a named ref is shortened, then even if one of the later instances has the full ref, none of the references will be rendered in the PDF.

Strange, no?

This is not an issue on Wikipedia articles, since if you place a shortened ref before the full reference they all will still appear normally in the reflist, but it seems to cause this bug on the PDF function for some reason.

I have seen bots correct such sequential errors on wikipedia articles, but never paid much attention to this task until now. It seems that I need to use one of those bots to correct any future pages that I want to convert to PDF.

So my new Q is: does anyone know which bots perform the task of putting the full reference before the shortened references in an article? Many thanks, Lesion (talk) 15:34, 1 March 2014 (UTC)[reply]

The pdf creator uses its own wikitext parser different from that used to generate HTML visible on the screen. (See mw:Extension:Collection) And this parser has many issues: see Help:Books/Feedback. Ruslik_Zero 18:55, 1 March 2014 (UTC)[reply]

Also, the PDF rendering backend is in the process of being replaced. See mw:PDF rendering. Anomie ⚔ 00:30, 2 March 2014 (UTC)[reply]

Thanks for background... but for the time being does anyone know what bot would carry out this task:

Before:

Lorem ipsum dolor sit amet,<ref name=ref1 /> consectetur adipisicing elit.<ref name=ref1>Ref 1</ref>

After:

Lorem ipsum dolor sit amet,<ref name=ref1>Ref 1</ref> consectetur adipisicing elit.<ref name=ref1 />

I am sure I have seen bots do this, but I don't usually pay them attention. Any ideas? Thanks, Lesion (talk) 00:38, 2 March 2014 (UTC)[reply]

I suspect this is Template:Bug - Template expansion via API fails . -- Gadget850^talk 03:00, 4 March 2014 (UTC)[reply]

Template:Documentation

When using the |content= parameter with Template:Documentation, it is breaking up the green background area on the template page in Firefox 27.0.1. See as an example: Template:Template link templates, down at the bottom. The /doc portion is very strange. Funandtrvl (talk) 20:55, 1 March 2014 (UTC)[reply]

Template:Template link templates doesn't look like much of a template to me, what is its purpose? Other than that, I can spot by viewing the source of your example that apparently when using |content= the {{{content}}} <p>...</p> section is being added in between the outer div and footer sections but it is being created in a different way causing the top and bottom section to close and the {{{content}}} <p>...</p> section is showing up not in the main div. ~~I'll look at Module:Documentation and see if I can isolate the issue and I have a pretty good idea where to look on this one (I think)~~. — {{U|Technical 13}} ^{(t • e • c)} 21:17, 1 March 2014 (UTC)[reply]
The {{documentation}} template was being called on a line starting with an asterisk, meaning that until the first line break in the module output it was interpreted as being part of a bulleted list. We could start the module with a line break to prevent this, but that might introduce unwanted white space on other pages. At any rate, I've fixed the template link templates page. — Mr. Stradivarius on tour ^{♪ talk ♪} 23:34, 1 March 2014 (UTC)[reply]
- Yeah, the proper fix for something like that is "don't do that". Trying to fix it in the module would be the same mistake that caused Template:Bug. Anomie ⚔ 00:32, 2 March 2014 (UTC)[reply]

Tech News: 2014-10

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

The latest version of MediaWiki (1.23wmf16) was added to test wikis and MediaWiki.org on February 27. It will be added to non-Wikipedia wikis on March 4, and all Wikipedia wikis on March 6 (calendar).
When users enable web fonts by default, Universal Language Selector will now log if they don't have fonts to display pages correctly. This information will be used by developers to improve font support in the future. Read more about missing fonts. [4]
You can now use Guided tours on the Czech and Japanese Wikipedia. If you want this tool on your wiki, you need to translate it and ask in Bugzilla. [5] [6]
You can now use information from Wikidata in all Wikisource wikis. [7]
The multimedia team is now posting weekly updates on their mailing list. [8]

VisualEditor news

You can now change image size to default for your wiki. If you add new images to pages, they will also be default size. [9] [10] [11]
If you switch from VisualEditor to wikitext editing, your edit will now be tagged. [12]
Template parameters now have a bigger, auto-sizing input box for easier editing. [13]
VisualEditor now has Arabic, Finnish and Kölsch icons for text styling. If you want icons for your language, ask in Bugzilla. [14] [15] [16]

Future software changes

The new tool for viewing media files will soon show a progress bar and a thumbnail while loading full images. [17] [18]
You will soon be able to make user contributions show only page creations. [19] [20]
Article Feedback Tool will be removed from the English and French Wikipedias on March 3. It will also no longer be possible to add this tool to any Wikimedia wiki. [21] [22]
Wikis using the new search tool will come back to the old tool for a few hours starting at 00:00 UTC on March 6. [23]

Problems

For about an hour on February 23, there were problems with page loading due to a MediaWiki bug. [24]

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

09:30, 3 March 2014 (UTC)

Internal Server Error

I have been consistently getting a Internal Server Error when trying to use count lately. Anyone else? What can be done about it? Thanks in advance, XOttawahitech (talk) 15:25, 3 March 2014 (UTC)[reply]

This is referring to pcount, one of X!'s tools. @Cyberpower678: can you fix it? πr² (t • c) 16:54, 3 March 2014 (UTC)[reply]

Everytime I look. It works for me.—cyberpower ^Chat_Absent 20:35, 3 March 2014 (UTC)[reply]

Doesn't work for me either - and edit creator tool still won't load. Giant Snowman 20:39, 3 March 2014 (UTC)[reply]

It seems to go back and forth for me. One moment it works, then it serves me a 500 Internal Server Error again. Sometimes it works again within a minute or two, other times it takes a while before it starts working again. Currently working for me, but wasn't approx. 20 minutes ago. Since the past few days (26th or 27th of February, I think), I've been getting "500 - Internal Server Error" approximately 20-25% of the times I attempted to use it, not counting the refreshes within a few minutes that also led to the same error. Sometimes, they're all pretty close in a row, where the tool pretty much alternates between "error" and "working" for an hour or two (in one case, it served me an error, worked again two minutes later and served me an error again another minute later). Other times, it works fairly well for most of an editing session (2-4 hours, usually), with just one or two errors in between. AddWittyNameHere (talk) 21:07, 3 March 2014 (UTC)[reply]

And now it's giving me the following error:

click "show" for the full error

Warning: mysql_connect(): Can't connect to MySQL server on 'enwiki.labsdb' (4) in /data/project/xtools/public_html/counter_commons/Database.php on line 62 Warning: mysql_select_db() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 63 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Notice: Undefined offset: 0 in /data/project/xtools/public_html/pcount/counter.php on line 104 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Notice: Undefined offset: 0 in /data/project/xtools/public_html/pcount/counter.php on line 119 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/pcount/counter.php on line 198

and tried to tell me AddWittyNameHere does not exist. Existential crisis here! I apparently do not exist! AddWittyNameHere (talk) 22:42, 3 March 2014 (UTC)[reply]

If this is still an issue, the best place to bring this up might be https://lists.wikimedia.org/mailman/listinfo/labs-l --AKlapper (WMF) (talk) 12:04, 4 March 2014 (UTC)[reply]

Will do if it starts doing so again. Right now, it works. AddWittyNameHere (talk) 14:20, 4 March 2014 (UTC)[reply]

Unfortunately, I don't see what is being mentioned here, making it impossible for me to look into.—cyberpower ^Chat_Absent 16:37, 4 March 2014 (UTC)[reply]

It has already been resolved. You might grep the #wikimedia-labs logs from yesterday for "labsdb" if you want more info. πr² (t • c) 17:38, 4 March 2014 (UTC)[reply]

A New Browser Based Framework for Tools

For my dissertation, I've been making a framework to make tools in the browser. It's still in development, but I'd like to start encouraging some participation in the development of Vada and its plugins/tools/apps/hacks.

A quick overview, it's written entirely in synchronous javascript (which makes it much easier to develop with), comes with a number of GUI elements with underlying code, such as a queue, a queue builder and predefined buttons (revert & warn, template user, thank user, etc.) and abstracts the API into objects with a tailored caching mechanism.

Currently on this wiki, there is an anti vandal plugin "app" that you can test, which demonstrates some of the features Vada provides.

I would appreciate thoughts, ideas and suggestions to make this framework as useful as possible.

930913(Congratulate) 18:09, 3 March 2014 (UTC)[reply]

What's going on with Pollinator?

Tracked in Phabricator
Task T48014

On the page Pollinator, a piped link to taxonomic rank is somehow interrupted mid-word with "Heading 1" in heading form. Step right up and take a look before this freakish problem is fixed! What's going on? ± Lenoxus (" *** ") — Preceding undated comment added 21:26, 3 March 2014 (UTC)[reply]

Upon further investigation, it looks like a bug (appropriately enough) in the bot that undid the testing-vandalism edit. I'm guessing that if someone edited and saved it with zero changes, the problem would go away, but I could be wrong, and I sort of don't want to disturb the bug while it remains active. ± Lenoxus (" *** ") 21:31, 3 March 2014 (UTC)[reply]

FYI, Lenoxus is not crazy, it really was doing something irrational. But I made a null edit to the article (an actual null edit, not a 1-character edit), and cleared the cache, and now it looks fine. Lenoxus, if it doesn't look OK for you now, then do the same. As for what actually caused that, Lenoxus knows more than me (and sorry if I messed up your example of the bug for other people to see). --Floquenbeam (talk) 21:35, 3 March 2014 (UTC)[reply]

It's all good! The page is now fixed but the weird issue is still there in history. Compare this historical page (which contains "Heading 1" and doesn't contain the complete word "subfamily") to the way it looks in edit mode (which is the other way around: it has "subfamily" but not "Heading 1"). ± Lenoxus (" *** ") 21:53, 3 March 2014 (UTC)[reply]

We've seen this a couple of times now; see bug 46014. The last report on VPT was in December. The bug is not in the bot, but in MediaWiki; there should not be a way for a bot to prevent the cache being updated when it edits a page. This problem crops up whenever a revert follows fast on the heels of the edit being reverted. Every case reported so far has involved ClueBot NG, simply because it is so fast at reverting vandalism. – PartTimeGnome (talk | contribs) 22:25, 3 March 2014 (UTC)[reply]

WMF Labs problem

Is there some problem with the WMF Labs servers, I have been trying to use the Category Tree Intersection tool at http://tools.wmflabs.org/catscan2/quick_intersection.php?lang=en&project=wikipedia and keep getting the error message

Warning: mysqli::mysqli(): (HY000/2003): Can't connect to MySQL server on 'enwiki.labsdb' (110) in /data/project/magnustools/public_html/php/common.php on line 88 Fatal error: Call to a member function real_escape_string() on a non-object in /data/project/magnustools/public_html/php/common.php on line 101

Keith D (talk) 21:46, 3 March 2014 (UTC)[reply]

See "Internal Server Error" thread above. --AKlapper (WMF) (talk) 12:04, 4 March 2014 (UTC)[reply]

Question about the unsubst: module

I recently moved Template:Necessary? to Template:Overly detailed-inline and, while going over the code, noticed the unsubstitution code uses parameter |$N=Template name.

The module Module:Unsubst is only a year old (or something similar), I think, and I'm not too familiar with Lua. Following renaming of templates, is it a requirement to update the parameter name, or can the system handle it?

First time posting here btw. meteor_sandwich_yum (talk) 23:46, 3 March 2014 (UTC)[reply]

Short answer: yes, changing it was a good idea. Long answer: if a template using Module:Unsubst is transcluded, this setting doesn't have any effect. However, if it is substituted, then the |$N= parameter is the template used for the template invocation generated by the module. For example, if you had the template invocation {{subst:overly detailed-inline|one|two|foo=bar}}, and the |$N= parameter in Template:Overly detailed-inline was set to "baz", then Module:Unsubst would output the template invocation {{baz|one|two|foo=bar}}. If you hadn't updated the |$N= parameter, the template would have produced a template call to {{necessary?}} rather than to {{overly detailed-inline}}. That wouldn't really have been a problem as the former is a redirect to the latter, but it is probably best to use the current template name to avoid things being unnecessarily confusing. — Mr. Stradivarius ^{♪ talk ♪} 01:11, 4 March 2014 (UTC)[reply]

Now that I think of it, gerrit:99797 should let us get rid of that $N parameter. @Mr. Stradivarius, care to have a look at Module:Unsubst/sandbox (diff)? Anomie ⚔ 01:54, 4 March 2014 (UTC)[reply]

Good thinking. :) I would keep the check for the $N parameter in there (like this) until the |$N= code is removed from all the transclusions. If we remove the check, and someone substitutes a template that uses Module:Unsubst before we update that transclusion, the module would include code like |$N=foo in the template invocation it generates. I'll have another look and see if I spot anything, but that's all I've got for now. — Mr. Stradivarius ^{♪ talk ♪} 06:22, 4 March 2014 (UTC)[reply]

Found another issue - for templates, the module was outputting invocations like {{Template:Foo}} instead of just {{Foo}}. That's fixed in the sandbox now. — Mr. Stradivarius ^{♪ talk ♪} 07:02, 4 March 2014 (UTC)[reply]

See, this is why I asked for review ;) Thanks Anomie ⚔ 16:09, 4 March 2014 (UTC)[reply]

server problems?

Wikipedia seems incredibly slow for me right now -- is it just me, or are other people noticing anything? —Steve Summit (talk) 03:34, 4 March 2014 (UTC)[reply]

I had been noticing this, but it seems to have cleared up by now:Jay8g [V•T•E] 04:26, 4 March 2014 (UTC)[reply]

Yup. —Steve Summit (talk) 06:34, 4 March 2014 (UTC)[reply]

I've found it getting slower through the day, but a reload of the browser speeds things up again. Probably irrelevant... Peridon (talk) 12:47, 4 March 2014 (UTC)[reply]

I was having a lot of problems yesterday evening New York time also. Reloading the browser didn't help. Robert McClenon (talk) 15:32, 4 March 2014 (UTC)[reply]

Kite

Hi, when I was searching for kite, I saw that on the search results page for kite, there were two links to kite article page (I think so), 1 bold and one that is not bold, I would like someone to deal with this issue on Special:Search by typing in kite and checking it out, if the pages are not the same, maybe delete it under CSD A10 (if possible). Thanks for checking out the problem in advance. (Safari) -- Yutah Andrei Marzan Ogawa¹²³|UPage|_☺★ (talk) 09:30, 4 March 2014 (UTC)[reply]

Well, the word that you type in is in a regular face in the search box, while any bold items are actual pages or redirects that match the search term. Van Isaac_WS^cont 10:15, 4 March 2014 (UTC)[reply]

Yes, the suggestions that appear below the type in box have what you typed in bold. kite in the box and Kite in the pop-down list are the same article. If you type kite t in the box, the top suggestion will be Kite types. Peridon (talk) 12:44, 4 March 2014 (UTC)[reply]

This is not broken with Cirrus: [25]. πr² (t • c) 12:45, 4 March 2014 (UTC)[reply]

I've tried it and got the same result. On the search page for "kite" (not the search box, the actual page Special:Search), the top two results both link to the article Kite, one bolded and one not. Also, while the dates of last modification are the same for both results, the unbolded page is 113 bytes bigger (though again, they link to the same article). SiBr₄ (talk) 13:43, 4 March 2014 (UTC)[reply]

By the way, I'm using Firefox 27.0.1. SiBr₄ (talk) 13:46, 4 March 2014 (UTC)[reply]

I've been here nearly six years and never used that. (If I can't get it the search box, I Google with 'wiki'.) Hmmm - odd. Exactly the same article. The difference in size of 113 words is puzzling. I can't see an easy way of getting to that amount of difference without going back over a week - possibly even a month. Peridon (talk) 14:13, 4 March 2014 (UTC)[reply]

Please note: the 113 is words not bits or bytes. Peridon (talk) 14:14, 4 March 2014 (UTC)[reply]

Yeah, I agree it's strange, but we won't be using Lucene search by the end of this month. It seems fine with Cirrus. πr² (t • c) 15:59, 4 March 2014 (UTC)[reply]

I see the problem. Two results for Kite, one not bold and second Bold. There's also a size difference although the date of modification is the same. This seem to definitely be exposing some sort of bug. A bug report should be filed. Hopefully somebody clever enough can figure out more detail of what's occurring. Jason Quinn (talk) 15:50, 5 March 2014 (UTC)[reply]

addOnloadHook deprecated for ResourceLoader?

I haven't been keeping updated with the latest code changes on Wikipedia. So I heard addOnloadHook is being deprecated with ResourceLoader? I usually use jQuery's $(document).ready() anyway, so it's not a big deal, but for some of my scripts I still use addOnloadHook because it runs the code after all $(document).ready()'s have been run.

So what would be the equivalent when written with ResourceLoader?

Thanks Gary (talk · scripts) 18:36, 4 March 2014 (UTC)[reply]

Check your console... ""MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead"" suggests to me that it is already deprecated... There's actually a bunch of other deprecated stuff too that should be fixed. ""MWDeprecationWarning: Use of "insertTags" property is deprecated. Use mw.toolbar.insertTags instead"", ""MWDeprecationWarning: Use of "wikiGetlink" property is deprecated. Use mw.util.getUrl instead."", and ""MWDeprecationWarning: Use of "mwCustomEditButtons" property is deprecated. Use mw.toolbar instead"". — {{U|Technical 13}} ^{(t • e • c)} 19:52, 4 March 2014 (UTC)[reply]

@Gary: all the deprecated functions with their RL/jQuery equivalents is at: mw:ResourceLoader/JavaScript Deprecations. Legoktm (talk) 20:26, 4 March 2014 (UTC)[reply]

Okay thanks, I guess it just switched to jQuery. So most of my scripts are fine already. I find addOnloadHook is still useful for scripts that need to be run last, though, such as when they depend on another script (and the order of script-loading is unspecified). Gary (talk · scripts) 17:04, 5 March 2014 (UTC)[reply]

@Gary: addOnloadHook(…) is mostly equivalent to $(window).on('load', …), with the caveat that the latter won't fire if you call it after the page has already been loaded – this only matters if you're doing weird things with loading scripts on-demand or when developing and testing code in the browser's console.

It is also worth noting that you can explicitly specify the dependencies of your script (and thus the load order) if the dependencies are ResourceLoader-enabled gadgets instead of random scripts (using mw.loader.using(['ext.gadget.<name>', …], function(){…}))), which is one very big pro of caring about RL :) Matma Rex talk 19:24, 5 March 2014 (UTC)[reply]

Turning off Javascript

Is it possible to disable JavaScript on Wikipedia, through Wikipedia? I noticed that Wikipedia works a lot slower for me when I'm logged onto my account than when I'm logged off. Is there any way to fix this? (with turning off JavaScript being one possibility) All Hallow's Wraith (talk) 01:40, 5 March 2014 (UTC)[reply]

The difference in speed you are noticing may be due to caching. For anonymous users viewing articles, the entire page is cached, which speeds up load times considerably. If you are logged in, MediaWiki needs to generate the links to your user page etc. at the top of the page, so it can't cache the whole page. There are a few other caching layers that work for logged-in users, though, so it depends what you are doing. When you are logged in, do you notice slower loading times for history view or edit view? Those aren't cached in the same way that read view is. Also, there isn't any way to turn off JavaScript from within Wikipedia, but you could try disabling some of your gadgets from your preferences. (I see you have already cleared your common.js page.) — Mr. Stradivarius ^{♪ talk ♪} 02:12, 5 March 2014 (UTC)[reply]

"When you are logged in, do you notice slower loading times for history view or edit view?" Yes, I definitely do. All Hallow's Wraith (talk) 02:34, 5 March 2014 (UTC)[reply]

P.S., how do I turn off all the MediaWiki stuff you are talking about? All Hallow's Wraith (talk) 02:39, 5 March 2014 (UTC)[reply]

If you are noticing different loading times on history and edit views as well, then caching probably isn't the issue. And you can't turn it off, anyway. (Not that you would want to, as it makes things faster.) Have you tried disabling your JavaScript gadgets? Go to Preferences > Gadgets and try removing all of them. (Also, try and remember which ones you had turned on so that you can turn the necessary ones back on later - some of them are really useful.) Let me know if that works or not. — Mr. Stradivarius ^{♪ talk ♪} 05:05, 5 March 2014 (UTC)[reply]

"Not that you would want to, as it makes things faster" - I would definitely want to. In my previous browser, I could turn off JavaScript, and Wikipedia was unquestionably faster without it. It doesn't add anything to my Wikipedia experience. As for gadgets, I have all of them turned off. It doesn't make it any faster... All Hallow's Wraith (talk) 05:25, 5 March 2014 (UTC)[reply]

@All Hallow's Wraith: I believe that misunderstood Mr. Stradivarius' comment. He said that you would not want to turn off caching, that statement was not talking about JavaScript. As to JavaScript, you may be able to turn off JavaScript within your browser. At least for Firefox, the NoScript extension allows you to disable scripts based on various criteria, particularly the domain from which they are hosted. For Google Chrome there appear to be a few, but I have not tried any of them and the reviews are such that I hesitate to point you at a specific one. You did not specify your current browser, so it is hard for anyone to make recommendations on that end. — Makyen (talk) 06:17, 5 March 2014 (UTC)[reply]

Oh, sorry, the browser is internet explorer 11. All Hallow's Wraith (talk) 12:44, 5 March 2014 (UTC)[reply]

Navboxes and reflist displaying inside of another template

Something is clearly wrong with the Tic Price article and I'm not sure how to fix it. Northern Antarctica (talk) 04:26, 5 March 2014 (UTC)[reply]

The combination of templates on the page was creating an unclosed wikitable. I've fixed the immediate problem with this edit, but someone who knows the correct statistics should replace the |} code that I added with {{CBB yearly record end}}. — Mr. Stradivarius ^{♪ talk ♪} 04:45, 5 March 2014 (UTC)[reply]

Freeze Panes - Top Row in Tables

Could we implement an option where the top row in a table (the one with labels) would scroll along with the broswer window when viewing long tables? Microsoft Excel has a similar feature called "Freeze Panes." It's rather annoying to have to scroll back up to recognize what a column means and we have many pages of long tables where I think such an enhancement would greatly aid the user experience. For example Assembly of the International Space Station --Rwheimle (talk) 10:57, 5 March 2014 (UTC)[reply]

The technology for this does exist; but see MOS:SCROLL. --Redrose64 (talk) 12:21, 5 March 2014 (UTC)[reply]

Template:Bug. Matma Rex talk 12:29, 5 March 2014 (UTC)[reply]

Preview now jumps directly to edit window

When I preview an edit, I'm now taken directly to the edit window (ironically, from the edit window) instead of the the top (preview, with the red "This is only a preview...") section. Trouble is, I don't know if I need to continue editing until after I've read the preview and it's inconvenient to have to keep scrolling up. I checked my preferences, and couldn't find any gadgets or other stuff that would cause this. I use XP (stop laughing) and FF 27.0.1. Is it a bug, or is it me? Thanks for any help and all the best, Miniapolis 16:54, 5 March 2014 (UTC)[reply]

I cannot reproduce this effect with Firefox 27.0.1 on Windows 8, under skins Modern and Monobook, preferences: Editing Preview:

[ ] Show preview on first edit

[x] Show preview before edit box

[ ] Use live preview (experimental). I've disabled Gadget wikEd, and enabled wikEdDiff, and disabled all Beta Features. Also tried with and without "Show edit toolbar" under Editor preferences. -84user (talk) 18:41, 5 March 2014 (UTC)[reply]

This is a wikEd thing (may be part of something else too). When you say you "disabled" do you mean you unchecked all wikEd boxes on the gadget page or clicked the icon in the top right corner to disable? Cacycle may be able to help with this question... — {{U|Technical 13}} ^{(t • e • c)} 18:53, 5 March 2014 (UTC)[reply]

I use Vector, but don't think something like this is skin-dependent. "Show preview before edit box" is checked; it's there, but now I have to scroll up from the edit window to read it. Oddly, though, I can't seem to disable wikEd (I don't have wikEdDiff checked); when I uncheck wikEd on the gadgets-editing menu, save, shift-reload to purge the cache and return to it, it's checked again (and my original problem persists)! Thanks for the help and all the best, Miniapolis 20:45, 5 March 2014 (UTC)[reply]

Finally disabled wikEd, but since the problem persists I'm going to re-enable it. Miniapolis 20:57, 5 March 2014 (UTC)[reply]

Bug report: Search settings in Preferences

Tracked in Phabricator
Task T64268

Seems like checkboxes in "Search" section of the "Preferences" are broken, here are more details.

My settings included a selection of namespaces to be searched, and when I accessed this "Preferences" section yesterday, all checkboxes were displayed as empty, what's the first issue. After selecting a few namespaces (other than "Search in all namespaces") and submitting the form, all checkboxes are displayed back as cleared. The only thing that seems to be working is the "Search in all namespaces" checkbox; when selected and submitted/saved, this checkbox displays back as expected. That's the second issue.

Tested yesterday and today on English Wikipedia and Wikimedia Commons, and they behave the same; browsers used were Firefox 24 and 27. Obviously a bug – any chances, please, for fixing it? — Dsimic (talk | contribs) 17:33, 5 March 2014 (UTC)[reply]

This seems to be related to gerrit:110610 by 01tonythomas (mw:User:01tonythomas). Helder.wiki 19:01, 5 March 2014 (UTC)[reply]

*sigh* yep... Anomie, Matma Rex — {{U|Technical 13}} ^{(t • e • c)} 19:06, 5 March 2014 (UTC)[reply]
- No, not related to that patch. Anomie ⚔ 20:26, 5 March 2014 (UTC)[reply]

That patch isn't deployed here yet – on https://gerrit.wikimedia.org/r/#/c/110610/, click "Included in" – only branches are master and 1.23wmf16. The English Wikipedia is at 1.23wmf15 right now (see Special:Version). I can reproduce the bug (fascinating), but the cause must be different. Matma Rex talk 19:13, 5 March 2014 (UTC)[reply]

Bug report: Appearance settings in Preferences

On Wikimedia Commons, "Thumbnail size" label in the "Appearance" section is displayed in Greek language (I guess) instead of being displayed in English. No other labels are affected by this issue, and they're all displayed in English as expected. Also, English Wikipedia isn't experiencing this issue.

Obviously a bug – any chances, please, for fixing it? — Dsimic (talk | contribs) 17:38, 5 March 2014 (UTC)[reply]

Trout Commons:User:Badseed for this edit. Anomie ⚔ 19:31, 5 March 2014 (UTC)[reply]

Fixed. Trijnstel_talk 20:08, 5 March 2014 (UTC)[reply]

Great, thank you for fixing it so quickly! — Dsimic (talk | contribs) 20:38, 5 March 2014 (UTC)[reply]

Underlines versus fractions

Resolved

I am creating a link like this: 4 ft 8+1⁄2 in. Is it possible and advisable to interrupt the underlines at the fraction (denominator)? I found that class="nounderlines" doesn't seem to work on parts of a wikilink. -DePiep (talk) 18:34, 5 March 2014 (UTC)[reply]

There is no such class, but even with an inline styling (text-decoration: none;) it does not seem to work. — Edokter (talk) — 20:05, 5 March 2014 (UTC)[reply]

@DePiep and Edokter: Yes, it's not possible to "undo" a text-decoration rule (used internally by the browser for underlines, strike-throughs and some more exotic things), unlike, say font-weight or text-transform. That's because it's not applied to the individual characters, but to an entire text "box" (which can in fact be seen in the original example here). My explanation is probably not very clear, but consider the difference between ~~1⁄2~~ (where the entire "box" is striken) and ¹⁄₂ (where every character is striken separately). Matma Rex talk 20:47, 5 March 2014 (UTC)[reply]

OK, not possible then. For Edokter: Main page and Main page. -DePiep (talk) 20:55, 5 March 2014 (UTC)[reply]

MediaWiki:Edittools?

It seems like "Edittools" has disappeared from under the Edit summary on pages that I'm editing. The one that usually can display "Wiki markup" tools, like inserting a defaultsort, etc. Funandtrvl (talk) 19:47, 5 March 2014 (UTC)[reply]

It's there as I type this. There is discussion at MediaWiki talk:Edittools and User talk:Edokter, possibly elsewhere. --Redrose64 (talk) 19:53, 5 March 2014 (UTC)[reply]

Funandtrvl, have you tried clearing your cache? Helder.wiki 20:00, 5 March 2014 (UTC)[reply]

(ec) Please check if "CharInsert" is still enabled in your gadget preferences. — Edokter (talk) — 20:03, 5 March 2014 (UTC)[reply]

Yes, I cleared my cache and reset all my preferences. It was working yesterday, but not today on Firefox 27.0.1. Funandtrvl (talk) 20:04, 5 March 2014 (UTC)[reply]

Works on my end. Do you perhaps have javascript turned off? (Happens to me all the time.) — Edokter (talk) — 20:09, 5 March 2014 (UTC)[reply]

Now it's working! Funandtrvl (talk) 20:13, 5 March 2014 (UTC)[reply]

RFC: Should we hide template and image deletion notices from users not logged in?

Images and templates currently undergoing a deletion proposal always have a notice similar to the following:

‹ The template below (<template name>) is being considered for deletion. See templates for discussion to help reach a consensus.›

Is it really necessary to involve users that are not logged in, most of which are not experienced with the Wikipedia deletion process, by displaying this notice to everyone? Can we hide this notice from users who are not logged in? —DragonLord ^talk^/^contribs 20:01, 5 March 2014 (UTC)[reply]

Please, no RfCs on this page. Create a page for it or use a different village pump. Yes it's technically possible to do. Whether we want to do it is a policy issue. Legoktm (talk) 20:14, 5 March 2014 (UTC)[reply]

Absolutely not. Non-logged-in users are not debarred from participating in XfDs, therefore must not have information about XfDs hidden from them. --Redrose64 (talk) 21:05, 5 March 2014 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=598308756"

Categories:

Hidden category:

Non-talk pages that are automatically signed

@@ Line 604: / Line 604: @@
 Is it really necessary to involve users that are not logged in, most of which are not experienced with the Wikipedia deletion process, by displaying this notice to everyone? Can we hide this notice from users who are not logged in? <span style="font-family:Georgia">—[[User:DragonLord|<span style="color:red">DragonLord</span>]][[User talk:DragonLord|<sup style="color:green">talk</sup>]]<sup>/</sup>[[Special:Contributions/DragonLord|<sup style="color:blue">contribs</sup>]]</span> 20:01, 5 March 2014 (UTC)
 :Please, no RfCs on this page. Create a page for it or use a different village pump. Yes it's technically possible to do. Whether we want to do it is a policy issue. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 20:14, 5 March 2014 (UTC)
+::Absolutely not. Non-logged-in users are not debarred from participating in XfDs, therefore must not have information about XfDs hidden from them. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] ([[User talk:Redrose64|talk]]) 21:05, 5 March 2014 (UTC)