Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Sidebar menus: reply: I've got a script that does this
Line 986: Line 986:
Our public computers at our local library often have givrn me trouble. We now have HP Compaq Pro 6300. The "START" page says the OS is Windows 7 (ver. unknown), and Windows Help says the browser is Internet Explorer 9 (ver. unknown). When I attempt to Log in, I repeatedly find myself back on an edit page with an error message: "You are not logged in!" I am sending this message from my cellphone, but losing battery fast: please, if gou can help, leave me a message in my User_Talk page: user:Ragityman. I will attempt to check it from this library computer.
Our public computers at our local library often have givrn me trouble. We now have HP Compaq Pro 6300. The "START" page says the OS is Windows 7 (ver. unknown), and Windows Help says the browser is Internet Explorer 9 (ver. unknown). When I attempt to Log in, I repeatedly find myself back on an edit page with an error message: "You are not logged in!" I am sending this message from my cellphone, but losing battery fast: please, if gou can help, leave me a message in my User_Talk page: user:Ragityman. I will attempt to check it from this library computer.
[[User:Ragityman|Rags]] ([[User talk:Ragityman|talk]]) 20:42, 12 May 2014 (UTC)
[[User:Ragityman|Rags]] ([[User talk:Ragityman|talk]]) 20:42, 12 May 2014 (UTC)

== Media Viewer launches next week on the English Wikipedia ==

[[File:Media_Viewer_Desktop_-_Large_Image_Opaque_Info.png|thumb|Media Viewer lets you see images in larger size]]

[[File:Media Viewer - Survey Graph - Overall Usefulness - May 5 2014.png|thumb|[[mw:Multimedia/Media_Viewer/Survey/Results_-_05-05-2014|The majority of users find Media Viewer useful]].]]

Greetings! As discussed in [[w:Wikipedia:Village_pump_(technical)/Archive_126#Introducing_Media_Viewer|earlier posts]], [[w:Wikipedia:Media_Viewer|Media Viewer]] is scheduled to launch on the English Wikipedia next week, to provide a better viewing experience for our users.

[[mw:Multimedia/About_Media_Viewer|Media Viewer]] has been tested extensively on many large wikis around the world, and the feedback collected from thousands of users suggests that this tool is generally useful to them, as outlined in [[mw:Multimedia/Media_Viewer/Survey/Results_-_05-05-2014|these survey results]]. More importantly, the rate of favorable feedback keeps increasing across all languages over time: for example, the French approval rate started out at about 64% a few weeks ago, and is now up to 70%, which is very encouraging.

Here on the English Wikipedia, over [[Special:Preferences#mw-prefsection-betafeatures|13,874 beta users]] have been testing it, since the tool was first deployed as a beta feature in November 2013. Thanks to all their helpful feedback, Media Viewer has been greatly improved in recent months, and we are now getting ready to roll it out on all wikis worldwide.

Media Viewer will be enabled by default on the English Wikipedia on Thursday, May 22 at about 20:00 UTC. We will deploy this tool very carefully and keep a close eye on this release, to make sure it all goes smoothly. The tool will then be released to all wikis the following week, as described in [[mw:Multimedia/Media_Viewer/Release_Plan#Large_Wikis|this release plan]].

Please let us know if you have any questions or comments about Media Viewer, which you can [[mw:Multimedia/About_Media_Viewer#How_can_I_help.3F|test here in beta]] -- or learn more about on [[mw:Help:Multimedia/Media_Viewer|this Help page]] (which includes tips for bypassing this tool, or turning it off in your preferences). You are invited to [[w:Wikipedia_talk:Media_Viewer|share your feedback in this discussion]], to help improve this feature. You're also welcome to [https://www.surveymonkey.com/s/media-viewer-1?c=help-enwiki take this quick survey] -- or join [[mw:Talk:Multimedia/About_Media_Viewer|this in-depth discussion on MediaWiki.org]], as you prefer.

Many thanks to all the community members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This has been an exceptionally productive partnership, which we hope to build on for future projects. [[User:Fabrice Florin (WMF)|Fabrice Florin (WMF)]] ([[User talk:Fabrice Florin (WMF)|talk]]) 01:15, 13 May 2014 (UTC)

Revision as of 01:15, 13 May 2014

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (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.

Reflist should be shown when previewing a section edit

This is an attempt to revive an older discussion, which was unsuccessful because of dive into implementation detail. The essence of proposal is following:

In section preview the editing interface should provide preview of references (as formatted with {{reflist}}).

Rationale: normally reference list is not available during section editing, which leads to two kinds of undesired edits:

  • an editor misformats citation template(s) or
  • an editor forgets to remove {{reflist}} which was added temporarily to be able to review references.

Even if editor manages to avoid both issues, verifying correctness of citation formatting takes longer then it could have taken, be references presented during preview.

I specifically ask to avoid discussing placement, scope and implementation details for the required change. This poll is held in order to determine consensus on the general idea, so that more in-depth discussion about the proper way to implement this proposal could be started. — Dmitrij D. Czarkoff (talktrack) 10:59, 25 April 2014 (UTC)[reply]

Support

  1. As nom. — Dmitrij D. Czarkoff (talktrack) 10:59, 25 April 2014 (UTC)[reply]
  2. I can't believe that anybody would actually oppose this idea, which is one of the oldest problems on the entire site. — Scott talk 11:36, 25 April 2014 (UTC)[reply]
  3. Very good idea. It Is Me Here t / c 13:22, 26 April 2014 (UTC)[reply]
  4. Very helpful when editing refs. KonveyorBelt 17:20, 1 May 2014 (UTC)[reply]
  5. If there's a script out there, I'd be happy to take that, but this seems like a solution that should always be implemented, or at the very least a Gadget. Supernerd11 :D Firemind ^_^ Pokedex 14:15, 9 May 2014 (UTC)[reply]

Oppose

*It's not absolutely necessary. There has been a workaround for a decade or so: just tack in a temporary <references/> during your edits. --Ancheta Wis   (talk | contribs) 13:58, 25 April 2014 (UTC) [reply]

Abstain

  1. Due to the constrains of no discussion of implementation. --  Gadget850 talk 11:32, 25 April 2014 (UTC)[reply]
    Gadget850, I'm pretty sure you could have suggested my response. I reacted in opposition before reading what you said. Redrose64, I concur. --Ancheta Wis   (talk | contribs) 14:24, 25 April 2014 (UTC)[reply]

Where are the HTML paragraph tags coming from?

I'm contemplating changes to {{infobox ship career}}. Mostly the changes I wanted to make were cosmetic. But, I've noticed an oddity that I can't explain. It is very common for editors to list multiple items in a single field. For example, if a ship over its lifetime has had multiple names, those might be listed like this:

|Ship name=Ship name1<br />Ship name2<br />Ship name3<br />Ship name4<br />Ship name5<br />Ship name6

which produces this html:

<td>Ship name1<br /> Ship name2<br /> Ship name3<br /> Ship name4<br /> Ship name5<br /> Ship name6</td>

But, editors very often do this:

|Ship name=Ship name1<br />
Ship name2<br />
Ship name3<br />
Ship name4<br />
Ship name5<br />
Ship name6

which produces this html: <td>Name:</td> <td> <p>Ship name1<br /> Ship name2<br /> Ship name3<br /> Ship name4<br /> Ship name5<br /></p> Ship name6</td> </tr>

In the rendered display, the Name: text in the left column is at one level but the list of names in the right column is vertically offset slightly lower. There is also a gap between the next-to-last and last names. You can see this at Template:Infobox ship career/testcases#Live template. Special:ExpandTemplates shows that the <p>...</p> tags are not the result of the template but must come from some other source.

I can get around this by stripping newlines from parameter values by adding this to each parameter in the template with (the template sandbox uses this for |Ship name=):

{{#invoke:String|replace|{{{Ship name|}}}|[^%S ]||plain=false}}

Is there a better way? Is there a way to tell whatever process follows the template to leave the contents of the <td>...</td> alone? Is there css or other markup that can go in the <td>...</td> to accomplish the same thing?

Trappist the monk (talk) 14:56, 27 April 2014 (UTC)[reply]

In my experience, when you get unexplained HTML then HTML Tidy is at work. Looks like you want to make this work either way editors add the list. The better way is to add |datastyle = class="hlist" and then use * list markup, but this means you have to change each article. --  Gadget850 talk 15:53, 27 April 2014 (UTC)[reply]
I just tried the affected marker markup in a MediaWiki message on the test wiki here (result). This suggests that it's a parser issue, and not an HTML Tidy issue, as HTML tidy isn't run on MediaWiki messages. (If someone could confirm my line of reasoning here, that would be great.) — Mr. Stradivarius ♪ talk ♪ 16:09, 27 April 2014 (UTC)[reply]
One of the things that strikes me as interesting is the position of the <p>...</p> tags. If there is a reason for them, why do they not enclose the entire content of the <td>...</td>?
Trappist the monk (talk) 17:40, 27 April 2014 (UTC)[reply]
It is a parser issue; it counts linebreaks. Two linebreaks triggers a paragraph. Inserting <br /> makes it lose count somehow, which may result in a misplaced closing paragraph tag. Edokter (talk) — 20:35, 27 April 2014 (UTC)[reply]
WP:SHIPS have determined that * list markup in ship infoboxes is not acceptable. This is why there are lots and lots of parameters that use the markup I describe above. Additionally, there are companion templates where similar markup is preferred. The problem doesn't occur with {{plainlist}} but editors aren't very inclined to use it and making it compulsory would not be accepted. Which leaves me to find an alternate solution.
Trappist the monk (talk) 16:37, 27 April 2014 (UTC)[reply]
Ehm on your TD element, add class="hlist" or class="plainlist" and start converting to proper lists. If there is no list in the content, the class won't do anything, but if there is, it just works. Also you would no longer have to advise people to use the plainlist template to do the same, it would be automatic if people use proper lists. These problems have been solved, better to use the solutions than to muddle along and create less accessible articles. If WP:SHIPS has actual problems with using hlist or plainlist styling, then they should bring those concerns here, so we can help them find better technical solutions. Messing with line breaks is just one of the reasons we have converted almost every instance of such type of lists into hlist andplainlists over the past 5 years. —TheDJ (talkcontribs) 23:09, 27 April 2014 (UTC)[reply]
Thanks for that, it was exactly what I was looking for. But, was it really necessary to chastise me for not knowing that this solution existed?
Trappist the monk (talk) 11:09, 28 April 2014 (UTC)[reply]
This works great, but ... In normal * list markup, ** indents the list item. That doesn't seem to be the case for <td class="plainlist">...</td> ({{plainlist}} doesn't appear to support ** markup either). Is this intended? A bug? Is there a better way around it than to insert some number of &nbsp;s between the * and the list item text?
Trappist the monk (talk) 13:07, 28 April 2014 (UTC)[reply]
You can also use {{unbulleted list}} if you're averse to inserting asterisks. As for the lack of indentation, I'm pretty sure that's intended (although I don't know who decided it). You can set a style of "margin-left: 1.6em;" if you want to fake the indentation. — Mr. Stradivarius ♪ talk ♪ 13:24, 28 April 2014 (UTC)[reply]
Is this not a bug then? Certainly this defies user expectation given that we are trained by the everyday use of normal * list markup (H:LIST) to expect an indent when we use ** in a list. Who do I talk to to get this fixed?
For these ship infobox templates, I'd prefer to make life as simple as possible for editors. That means allowing * list markup, but hiding the bullet points. Editor TheDJ's excellent suggestion to use <td class="plainlist"> ... </td> accomplishes almost all of that goal. The only problem is that class="plainlist" prevents whatever it is that undoes the ** indented list. The output from the template is the same whether it uses <td class="plainlist"> ... </td> or not.
Trappist the monk (talk) 14:54, 28 April 2014 (UTC)[reply]
Normally, lists are indented and have a bullet marker. The plainlist markup removes both of these in CSS so the list is flush with its surrounding text. Nested lists were never intended or anticipated, but I think I can add one line to make that possible. Edokter (talk) — 16:38, 28 April 2014 (UTC)[reply]
Sandbox
History
Spain
Name
  • Ship name 1
  • Ship name 2
    • Ship name 3
  • Ship name 4
  • Ship name 5
  • Ship name 6
That would be great! If, for whatever reason it's inappropriate to change the plainlist class, is it possible to create a 'local' version, perhaps plist class, that can be made part of the template? A handful of experiments that I did weren't very productive, but then I have next to no knowledge of css.
Trappist the monk (talk) 18:09, 28 April 2014 (UTC)[reply]
Wow! Look at that! Now, <td class="plainlist"> ... </td> is doing exactly what it should be doing. What's changed, and who do I thank?
Trappist the monk (talk) 00:13, 29 April 2014 (UTC)[reply]

This has changed, and you need to thank Edokter. :) (Also, sorry for completely misinterpreting your comment yesterday and giving you a nonsense answer...) — Mr. Stradivarius ♪ talk ♪ 04:27, 29 April 2014 (UTC)[reply]

Such a simple fix. Thank you.
@Edokter: Thank you for making that fix, you've just made my life measurably easier. I am grateful.
Trappist the monk (talk) 09:54, 29 April 2014 (UTC)[reply]

Sorry

The fix had unintended side effects, so I had to undo it. I could reinstate it, but only under the condition that hlist should never be nested inside a plainlist. See MediaWiki talk:Common.css#plainlist + hlist indentation. Edokter (talk) — 22:22, 3 May 2014 (UTC)[reply]

Automatic wikiproject tagging of pages redirected after moves of articles already under scope of said Wikiproject

It'd be really handy if the redirects left behind pages that were moved were automatically tagged as redirects under the scope of the existing Wikiprojects the page is under. Would save a lot of time and is useful in keeping track of the articles (eg in project-wide watchlists). --LT910001 (talk) 03:24, 28 April 2014 (UTC)[reply]

It seems that what you are asking for is the WikiProject banner templates to be copied from the existing talk page to the newly-created talk page redirect, but with all the templates having |class=redir instead of whatever was set previously. There's nothing that we can do about this, because the page move process is part of the MediaWiki software. You would need to file a feature request at bugzilla:, but don't get your hopes up - it took them *years* to change the software so that the automatic addition of {{R from move}} was actioned. They are also likely to refuse on the grounds that MediaWiki changes affect all languages, plus Commons, Meta, Wiktionary, etc., and WikiProject templates are only found on a few Wikipedias: you might expect there to be several dozen equivalents to Template:WikiProject France - but there are only four, so the MediaWiki devs are not likely to consider this a priority. --Redrose64 (talk) 14:20, 28 April 2014 (UTC)[reply]
You should be able to get a WP:BOTREQ that will handle this. I asked for a one-off list a few years back (in the opposite direction, because WP:MED doesn't normally tag redirects), and the code is at the top of User:WhatamIdoing/Med_redirects. WhatamIdoing (talk) 18:29, 28 April 2014 (UTC)[reply]
Thanks WAID and Redrose for your responses. I think this would be very handy but I think it would be best if it was ongoing, it just makes moving pages that much more time-consuming. There seems to be an extensive process to get this going, and I think I will just return to my burrow and continue editing. --LT910001 (talk) 04:34, 2 May 2014 (UTC)[reply]

WP 1.0 web tool is down

Clicking on the normal link or any of its sub links gives a 404 error: http://tools.wmflabs.org/enwp10/ Brirush (talk) 17:19, 29 April 2014 (UTC)[reply]

@Brirush: Thanks! I've fixed this and the tool is now operational. Sorry for any inconvenience. Theopolisme (talk) 22:14, 30 April 2014 (UTC)[reply]
@Theopolisme:Great! Thanks for volunteering your time.Brirush (talk) 16:03, 1 May 2014 (UTC)[reply]
@Brirush and Theopolisme: The 404 error is back. – Editør (talk) 09:48, 9 May 2014 (UTC)[reply]

Error Rendering Book

I was trying to render a book from a article, and it failed at about 38%. The page it hung on rendering was List of jōyō Kanji, which has a large table in it. It was able to save any format besides PDF, so I think it may be a bug of soem sort or a pagees limitation.


Here is the list of pages I was turning into a book:

Japanese writing system

Dakuten

Katakana

Kana

Kanji

List of jōyō kanji

Hiragana

Hentaigana

Help:IPA for Japanese

Romanization of Japanese


I was making a collection of articles on the Japanese Language. Downloading the EPUB version and converted it to PDF with Calibre. Just letting you know for future reference incase anyone else experiences this. I will check on this post every so often to see if there are any replies.

69.131.180.86 (talk) 17:58, 30 April 2014 (UTC)[reply]

Confirming this. Steps to reproduce:
  1. Go to List of jōyō kanji and click the "Create a book" link under the print/export menu.
  2. Click "Start book creator". This takes you back to List of jōyō kanji.
  3. Click "Add this page to your book".
  4. Click "Show book (1 page)".
  5. Set the format as "e-book (PDF)", and click Download.
For me, it rendered 85% of the page and then stopped. Rendering that 85% took a long time, though, perhaps about a minute. Refreshing the page after that didn't change the 85% figure. The table on List of jōyō kanji is just over 2000 entries, so it's not surprising that it takes a long time to render. It sounds like something is timing out, but I'm not sure exactly what. — Mr. Stradivarius ♪ talk ♪ 10:03, 1 May 2014 (UTC)[reply]
Might be yet another bug in the Collection extension (and there is work going on to rewrite it). A bug report could be filed. --AKlapper (WMF) (talk) 16:32, 3 May 2014 (UTC)[reply]

The little toolbar having a problem...

Screenshot of the cite button in the classic edit toolbar.

...specifically, the handy one at the top of the edit window. And more specifically, the "Cite" button, instead of being on the far right, is now in the dead center of the bar (between the 'horizontal line' and 'redirect' buttons), which means when it's pressed the bar becomes disjointed with the select-a-citation-template bar splitting it. - The Bushranger One ping only 21:02, 30 April 2014 (UTC)[reply]

@The Bushranger: I assume you are talking about MediaWiki:RefToolbarLegacy.js, which is loaded if you disable the WikiEditor toolbar. Its icon is displayed in the end (after the "<ref/ref>" button) after I clear the cache in my browser. Have you tried that? Helder.wiki 21:13, 30 April 2014 (UTC)[reply]
@Helder.wiki: My browser (Firefox 22) automatically dumps the cache every time I close it. And I just now tried a hard refresh (bypassing the cache) on this very edit window. {{cite}} is still dead center in the toolbar between "horizontal line" and "redirect". - The Bushranger One ping only 23:32, 4 May 2014 (UTC)[reply]
I uploaded an screenshot from my test using Firefox 29. The button (in the middle) is opening just fine. However, notice the position of buttons from different scripts in the toolbar depends on the order those scripts are loaded. So, if the RefToolbar gadget is loaded before MediaWiki:Common.js/edit.js, it is normal that its button will be displayed before the buttons such as . On the other hand, the position of the buttons Web, News, etc... is defined by MediaWiki:RefToolbarLegacy.js (which I didn't touch during the migration of the script to a gadget). This edit by TheDJ should make it better positioned, since the old "toolbar.appendChild(citemain)" meant the script was assuming its main button to be always in the end of the toolbar (which is not always the case). Helder.wiki 13:05, 5 May 2014 (UTC)[reply]
Well, it's working just fine for me, it's just ugly now what with it opening its buttons in the middle of the bar (Which, oddly perhaps, it didn't put the "ref" button after them even when it was located on the right, just before that button.) - The Bushranger One ping only 23:54, 8 May 2014 (UTC)[reply]
And now the buttons are properly placed when I click on "cite". Thanks for the fix. - The Bushranger One ping only 00:46, 11 May 2014 (UTC)[reply]

Why was the cite button moved?

I am using the MonoBook skin and in the last couple days, the handy {{cite}} button above the edit box has been moved from being the last one on the right (after the <ref></ref> button) to being in the middle, between the ---- and the #Redirect buttons. As a side effect, when cite button is pressed, the functions appear between two rows of buttons! What gives?-- Brainy J ~~ (talk) 16:23, 2 May 2014 (UTC)[reply]

Pinging Helder.wiki. Edokter (talk) — 16:39, 2 May 2014 (UTC)[reply]
Better now ? —TheDJ (talkcontribs) 21:01, 3 May 2014 (UTC)[reply]
In my tests it is working just fine (see the screenshot). Helder.wiki 13:05, 5 May 2014 (UTC)[reply]

Back button not working properly

When ever I go from Wikipedia:Articles for deletion/Registry Dr. to Wikipedia:WikiProject Deletion sorting/Internet then click back there's no problem but when ever I go from Wikipedia:Articles for deletion/Registry Dr. to Wikipedia:WikiProject Deletion sorting/Internet then click another article in Wikipedia:WikiProject Deletion sorting/Internet, clicking back the first time does nothing and clicking back a second time takes me back 2 pages to Wikipedia:Articles for deletion/Registry Dr. Blackbombchu (talk) 02:38, 1 May 2014 (UTC)[reply]

It works for me. The back button is a browser feature. What is your browser? And please give an example article. PrimeHunter (talk) 08:44, 1 May 2014 (UTC)[reply]
It's internet explorer 11. It wasn't just one article but I noticed the problem on all the articles in the articles in the Wikipedia:WikiProject Deletion sorting/Internet that I clicked. The problem was not with the article itself but with which page I got to it from. A little while after I wrote about that technical issue, I noticed that it wasn't always happening anymore. Blackbombchu (talk) 17:08, 1 May 2014 (UTC)[reply]

"Your preferences have been saved." green box

It hurts my eyes and makes me nauseous just looking at it. Can the green color be toned down a bit?—cyberpower ChatOnline 17:49, 1 May 2014 (UTC)[reply]

Actually it's the border causing the issue. Can the border color be toned down instead? — Preceding unsigned comment added by Cyberpower678 (talkcontribs) 17:51, 1 May 2014 (UTC)[reply]
.successbox {
    color: #009000;
    border-color: #B7FDB5;
    background-color: #E1FDDF;
}
These are the default settings. Paste that into Special:MyPage/common.css, alter the colour values e.g. to border-color: #c7ecc6; and save. --Redrose64 (talk) 18:04, 1 May 2014 (UTC)[reply]
Awesome. Perfect. Thanks.—cyberpower ChatOnline 18:18, 1 May 2014 (UTC)[reply]

"Edit links" doesn't appear anymore (with Monobook)

Hi. The "Edit links" feature on the side navigation doesn't appear anymore when I choose the Monobook theme. If I set the theme to Vector, it works perfectly but I prefer Monobook. The bug appears on every version of Wikipedia. --Deansfa (talk) 21:08, 1 May 2014 (UTC)[reply]

It's working for me. On which pages is it failing for you? --Redrose64 (talk) 21:32, 1 May 2014 (UTC)[reply]
It's still appearing for me as well. Do you have any gadgets or scripts enabled that might be interfering with it? Novusuna talk 22:28, 1 May 2014 (UTC)[reply]
Thanks for your answers. On every page that doesn't have any interwiki link. For example: Pineau de Re. If you don't see any error, I will deactivate gadgets and customed scripts in my preferences. --Deansfa (talk) 22:40, 1 May 2014 (UTC)[reply]
Hmmm. In Vector skin, there is an "Add links" link; in Monobook, there isn't. --Redrose64 (talk) 22:59, 1 May 2014 (UTC)[reply]
I can see the relevant parts in the HTML source, but not in the DOM. I guess some script removes it when it shouldn't. Edokter (talk) — 00:14, 2 May 2014 (UTC)[reply]
I can confirm that as well, the edit links button still appears when there are interwiki links, but the add links button has disappeared in monobook. Novusuna talk 23:06, 1 May 2014 (UTC)[reply]
Thanks very much for the feedback. So it means it's not only me. I will temporary move to Vector, hoping it will be fixed (I do mostly interwiki edits). I am sure it worked well several hours ago. --Deansfa (talk) 23:27, 1 May 2014 (UTC)[reply]
And apparently, it is on every other projects Example on Wikisource. Is there a website/url where we can contacts the developers? --Deansfa (talk) 05:08, 2 May 2014 (UTC)[reply]
Bugs can be reported at bugzilla:. #Tech News: 2014-18 says: "The latest version of MediaWiki (1.24wmf2) was added to test wikis and MediaWiki.org on April 24. It will be added to non-Wikipedia wikis on April 29, and all Wikipedias on May 1 (calendar)." https://wikitech.wikimedia.org/wiki/Server_admin_log says for May 1: "18:42 logmsgbot: reedy rebuilt wikiversions.cdb and synchronized wikiversions files: Wikipedias to 1.24wmf2". Considering the timing, I guess this is the cause. testwiki: is already on 1.24wmf3 and I see "Add links" there: https://test.wikipedia.org/wiki/Page100?useskin=monobook. Is that how it usually looks in MonoBook? PrimeHunter (talk) 09:05, 2 May 2014 (UTC)[reply]
About your last question: Yes! --Deansfa (talk) 21:27, 2 May 2014 (UTC)[reply]
Yes, I spotted this last night when I created new articles that I know exist on the German and Dutch Wikis. Existing articles with iwiki links are fine, it's just when they don't have any link. Using Firefox too. Lugnuts Dick Laurent is dead 09:48, 2 May 2014 (UTC)[reply]
Not an issue with Modern or Cologne Blue so appears to limited to Monobook only. Nthep (talk) 10:00, 2 May 2014 (UTC)[reply]
I have submitted it at bugzilla:64741. In IE9 I'm missing "Add links" in all skins. PrimeHunter (talk) 10:35, 2 May 2014 (UTC)[reply]
I've found that if an article has a Wikidata entry for English Wikipedia alone, the "Edit links" link does not appear; but if the article also has a local ILL, the "Edit links" link does appear. For example, The End of Time (book): without local ILL; with local ILL; Wikidata entry. Monobook, Firefox 28 --Redrose64 (talk) 14:49, 2 May 2014 (UTC)[reply]

Please check if any of you have the "Compact language links" under the beta features enabled. A recent patch in Universal Language Selector may be responsible for this behaviour. Edokter (talk) — 11:02, 2 May 2014 (UTC)[reply]

I don't have "Compact language links". It makes no difference to enable it. PrimeHunter (talk) 11:36, 2 May 2014 (UTC)[reply]
Me neither. --Deansfa (talk) 16:42, 2 May 2014 (UTC)[reply]
Any update on when this might be fixed? Lugnuts Dick Laurent is dead 18:18, 6 May 2014 (UTC)[reply]
Any update on when this might be fixed? Lugnuts Dick Laurent is dead 10:42, 9 May 2014 (UTC)[reply]

Parser query

{{Infobox militant organization
| ideology = [[foo],]
}}

{{Infobox militant organization | ideology = [[foo],] }}

In the above example, the arguably broken wiki-link seems to suppress template closure.

Another legitimate link doesn't fix it

{{Infobox militant organization
| ideology = [[foo],] [[bar]]
}}

{{Infobox militant organization | ideology = [[foo],] bar }}

Nor does closing "]]" outside the template.

{{Infobox militant organization
| ideology = [[foo],]
}}]]

{{Infobox militant organization | ideology = [[foo],] }}]]

although closing the "}}" after the "]]"works

{{Infobox militant organization
| ideology = [[foo],]
}}]]}}
Village pump
Ideology[[foo],] }}]]

It seems to me that the parser gives up trying to match "[[" at the end of a line, and should therefore be happy with the "}} on the following line - and indeed not match another "]]" if it finds it.

Does this behaviour ascend to the heights of a bug? And if so is it already 'zillared?

All the best: Rich Farmbrough11:14, 2 May 2014 (UTC).

I'm inclined to think it does, because 1. the text is not malformed, we are supposed to be able to have unmatched delimiters. 2. it is not expected behaviour - it is fragile rather than robust - that we expect of wiki-mark-up. All the best: Rich Farmbrough11:23, 2 May 2014 (UTC).
I disagree; this is a standard case of unmatched template- and/or link markers. It behaves correctly in that it does not attempt to parse it as a template to begin with, because it detects this mismatch and resets all the counters, so the rest of the page may render correctly. There is only so much the parser can do to salvage invalid wiki markup. Edokter (talk) — 11:30, 2 May 2014 (UTC)[reply]

Trace route?

On the contribution page for longer IPs (like 2601:9:1B00:629:20D:93FF:FE7D:F8C8), there is a link to "Traceroute" but it leads not to a geolocation but to a website that requires individuals to sign up to use. Is there a more accessible alternative site to find out the general geolocation of an IP editor as exists for ordinary IPs? Liz Read! Talk! 14:27, 2 May 2014 (UTC)[reply]

Please see Wikipedia:Village pump (technical)/Archive 125#Wrong geonotice. --Redrose64 (talk) 14:50, 2 May 2014 (UTC)[reply]
Thanks for the link, Redrose64. I was sure I was not the only user having problems. It's so easy to find a geolocation for short IPs, it's frustrating not to have that information available for the new IPs. Liz Read! Talk! 14:56, 2 May 2014 (UTC)[reply]
I don't think that answers the question completely. The question is about sp-contributions-footer-anon linking to a service which one must register for, not Wikimedia's own geoiplookup. (I might be wrong.) A more useful link would be something like this. πr2 (tc) 18:33, 2 May 2014 (UTC)[reply]

Question about use of open WiFi

Dear technical experts: I am away from home at a conference. I have access to the Internet through my 3G/4G cell phone network, but with limited data. There is also an open WiFi access point here. I have been warned that if I use open WiFi to log in to Wikipedia, others could see my login and password and my account could be hacked, so I have been avoiding that. I have asked Wikipedia to keep me logged in for 30 days. My question is, if I am already logged in, using a private network, and then switch to the public network, is my login data still at risk? —Anne Delong (talk) 18:54, 2 May 2014 (UTC)[reply]

In my opinion, if you have your own computer and you have been using https on both networks you should be OK. EdJohnston (talk) 19:42, 2 May 2014 (UTC)[reply]
As long as you only communicate with Wikipedia using HTTPS there should be no risk. I recommend using HTTPS Everywhere if possible. And if you're concerned about a possible compromise of your account, it never hurts to change your password. For generating and managing secure passwords you might want to consider using a password manager. --108.38.196.65 (talk) 22:36, 3 May 2014 (UTC)[reply]
A lot of users have an alt account that they use to log in on public wifi. It's especially important for admins to be secure. -- Diannaa (talk) 22:52, 3 May 2014 (UTC)[reply]
Thanks. It turned out that I was too busy at the conference to do much editing; I will be sure to investigate all of the suggestions before next time. —Anne Delong (talk) 00:45, 5 May 2014 (UTC)[reply]

A non-admin closure could be good

{{resolved}} (question answered, but topic lives) - struck by OP editor: DePiep (talk) 00:35, 5 May 2014 (UTC)[reply]

Please see this TfD:Rellink. It can be closed by now. It is a simple TfD, but it has an interesting MediaWiki:Common.css edge. I'd like to see how an editor who knows about classes would close it. That would be (could be) a non-admin closure for quality. -DePiep (talk) 21:17, 2 May 2014 (UTC)[reply]

(m) A nice sideline question: how are classes added & changed & deleted? Is there a "Class for Discussion" route at mw? So far, I mostly see EDokter arguing & handling all very good, but still. -DePiep (talk) 21:47, 2 May 2014 (UTC)[reply]
Is done. -DePiep (talk) 02:43, 3 May 2014 (UTC)[reply]
It's just handled by talking about it at MediaWiki talk:Common.css, as far as I'm aware. — Mr. Stradivarius ♪ talk ♪ 16:38, 3 May 2014 (UTC)[reply]
BTW. classes are not ONLY used for styling. They are also used for semantics. So the fact that a dablink class is use explicitly tells you that the links inside it are disambiguation links. rellink means that the links are related. I'm not sure how many 3rd party software might be relying on such a thing, but such a dependency is possible.. Same with seealso (boilerplate is an old styling class btw, i don't think it is in use anymore). You always have to keep such things in mind. It does not seem that this has been terribly considered in the TfD however. TfD residents ought to know such things. —TheDJ (talkcontribs) 20:06, 3 May 2014 (UTC)[reply]
Unfortunately, we have Wikipedia: pages with titles and content referring to "CSS classes". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 3 May 2014 (UTC)[reply]
re TheDJ: TfD residents ought to know such things and all you say. That means we cannot move here at enwiki sovereign, and even all of WP cannot change because of "outside usage". Are we tied that seriously? Cannot even all:wikipedia decide on a class? -DePiep (talk) 00:19, 5 May 2014 (UTC)[reply]
You can, you just need to be aware that you are required to wield that power (for instance, i'm positive that dictionary.app of apple used to filter on that class. They no longer do, but it happens). Also remember that for a bot, it might be handy to be able to distinguish between dablinks and rellinks, to make sure that the all entries on a disambiguation page link back to it in the right way. These things share a style now, but what if we no longer want them to share the same style in the future ? These are considerations that are important. You can only act sovereign if you know your kingdom. —TheDJ (talkcontribs) 08:28, 5 May 2014 (UTC)[reply]

Has duration of inactivity before automatic log-off changed?

I've been noticing on a pretty regular basis in the last few weeks that I'm getting logged out if I've not made an edit within the past couple of hours, even if I am continuing to use the search function or go to other pages without editing or committing a logged action. I've noticed this on several different browsers and several different computers on different ISPs, so I don't think this is in any way related. Case in point: logged out after 3 hours of not *editing* (between 23:26 on May 3 and 02:53 May 4), despite having looked at different pages several times during that 3 hour period. What's changed? Risker (talk) 14:44, 4 May 2014 (UTC)[reply]

I haven't heard of any such change, but there have been a lot of complaints about getting logged off in the last few weeks. Whatamidoing (WMF) (talk) 21:16, 4 May 2014 (UTC)[reply]
I've asked anomie on IRC if we have some kind of FAQ so users know how to basically investigate this, but we haven't. Most of the time it's cookie-related (which I must admit is an extremely vague answer). :( --AKlapper (WMF) (talk) 16:12, 5 May 2014 (UTC)[reply]

View and restore deleted pages shows a number of edits by User:Jbenson90, but when I click on the contribs link, I get No changes were found matching these criteria. Ticking the Deleted only checkbox doesn't alter that. What am I doing wrong? -- RoySmith (talk) 14:45, 4 May 2014 (UTC)[reply]

I never use "Deleted only". Instead I use "deleted user contributions", one of the small links above the "Search for contributions" box at the top. Using that I see 14 edits, which matches those listed at Special:Undelete/Internetization. --Redrose64 (talk) 14:53, 4 May 2014 (UTC)[reply]
Me too. "Deleted only" appears to be for revision deleted edits and not edits to deleted pages. PrimeHunter (talk) 14:58, 4 May 2014 (UTC)[reply]
Ah, that worked. Thanks! -- RoySmith (talk) 18:44, 5 May 2014 (UTC)[reply]

Edit conflicts not reported

I've come across two recent instances of the system failing to give its usual warning that there was an edit conflict, and allowing one editor to overwrite another editor's changes. Here is a discussion about one with a link to the diff at 13:55 on 2 May, when three edits by me were reverted by Skookum1. Here 2 is another at 21:12 on 3 May, in which I unknowingly reinstated the word "to" on line 32 which had just been removed by Wiltingdaffodils. – Fayenatic London 20:03, 4 May 2014 (UTC)[reply]

This happened to me a couple of days ago. Let me know if a link to the diffs would help. – Jonesey95 (talk) 05:15, 5 May 2014 (UTC)[reply]
I hope this problem will go away once bugzilla:56849 is fixed. --AKlapper (WMF) (talk) 11:39, 5 May 2014 (UTC)[reply]

Portal namespace

What would I have to do to get a portal namespace at scowiki? --AmaryllisGardener talk 21:07, 4 May 2014 (UTC)[reply]

Request it to be added in the configuration on Bugzilla. Edokter (talk) — 21:32, 4 May 2014 (UTC)[reply]
See also meta:Requesting wiki configuration changes which asks that you link to a local wiki discussion showing consensus. PrimeHunter (talk) 23:31, 4 May 2014 (UTC)[reply]
Thanks, I've opened an RfC about it. If there is consensus to create a portal namespace, I'll request it be done at Bugzilla. --AmaryllisGardener talk 23:52, 4 May 2014 (UTC)[reply]

Moved text, didn't move edit history.

I moved some text from User:Gobonobo/sandbox7 into an existing article (Betty Bone Schiess), but of course now the article itself doesn't contain the full edit history. Can this be fixed? --Slashme (talk) 21:08, 4 May 2014 (UTC)[reply]

The edit histories overlap slightly, so it's best to leave them as they are. If there was no overlap they could have been history merged, but this is not advisable if there are parallel editing histories, as it results in very confusing diffs. — Mr. Stradivarius ♪ talk ♪ 03:36, 5 May 2014 (UTC)[reply]
OK, thanks. I'll be more careful next time. --Slashme (talk) 06:29, 5 May 2014 (UTC)[reply]

Ref Toolbar Question

At some point, Ryan Vesey assisted me in changing my version of the ref toolbar, such that when I clicked the accessdate icon to autofill today's date, it would come up in mdy format, as I almost exclusively edit American articles. This worked fine, until today, when it went back to dmy format. Could someone help me rectify this issue? Thank you! Go Phightins! 21:44, 4 May 2014 (UTC)[reply]

Sorting localization

Hi! Is it possible tomake a local sorting in other Wikipedia? The thing is, that Latvian alphabet has some diacritic signs (like ģ, ā and other), so in categories they are after the whole Latin alphabet (for example, see this category's entry "Ģeotermālā enerģija" which should be placed in section of "G"). I know, that this could be resolved with DEFAULTSORT, but it would be nice to resolve without using it, but make some changes in some javascript file (like this for table sorting (line, which starts with such code mw.config.set( 'tableSorterCollation')). --Edgars2007 (talk/contribs) 06:42, 5 May 2014 (UTC)[reply]

@Edgars2007: Yes, see mw:Manual:$wgCategoryCollation. You can file a request to change this setting for Latvian Wikipedia (or Latvian wikis in general, whichever is more appropriate) at Bugzilla, you can use other bugs asking for this (for other wikis) as "templates" (e.g. Template:Bug, a full list is available as blockers to Template:Bug). (See also meta:Requesting wiki configuration changes for general help.) Matma Rex talk 07:41, 5 May 2014 (UTC)[reply]
Ok, thanks for response! --Edgars2007 (talk/contribs) 07:48, 5 May 2014 (UTC)[reply]

07:29, 5 May 2014 (UTC)

What code makes text in Editing Window Monospace?

I was wondering how the following happens - when I edit the source of any article, text in the editing window is displayed in a Monospaced font. I want to implement a similar behavior on hiwikipedia. Right now in hiwiki, text in the editing window is displayed in regular varied width font, which makes reading and editing a pain. Could someone here help me locate the page and the code which make this possible on enwiki? Is it Mediawiki:Common.js, Mediawiki:Common.css ?Shubhamkanodia (talk) 11:17, 5 May 2014 (UTC)[reply]

@Shubhamkanodia: It's this way by default. If it's different on hi.wikipedia, then that's most likely a local override there (or a problem with fonts themselves). Matma Rex talk 11:27, 5 May 2014 (UTC)[reply]
In fact I see the edit box there in a monospace font: [15], however the Hindi text is not monospace (the characters don't like up with Latin text when I try selecting it with mouse). Is it even possible to have monospace fonts for complicated scripts like this? I recall someone reporting problems with this, I can't remember the script involved, though. Matma Rex talk 11:31, 5 May 2014 (UTC)[reply]


@Matma Rex: Changing an option in the Editing Tab of My preferences fixed it. Thanks anyway! 11:45, 5 May 2014 (UTC) — Preceding unsigned comment added by Shubhamkanodia (talkcontribs) [reply]
The script is Devanagri and yeah, it would be a nightmare to design a fixed width font for it, but I'm still guessing its possible, though none exist . Atleast the latin script is mono-spaced now! — Preceding unsigned comment added by Shubhamkanodia (talkcontribs) 11:47, 6 May 2014 (UTC)[reply]

Cologne Blue

Hi. On Cologne Blue I already have it programmed to add the categories at the bottom rather than top. Can somebody show me the coding to also add the interwiki link titles at the bottom too? Although in looking I think it also shows at the bottom too, so I need a way to suppress it appearing at the top. It's just for popular articles with dozens of interwiki links it bloats out the top. ♦ Dr. Blofeld 16:29, 5 May 2014 (UTC)[reply]

@Dr. Blofeld: Yes, Cologne Blue has two sets of interlanguage links; those at the top may be hidden easily, by adding
div#langlinks { display: none; }
to Special:MyPage/cologneblue.css but those at the bottom are more difficult. Shout if you want those hidden too. --Redrose64 (talk) 17:33, 5 May 2014 (UTC)[reply]
@Redrose64: I've tried it at User:Dr. Blofeld/cologneblue.css but it isn't working. Can you spot why?♦ Dr. Blofeld 18:32, 5 May 2014 (UTC)[reply]
You'd put some javascript in that page as well. Browsers don't like it if they're expecting CSS and are given Javascript. I've hidden it. --Redrose64 (talk) 18:38, 5 May 2014 (UTC)[reply]
and vice versa --Redrose64 (talk) 18:42, 5 May 2014 (UTC)[reply]
@Redrose64: Ah ha, nice one. Now works! Thanks! How about hiding the "Privacy policy | About Wikipedia | Disclaimers | Contact Wikipedia | Developers | Mobile view" line too and moving the grey line underneath the header of the articles underlining it? Feel free to edit it yourself again. Also it would be better to have the coordinates of things displaying on the top right rather than top left which overlaps with the side bar.♦ Dr. Blofeld 19:31, 5 May 2014 (UTC)[reply]
If you want to hide all six from "Privacy policy" to "Mobile view" inclusive, use
div#langlinks, div#titlelinks { display: none; }
instead of the previous code. --Redrose64 (talk) 19:52, 5 May 2014 (UTC)[reply]
The grey line isn't a grey line at all - it's a zero-height box with a grey border. When there is a Sitenotice or a CentralNotice, the box expands to accommodate the notice. --Redrose64 (talk) 22:58, 5 May 2014 (UTC)[reply]
@Dr. Blofeld: I've put code into User:Dr. Blofeld/cologneblue.css to hide "Privacy policy" etc., also to move the coordinates to extreme top right. --Redrose64 (talk) 23:22, 5 May 2014 (UTC)[reply]

Book Creator

I created a book in Book Creator, but it will not download as a pdf and I suspect that it is too large. I want to split it into 3 smaller books, but I can't see how to create a second book without losing my original. How can I do that? Thanks. — Preceding unsigned comment added by KeithWParry (talkcontribs) 17:29, 5 May 2014 (UTC)[reply]

Try making the book in your userspace and name it something like "[book name] Sectioned". You can leave the original just fine and copypaste the different parts into the different book divisions. Supernerd11 :D Firemind ^_^ Pokedex 13:33, 6 May 2014 (UTC)[reply]

Thank you for your help KeithWParry (talk) 17:21, 6 May 2014 (UTC)[reply]

No problem! In the future, WikiProject Wikipedia-Books might have better answers for you; they're the specialists on that topic. Supernerd11 :D Firemind ^_^ Pokedex 17:39, 6 May 2014 (UTC)[reply]

Can anyone tell me why the "2014" in the "This single" field isn't showing up? I've tried everything I can. 2014 is very clearly put in the "this single" field, but no matter what I do, the "2014" part refuses to show up. Ten Pound Hammer(What did I screw up now?) 22:45, 5 May 2014 (UTC)[reply]

It's because it gets value from PAGENAME (there are some changes in infobox, see Template talk:Infobox single#Data granularity redux). --Edgars2007 (talk/contribs) 22:54, 5 May 2014 (UTC)[reply]
@Edgars2007: In English, please? Ten Pound Hammer(What did I screw up now?) 21:57, 6 May 2014 (UTC)[reply]
Maybe in Latvian :) it's my native language ? Ok, let's try. At the moment of your first question (first post) there wasn't "This single" field in infobox itself (that "field" was filled with single's name; you could write anything what you want (|This single = hfhfhfhfh), it would show you only "Beachin'"), which now is fixed in infobox. --Edgars2007 (talk/contribs) 10:11, 7 May 2014 (UTC)[reply]

Template wikitext from visual editor

While looking for broken options in all {{convert}}s, I found that a dozen of the 1.7 million converts have wikitext like the following:

  • {{Convert|5|cm|4 = 0|abbr = on|sp = us}} → 5 cm (2 in)
  • {{Convert|15-20|cm|4 = 0|abbr = on}} → 15–20 cm (6–8 in)

The "standard" way of entering the above is:

  • {{convert|5|cm|0|abbr=on|sp=us}} → 5 cm (2 in)
  • {{Convert|15-20|cm|0|abbr=on}} → 15–20 cm (6–8 in)

or perhaps:

  • {{convert|5|cm|abbr=on|sp=us|0}} → 5 cm (2 in)
  • {{Convert|15-20|cm|abbr=on|0}} → 15–20 cm (6–8 in)

The edits introducing these that I've checked have "(Tag: VisualEditor)" so presumably we can look forward to the imposition of this style in all templates. I'm overly sensitive about source style and am posting this for a minor vent, but it may be of interest to others. The 4 = 0 is setting the numbered parameter 4 to the string 0, and the template will receive the parameter with leading and trailing whitespace removed. Possibly the 4 is a slightly broken attempt by VE to count where it was up to (it's not 4 in the "standard" examples above). Convert accepts some very weird syntax and I suspect that the missing parameter 3 could cause it confusion in some cases, and the stripped whitespace could conceivably matter. Does anyone feel like checking this out with some VE testing? Does the current version do the above? Is it really missing parameter 3? Johnuniq (talk) 01:57, 6 May 2014 (UTC)[reply]

You should check the TemplateData table in the template's documentation first, because that is ususally the source of these errors. VE uses these to create and edit templates. Edokter (talk) — 10:25, 6 May 2014 (UTC)[reply]
VisualEditor is doing as it's supposed to by saying 4 = 0. Template:Convert#TemplateData says parameter 3 is the unit being converted to, and parameter 4 is the precision. If the user gave no parameter 3 then the '4' in 4 = 0 is needed to assign parameter 4 and not parameter 3 (it could also have said {{Convert|5|cm||0|abbr = on|sp = us}} to show there is no parameter 3). The "standard" {{convert|5|cm|0|abbr=on|sp=us}} corresponds to 3 = 0 and no parameter 4. The template is apparently designed so the unit being converted to is optional and a default unit is chosen if none is specified, for example inches for cm. If a number is given as parameter 3 then the template assumes it's a precision (which should normally have been parameter 4) and not the unit being converted to. I don't know whether VisualEditor can be programmed to understand such features and move parameter 4 down to parameter 3 if it's a number and no parameter 3 was given. PrimeHunter (talk) 10:47, 6 May 2014 (UTC)[reply]
Thanks, I see what you mean. Unfortunately convert can be a lot more complex than the template data envisages:
  • {{convert|1|x|2|x|4|ft|m|3}} → 1 by 2 by 4 feet (0.305 m × 0.610 m × 1.219 m)
  • {{convert|1|yd|2|ft|6|in|m|adj=mid|-wide|3}} → 1-yard-2-foot-6-inch-wide (1.676 m)
Perhaps convert can be stripped back to a sane syntax one day. And we'll have to learn to love VE's idiosyncratic spacing style? Johnuniq (talk) 12:38, 6 May 2014 (UTC)[reply]
Is this a case of the template being overloaded, like {{coord}} is?
The ideal spacing appears to be an unresolved debate: if you add no spaces, then the wikitext won't wrap; if you add some, then whatever you choose is obviously wrong (unless what you choose is what I would have chosen ). If everyone could agree on a standard for spacing that applied to all templates, then I'd be happy to propose to the devs that they follow it. Whatamidoing (WMF) (talk) 20:29, 6 May 2014 (UTC)[reply]
I do have a system, but it's variable. If the template produces a box-type structure, like an infobox, I use one parameter per line, and line up the equals:
{{template
|name1       = value1
|name2       = value2
|longername3 = value3
}}
If the template produces inline output, like a citation template, I put the whole template on one line. For each named parameter, there are four permissible places to put a space - either side of the pipe, and either side of the equals. Of these four, I only put spaces before each pipe:
{{template |name1=value1 |name2=value2 |longername3=value3 }}
This permits word wrapping, but when wrapping occurs, the name and value stay together. --Redrose64 (talk) 20:59, 6 May 2014 (UTC)[reply]
That's one of my preferred systems for horizontal ones. Whatamidoing (WMF) (talk) 16:50, 7 May 2014 (UTC)[reply]

@Whatamidoing: If custom is a guide, there are 1,773,352 converts in articles in the 20140502 dump (not counting indirect usage such as when an infobox calls convert). Of those:

  • 979,330 have an option of the form "x=y" (no space).
  • 1,112 have "x = y" (space on each side).
  • 352 have either "x= " or " =y" (space on one side only).

Custom clearly favors no space. Johnuniq (talk) 02:34, 7 May 2014 (UTC)[reply]

Custom would be a more useful guide if it involved all templates, not just this one. The devs are not going to be impressed with a request that they use different spacing schemes for different templates. Whatamidoing (WMF) (talk) 16:50, 7 May 2014 (UTC)[reply]

Dear technical experts: I have for some time been trying to create a search box that would be helpful to people reviewing at Afc, but was hindered by the fact that the search engine didn't check text in transcluded templates. Now it seems that there is a new search engine which does. I have "New Search" selected in my preferences. I created this search box which checks only in "Wikipedia talk:Articles for creation/":


By typing "football review waiting" into the search box I thought that I would see only see submissions with the requested prefix, the word "football" and the words "review waiting" which appear in the submission template. Instead I am getting mainly redirects to mainspace which months ago had this text, but in which currently neither the redirect not the mainspace page have the words "review waiting". What is going wrong? —Anne Delong (talk) 09:46, 6 May 2014 (UTC)[reply]

You found a bug. The search results page shows timestamps for the searched revision. In all cases I examined, this was the last edit before the page was moved and became a redirect. The search index for the old title apparently isn't updated when a page is moved, at least not for the examined cases. For example, this search currently says with UTC:
Wikipedia talk:Articles for creation/Summer Cup (Scottish football)
Review waiting. This may take 2–3 weeks. The Articles for creation process is highly backlogged. Please
4 KB (587 words) - 19:45, 19 January 2014
Wikipedia talk:Articles for creation/Summer Cup (Scottish football) was moved to Summer Cup (Scottish football) 19:46, 19 January 2014‎. The last revision before that in the page history of Summer Cup (Scottish football) is [16] 19:45, 19 January 2014‎. It would have produced the "Review waiting" text when it was at Wikipedia talk:Articles for creation/Summer Cup (Scottish football) before the move. In other cases the time difference was more than 1 minute but it was always the last revision before the move. PrimeHunter (talk) 10:21, 6 May 2014 (UTC)[reply]
Ah, that probably explains why this search turns up lots of albums which don't mention the word "sophomore" at all. However, it doesn't explain the presence of Breakaway (Kelly Clarkson album) in the search results - it was only moved once, in March 2009, at which time the word "sophomore" wasn't in the article.
Is there a bugzilla? --Redrose64 (talk) 10:46, 6 May 2014 (UTC)[reply]
Well, this is a disappointment. I thought that when the new search came out I would finally be able to distinguish between pages submitted for review and those not currently submitted. —Anne Delong (talk) 10:54, 6 May 2014 (UTC)[reply]
@Redrose64: Do you have "New search" enabled at Special:Preferences#mw-prefsection-betafeatures? I only get Breakaway (Kelly Clarkson album) in the search results when New search is disabled. It's unrelated to the old move. Maybe there is a page somewhere with a piped link saying "sophomore album" in the link text. That can affect search results for the link target. PrimeHunter (talk) 11:05, 6 May 2014 (UTC)[reply]
All of my beta features are disabled, because of Visual Editor, Typographic refresh and other "enhancements". Bad reputation → refusal to use. --Redrose64 (talk) 11:28, 6 May 2014 (UTC)[reply]
Whoops, there is very much a bug here, PrimeHunter spotted it. We're not updating the old page after a successful move. Will get working on a patch for this today. ^demon[omg plz] 14:54, 6 May 2014 (UTC)[reply]
Thanks very much. A fix would make the above template much more useful. —Anne Delong (talk) 15:15, 6 May 2014 (UTC)[reply]
Patch is written, pending a test and review. Will be live no later than Thursday's deployment. ^demon[omg plz] 16:06, 6 May 2014 (UTC)[reply]
  • Next question: Will the fix affect already-created redirects, or only newly created ones? If the former, is there a way to fix the pre-existing ones? A null-edit each, perhaps? —Anne Delong (talk) 16:41, 6 May 2014 (UTC)[reply]
  • A null edit will fix any one-off instances you come across, yes. We're planning an in-place reindex of most of the wikis in the near future anyway to pick up the new GeoData features so we'll fix it en masse then anyway. ^demon[omg plz] 17:08, 6 May 2014 (UTC)[reply]

I look forward to this feature. While primarily intended for the good people working at AfC, OTRS agents will find it useful. It is quite common for someone to report some issue with an article but it turns out they are talking about an AfC submission and don't know to provide the link. This search box is likely to help.S Philbrick(Talk) 19:43, 6 May 2014 (UTC)[reply]

I'll have to make another for the Draft: space, but it really only takes a minute or two to set up the template for the search box using the "search prefixes" template. —Anne Delong (talk) 21:31, 6 May 2014 (UTC)[reply]
Is there any ETA on a refresh that will update the timestamp for redirects? Right now the new search is not useful for articles that have been moved, because the search picks up text that was in the article before it was moved, perhaps months ago, rather than the current text. For the search I was doing above, that means that there are many more incorrect hits than correct ones. —Anne Delong (talk) 23:42, 9 May 2014 (UTC)[reply]
Weird, I thought I had narrowed this down locally and fixed it. I'll have to have another look at it again Monday or Tuesday. ^demon[omg plz] 05:56, 10 May 2014 (UTC)[reply]
^demon, you may very well have fixed it. I was referring to the "in place re-index' that you mention earlier in this thread. —Anne Delong (talk) 03:22, 11 May 2014 (UTC)[reply]
I just kicked it off a minute or two ago, making good time (avg. about 2500 pages/s). I'll update this thread when it's completed. ^demon[omg plz] 16:47, 12 May 2014 (UTC)[reply]
Hmm, it's complete but I'm still seeing the incorrect results. We've also got another fix in the pipeline with gerrit:132973 that should help as well. Will have to keep poking this until it's right. ^demon[omg plz] 19:59, 12 May 2014 (UTC)[reply]

No captcha for nih.gov?

There's currently an edit request at MediaWiki talk:Captcha-addurl-whitelist#PubMed etc. suggesting that we whitelist nih.gov so that it doesn't require a captcha by anonymous users to insert into pages. The request sounds reasonable to me, but I thought I'd bring it here for second opinions in case there's a drawback I haven't thought about. Is there any reason we shouldn't do this? — Mr. Stradivarius ♪ talk ♪ 11:57, 6 May 2014 (UTC)[reply]

Why is it even on the blacklist in the first place? DGG ( talk ) 21:07, 6 May 2014 (UTC)[reply]
Short answer: It isn't. Less short answer: There is no blacklist for this, any URL that doesn't match an entry on the whitelist triggers a CAPTCHA when inserted into an article by an anonymous user. (Unless, of course, I'm completely mistaken about how this works.) Since I can't imagine a spambot inserting nih.gov links, I see no reason not to add it. Novusuna talk 21:15, 6 May 2014 (UTC)[reply]
(edit conflict) All external links are on the blacklist by default. This isn't the same thing as the spam blacklist - anonymous users are still able to add blacklisted sites, they just have to enter a CAPTCHA before they can save their edits. This helps prevent spambots from adding links automatically. — Mr. Stradivarius ♪ talk ♪ 21:19, 6 May 2014 (UTC)[reply]
thanks for the enlightenment; Now that I know, I think the general rule a very good idea, and this a good exception . DGG ( talk ) 23:38, 6 May 2014 (UTC)[reply]
I've enacted the request, as there weren't any objections within 24 hours. — Mr. Stradivarius ♪ talk ♪ 09:47, 7 May 2014 (UTC)[reply]

Is there a template for user rights?

I'm wondering if there is a template that actually transcludes user rights, similar to {{Userrights}} but that doesn't require clicking a link, such that if I typed {{User permissions|Testuser}} I'd get something like Testuser (rollbacker, reviewer). Does such a template exist, or if not, could one be easily written?--Obi-Wan Kenobi (talk) 14:55, 6 May 2014 (UTC)[reply]

There isn't, and MediaWiki doesn't currently support making one. Jackmcbarn (talk) 21:39, 6 May 2014 (UTC)[reply]
User:Splarka/sysopdectector.js (note the funny spelling) if you add it to your personal javascript file, will display permissions of a user in large print when you view their user page. EdJohnston (talk) 01:11, 8 May 2014 (UTC)[reply]
Thanks, I have another js which does that as well. I'm just wondering whether it's possible to do so in a template, so that if we had a list of wikipedia users we could automatically display their permissions. It was suggested about this is impossible.--Obi-Wan Kenobi (talk) 17:51, 8 May 2014 (UTC)[reply]

What sorcery is this? Mischeviously broken file red links.

 revived from archives

Someone's been messing with the code again; links such as File:New Jersey Dry Town Listing.pdf do not currently lead to a page where I can click to see the deletion history. This breaks things and needs to be fixed. --Elvey (talk) 00:30, 7 March 2014 (UTC)[reply]

I'm pretty sure that is how it has been for quite some time now and that is why I threw together User:Technical 13/Scripts/fileRedlinks.js which you can use by adding:
importScript( 'User:Technical 13/Scripts/fileRedlinks.js' );// [[User:Technical 13/Scripts/fileRedlinks]] makes image redlinks work like page redlinks.
to your common.js. — {{U|Technical 13}} (tec) 00:46, 7 March 2014 (UTC)[reply]
Thanks for the reply, workaround and dupe fix. Any idea where the code sorcery that is responsible for this can be found? --Elvey (talk)
I think you're mistaken; things have gotten worse or are more complicated; see here - While File:New Jersey Dry Town Listing.pdf takes me to Wikipedia:File Upload Wizard, File:CBB-layout-problem.gif does take me to to a page where I can see the deletion history. WHY!?! Why is this deletion history being hidden from editors? --Elvey (talk) 01:03, 7 March 2014 (UTC)[reply]
This search indicates that this is a recurring problem that needs to be fixed! But it didn't help me find the code that is responsible for this. Please help me. I'd like to get a better handle on the thinking behind it before filing a bug over it.--Elvey (talk) 02:51, 7 March 2014 (UTC)[reply]
It's possible to bypass this bug: To view the deletion history of File:New Jersey Dry Town Listing.pdf, instead of clicking on the red link, paste the file name into the search box. Then, click on the red link (where it says "You may create the page "File:New Jersey Dry Town Listing.pdf", but consider checking the search results below to see whether the topic is already covered.") This works even if I am logged out. -- Diannaa (talk) 03:19, 7 March 2014 (UTC)[reply]
Per mw:Manual:$wgUploadMissingFileUrl, if http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php under 'wgUploadMissingFileUrl' added 'enwiki' => '//en.wikipedia.org/wiki/Special:Upload' then I think File:New Jersey Dry Town Listing.pdf would go to [17] instead of [18]. So the upload wizard would be replaced by the default upload form, and the latter displays the deletion log (and actually places the file name in the upload form). PrimeHunter (talk) 03:32, 7 March 2014 (UTC)[reply]
I use the script described at User:Equazcion/SkipFileWizard (without the "Option"). This means that if I click either of the file redlinks File:New Jersey Dry Town Listing.pdf or File:CBB-layout-problem.gif, they both behave the same: I get a page headed "Creating File:whatever", with two pink boxes: one beginning "Wikipedia does not have a File page with this exact title", the other beginning "A page with this title has previously been deleted", and the deletion log is in that second pink box. --Redrose64 (talk) 09:49, 7 March 2014 (UTC)[reply]
Redrose64@ Thanks but Technical 13 already provided a workaround, and that's NOT what's needed. This search indicates that this is a recurring problem that needs to be fixed! Thanks, PrimeHunter@! Wow, that file gets edited a lot. I have to look up Bug 42263 but have to run right now. --Elvey (talk) 03:30, 8 March 2014 (UTC)[reply]
We are discussing red file links which are controlled by mw:Manual:$wgUploadMissingFileUrl. mw:Manual:$wgUploadNavigationUrl controls where "Upload file" in the sidebar goes. PrimeHunter (talk) 21:25, 8 March 2014 (UTC)[reply]
It seems that Template:Bug was recreated when Special:Upload replaced Wikipedia:File_Upload_Wizard. I'm considering whether it's appropriate to simply reopen 6909, and I welcome guidance / suggestions someone taking other action. I guess the fix to that by @Raymond:, and/or Raymond himself could be of help here.--Elvey (talk) 02:10, 9 March 2014 (UTC)[reply]
Thanks for the ping :-) But sadly I cannot help to fix this bug in the UploadWizard. I like the UploadWizard but it is widly written in JavaScript which I do not like. Raymond (talk) 11:51, 9 March 2014 (UTC)[reply]
(Yeah, Template:Bug is tangential; I followed blame tools onto a wrong path to figuring this out.) --Elvey (talk) 23:52, 8 March 2014 (UTC)[reply]
What the …? This is no longer true! Yesterday, I wrote that "While File:New Jersey Dry Town Listing.pdf takes me to Wikipedia:File Upload Wizard, File:CBB-layout-problem.gif does take me to to a page where I can see the deletion history." but today, that's not true. Both take me to the upload wizard. WTF? (In the interim, I enabled and reverted the workaround; I suppose it's possible caching or memory problems are to blame.)--Elvey (talk) 23:52, 8 March 2014 (UTC)[reply]
Both have taken me to the upload wizard the whole time. Did you earlier click a link at Wikipedia talk:File Upload Wizard/Archive 3#Reader feedback: why is this a crummy upload ... with a colon in front like File:CBB-layout-problem.gif? That behaves differently. If the file exists then it goes to the file page instead of displaying the file, for example File:Example.jpg. PrimeHunter (talk) 01:11, 9 March 2014 (UTC)[reply]
Yes, I have noticed that the : in front produces the behavior more like what I think people want - like the fix to Template:Bug provided for a time. Not as I recall, but as I said, I suppose it's possible caching or memory problems are to blame. But perhaps the best solution is to revert the default to Special:Upload from Wikipedia:File_Upload_Wizard, as you suggested. There's a so much content that is policy compliant but can't be uploaded properly with the wizard. It's more hindrance than help in my experience. Wonder if there were any metrics compiled pre vs post rollout to evidence a net positive impact of the change.--Elvey (talk) 02:27, 9 March 2014 (UTC)[reply]
@PrimeHunter: So someone needs to submit a patch to take advantage of this ehancement which allows us to set the default to Special:Upload for redlinks, instead of inheriting the default from $wgUploadNavigationUrl, as you suggested, for review? I guess that's the next step. I see the discussions here and here indicate consensus that Special:Upload is where red links should go. I'm willing to figure out how to do it. --Elvey (talk) 19:04, 10 March 2014 (UTC)[reply]
@Odder: Can you do this? It looks like you do about 1/2 the editing of InitialiseSettings.php. You still alive? Looks like you are, on commons. The admin edit request is to make the precise edit PrimeHunter indicated, to take advantage of this ehancement which allows us to set the default to Special:Upload for redlinks, as it's clear we have consensus (support and no opposition). If not, I suppose I could post to WP:AN, but does this really need attention from more than one admin and a reviewer? It's not controversial. (And {{editrequest}} would complain that I'm not using it on a talk page.) (Also still pursuing the DIY path-trying to do this myself with Gerrit.) --Elvey (talk) 18:10, 6 May 2014 (UTC)[reply]
@Elvey: Do you mean the edit described by PrimeHunter at 03:32, 7 March 2014? If so, {{editrequest}} won't help because it's not an admin-editable page. At least, I'm an admin and I see no edit links on the page. --Redrose64 (talk) 20:09, 6 May 2014 (UTC)[reply]
Yes. Which is why I pinged odder. He's a full sysop/superuser/what have you ... and as I said, he does about 1/2 the editing of InitialiseSettings.php. Although he seems to have retired from this wiki, he can probably still do the edit, as it's not an on-wiki edit.--Elvey (talk) 02:56, 7 May 2014 (UTC)[reply]
Good news. I submitted a patch and the edit (yes, the one described by PrimeHunter at 03:32, 7 March 2014 your time, AKA 7:32 pm, 6 March 2014 (UTC−8)) was rolled out half an hour ago. So, FIXED! Y'all can remove any code you implemented to work around the bug, e.g. blank User:Technical 13/Scripts/fileRedlinks.js, Technical 13. Kudos all 'round. (PS smart, helpful sig, T13! I just copied it.) --{{U|Elvey}} (tec) 15:56, 7 May 2014 (UTC)[reply]

I thought it worth more widely sharing the comment of the reviewer who approved the change, so here it is. (modified: fixed implied wikilinks)-{{U|Elvey}} (tec) 19:02, 10 May 2014 (UTC) [reply]

I'm inclined to think that Wikipedia:File_Upload_Wizard should be updated if not just replaced with mw:Extension:UploadWizard (which hopefully doesn't have the problems), rather than dumping people back on Special:Upload with the problems that Wikipedia:Upload was created to fix in the first place.

But let's not let the perfect be the enemy of the good here, and the on-wiki discussion seems to have a minimum of consensus. This can always be undone once the fancier things are fixed.

--Anomie

IMO, the Einstein Principle is essential to a good uploader tool, and is a principle that the wizard writers seem to have failed to honor, IMO. Solution: If the wizards didn't over-promise, I'd be happier with them, but they do. If they started off by saying something like, "uploading files properly is sometimes very complicated (which could link to a page listing those reasons - from copyright to file size). This wizard is designed to be easy to use, especially for new users in the most common cases, but the simplification required to make it means that it cannot handle many of the complicated cases; for those, you should use a different upload tool." That sentence could use some refinement, but expression of the core sentiment is critical. Otherwise, they're more harmful than helpful. Not to mention:

Copied from https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback#Wizard_stoped:

The Upload Wizard is pretty much in a perpetual state of brokenness. Have you tried Commons:Upload? It tends to be much more reliable. —LX 19:13, 28 April 2014 (UTC)

--{{U|Elvey}} (tec) 19:02, 10 May 2014 (UTC)[reply]

"AFCH error" box


Per WP:MULTI: Avoid posting the same thread in multiple forums This has been posted at Wikipedia_talk:WikiProject_Articles_for_creation#.22AFCH_error.22_box as well, where this discussion should be continued. (tJosve05a (c) 09:49, 7 May 2014 (UTC)[reply]


Why am I getting a box with this text:

AFCH error: user not listed
AFCH could not be loaded because "Beyond My Ken" is not listed on Wikipedia:WikiProject Articles for creation/Participants. You can request access to the AfC helper script there.

whenever I open anyone's user page? It's pretty annoying. BMK (talk) 22:29, 6 May 2014 (UTC)[reply]

You have the AfC gadget enabled in your preferences, but you're not listed as an AfC reviewer on Wikipedia:WikiProject Articles for creation/Participants. If you are interested in reviewing AfC submissions, add your name to Wikipedia:WikiProject Articles for creation/Participants. If you're not, disable the AfC gadget. Jackmcbarn (talk) 22:36, 6 May 2014 (UTC)[reply]
I did not enable an "AfC" gadget, so it was added as "opt out"? I vehemently protest about this. I will turn the gadget off, but editors should not have to opt out. And why does the message come up when I'm simply looking at a user page - that's not an AfC-related activity. This whole thing seems like an enormous fuck up and needs to be totally re-thought. Where is the discussion that authorized it? BMK (talk) 22:48, 6 May 2014 (UTC)[reply]
The gadget is, and has always been, opt-in. If it was enabled, it's because you enabled it at one point. Looking at user pages is AfC-related, because some users create AfC submissions in their userspace. It was authorized at Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission implementation. Jackmcbarn (talk) 22:52, 6 May 2014 (UTC)[reply]
Could someone perhaps add a hint in the box to those of us who tried AfC at one point and were burned about how to get rid of the pop-up? It took me quite a while to find this discussion and to remember that in a moment of unbecoming zeal I did change my preferences, and the change was in the gadgets section. (AfC is a seriously hot potato!) Sminthopsis84 (talk) 15:30, 7 May 2014 (UTC)[reply]
You folks instituted a change in functionality on the basis of an RfC which recieved the opinons of 14 editors! Do you really think that's a valid cross-section of the community? And then the implementation is botched, and you're still trying to sell it as a feature, and not what it is, a bug. This whole thing should be undone and receive a real RfC before it is re-implemented, and the implementation should be reconsidered. BMK (talk) 23:04, 6 May 2014 (UTC)[reply]
The default status of gadgets can be seen and changed at MediaWiki:Gadgets-definition. There is no "default" in the line for afchelper so it isn't enabled by default. If it has ever been default then it should show in the page history, but I don't think it has. It would certainly be inappropriate if it was. Users sometimes say a non-default gadget is enabled in their account without any action on their part. It's hard to tell whether this is correct or they accidentally enabled it, but I think the common assumption is the latter. If it actually did enable without user action then the problem would be in MediaWiki or the Wikimedia servers and not in the implementation of this particular gadget at the English Wikipedia. Anyway, you can disable it now so your problem is solved and I don't see reason to go on about it unless other users also claim it has enabled automatically. PrimeHunter (talk) 23:20, 6 May 2014 (UTC)[reply]
I am almost certainly wrong about the default. I do recall doing a few AfC's at one point, so I most probably turned on the gadget myself. Nevertheless a change in system functionality has been (badly) implemented on the basis of 14 people's opinion. That's a very bad idea, and no one at AfC seems to want to own up to having pulled a boner. They have. BMK (talk) 23:25, 6 May 2014 (UTC)[reply]
Implementation details of gadgets rarely get large discussions and this gadget is not default and has few users. The message you quoted is from MediaWiki:Gadget-afchelper.js/core.js. You could suggest it adds something like: 'This message can be avoided by disabling "Yet Another AFC Helper Script" under "Editing" in your gadget preferences.' That should help users like you who are annoyed by the message and don't know how to get rid of it. PrimeHunter (talk) 23:55, 6 May 2014 (UTC)[reply]

You all might be interested to learn that AFC are intending to remove your name from the list if you don't do a review in two months. So even if you put your name on the whitelist to suppress the error messages, you will get them back again in two months unless you uninstall the gadget. Seems to me that AFC are overstepping their scope with this. SpinningSpark 00:02, 7 May 2014 (UTC)[reply]

Well that wins for bad ideas. I review AfC's as I have the time, and have reviewed quite a few. However, it wouldn't at all surprise me if there was a two month period at some point in the future when I don't have time to review an AfC. If I come back from whatever forced that break and realize I have to jump through a hoop to be able to use AFCH again, I'm just as likely to give up on helping a mostly broken process as I am likely to restore my name and start doing AFC reviews again. The idea that AFCH - a script that, mind you, could be implemented in userspace without *that* much difficulty without checking the white list and with no special permissions - is so sensitive that it needs a removal of permissions only one third of the time we give inactive sysops is pretty odd. Kevin Gorman (talk) 03:46, 7 May 2014 (UTC)[reply]

What we have here, is a failure of one editor to read a message and to either add themselves to a list for AFC participants or to remove the AFCH (or previously Yet Annother AFC submission handler) preference/gadget from their javascript. That does not excuse rudeness (Wikipedia_talk:WikiProject_Articles_for_creation#.22AFCH_error.22_box, User_talk:Hasteur/Archive_9#Please...., User_talk:Hasteur/Archive_9#Too_bad...). If only there were some way the editor could go back to assuming good faith and following the advice they give on their own talkpage (which option will best serve the building of an encyclopedia) rather than making it a "AFC is full of bad people" battleground. Hasteur (talk) 00:13, 7 May 2014 (UTC)[reply]

No, what we have here is arrogance on the part of Hasteur and AfC. Why in hell should I be required to add myself to a list in order not to receive an error message. The message did not say that it was generated because I had an obscure gadget turned on. It did not say that I could stop receiving the message by turning off the gadget. No, you just assumed that your project was so damned important that everyone should jump through your hoops to accommodate you. You're pretty darn high-falutin' with a overdeveloped sense of AfC's importance. — Preceding unsigned comment added by Beyond My Ken (talkcontribs) 00:46, 7 May 2014 (UTC)[reply]
  • That was the discussion I was pointed to when I asked for the consensus discussion which authorized that change. If there were others, that's good, that's better, but it doesn't change the piss-poor attitude of Hasteur and the problems in the implementation. BMK (talk) 00:46, 7 May 2014 (UTC)[reply]
  • (edit conflict) I won't debate you that his methods and attitude are poor at best on most things of this nature, but he was still not wrong (albeit unnecessarily defensive) about this implementation. I will say, that complaining about Hasteur doesn't improve the wiki all that much, and the topic should just be dropped (at least in this venue, if you choose to take it to another venue where it is appropriate to complain about other editor behavior, that is your prerogative). — {{U|Technical 13}} (tec) 00:51, 7 May 2014 (UTC)[reply]

Per WP:MULTI: Avoid posting the same thread in multiple forums This has been posted at Wikipedia_talk:WikiProject_Articles_for_creation#.22AFCH_error.22_box as well, where this discussion should be continued. (tJosve05a (c) 09:49, 7 May 2014 (UTC)[reply]


Supercount down?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Supercount is curently displaying a four o four. -- Fauzan✆ talk ✉ email 07:06, 7 May 2014 (UTC)[reply]

This is indeed quite irritating. Anyone know who we need to nudge to get it back up again? —Tom Morris (talk) 08:27, 7 May 2014 (UTC)[reply]
That would be User:Cyberpower678. — Mr. Stradivarius ♪ talk ♪ 09:11, 7 May 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bracketbot and Referencebot are welcoming vandals

I'm not sure whether this is appropriate for a bugzilla report, hence this entry here, but wikipedia's behaviour is not ideal. In this edit, a vandal removed a random chunk of code, without citations, so perhaps Cluebot wouldn't notice such a thing. In any case, Bracketbot's response to this on the IP's talk page is a bit absurd. Similarly, Referencebot has welcomed a vandal with open arms in response to a seriously scrambled edit that involved, inter alia, deleting all the references from the page. Could these bots be asked to run a bit less enthusiastically? Sminthopsis84 (talk) 15:01, 7 May 2014 (UTC)[reply]

I think such things are usually raised at the bot's/bot's owner's TP? It Is Me Here t / c 09:42, 10 May 2014 (UTC)[reply]

Redirect not working right

The target of the redirect WP:NMOTORSPORT is, as it should be, Wikipedia:Notability (sports)#Motorsports; but clicking on it doesn't take you to the right place in the article. Any ideas? JohnCD (talk) 20:28, 7 May 2014 (UTC)[reply]

It works for me, using Firefox 28. Some browsers may get confused by the collapsed "FAQ" box at the top of the page. -- John of Reading (talk) 20:37, 7 May 2014 (UTC)[reply]
It still doesn't for me on FF29. What I don't understand is that clicking on Wikipedia:Notability (sports)#Motorsports does take me to the right place, but clicking WP:NMOTORSPORT, which has exactly that as its target, doesn't. If it is a browser problem, wouldn't they both be wrong? JohnCD (talk) 22:06, 7 May 2014 (UTC)[reply]
Works for me in Safari, but not with FF 29. With FF it does jump to a spot in the page pretty quickly, perhaps before it's read and dealt with all the stylesheets and JS that affects the page - i.e. as John of Reading is suggesting. The delta between where it lands and where it should land is also about that size.--JohnBlackburnewordsdeeds 22:19, 7 May 2014 (UTC)[reply]
It's a race condition, something encountered in asynchronous processing. You've got two (well, actually a lot more) largely-unrelated tasks being kicked off more or less at the same time: one to go to the position specified by the fragment #Motorsports, the other to collapse the FAQ box at the top. If the collapse finishes first, the position will be correct; if the collapse finishes second, the position will be off by the height reduction of the FAQ box. Which one finishes first varies not just between browsers, but between machines with the same browser - it can be affected by other things going on unrelated to browsing, like that big spreadsheet that you're printing off for Joe in Accounts. --Redrose64 (talk) 23:16, 7 May 2014 (UTC)[reply]
This might (or might not!) have something to do with HotCat or WikEd. See User talk:Cacycle/wikEd#wikEd bug report:clicking on section links. Thincat (talk) 22:15, 9 May 2014 (UTC)[reply]
The wikEd/HotCat problem being discussed below at #Section links not working properly has got nothing to do with FF 29 as that also occurs on FF 28. Also, JohnBlackburne's description above doesn't fit the symptoms of the wikEd/HotCat incompatibility: here, it appears the browser jumps to nearly the right place, whereas with the wikEd/HotCat problem, you first get to the right place and then suddenly land at the top of the page. The "nearly getting there" effect is most probably what Redrose64 explained above. The "jump to top" effect is a conflict between wikEd and HotCat. Lupo 22:32, 9 May 2014 (UTC)[reply]
I've just upgraded from FF 28 to 29.0.1 and I think that the behaviour has changed. --Redrose64 (talk) 10:47, 10 May 2014 (UTC)[reply]
Concur. I've got FF28 on my desktop and FF29 on my laptop, and it works on the former but not the latter. Black Kite (talk) 10:59, 10 May 2014 (UTC)[reply]

A kind of inverse watchlist viewing/editing ..?

Is it possible to view/edit your watchlist sorted according to how long pages on it have remained unchanged..? If so, how/where would be much appreciated, with apologies in advance if I've missed something obvious. Sardanaphalus (talk) 22:17, 7 May 2014 (UTC)[reply]

I think this option is not available, but someone could try to develop a script using the API. Helder.wiki 22:33, 7 May 2014 (UTC)[reply]

Autoarchiving again

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Have implemented autoarchiving on Talk:Anatomy but even after many days, it's still not working. Would a more experienced user be able to have a look? --LT910001 (talk) 03:14, 8 May 2014 (UTC)[reply]

 Done I tried it out with a manual archiving tool, which makes an archive based on the Misza bot configuration and it archived to mainspace instead of talk. I fixed the configuration, and the manual archiver worked right, so let's see if that works for the bots in the next day. If it still doesn't work, post here or on my talk page and I'll take another look. VanIsaacWScont 04:44, 8 May 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Tables and other multimedia objects

Tables cannot be put under other multimedia objects. See here for an example. Esszet (talk) 10:42, 8 May 2014 (UTC)[reply]

I don't think a table is considered a multimedia object. class="wikitable floatright" will place it below the image in your example. PrimeHunter (talk) 11:19, 8 May 2014 (UTC)[reply]
Ah. Thank you. Esszet (talk) 13:51, 8 May 2014 (UTC)[reply]
Yes, align only says something about position. Multimedia objects also automatically "clear" (so go on the next line from a previous right floating element), but tables do not. So you either need to manually (style="clear:right") or you use the floatright class, which aligns and clears at the same time. —TheDJ (talkcontribs) 07:51, 9 May 2014 (UTC)[reply]

Normally when I click on a link to a particular section of a page, I'm brought to that section. However, for the past few days I've noticed that while I am brought to the section while the page is loading, once loading is complete it jumps back up to the top of the page. How can I fix this? Nikkimaria (talk) 12:09, 8 May 2014 (UTC)[reply]

Do you use WP:WikEd? I've been havng the same problem and it only went away when I disabled WikEd (logged as an issue at User talk:Cacycle/wikEd), having tried every other gadget and script I'd got installed. Nthep (talk) 12:47, 8 May 2014 (UTC)[reply]
I've noticed that problem. I did have WikEd, but disabled it. Still happens.S Philbrick(Talk) 15:57, 8 May 2014 (UTC)[reply]
I've just blanked my common.js, common.css and gone through each entry there and all the gadgets in preferences that I have enabled and the problem for me seems to be when both WikEd and HotCat are enabled. Disable one or the other and I have no problem. Nthep (talk) 16:06, 8 May 2014 (UTC)[reply]
Oops, I was mistaken. I thought I recently disabled WikEd, but it was the enhanced tool bar I disabled. I just disabled WikEd, and that "solved" the problem.--S Philbrick(Talk) 16:26, 8 May 2014 (UTC)[reply]
Can anybody get HotCat to work? I do nopt see the jumping problems, but I also do not see anything HotCat related on my edit pages (independent of wikEd enabled or not). Cacycle (talk) 18:56, 8 May 2014 (UTC)[reply]
HotCat works but when both it and WikED are enabled this bouncing behaviour is seen, diable either and problem goes away. Looking at c:MediaWiki:Gadget-HotCat.js HotCat was upgraded to v2.28 last weekend which was when I first saw the problem, whether this has anything to do with it I don't know. Nthep (talk) 09:00, 9 May 2014 (UTC)[reply]
No, HotCat's upgrade to 2.28 cannot possibly have anything to do with this. (Famous last words... :-) That upgrade just affected the behavior of the category editor, which opens after a user clicked the (±) or (+) link, and only if the user uses an IME (Input method editor). Other behavior of HotCat has not changed. However, I see quite a lot of recent changes in wikEd.
Anyway, if you want anybody to be able to try to reproduce the problem, we need more information: which browser are you using? Firefox/Safari/Chrome/Opera/IE? On which OS? Which versions (of both)? Does the problem appear on all pages? Or only on some? Can you give us a section link that does consistently lead to the problem you mention? Are there any JavaScript-related error messages in your browser's error log/console? If so, what do they say? Lupo 20:34, 9 May 2014 (UTC)[reply]
Firefox 29.0.1, Windows 8.1 (by had same issue on Firefox 17/Windows XP, IE11/Windows8.1), Modern skin (but also seen the same problem using Vector and Monobook). The issue occurs whenever I click on any section link on any page e.g. from watchlist or article history and I can't see any js related errors in Firefox's console. Nthep (talk) 21:05, 9 May 2014 (UTC)[reply]
It's line 3648 in wikEd, which does window.scroll(0, wikEd.GetOffsetTop(wikEd.inputWrapper) - 2);. That's inside wikEd.TurnOn(), and it makes the page jump to the top. Lupo 21:19, 9 May 2014 (UTC)[reply]
Hm. WikEd looks for an edit form (elements #editform, wpTextarea1 etc) in the DOM, and if it finds one, assumes it's on an edit page. HotCat does add a similar hidden form to make its edits (but the form id is #hotcatCommitForm, not #editform like for normal edit pages). So, when both are active, depending on the order the scripts run, it may or may not work: if wikEd runs first, the HotCat form isn't there yet, and everything is fine. If HotCat runs first, wikEd is misled, and then the "jump to top" problem occurs. Now, that's an area of HotCat that hasn't changed in a long time, and although I'm not sure, I don't think wikEd has changed in that area either. Why didn't that problem surface earlier? Cacycle, any suggestions for avoiding this conflict? Lupo 21:47, 9 May 2014 (UTC)[reply]
Thanks for these details. I will check into it. Cacycle (talk) 21:52, 9 May 2014 (UTC)[reply]
BTW: if there is an element with id "hotcatCommitForm" in the DOM, you can be sure not to be on an edit page, as HotCat is never active on edit pages. Lupo 22:34, 9 May 2014 (UTC)[reply]
I have fixed the problem in the current version 0.9.126b, please update with Shift-Reload. Thanks to Lupo! Cacycle (talk) 22:57, 9 May 2014 (UTC)[reply]
OK, not yet fixed but still working on it... Cacycle (talk) 23:10, 9 May 2014 (UTC)[reply]
Finally it works... (wikEd version 0.9.126c). Cacycle (talk) 23:30, 9 May 2014 (UTC)[reply]
Thank you both for investigating and resolving this. Nthep (talk) 10:29, 10 May 2014 (UTC)[reply]

Template settings

I would like to have {{Blacklisted-links}} auto expanded for me and have that setting persist, right now I have to click it every time I want to review an article. Werieth (talk) 12:49, 8 May 2014 (UTC)[reply]

How to search through User history?

I want to search through user edit history for specific articles, every time I use the Tag filter in contributions no results appear even when I know the user edited the article. Valoem talk contrib 15:06, 8 May 2014 (UTC)[reply]

The tag filter looks for articles that match certain defined criteria, like a section being blanked. If you want to see all the edits made by one specific user to one specific article, you can either go to their contribs and search for the article, or go to the article history and search for the username. In both cases, leave the tag filter window empty. --Redrose64 (talk) 16:32, 8 May 2014 (UTC)[reply]
So I have to manually search through all contribs? Valoem talk contrib 17:12, 8 May 2014 (UTC)[reply]
Or the articles' history. There are other things you can do. Most useful is try and narrow it down by date to shorten either sort of list. Sometimes 'what links here' helps if it e.g. finds a related formal discussion, such as an RM or AfD, or an archive such as for a notice board, all of which will have dates on. Or the articles' talk pages which again have dated contributions.--JohnBlackburnewordsdeeds 17:30, 8 May 2014 (UTC)[reply]
@Valoem: You could use commons:MediaWiki:Gadget-rightsfilter.js in the user contributions page. Helder.wiki 19:35, 8 May 2014 (UTC)[reply]
Sorry, how do I do this? Valoem talk contrib 20:02, 8 May 2014 (UTC)[reply]
@JohnBlackburne: You just need to add

mw.loader.load( '//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-rightsfilter.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

to your common.js (and clear you cache). Helder.wiki 20:39, 8 May 2014 (UTC)[reply]
Added and clear cache now what? Valoem talk contrib 21:10, 8 May 2014 (UTC)[reply]
@Valoem: check the link I posted above. There will be a new field where you can type something, and the script will restrict the list to (or highlight) those items which match what you choose. Helder.wiki 22:08, 8 May 2014 (UTC)[reply]
...and on other special pages where there are lists, check the action menu in the top of the page to find a "Filter" link which shows this field. Helder.wiki 22:10, 8 May 2014 (UTC)[reply]
@Valoem: You might also find the user contribution search tool useful. Graham87 08:45, 9 May 2014 (UTC)[reply]
@Graham87: The tool doesn't seem to load for me. Valoem talk contrib 13:25, 9 May 2014 (UTC)[reply]
It's working for me at the moment, but the WMF Labs server is flaky. Graham87 14:35, 9 May 2014 (UTC)[reply]

Reduced pull quote problem

The template {{Reduced pull quote}} is supposed to display curly quotes, then the selected text rendered in Times New Roman with size 3.3 em. It clearly is not—the quotes are there, but it looks like the standard font. (I asked this question on the template talk page, but that page doesn't get much traffic so asking here.)S Philbrick(Talk) 15:46, 8 May 2014 (UTC)[reply]

attempt to move a move-protected page by non-admin results in wrong error message

About a year and a half ago, I reported a bug in which MediaWiki displays the wrong message error when a non-admin tries to move a move-protected page (Template:Bugzilla); the message would say the page can only be edited by admins even when it's merely protected from moves. A developer reported that the bug has been fixed, but when I try to rename a move-protected page with my non-admin test account, it still says the page can only be edited by administrators.

Does one of the system messages need to be updated, or is this some sort of regression? --Ixfd64 (talk) 17:34, 8 May 2014 (UTC)[reply]

I've reopened the bug, and I have a patch now. The problem is that we customize the message that they changed, and we can't currently tell whether it's being called for an edit or move. My patch will allow it to distinguish these cases. Jackmcbarn (talk) 19:25, 8 May 2014 (UTC)[reply]

Error message I don't understand

Hello,

Lately when I click on some links I get the error message: "AFCH error: user not listed AFCH could not be loaded because "Parabolooidal" is not listed on Wikipedia:WikiProject Articles for creation/Participants. You can request access to the AfC helper script there."

I'm not trying to create an article or anything when I get this message. I don't know what a "AfC helper script" is. I am just following a wikilink which I works anyway for me but with this message. What is the message telling me to do? Thanks, Parabolooidal (talk) 17:38, 8 May 2014 (UTC)[reply]

See the similar question above at Wikipedia:VPT#.22AFCH_error.22_box, it might also be the problem you are having. RudolfRed (talk) 18:07, 8 May 2014 (UTC)[reply]
Thanks for that link - I never would have figured it out. Hope removing the AfC from Gadgets will do away with it. (Thing is, I haven't changed my Preferences in a while, but this error message just started in the last few days, so it seems like something has changed!) Parabolooidal (talk) 18:53, 8 May 2014 (UTC)[reply]

Cologne blue taskbar

Hi, Is it possible to have a hide/show option for the side item bar so that you can click "hide" while reading to the full page screen and then click show when you want to navigate? Where it says "Find" would probably be a good place for a hide/show option of the whole side bar. It's an option which I'm surprised isn't available in preferences.♦ Dr. Blofeld 19:24, 8 May 2014 (UTC)[reply]

On vector skin, I use commons:MediaWiki:IPadSidbarSlider.js. Helder.wiki 19:38, 8 May 2014 (UTC)[reply]
Doesn't work on cologne blue!♦ Dr. Blofeld 20:30, 8 May 2014 (UTC)[reply]
It won't have worked, because it's Javascript (the .js on the end of the filename is the key here), and you put it into your .css file. Try putting it in User:Dr. Blofeld/cologneblue.js instead. --Redrose64 (talk) 23:22, 8 May 2014 (UTC)[reply]
Doesn't work. An arrow does appear but it doesn't hide the bar.♦ Dr. Blofeld 09:08, 9 May 2014 (UTC)[reply]

Template expansion limits

I'm continuing to prep the Paul Erdős Bibliography article, and have just come across Wikipedia:Template limits. I was planning on using ~1600 cite journal templates and a couple hundred math templates. Writing an article of this size requires creating a BibTeX database, writing code to convert those entries into wiki markup, and then uploading the result. I'd really rather not have to write the conversion script twice (once using cite, then a second time without any templates because I ran into the limit).

Can someone give me a ballpark idea how many cites can be included in an article before I can expect to start hitting the expansion limits? I expect the answer will be "It depends", but I'm looking for a rough guide here. If 500-citation articles regularly run into problems, then I'll plan on hand-coding my own cites.

Thanks much,

Lesser Cartographies (talk) 05:05, 9 May 2014 (UTC)[reply]

Someone else may have a more technical answer, but you might consider breaking the article into multiple articles, with one article covering each decade (or some other reasonable range). Then create a master article, as was done with List of gay, lesbian or bisexual people. I don't know if this is a standard way of addressing potentially-long articles, but it appears to work. – Jonesey95 (talk) 05:32, 9 May 2014 (UTC)[reply]
Numbers for citation templates from 2006 have no relevance. Many of the main citation templates – including {{cite journal}}, {{cite book}}, {{cite web}}, etc. – were re-written in Lua instead of wiki-template code. Lua is much more efficient. I don't have numbers for you, but it would be easy to find out by experiment. Just grab a version of a filled in template that approximates how you are going to use it and put 1600 copies on a page in your sandbox. See what happens.
I would second the opinion that it sounds like your page inherently needs to be broken into multiple pages. Without consideration of the number of citation templates which you plan to use, almost anything that has 1600 entries should be broken into multiple pages. Think about how hard it will be for users to read the page with 1600 bibliographic entries. Normal default usage in Wikipedia is to present a couple of hundred entries per page for most system lists. This could be considered an appropriate ballpark. How you organize breaking the page into subpages depends on what exactly you are listing. As a bibliography, breaking into groups of first letters sounds normal. — Makyen (talk) 07:10, 9 May 2014 (UTC)[reply]
I just tested 2000 long-ish instances of {{cite journal}} in my sandbox, and I got to 1007 before I went over the post-expand include size limit. That number will increase for shorter citations, but probably not enough to fit 1600 normal-sized citations in. There's not much you can do about that apart from substitute them, or better, expand them with Special:ExpandTemplates. (Alternatively, as was suggested above, separate pages would also work.) As most of the cite templates are already Lua-ified, we can't reduce the post-expand include size by tweaking things inside the templates. And VanIsaac's #switch won't work, as that is a fix for the wrong template limit (the expansion depth). The problem here is the sheer amount of text, which using #switch will not affect. So, in short, if you're expecting more than 1000 cites, and you don't want to split the page, substitution is probably the way to go. — Mr. Stradivarius ♪ talk ♪ 10:23, 9 May 2014 (UTC)[reply]
Yeah, I misunderstood what he was doing exactly - I though he was writing a series of articles that would need to select from Erdos' bibliography, not a single article archive - but I still think resurrecting the old non-lua citation template so he can subst in the citation formatting in pieces is probably a workable idea to limit template expansion issues. VanIsaacWScont 00:58, 10 May 2014 (UTC)[reply]
I don't know if any of these are such a good idea. Given this sample, here's what I get:
Original
{{cite book |last=Richardson |first=Tim H. |title=Sweets: A History of Candy |publisher=Bloomsbury USA |year=2002 |isbn=1-58234-229-6 |pages=53–54}}
Subst
{{#invoke:citation/CS1|citation |CitationClass=book }}
Special:ExpandTemplates
<span class="citation book">Richardson, Tim H. (2002). ''Sweets: A History of Candy''. Bloomsbury USA. pp. 53–54. [[International Standard Book Number|ISBN]] [[Special:BookSources/1-58234-229-6|1-58234-229-6]].</span><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3ASpecial%3AExpandTemplates&rft.aufirst=Tim+H.&rft.aulast=Richardson&rft.au=Richardson%2C+Tim+H.&rft.btitle=Sweets%3A+A+History+of+Candy&rft.date=2002&rft.genre=book&rft.isbn=1-58234-229-6&rft.pages=53-54&rft.pub=Bloomsbury+USA&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;"> </span></span>
So regular subst'ing is useless (that produces an error message about an empty citation), and ExpandTemplates is filled with span tags. Why not just plain manual formatting? This is a one-time task that won't require much maintenance. WhatamIdoing (talk) 14:49, 9 May 2014 (UTC)[reply]
Hmm, that is food for thought. You're right that expanding the templates as-is doesn't make very clean wikitext. However, if we can convince the module not to output all of those span tags, then we might well be able to fit 1600 references in an article without going over the template limits. All characters in the code output count towards the post-expand include size, after all. — Mr. Stradivarius ♪ talk ♪ 15:35, 9 May 2014 (UTC)[reply]

I would seriously question the readability of an article with 1600 references.. And thus the article's existence. I haven't read this, but if you need 1600 references for an article, then that just feels wrong to me. —TheDJ (talkcontribs) 16:55, 9 May 2014 (UTC)[reply]

It's really more a "List of publications by" than "article about". A list of 1600 items is very long, but not necessarily completely out of the question. WhatamIdoing (talk) 17:30, 9 May 2014 (UTC)[reply]
Thank you all for the in-depth responses. Let me give a few more details. The main bibliography I'm working from is here. Most of these entries are categorized using one or more Mathematics Subject Classification numbers. The article will have a tabular topic index with columns representing decades, rows representing the MCS categories, and the table itself containing a list of <ref> tags that point to the bibliography entries.
I've given a fair amount of thought to how this collection could be carved into multiple articles, and at this point I haven't found a good solution. The <ref> tags in the topical index will have both "group" and "name" attributes, and I'm assuming there's no way to point those to a different page. (If there was the problem is solved: the topical index forms one page, and each decade's worth of citations would get a separate page for the actual bibliographical entries.)
I've also thought of creating several articles divided by either year or collection of topics. The former means that if you want easy access to all of Erdos's work on set theory, you need to visit several articles. The latter means that it's difficult to make serendipitous connections: what else was Erdos working on when he published his seminal work on random graphs?
I agree that a 1600-entry bibliography is unreadable. Part of my motivation for doing this work was my frustration dealing with Grossman's dead-tree attempt (and let me emphasize that Grossman did a terrific job given the limitation of the media he had to work with). 1600 ref tags spread over a table should be far more useful and usable interface to the bibliography proper.
I started this project thinking that it was the most difficult (but feasible) article I could come up with, and while it's far more difficult that I originally imagined, I've yet to prove it isn't feasible. Generating raw HTML sounds like a good fallback position, and perhaps writing a set of specialized "skinny" templates is worth investigating as well. Anyway, this is a hell of a lot more fun than chasing sock puppets.....
Lesser Cartographies (talk) 17:41, 9 May 2014 (UTC)[reply]

VisualEditor citation tool going live

I've just enabled the citation tool in VisualEditor, which adds a prominent menu in the toolbar listing the most common citation templates to insert as new citations. You can also use this tool to edit most existing references that use these templates, bypassing the need to edit a template inside a reference. Feedback welcome!

Jdforrester (WMF) (talk) 14:38, 9 May 2014 (UTC)[reply]

Strange offsets

Hello all, I've got another issue that may or may not be with the computer I'm currently using: Syntax Highlighting's all discombobulated, like orange highlighting four letters that are unrelated to the four tildes when I sign (simple example shown in the screenshot); and sometimes the search results show up in the center of the dashboard as opposed to under the search bar. I remember something here a while ago about the latter, but can't remember what was said there, and it only happens sometimes. Any ideas about why? (I'm using Vector without disabling the new font, and the problem doesn't appear to be connected with any user scripts I've got in my vector.js or common.js pages) Supernerd11 :D Firemind ^_^ Pokedex 14:41, 9 May 2014 (UTC)[reply]

I'm assuming you are using the Gadget of: mw:User:Remember_the_dot/Syntax_highlighter. I recently made some changes to the styling and setup of WikiEditor, so it could be that this is affecting this Gadget in an unforeseen way. Perhaps User:Remember_the_dot can help both of use out with this :D —TheDJ (talkcontribs) 17:31, 9 May 2014 (UTC)[reply]
Yep, that's the one! If RtD doesn't respond for a while, I'll leave a message on his MediaWiki page. Supernerd11 :D Firemind ^_^ Pokedex 21:09, 9 May 2014 (UTC)[reply]
What web browser are you using, and what version? The syntax highlighter requires a fully up-to-date web browser. —Remember the dot (talk) 03:03, 10 May 2014 (UTC)[reply]
Ah, I didn't realize Firefox released a new update. Seems be fixed now, thanks! Supernerd11 :D Firemind ^_^ Pokedex 16:00, 10 May 2014 (UTC)[reply]
[addendum] Still seems to be sometimes offsetting search results (screenshot available per request). Any ideas? Supernerd11 :D Firemind ^_^ Pokedex 19:47, 11 May 2014 (UTC)[reply]

Adding local description to files

What is this new feature of "adding local desciption" to files? It creates dummy files on local wikis as the users do not understand that they are not editing Wikimedia Commons but a local wiki. Why are the local descriptions even necessary? Is this a bug or flawed design? --Pxos (talk) 18:02, 9 May 2014 (UTC)[reply]

This must be some kind of error: [19]. You could add local descriptions technically but it is not allowed and there is a big warning. Well there is no warning on the Finnish Wikipedia and people have started to edit the local file pages. Please relay my rant to the people who can do something about this. --Pxos (talk) 18:07, 9 May 2014 (UTC)[reply]

It's not an error; adding a local description for a Commons file is allowed, but there's generally no reason to do that except in some cases (such as locally featured images). SiBr4 (talk) 18:21, 9 May 2014 (UTC)[reply]
And people will add the local descriptions to files because they cannot understand the difference between Commons and local repositories. They just think that they are editing the description of the file. It wasn't a problem before the tabs were introduced. Now it is. When the file is renamed in Commons, the local description becomes orphaned and the data is lost. --Pxos (talk) 18:29, 9 May 2014 (UTC)[reply]
It was always possible to create a local description, and I think there used to be a tab just saying "Edit". The new tab name is more descriptive, and a new tab "View on Wikimedia Commons" was added. The tabs are wide. You can make them more narrow and just say "Commons" and "Edit" with this in your CSS:

importScript('User:PrimeHunter/Image tabs.js'); // Linkback: [[User:PrimeHunter/Image tabs.js]]

PrimeHunter (talk) 18:38, 9 May 2014 (UTC)[reply]
I want the tabs to be "Edit on Commons" for everyone as default. The tab "add local description" should be hidden somewhere like the "move" tab is or the "delete" tab for administrators. --Pxos (talk) 18:41, 9 May 2014 (UTC)[reply]
(edit conflict) Before the "View on WM Commons" and "Add"/"Edit local description" tabs there would be normal "Read"/"Edit"/"History" tabs if the local page existed and a "Create" tab if it didn't exist, if I remember correctly. I don't see how what you describe only became a problem when the tabs were changed; someone who wants to add/edit a description and doesn't know what Commons is would click "Create"/"Edit" before and will click "Add local description"/"Edit local description" now. The automatic box "This is a file from the Wikimedia Commons..." and the edit notice you described are also still there. SiBr4 (talk) 18:47, 9 May 2014 (UTC)[reply]
The "create" tab conveys to the reader a meaning that by pressing it, one is going to create a file. There is no incentive to press "create" when people see that the file already exists. Now the text "add local description" might be understood as "edit the text that is visible on the page". There is a case of Finnish Wikipedia where a person uploaded the file on Commons with all the correct license information but then came back to add to what he had written. Guess where he wrote the new text? When done, the file page displays both the text from Commons and from the local page. Perhaps we should also construct an automatic box that says "you have indeed pressed the wrong tab, now go away." What's the point in that? --Pxos (talk) 19:11, 9 May 2014 (UTC)[reply]
You can't create a file on MediaWiki, only upload one. To me it doesn't seem logical if you need to click "add a description" in order to edit one that's already there. Even if one does wrongly click the "add local description" tab, there's the edit notice that says descriptions should be added at Commons and creating a local page is rarely necessary. An "Edit on Commons" button and/or moving the local description buttons to the drop-down menu seems like a good idea, nevertheless. SiBr4 (talk) 19:39, 9 May 2014 (UTC)[reply]
People create files by uploading them. There are thousands of people who blatantly defy logic in their everyday lives. Any logical system that is designed to be used by people will fail sooner or later. It seems perfectly logical to click various buttons to achive some goals on Wikipedia. When a tab or button gives you a page to edit, the page will be edited – and when the result seems convincing, there is no problem. Only the few logical people understand where the bits and pieces of the description really is. The rest could not care less. --Pxos (talk) 20:00, 9 May 2014 (UTC)[reply]
The tab "add a local description" gets you to a page that says "please do not add a local description" on the English Wikipedia. On the Finnish Wikipedia there is no warning at all. The tabs read now "VIEW on something"; "EDIT something"; "ADD something". Normal people just do not understand what is "local" and what is "Commons". --Pxos (talk) 20:17, 9 May 2014 (UTC)[reply]
(edit conflict) Exactly the same can be argued for the old system as well, so again, why is it a problem that only started with the tabs change? Also, do you think the edit notice isn't clear or do you think people will ignore it? You mentioned an example at the Finnish Wikipedia, though the "this file is on Commons" note appears to be a normal line of text on fiwiki, which is more easily skipped than the red error-like box on this wiki. SiBr4 (talk) 20:27, 9 May 2014 (UTC)[reply]
Well to be frank, the problems only start when I notice them, of course. Hah haa! I don't think that anyone paid attention to this problem before me. I tried to explain above that the phrases "create" and "add a local description" seem different to the reader although they lead you to the same page as before. This is a problem that clearly does not affect the English wikipedia, but I am such a poor bastard that I don't know where to discuss this properly. If I can be wrong in some other venue, please direct me there. --Pxos (talk) 20:37, 9 May 2014 (UTC)[reply]

If you want to request a change to the interface of the Finnish WP, then you obviously need to do that there, though for general discussion or technical help it's reasonable to ask the EnWP village pump rather than the Finnish one since you'll get more attention here. The "View on Commons" link was added exactly for preventing people locally editing a file page that's actually at Commons (the patch is here, by the way).
I've found the translatewiki page using Google (I didn't know about that site)". I think the "e.g. Wikimedia Commons" in the description of the message is incorrect, as the message should show if the local page doesn't exist yet (since if it does exist, it should display "edit local description source"). Refers to removed comment. SiBr4 (talk) 21:09, 9 May 2014 (UTC)[reply]

Thank you for the link to the Gerrit patch! It seems I have thought the solution was the problem, now I understand that the end users are the problem. I am certain that the new tab "add local description" will prevent people from adding local descriptions to the files. --Pxos (talk) 21:32, 9 May 2014 (UTC)[reply]

Numbers rendering below text on article titles in Vector skin

I noticed that the number renders below the line of text on this article's title when using the Vector skin. Is this a know bug? If not, will someone tech-wise report it, please? Thank you.—John Cline (talk) 22:41, 9 May 2014 (UTC)[reply]

ABC1234567890DEF
It's a feature of the Georgia font used for the headings, see sample above. Matma Rex talk 22:58, 9 May 2014 (UTC)[reply]
Moreover, it's an effect of the recent decision to use a different font from the body text (which is the vanilla font-family: sans-serif;) for the headings in Vector skin. In Vector, headings now use the cascade font-family: "Linux Libertine",Georgia,Times,serif; one or more of which has text figures. @John Cline: If you want the headings to be sans-serif like the main text, I can knock up some simple CSS to do that. --Redrose64 (talk) 10:38, 10 May 2014 (UTC)[reply]
Thank you Redrose64, that is a kind offer and I know your skills are in great demand; always. I am more interested in experiencing Wikipedia just as our newest users do, so as not to loose touch with the perils they will surmount. The titles rendition just seemed odd to me upon first seeing it, though I now understand it is not a bug after all. Nevertheless, I am now ready when a new user asks at the teahouse about this occurrence, to give a good answer. I do thank everyone who replied here; helping me to this end. Cheers.—John Cline (talk) 11:03, 10 May 2014 (UTC)[reply]

Question regarding a template

Hello guys, I'd like to ask you something about a template I used. As you can see here Olympiacos B.C.#Seasons the template works fine, but ideally I would like the cursor to start from the bottom of the box (from the newest season, up to the older ones) when somebody visits the page. Is there any way I can achieve that? Thank you in advance, Gtrbolivar (talk) 23:33, 9 May 2014 (UTC)[reply]

Yes, probably; but I don't think that you should be doing that, see MOS:SCROLL. --Redrose64 (talk) 10:40, 10 May 2014 (UTC)[reply]
Thanks anyway. Gtrbolivar (talk) 12:15, 10 May 2014 (UTC)[reply]

Stats

According http://stats.grok.se/en/201405/Ukraine article "Ukraine has been viewed 153902 times in 2014.05. This article ranked 29 in traffic on en.wikipedia.org." Is there any place where i can view full ranks, recently (or live) updated. If possible for top ~1000 pages. Also, if is possible, not only for enwiki: i.e. i want see most viewed articles on rowiki, ruwiki and ukwiki. (general/all-time and recently stats). Thank you in advance. 188.213.216.18 (talk) 13:50, 10 May 2014 (UTC)[reply]

See Wikipedia:Statistics#Page views. PrimeHunter (talk) 14:39, 10 May 2014 (UTC)[reply]

Transclusion of subpages with parameters broken from yesterday?

I implemented transclusion of a review list on the main page of WP:Peer review some time ago. I use the parameter 'mode' to set whether reviews should be transcluded in full or not.

I use this transclusion: {{Wikipedia:Peer review/List of active reviews|mode=transclude}}

From yesterday, this stopped transcluding anything at all, and now just sits as a link. Why is there a problem? {{Wikipedia:Peer review/List of active reviews}} transcludes fine, but with a parameter, nothing transcludes at all. This includes the headings on the subpage, which should transclude regardless of the parameter.

I've re-implemented the old system in the meantime.

Hoping for some clear answers to this bedevilling problem, --LT910001 (talk) 23:42, 10 May 2014 (UTC)[reply]

The page exceeds the template limits. Matma Rex talk 23:54, 10 May 2014 (UTC)[reply]
Ah. Any way to get around this using the transclusion above? --LT910001 (talk) 04:04, 11 May 2014 (UTC)[reply]

I want to reorganise my sidebar menus. I know how to add new links to a portlet and how to create new portlets on my .js page. What I don't know how to do is move a built-in item from one portlet to another. Is this possible? SpinningSpark 10:50, 11 May 2014 (UTC)[reply]

It is possible, but only using JavaScript/jQuery. There is no pre-defined function for that (that I know of), so you will need to write such a function yourself. Edokter (talk) — 10:55, 11 May 2014 (UTC)[reply]
I realise it is going to need javascript, but I don't really have the capability, that's why I am asking here. As I say, I know how to insert items into portlets, as I have been doing at User:Spinningspark/monobook.js, but I don't know how to remove an item I haven't inserted myself. Any hints appreciated. SpinningSpark 11:11, 11 May 2014 (UTC)[reply]
I don't know how to move it but if you know an addPortletLink to add it where you want it then you can do that and remove it in the other place. Look for its id in the html source, for example id="t-whatlinkshere" for "What links here". Then add this to your CSS:
#t-whatlinkshere {display: none;}
PrimeHunter (talk) 12:43, 11 May 2014 (UTC)[reply]
Stupidly, I already had examples of that css code in my skin but thought that it would suppress both the old and the new link. The key thing I was missing is that I could give the new link a different id. Thanks for your help. SpinningSpark 15:30, 11 May 2014 (UTC)[reply]
@Edokter, Spinningspark, and PrimeHunter: I've got a function that does this in my nothingthree.js collection that moves portlets. Using the collection's currently a little awkward (you import the script, and it imports Special:MyPage/nothingthree-config.js where you can activate individual functions), but here's an example from the script I use to selectively move the "delete" tab out of the menu: nothingthree.tabMove.core({"id": "ca-delete", "followingElement": "ca-history", "targetParent": "p-views"});{{Nihiltres|talk|edits}} 22:18, 12 May 2014 (UTC)[reply]

Searching for non-alphanumeric character returns an error.

I wanted to search for instances of U+20A4 LIRA SIGN ("₤") The obvious search gives an error. Searching for e.g. "₤5" searches for "5", ignoring the currency symbol.

On further testing, the situation seems to be: any combination of non-alphanumeric characters gives an error; if any alphanumeric characters are added then these are searched for, the non-alphas being ignored entirely. alphanumerics from other alphabets seem to be treated similarly to Latin alphanumerics.

Is this a configuration issue with this wiki, or a MediaWiki bug? And are there any workrounds to allow searching for arbitrary non-alpha characters? Pseudomonas(talk) 21:12, 11 May 2014 (UTC)[reply]

@Pseudomonas: It's a known bug in the current search system. Try enabling the "New search" beta feature (Special:Preferences#mw-prefsection-betafeatures), it at least doesn't throw errors at you, although I have been unable to get it to actually search for the sign – it supports some advanced options, maybe you can find something working in the documentation at mw:Help:CirrusSearch? (cc: Manybubbles / NEverett (WMF) who works on this) Matma Rex talk 23:07, 11 May 2014 (UTC)[reply]
Known bug in lsearchd/MWSearch. I've given up trying to find a solution to it and instead we're devoting full efforts to getting Elasticsearch/Cirrus live everywhere for everyone. ^demon[omg plz] 16:21, 12 May 2014 (UTC)[reply]

AWB password

Dear editors: I am ready to try out the AutoWikiBrowser. I have downloaded and installed it. I have managed to coax it into loading a list of pages. At this point I need to log in. The instructions say that I should see the "standard Wikipedia login", but the login dialogue box does not look like the one that I usually use to log into Wikipedia. Maybe this is because I'm not an IE user. Just to be sure: am I right in assuming that the login and password required are those that I use when logging into the English Wikipedia, and that this is a secure connection? —Anne Delong (talk) 04:31, 12 May 2014 (UTC)[reply]

  • Yes, the login is for AWB, so it looks nothing like a regular wikipedia login screen, and your AWB login is completely independent of your wikipedia login status. The AWB login is a popup window called "Profiles" with heading of ID, Username, Password saved?, Default settings, and Notes; Login, Add, Edit, and Delete buttons; a Quick login frame with Username and Password fields, Save this account and Save password checkboxes, and a Login button; and lastly a Close button. If that's what you are seeing, just enter your wikipedia username and password and you can login. If you save your account, then it will become a profile that you can click on the next time you try to login. VanIsaacWScont 06:38, 12 May 2014 (UTC)[reply]
  • And yes, this is a secure connection (Wikipedia:AutoWikiBrowser/User manual#Login). Be cautious about asking AWB to remember the password, though, as someone who gains access to your machine would then be able to make AWB edits using your account. -- John of Reading (talk) 06:46, 12 May 2014 (UTC)[reply]
Thanks,Van and John of Reading. I was seeing the right login box; I am just cautious. No, I never ask for my password to be saved; it's only in my head, which rapidly running out of storage space. —Anne Delong (talk) 16:37, 12 May 2014 (UTC)[reply]

06:00, 12 May 2014 (UTC)

Sort-table sorting numbers "alphabetically"

Resolved

The table at Casualties_of_the_Syrian_Civil_War#Foreign_civilians_killed seems to be sorting the second, numerical column "alphabetically" (e.g. 11 ... 19 ... 2 ...). Could anyone help? Thanks! It Is Me Here t / c 17:17, 12 May 2014 (UTC)[reply]

@It Is Me Here: Yes[38]. The table sorter does try to detect table columns containing only numeric values, but this fails in some cases (the problem here are the references, a value like "74[110]" is nor recognizable as a number). Matma Rex talk 17:39, 12 May 2014 (UTC)[reply]
Thank you! It Is Me Here t / c 19:28, 12 May 2014 (UTC)[reply]

login problems: new public computer at public library

Our public computers at our local library often have givrn me trouble. We now have HP Compaq Pro 6300. The "START" page says the OS is Windows 7 (ver. unknown), and Windows Help says the browser is Internet Explorer 9 (ver. unknown). When I attempt to Log in, I repeatedly find myself back on an edit page with an error message: "You are not logged in!" I am sending this message from my cellphone, but losing battery fast: please, if gou can help, leave me a message in my User_Talk page: user:Ragityman. I will attempt to check it from this library computer. Rags (talk) 20:42, 12 May 2014 (UTC)[reply]

Media Viewer launches next week on the English Wikipedia

Media Viewer lets you see images in larger size
The majority of users find Media Viewer useful.

Greetings! As discussed in earlier posts, Media Viewer is scheduled to launch on the English Wikipedia next week, to provide a better viewing experience for our users.

Media Viewer has been tested extensively on many large wikis around the world, and the feedback collected from thousands of users suggests that this tool is generally useful to them, as outlined in these survey results. More importantly, the rate of favorable feedback keeps increasing across all languages over time: for example, the French approval rate started out at about 64% a few weeks ago, and is now up to 70%, which is very encouraging.

Here on the English Wikipedia, over 13,874 beta users have been testing it, since the tool was first deployed as a beta feature in November 2013. Thanks to all their helpful feedback, Media Viewer has been greatly improved in recent months, and we are now getting ready to roll it out on all wikis worldwide.

Media Viewer will be enabled by default on the English Wikipedia on Thursday, May 22 at about 20:00 UTC. We will deploy this tool very carefully and keep a close eye on this release, to make sure it all goes smoothly. The tool will then be released to all wikis the following week, as described in this release plan.

Please let us know if you have any questions or comments about Media Viewer, which you can test here in beta -- or learn more about on this Help page (which includes tips for bypassing this tool, or turning it off in your preferences). You are invited to share your feedback in this discussion, to help improve this feature. You're also welcome to take this quick survey -- or join this in-depth discussion on MediaWiki.org, as you prefer.

Many thanks to all the community members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This has been an exceptionally productive partnership, which we hope to build on for future projects. Fabrice Florin (WMF) (talk) 01:15, 13 May 2014 (UTC)[reply]