Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
(2 intermediate revisions by the same user not shown)
Line 834: Line 834:
<hr><br><hr>
<hr><br><hr>
:I have a similar problem on ro.wiki. I created template [[:ro:Template:Navbox-test|Navbox-test]] (copy of [[Template:Navbox|Navbox]]). It uses [[:ro:Module:Navbox]] (+ [[:ro:Module:HtmlBuilder]] and [[:ro:Module:Navbar]]). Everything in them are copied from enwiki, but result is not the same - navbox is broken. See here an example [[:ro:User:XXN/teste2]]. How you can see the 3 buttons: view, talk and edit template - are not at their place, and when i collapse template it retracts in upper-left corner. What is the problem? [[User:XXN|XXN]] ([[User talk:XXN|talk]]) 23:15, 10 January 2014 (UTC)
:I have a similar problem on ro.wiki. I created template [[:ro:Template:Navbox-test|Navbox-test]] (copy of [[Template:Navbox|Navbox]]). It uses [[:ro:Module:Navbox]] (+ [[:ro:Module:HtmlBuilder]] and [[:ro:Module:Navbar]]). Everything in them are copied from enwiki, but result is not the same - navbox is broken. See here an example [[:ro:User:XXN/teste2]]. How you can see the 3 buttons: view, talk and edit template - are not at their place, and when i collapse template it retracts in upper-left corner. What is the problem? [[User:XXN|XXN]] ([[User talk:XXN|talk]]) 23:15, 10 January 2014 (UTC)

*All the inboxes for {{tl|Infobox horseracing personality}} have had a major parameter collapsed when it's not the default, and there is no "show" option to uncollapse them. See, e.g. [[Rosie Napravnik]]. It's not in the history of that template, so must be some parent set of templates, but it's not happening everywhere. Earlier, someone broke everything at Infobox person, but that was fixed. Who is screwing around with these parameters and where? [[User:Montanabw|<font color="006600">Montanabw</font>]]<sup>[[User talk:Montanabw|(talk)]]</sup> 23:50, 10 January 2014 (UTC)


==Visual impairment==
==Visual impairment==

Revision as of 23:54, 10 January 2014

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security@wikimedia.org or filed under the "Security" product in Bugzilla.

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


New classic edit toolbar buttons no longer appear to work in new version on mediawiki?

New classic edit toolbar buttons, which I created myself, no longer appear in the new version on mediawiki 1.22 monobook skin.

I created this page: User:Igottheconch/common.js with several edit toolbar buttons, and nothing appears, even after I refreshed the page. I have tried this on three other wikis, mediawiki.org and two personal wikis, and these new edit toolbar buttons do not appear.

Any suggestions?

Thank you!

Igottheconch (talk) 18:54, 28 December 2013 (UTC)[reply]

@Igottheconch: mwCustomEditButtons is no longer supported, you can achieve the exact same functionality using mw.toolbar.addButton(): basically, replace structures like mwCustomEditButtons[mwCustomEditButtons.length] = { ... } with mw.toolbar.addButton({ ... }). This change has been discussed at Template:Bug and was announced via Tech News a few months ago. Matma Rex talk 20:55, 28 December 2013 (UTC)[reply]

Sigh, i still can't get it to work.

How would I change the below to something that would work? Thank you. 

 if (mwCustomEditButtons) {
 
   mwCustomEditButtons[mwCustomEditButtons.length] = {
     "imageFile": "http://images.wikia.com/central/images/7/74/Button_comment.png",
     "speedTip": "Comment visible only for editors",
     "tagOpen": "<!-- ",
     "tagClose": " -->",
     "sampleText": "Insert comment here"}
  }

Igottheconch (talk) 22:07, 29 December 2013 (UTC)[reply]

@Igottheconch: You have one '}' too many, that should never have worked :). The following is okay. Matma Rex talk 11:17, 6 January 2014 (UTC)[reply] 

  mw.toolbar.addButton({
     "imageFile": "http://images.wikia.com/central/images/7/74/Button_comment.png",
     "speedTip": "Comment visible only for editors",
     "tagOpen": "<!-- ",
     "tagClose": " -->",
     "sampleText": "Insert comment here"
  });

A template purge bot or manual purge assistant might be handy

(originally posted at WP:Help desk)

There have been a rash of template vandalisms lately. Even after a vandalized template is fixed, pages may continue to show the vandalism until they have been purged. This is a rather tedious process to perform manually, especially since the vandals target highly used templates. The community is having a discussion about what if anything could/should be done: Wikipedia:VPP#Template_Vandalism.

Is there a project page where 'bot and/or tools authors get together to exchange ideas? I was thinking that a nice 'bot and/or manual tool to have would be one that can seek out all pages that transclude a recently modified template and apply a purge to those pages.

A manual tool would probably put less load on the servers, since I can easily imagine templates being edited in stages.

I was originally considering submitting a feature request to Bugzilla, but this doesn't exactly count as a bug or even a MediaWiki enhancement. Stigmatella aurantiaca (talk) 16:24, 31 December 2013 (UTC)[reply]

To refresh pages after template changed, add "?action=purge". -Wikid77 08:29, 6 January 2014 (UTC)[reply]
  • Wait 2 days or edit from transclusion-info page: The null-editing of pages has been updating the "page was last modified" date at bottom, so for templates with fewer than 1,000 related pages, the automatic reformat should complete within 2 days. However, when major articles are affected, then they can be directly null-edited from the related transclusion-info page, such as:
There is an edit-tab for each page listed, and high-visibility pages can be selected sooner (if known) from the list. Edit perhaps 40 pages, and then refresh the transclusion-info list (the page-count lags behind for days). Meanwhile, people have been discussing reduced editing of the mega-templates which flood the wp:job_queue(s) with millions of pages to reformat. Otherwise, "Do not Panic" as there are numerous problems in thousands of pages, and the major readership has come to expect occasional vandalism to slip past, along with out-dated facts, or partial data. Also, some vandalism can be a good thing, if it spurs idle users to fix the page, then copy-edit for clarity, and perhaps update other pages. We are too accustomed to seeing vandalism as an isolated, negative event, rather than an incentive for many users to actively help update thousands of other pages. -Wikid77 (talk) 18:51/20:43, 31 December 2013 (UTC)[reply]
Example: A template changed at 21:28, 3 January 2013, triggered reformatting of 217 small pages (to hide a space in mixed numbers), which completed by early 5 January (within 40 hours), while the wp:Job_queue(s) held over 500,000 jobs in processing. -Wikid77 08:29, 6 January 2014 (UTC)[reply]
In answer to the question about where to ask about bot ideas, I think you want WP:Bot requests. A manual tool would probably be better, since most template edits don't need the pages using the template to be updated immediately. It's only urgent cases such as vandalism where it's necessary.
Regarding a Bugzilla request, MediaWiki already has a feature to update all pages that transclude a template: just edit the template. For templates with less than 500 transclusions, the updates happen almost immediately. If a template has more than 500 transclusions, the page updates are added to the job queue. Unfortunately, MediaWiki is often slow to process the job queue, normally taking days. Since updates are processed in a queue, edits to well-used templates will slow down updates for other less well-used templates. Ideas to improve this should be submitted to Bugzilla, as I'm sure the developers would love to hear about them. – PartTimeGnome (talk | contribs) 21:11, 31 December 2013 (UTC)[reply]
The statement that "For templates with less than 500 transclusions, the updates happen almost immediately" is inconsistent with experience. Over 24 hours ago (specifically at 20:48 UTC, 1 January 2014) I edited Template:Brian Grazer to remove a link to The Inside and replace it with a link to The Inside (TV series). That template has 88 transclusions, far fewer than 500. However, approximately 25 hours after making this edit, Special:WhatLinksHere/The Inside still shows about 80 incoming links, of which the vast majority are due solely to template transclusions. (The discrepancy in numbers is probably because a few of the 88 articles transcluding the template happen to have been edited within the intervening time for other reasons.) Incidentally, last month I did a similar template edit and watched the "what links here" count for the link I fixed for over 14 days, and there was no indication that the job queue had done anything at all in that time. --R'n'B (call me Russ) 21:52, 2 January 2014 (UTC)[reply]
Sorry, when I said "updates", I was simplifying slightly. By "update", I meant that the parser cache for those pages is invalidated, to be regenerated next time the page is viewed. (The parser cache stores the HTML sent to browsers when a page is viewed.) The updates to the link tables used by Special:WhatLinksHere happen separately. These updates always go through the job queue AFAIK, so might lag behind the pages themselves being re-rendered. Up to now this thread was only about what readers saw in articles, so I didn't mention the link table updates in my earlier post (it's confusing enough as it is!). – PartTimeGnome (talk | contribs) 22:56, 2 January 2014 (UTC)[reply]
Well, the parser-cache version of pages can still lag behind for at least 2 days, after changing a template with only 217 transclusions. -Wikid77 08:29, 6 January 2014 (UTC)[reply]

stats.grok.se

December 31 pageviews

The pageview tool seems to have either gotten interrupted or was subject to partial data. I need help figuring out which it was. From what I can tell there must be some process that runs through WP pages alphabetically. Somewhere between Tim Hardaway, Jr. and Tory Burch, the process did not run for December 31. Either the underlying data was not available for the end of the alphabet or they were not compiled. Can someone tell me whether the underlying data exist for the underlying data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:31, 2 January 2014 (UTC)[reply]

It's the Y2K+14 bug I've been trying to raise the alarm about! Now don't you wish you'd listened to me??? EEng (talk) 05:14, 2 January 2014 (UTC)[reply]
  • Estimate the missing 31-December data: Since the stats are complete for pages "A"-"TNZ", then until the database is fixed (during the next few days), perhaps treat the partial day's stats in "To"-"Zzz" as an estimate for 31 December as either the pageviews from 30 December, or 17 December (2 weeks prior), or the average: (30Dec + 17Dec)/2. After "To" there is some partial data, such as "Toy" from 472 to 3, or "Tow" 72 to 5, or "TS" 114 to 76. -Wikid77 13:03, 2 January 2014 (UTC)[reply]
It looks like it's just a problem with the stats.grok.se site:
alexz@tools-login:~$ zgrep -F "en ZZ_Top " pagecounts-20131231-080000.gz
en ZZ_Top 52 1578087
-- Mr.Z-man 15:29, 2 January 2014 (UTC)[reply]
Either you are showing me something that suggests ZZ Top got 1.578 million pageviews or 52 pageviews in the 8:00 hour on December 31 according to the underlying data. I will assume it got 52 pageviews that hour. So something is not compiling correctly starting at some point in the alphabet between Tim Hardaway, Jr. and Tory Burch. Starting at "TO" there is minimal data according to User:Wikid77. I'll be watching here for confirmation that the database has been corrected.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:18, 2 January 2014 (UTC)[reply]
Yes, it's 52. The second number is the total number of bytes sent (I'm not sure why that's included in the data). Mr.Z-man 02:48, 3 January 2014 (UTC)[reply]
Having not run since the 1 January, it seems it tried to run for yesterday and most are complete but I've found a few that are missing. Blethering Scot 19:11, 6 January 2014 (UTC)[reply]
I am fairly certain that January 5 results are only about 25% of the daily totals.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:17, 6 January 2014 (UTC)[reply]
It looks like the underlying data does not exist after 5 AM and extending well into the 6th. All dates are now caught up except for December 31 (TO-ZZZ).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:24, 10 January 2014 (UTC)[reply]

stats.grok.se support

The help page for stats.grok.se (which we link to from all sorts of places, for example DYK notificiations) directs people to User talk:Henrik, but that's littered with people pointing out that User:Henrik doesn't answer queries there. Should we be providing the equivalent service from a WMF server?

[FYI, The issue I wanted to raise is that, on, for example [1], it says "Magistrate of Brussels has been viewed 57 times in 201401.". But that doesn't include today's visits (the article was under DYK on the main page today). Better wording would be something like "As of 4 December 9013, Magistrate of Brussels has been viewed 57 times in 201401."] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 5 January 2014 (UTC)[reply]

I think a couple of years back there was talk about Wikimedia finding another service for stats. What happened to that idea, I wonder? Henrik will often fix things if you email him. But posting on that talk page goes nowhere fast. And there seems to be many breakdowns of the stats. — Maile (talk) 01:32, 6 January 2014 (UTC)[reply]
I think we need to consider rebuilding the tool with more capabilities.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 18:23, 6 January 2014 (UTC)[reply]
There is definitely a problem with it. For example this only records the stats of 5 January and not the days before or after it (including one when it was on the main page as a DYK). The C of E God Save the Queen! (talk) 20:33, 7 January 2014 (UTC)[reply]
How do we start the process of getting a replacement to the current tool?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:57, 9 January 2014 (UTC)[reply]

Page traffic counter is sick

The counter has been down for a quite a few days now. There's no information as to whether 2 Jan figures are going to melt into the ether, lost forever. And no indication of whether the system is up and running properly now.

Would it not be better for the WMF to take over this facility formally? It's a very important facility. Tony (talk) 02:54, 10 January 2014 (UTC)[reply]

There is no data for the 6 Jan as it skips from 5 to 7. Then again there is nothing for 8 either.Lihaas (talk) 04:25, 10 January 2014 (UTC)[reply]

All of a sudden, January 1–3 & 7 ran. December 31 (TO–ZZZ) and January 6, 8 & 9 remain a mystery and January 5 only seems to be about 25% of the data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:38, 10 January 2014 (UTC)[reply]
There is definitely something wrong with it, I do agree that WMF probably should take over it so we can potentially minimize the disruption. for example, in this article, the 6th of Jan doesn't exist! The C of E God Save the Queen! (talk) 10:37, 10 January 2014 (UTC)[reply]

The raw data used to compute these things is generated by the WMF. This is what Henrik uses, what I use for WP:5000, and virtually all other statistical page view functionalities of which I am aware. I will note that something broke spanning Jan. 5 and Jan. 6 2014 (UTC). Otherwise, it has been quite stable for some time. West.andrew.g (talk) 16:03, 10 January 2014 (UTC)[reply]

West.andrew.g, thanks for the explanation about Jan 5/6. Can you tell me why December 31 was left incomplete for the TO–ZZZ portion of the alphabet. Also, what do you know about the dates listed at User:Killiondude/stats#Are_there_known_dates_for_which_complete_sets_have_not_been_compiled_although_the_data_seems_to_be_available?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)[reply]
All went through as planned with my processing script on Dec. 31, so there does not seem to be a fundamental problem. I cannot comment on what might have happened with Henrik's script . Henrik's tool is known the be imperfect in some ways. I can't account for all those dates listed (my storage began sometime in 2010), but it did used to be a far more buggy process than it is now. West.andrew.g (talk) 18:28, 10 January 2014 (UTC)[reply]
I guess my question is whether the numbers posted on Henriks page are final or whether they can ever be compiled to include December 31st for the end of the alphabet?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:56, 10 January 2014 (UTC)[reply]

Page-views

Hi there. I don't know if I am posting this in the right place, but I am sure that someone here you'll be able to send it to the right place. Is anyone here aware of these problems? The page-views Stats Grok is out order since early 2014. This is an important data information and I still don't get why WMF simply don't put it running in order and, so, we are still depending on unstable server and scripts. Regards, 177.148.179.211 (talk) 23:42, 9 January 2014 (UTC)[reply]

As I understand it, that's a private website run by a private individual. WhatamIdoing (talk) 01:16, 10 January 2014 (UTC)[reply]
So, thats another question. Its a important and very desirable information. Why we still depend on "private website run by a private individual" to get it? Come on, WMF guys, bring us the Page-views data back! 177.148.179.211 (talk) 03:55, 10 January 2014 (UTC)[reply]
Hi. See #stats.grok.se. Many things are provided by volunteers (bug fixes, tool/scripts used for editors, etc.). I actually prefer things that are run by (active) volunteers vs. the WMF getting involved. It's lamentable that Henrik's tool is erratic lately, however. Killiondude (talk) 22:35, 10 January 2014 (UTC)[reply]

Potential replacement

de:User:Hedonil has developed a tool on Labs that may be able to serve as a replacement. It doesn't currently have much historical data (only going back to September 2013), but it should hopefully be more reliable as it's run by a more active user. http://tools.wmflabs.org/wikiviewstats/?page=Example&lang=en&project=wikipedia Mr.Z-man 16:27, 10 January 2014 (UTC)[reply]

Thanks @Mr.Z-man:. Looks like a nice tool, however a comparison of a few pages stats show the newer tool comes out with a higher figure. Not sure whether thats because Henrik's tool discounts something or there is something else causing that, only checked out on two pages but with a variety of dates.Blethering Scot 16:47, 10 January 2014 (UTC)[reply]
Im wondering if it's redirects or something like that causing higher number of stats. Also what was interesting was if you run American Psycho (musical) on that tool it displays every days stats but adds a note that stats.grok.se was missing at least one day and page stats are lower by 1075. Thats useful buts different to the normally higher figures as doesn't display on all pages when data isn't missing on the other site. States uses dumps-wikimedia.org to get data but appears to check stats.grok.se to see if its missing data, can only assume tool was created for the basis of problems were having.Blethering Scot 17:26, 10 January 2014 (UTC)[reply]
The new tool is more powerful. You can click on a day and see the hourly totals. You can also see the current day partial totals. Can this tool be set to run over the historical datafiles to backfill its data?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:56, 10 January 2014 (UTC)[reply]
Its far better i agree, but whats accounting for the higher day to day figures. Also i cant link to a specific page's stats i.e. Kinky Boots (musical) it gives you a ? in domain name not the title of the search.Blethering Scot 18:51, 10 January 2014 (UTC)[reply]
Yes an explanation for the higher totals would be appreciated.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:57, 10 January 2014 (UTC)[reply]
He has explained in detail to another user on his talk page. Seems stats.grok.se is on average 10% lower.Blethering Scot 23:13, 10 January 2014 (UTC)[reply]
Victoria's Secret Fashion Show is one where stats.grok.se is 50% higher.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 23:28, 10 January 2014 (UTC)[reply]
Seems against the norm but all you can do is ask him. Seems pretty responsive.Blethering Scot 23:33, 10 January 2014 (UTC)[reply]

Searching in contributions

How to search quickly in my contributions - only actions where i renamed pages? Is possible to obtain this result via query, or tag filter or something else? Thanks. XXN (talk) 11:57, 2 January 2014 (UTC)[reply]

Special:Log/move/XXN should do it. Legoktm (talk) 12:07, 2 January 2014 (UTC)[reply]
You can also get to the same page by looking at the top of your Contributions page. You will see a link to "Logs" and then pick "Move log" from the first drop down box. GB fan 12:10, 2 January 2014 (UTC)[reply]
Thank you guys.

Other challenge: someone, sometimes uses AWB; and his edits has summary edit description ”using AWB”. It's possible somehow to show only those contributions throught many other - to view not all contributions, but only those done with AWB? :) XXN (talk) 13:35, 2 January 2014 (UTC)[reply]

Here is a link that does that for your edits, http://tools.wmflabs.org/sigma/summary.py?name=XXN&search=AWB&server=enwiki&max=500&ns= GB fan 14:00, 2 January 2014 (UTC)[reply]
For rowiki not working http://tools.wmflabs.org/sigma/summary.py?name=XXN&search=AWB&max=500&server=rowiki&ns= :)) XXN (talk) 21:04, 4 January 2014 (UTC)[reply]

"Disclaimers" not showing in mobile view

The tiny little link to our disclaimers that appears among a cluster of tiny little links at the bottom of articles in "desktop view" doesn't appear in "mobile view" - at least when I use Dolphin browser on my Samsung Note (Android/Ice Cream Sandwich). Not sure who to tell. --Anthonyhcole (talk · contribs · email) 13:13, 2 January 2014 (UTC)[reply]

Didn't appear on my Blackberry's default browser either, although IIRC it never appeared on the bottom section of articles on mobile view either. hmssolent\You rang? ship's log 15:43, 2 January 2014 (UTC)[reply]
You could file a bug under the mobile extension, or maybe someone from the WMF (ping Ironholds) can comment. πr2 (t • c) 15:58, 2 January 2014 (UTC)[reply]
I'll go see if any of the mobile devs are in the office and file a bug either way. Ironholds (talk) 18:09, 2 January 2014 (UTC)[reply]
Answer is "it's in the sidebar menu" (accessed by hitting the button in the top left that looks like a set of horizontal lines). Does that work? Ironholds (talk) 18:14, 2 January 2014 (UTC)[reply]
Thanks. Can you possibly arrange to have the disclaimer link appear on the same page as the articles? --Anthonyhcole (talk · contribs · email) 15:34, 4 January 2014 (UTC)[reply]
Same page? Both tabs can be visible simultaneously (at least on my device). Ironholds (talk) 19:59, 4 January 2014 (UTC)[reply]
Sorry, I didn't understand your response. I'm wondering if you can arrange things so that when a reader opens an article in mobile view the disclaimer link appears on the same page as the article text. --Anthonyhcole (talk · contribs · email) 11:27, 6 January 2014 (UTC)[reply]
User:Anthonyhcole: Well, I can't, but it seems like a reasonable request; wanna throw in a Bugzilla entry about it? Ironholds (talk) 21:57, 6 January 2014 (UTC)[reply]
I don't know how to do that. I went to the page linked above, and I'm still no wiser. Could you pass it on for me please, Ironholds? --Anthonyhcole (talk · contribs · email) 22:22, 6 January 2014 (UTC)[reply]

done. Ironholds (talk) 23:42, 6 January 2014 (UTC)[reply]

Merci beaucoup. --Anthonyhcole (talk · contribs · email) 04:36, 7 January 2014 (UTC)[reply]
Actually, the problem with the current arrangement is readers don't see the link to "disclaimer" when reading the article, because (at least on my device and I think some others above) its hidden behind a link consisting of 3 horizontal bars in the top left of the screen. Most readers will never click that link, so most won't even see the "disclaimers" link. It needs to be added to the little cluster of links at the bottom of the article, among

Wikipedia ® Mobile | Desktop
Content is available under CC BY-SA 3.0 unless otherwise noted.
Terms of use | Privacy

I'd add that as a comment to your request but I haven't received my account confirmation email yet. Would you mind making that clarification please, Ironholds? --Anthonyhcole (talk · contribs · email) 05:57, 7 January 2014 (UTC)[reply]

Common.css

Hello! I've added a code #p-lang div.pBody ul li { font-family: sans-serif; } to my common.css (I dislike previous appearance of font of interwiki) and I've been reported that «Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.» What does it mean? I think, this code is absolutely normal. In Russian Wikipedia it works without problems. Thanks. --VAP+VYK (talk) 17:05, 2 January 2014 (UTC)[reply]

It's a standard message that is shown at the top of all User .css and .js pages, regardless of what's actually on the page. It even shows for empty pages. Your CSS contains absolutely nothing that might be compromising your account. --Redrose64 (talk) 17:14, 2 January 2014 (UTC)[reply]
Thank you very much for answer, you've set my mind at rest. :) --VAP+VYK (talk) 17:32, 2 January 2014 (UTC)[reply]
You could also try Preferences → Beta features → Typography refresh. I quite like the new look. --  Gadget850 talk 17:44, 2 January 2014 (UTC)[reply]

Script for interactive chess board

Hello,

At Wikipedia_talk:WikiProject_Chess#Interactive_chess_board, I had suggested that we try and develop an interactive chessboard for usage on EnWiki, similar to how the Hebrew wiki articles have.

קיפודנחש (kipod), who had worked on the board on the Hebrew wiki, replied and has suggested a possible way to do this. But we would like more thoughts on how other editors think this should behave and whether it will be a good idea to have it as the default in mainspace in the future. (I think that is a very strong yes given how so many chess articles are dependant on the positions displayed in static diagrams instead of a board like this which would have take our articles' quality up a huge notch)

So what do other editors think of this and are there any changes we can do to make it better?

Regards, TheOriginalSoni (talk) 02:11, 3 January 2014 (UTC)[reply]

Sounds good. Will make chess-related articles more interactive and will be more hands-on informative. ///EuroCarGT 05:22, 3 January 2014 (UTC)[reply]
I'm saying the same thing as last time. Fine, but please just make it degrade nicely for people WITHOUT Javascript. And preferably in a way that doesn't make it look like a datadump. You could have a template include a reference to a page with pgn data and using Lua output a human readable 'simple' description of the game. Then the pgn viewer could detect this template with the hidden reference to the data page and load the pgn data for playback, partially or fully replacing the description. BTW. when it comes to these full games being included.. I find them as useless as episode listings without commentary. There should be a paragraph of text explaining the key moment of a game, the significance etc. Because Wikipedia is not a sport results site. So what i'm saying is, if I turn off Javascript on he:אליפות_העולם_בשחמט_2013 and it looks somewhat remotely like World_Chess_Championship_2013 instead of User:קיפודנחש/pgnviewer_demo, then it's a good solution. —TheDJ (talk • contribs) 10:10, 3 January 2014 (UTC)[reply]
this way of thinking is understood, but it shows some misunderstanding of the way chess games are regularly communicated: you say "human readable", but the whole point of pgn is that is *is* human readable. for example, please look at Pirc Defence#Sample games. (this is by no means unique - many chess articles contain similar sections). the idea here is that for people with no JS, the section(s) will continue to look more or less like this, and people with JS will see something like what you can see in User:קיפודנחש/pgnviewer demo when you activate the script User:קיפודנחש/pgnviewer.js. peace - קיפודנחש (aka kipod) (talk) 15:17, 3 January 2014 (UTC)[reply]
TheDJ, TheOriginalSoni: i do not think the right way to do it is to try and train some Artifical Intelligence to decide which position is the best one to show from each game. I think that this should be left to the editor. it is possible to create a template that will consume the PGN of the games, and some more stuff, and will display the "more stuff" to users without JS. this can be done by utilizing a mediawiki feature which is currently not used on enwiki: Mediawiki:Noscript.css. what one needs to do here is to create several new CSS classes: one which will have "display:none" in common.css and then "display:inherit" (and maybe another which will have "display:block" and a third which will have "display:inline") in noscript.css, and then another class that will have "display:none" in noscript.css. this way, template authors will be able to define parts of the tempalte which are visible to people without JS
this may come in handy in other places: for instance, we use collapsible elements (i.e., elements with "show/hide" buttons) all over the place. these elements rely on JS to do their thing, and for user with no JS they are always in a "show" state. i can imagine some special cases, in which it would be better to completely hide an element in case the collapsing mechanism does not work.
i can not do all this things in the script or in a template - it requires edit rights in the mediawiki namespace, IOW, "editinterface" permissions. in enwiki, only sysops/admins have this permission (some other wikis created a usergroup that have the "editinterface" permission without being sysop/administrator). someone with these permissions needs to create the classes, and then we can look at creating a template that will support JS-less viewers more gracefully.
peace - קיפודנחש (aka kipod) (talk) 15:38, 4 January 2014 (UTC)[reply]
TheOriginalSoni: yes, though i can't guarantee to do this expeditiously - my wiki-budget is somewhat limited. also, if testwiki supports more restricted rights than "admin/sysop", which still contain "editinterface", this would suffice (some projects *do* have "editinterface" user group. i don't think enwiki is one of them. such a group makes a lot of sense for testwiki to have). peace - קיפודנחש (aka kipod) (talk) 14:50, 9 January 2014 (UTC)[reply]

Are we not talking about a playable board? I think that having a fully playable game integrated into the article would be an enormous bonus. bd2412 T 20:48, 3 January 2014 (UTC)[reply]

BD2412: you can see for yourself exactly what we are talking about: you need to add to Special:Mypage/common.js the following line:
importScript('User:קיפודנחש/pgnviewer.js');
and then, look at User:קיפודנחש/pgnviewer demo. peace - קיפודנחש (aka kipod) (talk) 15:38, 4 January 2014 (UTC)[reply]
I have seen the simulation on Hebrew Wikipedia. I'm talking about the ability to play an actual game of chess. bd2412 T 20:41, 4 January 2014 (UTC)[reply]
if you are talking about the reader playing a game of chess against the website/computer, i doubt this can be achieved through wikipedia infrastructure. even if it _was_ possible, i don't believe this is "encyclopedic content", so i do not think it's something appropriate for wikipedia - see WP:NOTGAMEHOST. peace - קיפודנחש (aka kipod) (talk) 21:15, 4 January 2014 (UTC)[reply]
(edit conflict) In which case, it's simple: we do not host games, chess or otherwise. --Redrose64 (talk) 21:16, 4 January 2014 (UTC)[reply]

Pronouns

At Special:Preferences, under "Internationalisation" we're given the option of being identified as "he", "she", or neither. Many people however, including genderqueer and intersex people, prefer to be referred to using the singular they. Can this be fixed? – Arms & Hearts (talk) 06:22, 3 January 2014 (UTC)[reply]

We could, but it wouldn't make much difference right now, as the translations system only knows about male, female and generic. You'd have to fix all the translation systems for it to take any effect. But such a request would go into bugzilla with the translate/language team as a feature request. —TheDJ (talk • contribs) 09:41, 3 January 2014 (UTC)[reply]
For the records, some related discussion has taken place in bugzilla:53834. --AKlapper (WMF) (talk) 10:34, 3 January 2014 (UTC)[reply]
As far as I know, MediaWiki doesn't use it to say he or she anywhere, but in some foreign languages it's used for a gender-specific variant of the word "user". Wikipedia editors can choose to say "they" if the gender is not specified. {{They}} does exactly that. Are there English words which vary between not knowing anything about a person and knowing the person doesn't want to be described as either male or female? PrimeHunter (talk) 12:58, 3 January 2014 (UTC)[reply]
@PrimeHunter: It's used for more than that; for example, in Polish, in a sentence like "PrimeHunter said something", "said" would be a different word depending on your grammatical gender ("powiedział" for male, "powiedziała" for female). It's pretty much not used in English localization of MediaWiki, but it could be (in, say, Echo's notifications like "PrimeHunter mentioned you on his/her talk page" – this is currently not done). Matma Rex talk 13:30, 3 January 2014 (UTC)[reply]
  • I'm still wondering why the system changed from asking if a user was male, female, or unspecified. This asking if they want to be referred to as he or she implies that the system has some kind of AI that will automatically change any reference to any user to what they preferred to be called, and this is simply not the case. Technical 13 (talk) 13:38, 3 January 2014 (UTC)[reply]
    There was some long boring discussion somewhere about some people with complicated sexuality apparently being offended or something. And changing this *does* consistently change the entire interface in languages where this distinction matters more than in English, even the "User" namespace name is changes (like PrimeHunter mentioned), so this also makes it easy for other people to refer to one with correct grammatical gender. Matma Rex talk 13:42, 3 January 2014 (UTC)[reply]

In case one wishes to manually addr4ess another user as that user prefers, is there a way on en.wikipedia to see that user's prefernce choice on this item? DES (talk) 16:12, 6 January 2014 (UTC)[reply]

I use User:PleaseStand/userinfo. This script adds userrights and the date of the last edit, which is very helpful if you're trying to find someone who's actually active.
There are more direct methods (that presumably work on all wikis, not just en.wp), but I don't know how to use them. Perhaps someone else could post them? WhatamIdoing (talk) 18:51, 6 January 2014 (UTC)[reply]
There are templates too:
and just in case you're wondering, {{he or she|Redrose64}} → he or she; {{his or her|Redrose64}} → his or her (I'm not saying). --Redrose64 (talk) 20:03, 6 January 2014 (UTC)[reply]
The magic word GENDER works on all wikis. It is described at mw:Help:Magic words#Localisation and translatewiki:Gender. All the gender-dependent templates use GENDER. If you just want to see the gender then you can also use the API like this (there may be a shorter way): https://en.wikipedia.org/w/api.php?action=query&list=users&usprop=gender&ususers=WhatamIdoing. PrimeHunter (talk) 21:02, 6 January 2014 (UTC)[reply]

This all seems a bit ridiculous and political to me. The logic in the claim that "He edits wiki pages" is the top choice which implies the default gender can also be applied to the new format that "They edit their wiki sandbox (They/Their)" then "they" becomes the implied default gender. I don't really understand all this, but how often have you addressed someone else using a gendered pronoun rather than using the standard wikicoded {{reply to}} template or the [[User:...]] syntax? Why don't we just take the easiest route and have everyone declare their gender on their userpage instead? TeleComNasSprVen (talk • contribs) 20:18, 6 January 2014 (UTC)[reply]

In fact, now that we have the {{#babel...}} extension syntax and categories in place, we can just ask people to put {{#gender:...}} onto their userpage, put them into the relevant categories like the babel templates do, and ask people to address them this way. We could have all kinds of ways of addressing then, based on their inclusion in [[:Category:User male]], [[:Category:User female]], [[:Category:User intersex]], [[:Category:User bisexual]] etc, etc TeleComNasSprVen (talk • contribs) 20:29, 6 January 2014 (UTC)[reply]
I rarely address people by genderd terms, but i frequently would refer to them by such terms. "I agree with User:Example when he says that we ought to..." or "I think User:Sample is making a big mistake when she asserts that..." If I don't know the gender I will usually use "s/he" on talk pages (not in articles) -- I strongly dislike singular they. DES (talk) 21:58, 6 January 2014 (UTC)[reply]
Your proposal makes the data less structured, making it harder for software to choose the correct language. Though MediaWiki doesn't make much use of the preference in English, it is very important for other languages where terms such as "user" have masculine and feminine forms. Your proposal could work in addition to the preference to supply extra information for humans, though.
The example categories you gave aren't much use for making language decisions, though – if someone is in Category:User bisexual, I am none the wiser as to whether I should use "he", "she", "it", "they", etc. Better examples would be Category:User refer to as masculine (he/him/his), Category:User refer to as feminine (she/her/hers), Category:User refer to as neutral singular (it/its) and Category:User refer to as plural (they/them/their).
Personally I would find it too much effort to check a user page just to pick a pronoun. It's so much easier just to use {{subst:gender:UserName|his|her|their}} or similar. – PartTimeGnome (talk | contribs) 00:43, 7 January 2014 (UTC)[reply]
@DESiegel: Well, if you dislike singular they, you can still refer to everyone else who doesn't fit into the gender binary (genderqueer/intersex/neutral/unspecified) as "s/he", I suppose, so that doesn't add much as to why we need to include this feature at all. The alternative to that is using "it", and so far, I've never met anyone who wanted to be addressed/referred to as "it".
@PartTimeGnome: You have a good point, but I don't understand why using a magic word like {{#gender...}} would make data less structured, you'll have to explain that a little more in depth with me. Your second point, that in other languages the MediaWiki software uses this to create different inflections for the word "user", leads me to ask, what pronouns if any can other languages use to address/refer to people outside of the gender binary? And if so, what would be the inflection for the word "user"? In English this seems a pretty trivial matter to agonize over if someone or some software got your gender wrong when referring to you.
I think the root of the problem is more to do with the fact that the English language (and most other languages) have no pronouns at all to refer to genderqueer/intersex or genderless people (singular they is simply a pronoun to be used broadly, I use this when referring to anybody, gendered or not, and I don't really like having to use a template to refer to someone). TeleComNasSprVen (talk • contribs) 01:32, 7 January 2014 (UTC)[reply]
Yes, you've got that exactly right. Some of the agonising over this preference is because people see it as a statement of their identity, and dislike being constrained to the "standard choices" imposed by our language.
It isn't the use of a magic word that makes the data less structured, but the notion that users would not be restrained in the what they could set using the magic word. The software needs some way to translate whatever the user placed in the page to language for referring to that user. If the idea is to allow users a way to express their wishes in more detail just for humans (i.e. still keep a separate preference for the software to use), we already have a large range of userboxes. I'm not sure there's any point categorising – I don't think there's a good use for a list of Wikipedians that prefer to be referred to in a certain way.
You ask a good question about what options other languages have. Some cultures have the concept of a third gender (or more), though this does not seem so common in languages. Sanskrit does have a third gender. I don't know how MediaWiki handles such languages (does it?).
If your concern about using a template is how others might perceive this, use subst:. By substituting the template, just the word "he", "she", etc. is saved in the wiki source, so no one will see that you used a template to discover the word to use. If your concern is usability, I agree it isn't great – it would be good if the software disclosed this preference in a less technical manner. (I could say the same about the {{#gender...}} idea. A preference setting is a lot less technical than adding a parser function to a user page.) – PartTimeGnome (talk | contribs) 02:37, 7 January 2014 (UTC)[reply]

Wikiproject cleanup and popularity statistics

Some wikiprojects have this available:

  • Cleanup listing, documenting by type all tagged pages under a projects' purview (eg [3])
  • Popularity listing, listing the top 500 pages by viewcount (eg Wikipedia:MED1500 from [4]).

I'd like to enable this for WP:ANATOMY, as it would prove invaluable in determining which articles receive attention. However I haven't been able to contact the developers of either of the tools, or have tried and not had a response, and am beginning to worry that "Available in November" is not referring to November, 2013. I am wondering: (1) if there are alternate tools that we could use, or (2) if there are any users with privileges that could add our project to the listings above. This would prove invaluable to the project, and we'd be very grateful if it could be enabled. --LT910001 (talk) 00:11, 4 January 2014 (UTC)[reply]

Hi, I'm the author of the popularity stats tool. I was hoping to have it ready by November, but problems with the move from the Toolserver to WMF Labs combined with a total rewrite of the program itself have slowed things down a bit. Assuming nothing goes horribly wrong in the next couple of weeks, it should be ready for new projects by the end of this month. Feel free to leave me a message on my talk page sometime in the last week of January. Mr.Z-man 04:13, 4 January 2014 (UTC)[reply]

：：Great! Thanks a lot for creating the tool, Mr.Z-man I'll contact you later this month. Do you know how we might get the cleanup listings? I'm particularly interested in finding a list of all proposed merges under our scope. --LT910001 (talk) 00:15, 5 January 2014 (UTC)[reply]

See User:Svick/WikiProject cleanup listing. WhatamIdoing (talk) 18:54, 6 January 2014 (UTC)[reply]

How do I get OpenDyslexic working?

I just read User talk:Jimbo Wales/Archive 153#More WMF Bright Line violations. I'm not very technical. Am I right in thinking I can get that font working on the Wikipedia pages I read? --Anthonyhcole (talk · contribs · email) 15:32, 4 January 2014 (UTC)[reply]

You can, although it's not in a very obvious place. Click the cogwheel next to "Languages" in the sidebar, choose "Fonts" and then select OpenDyslexic from the list. the wub "?!" 15:37, 4 January 2014 (UTC)[reply]
Cool. Thanks the wub. Wow. It's like someone turned the light on. Thanks Lawrence. --Anthonyhcole (talk · contribs · email) 17:19, 4 January 2014 (UTC)[reply]
You know, if that information isn't already there, then maybe we should add it to WP:ACCESS and WP:WikiProject Dyslexia's pages. WhatamIdoing (talk) 18:56, 6 January 2014 (UTC)[reply]
Maybe Andy Mabbett, who seems knowledgeable and committed regarding accessibility issues, has some thoughts on how best to present this option to readers with reading difficulties. --Anthonyhcole (talk · contribs · email) 22:28, 6 January 2014 (UTC)[reply]

PrettyLog.js issue

MediaWiki:Gadget-PrettyLog.js doesn't work on Special:Log for me. Can someone fix it? --Rezonansowy (talk • contribs) 19:26, 4 January 2014 (UTC)[reply]

What do you mean with "doesn't work" ? You mean you don't get the same styling that you see as you don on Commons ? That seems logical, because search results on en.wp don't have the same styling either. Did this gadget ever work ? —TheDJ (talk • contribs) 13:25, 5 January 2014 (UTC)[reply]
OK, could add these styles to this script? --Rezonansowy (talk • contribs) 11:30, 6 January 2014 (UTC)[reply]
 Done —TheDJ (talk • contribs) 16:41, 6 January 2014 (UTC)[reply]
Thank you --Rezonansowy (talk • contribs) 23:14, 6 January 2014 (UTC)[reply]

Failed section redirect

I added the link Factors influencing size to Talk:Sea cave and when ever I open that link in a new tab, it takes me to the section Sea cave#Factors influencing size but when ever I click the link directly, it instead takes me to the beginning of the whole article. Blackbombchu (talk) 01:09, 5 January 2014 (UTC)[reply]

That problem is not happening anymore. It only happened immediately after I created that section on the talk page. That problem isn't happening in this section of Village pump either. Blackbombchu (talk) 01:12, 5 January 2014 (UTC)[reply]

"New messages" from 2011

I just happened to view a page while logged out, and when I did this, I saw the trusty old Orange Bar of Doom telling me I had new messages. However, as you can see, the last edit to my IP's talk page was in June 2011. I find it difficult to believe that no-one who has been assigned that IP since then had bothered to click the "new messages" link... but there you go.

More to the point, I was under the impression that the Orange Bar of Doom "expired" after a given period of time (say, a couple of weeks), since talk page messages for IPs generally become irrelevant after a while. Clearly this is not the case. I wonder if we should get such an expiry implemented...? — This, that and the other (talk) 10:23, 5 January 2014 (UTC)[reply]

Sounds like a sensible idea to me. I'm not sure whether the OBOD had an expiry set in the past, but if it did, then I suppose it's possible that the behaviour may have been changed when notifications were introduced. In either case, this should probably go in Bugzilla so that the right people are notified and can work out what actually happens in the code. — Mr. Stradivarius ♪ talk ♪ 08:34, 6 January 2014 (UTC)[reply]
As one who has taken some fairly long wiki-breaks in the past, I can tell you that the old orange bar still signaled for new messages for logged-in users when the newest msg was more than a year old. I don't think it included any expiry. I don't see why it should have included one only for IP users, but I've never really tested that. Many msgs are time-sensitive and make now sense months later, but some do. I'm not sure an expiration is actually a good idea. DES (talk) 14:28, 7 January 2014 (UTC)[reply]
However, the wording might be changed away from "You have new messages" if they are actually quite old. Many IP's have complained at the help desk that they got a warning about edits they didn't make. Some are worried that their computer or Internet connection was hacked, but mostly they just blame Wikipedia. After seeing the prominent OBOD they apparently don't notice the usually old date of the signed message, or MediaWiki:Anontalkpagetext which is displayed at the bottom of IP talk pages. Would it be possible to pass the age or time of the latest message so a wiki can adapt the text in MediaWiki:Youhavenewmessages and other system messages? PrimeHunter (talk) 15:26, 7 January 2014 (UTC)[reply]
Not just the help desk: sometimes they send complaints to the person who left the original message. I'm sure that I've seen these complaints over a long period, certainly from before the introduction of Notifications, and investigating, I find that they concern messages left more than two years earlier. this edit pre-dates Notifications, and if I log in as Redrose64a (talk · contribs), I used to get the full OBOD but now I get the orange-background "you have new messages" talk page link. User:Redrose64a has never visited User talk:Redrose64a, so that I can see how long the orange bar persists; it's over 14 months so far. --Redrose64 (talk) 15:52, 7 January 2014 (UTC)[reply]

Problem when using Chrome

When using Firefox, I see the tabs at the head of the article in two groups: the Article and Talk tabs on the left and Read, Edit, New section and View history on the right. The tabs I see using Chrome are different (Read, Edit, View history, star, down-arrow, and TW+down-arrow), but used to be positioned similarly. For the past week or so, the second groups of tabs is positioned below the first group and overlapping the article title, with the Read tab partially underneath the Talk tab. Besides the weird appearance, this interferes with click-drag selection of the article title. I'm using Chrome version 31.0.1650.63 m. Does anyone know if this is an resolvable by changing some Chrome setting, or perhaps a CSS issue, or what? 203.177.166.122 (talk) 10:48, 5 January 2014 (UTC)[reply]

The problem is only superficially your browser. The problem is that you are logged out when using firefox, but logged into an account when using chrome. That is the only way the last three tabs would even show up. So something is probably wonky with your .js or .css or gadgets on your account. If you edit from your account again so we can see those pages, we may be able to tell you more. Someguy1221 (talk) 10:58, 5 January 2014 (UTC)[reply]
If the row of buttons is overlapping the title, then that means that your browser window is not wide enough to fit them on the other line. —TheDJ (talk • contribs) 12:46, 5 January 2014 (UTC)[reply]
Thanks. I just realized about the logged in vs. not situation myself, checked that, and saw that logging in with firefox resolved the tab differences. The placement differences remain, though. I'm making this edit while logged in, and I'd appreciate anything you can tell me to help. I'm not a css or js jock and haven't looked at my userpage css or js files in quite a while. If it's a problem there, though, I can probably figure it out myself by the process of elimination -- I'll give that a try tomorrow if I don't see anything further here. Thanks again & Cheers, Wtmitchell (talk) (earlier Boracay Bill) 12:52, 5 January 2014 (UTC)[reply]
I have blanked my vector.js and vector.css pages, logged out, shut down and restarted chrome, and logged back in. I'm still seeing weirdness, as follows:
  • Right now I am viewing this page in tab 1 of a chrome window, editing this section in tab 2, and viewing (not editing) User:Wtmitchell/vector.css (which is currently empty) in tab 3.
  • Chrome tab 1 displays WPtabs in expected positions, but sometimes will misposition them briefly (sometimes multiple times) during a page reload.
  • Chrome tab 2 has the WPtabs mispositioned. Reloading the page does not fix this.
  • Chrome tab 3 has the WPtabs mispositioned. Reloading the page does not fix this.
  • Clearing the chrome's cache using chrome's settings->tools->clear browsing data->empty the cache and then reloading pages with mispositioned WPtabs doesn't get the WPtabs back to their expected positions.
I'm not sure where to go from here in troubleshooting this. Wtmitchell (talk) (earlier Boracay Bill) 19:47, 5 January 2014 (UTC)[reply]
Please provide a screenshot; it's easier to see what's wrong. ALso, do you by any chance have the Allow toggling between menus and tabs gadget enabled? — Edokter (talk) — 11:36, 6 January 2014 (UTC)[reply]
See image here. Apologies if my description above was unclear.

I don't think I have Allow toggling between menus and tabs enabled, but I don't see that on my Preferences page. Where would I check that? Wtmitchell (talk) (earlier Boracay Bill) 01:26, 7 January 2014 (UTC)[reply]
The option is called "Enable toggling between tabs and dropdown menus in the Vector skin". You can find it under Preferences → Gadgets → Appearance. – PartTimeGnome (talk | contribs) 02:46, 7 January 2014 (UTC)[reply]
I checked that, and it is not enabled. Making this edit, I see that the tabs are still mispositioned when I'm editing this article but not when I'm viewing. I see that they are mispositioned when I'm editing some other articles but not all of them. They seem to be not mispositioned when I edit articles I haven't previously edited, or perhaps not edited in a very long time. I'm wondering whether this might be somehow related to caching somewhere between me (on Boracay island in the Philippines) and WP (in Florida, as I remember). I haven't tried editing using Chrome and logged in from a different machine here -- I'll try it give that a whirl tomorrow and will report my results here after doing that. Wtmitchell (talk) (earlier Boracay Bill) 12:20, 7 January 2014 (UTC)[reply]
There is too little space in the screenshot. WHat is noticable, is the large search box. Check your preferences again to see if Widen the search box in the Vector skin under Gadgets is enabled. — Edokter (talk) — 12:46, 7 January 2014 (UTC)[reply]
I checked, and found "Enable simplified search bar (Vector skin only)" was enabled. I disabled that, and found on trying to edit this section that the tabs were not mispositioned. I re-enabled it and found on trying to edit this section that the tabs were still not not mispositioned. I had neglected to check before fiddling with that, so I don't know whether tabs were still mispositioned when editing this section before I fiddled with that vector preferences option. I restored the vector.css and .js files I had blanked and the tabs were still not mispositioned. It seems to be OK now. Thanks for your help. Wtmitchell (talk) (earlier Boracay Bill) 15:43, 7 January 2014 (UTC).[reply]

Infobox problems

Hi all, thanks in advance, I am trying to post multiple images (including one map) to the infobox on this article Pittsburgh metropolitan area. Yet only one image is showing. Can someone provide me the correct code for this I've already compared it to code in such articles as Atlanta metro area and all seems correct to my untrained eye. Market St.⧏ ⧐ Diamond Way 11:28, 5 January 2014 (UTC)[reply]

In the case of the skyline, you included "File:" where it was not needed, and in the case of image_map1, you added a line for it without removing the one that was already there, which defined it as null. Someguy1221 (talk) 11:35, 5 January 2014 (UTC)[reply]
Many thanks, and thank you even more for going ahead and fixing the code! Market St.⧏ ⧐ Diamond Way 12:08, 5 January 2014 (UTC)[reply]

If I try to look at the Commons page for an image used on English WP, I am sent to a non-existent page called "File:File:(whatever).JPG". I think this link needs to be sorted out. LynwoodF (talk) 12:49, 5 January 2014 (UTC)[reply]

Incidentally, I am solving the problem in the short term by copying and pasting the file name with just one "File:". LynwoodF (talk) 12:56, 5 January 2014 (UTC)[reply]
That is a bug in the MultimediaViewer beta. There is a notice about it on the feedback page of the MultimediaViewer beta. —TheDJ (talk • contribs) 13:40, 5 January 2014 (UTC)[reply]
Thanks. I see someone is working on it. LynwoodF (talk) 14:31, 5 January 2014 (UTC)[reply]

Minor problem with Template:Infobox international hockey competition

If the "winners" parameter is not defined, it causes a line break between "Second place" and the silver medal image (if the "second" parameter is defined), as well as a line break between "Third place" and the bronze medal image (if the "third" parameter is defined). If the "fourth" parameter is defined, there will be a line break between "Fourth" and "place". An example can be seen in this article revision (see the infobox to the right). I've been able to reproduce this problem in the latest versions of Safari and Chrome on the latest version of Mac OS X, but the latest version of Firefox does not have this problem. What causes this? Heymid (contribs) 16:59, 5 January 2014 (UTC)[reply]

Page moves in own userspace for users with non-Latin user names

Apparently the MediaWiki:Titleblacklist prevents pages from being moved to mixed-script names. Is there any way to override this for page moves in one's own userspace? This is a constant nuisance for me. (If I create a subpage with an English name (say, a draft) in my own userspace, and I don't like the name I first chose, I can't move it because of this restriction, as my Hebrew username and the Latin target subpage name form a mixed-script title; instead, I have to copy-paste and request a {{db-userreq}} for the original page.)

Thanks, הסרפד (call me Hasirpad) 19:21, 5 January 2014 (UTC)[reply]

@הסרפד: One workaround could be to create the draft in the new Draft namespace, where your username would not be part of the title. GoingBatty (talk) 19:45, 5 January 2014 (UTC)[reply]
@GoingBatty: True, but this only applies to the example I gave (there may be other reasons for wanting to move a page in one's userspace) and, in any case, I prefer to have my drafts in my userspace. הסרפד (call me Hasirpad) 19:58, 5 January 2014 (UTC)[reply]
I don't think you're hitting the mixed script rules; instead, it appears you are hitting a rule that is intended to block letter-lookalikes in article titles (apparently "פ" is considered a lookalike). I've added a whitelist entry for your userspace. Anomie⚔ 20:34, 5 January 2014 (UTC)[reply]
@Anomie: Thanks! I just tested it and it works. (Why was I not hitting the mixed-script rules though? Does the software (forgive my terminological ignorance) recognize subpages as non-mixed? הסרפד (call me Hasirpad) 21:35, 5 January 2014 (UTC)[reply]
The mixed-script rules exclude the User and User talk namespaces (and various others). Anomie⚔ 21:42, 5 January 2014 (UTC)[reply]

Problems with WikiProject Physics Portal

There is a problem with the WikiProject Physics Portal. In general, I think the instructions that tell each segment of the portal where to hold an article or picture for the que to the Physics Portal are no longer correct. More specifically, when I post an article to the Monthly Selected Articles it is there but hidden (Please see February. 2014 here and here); the monthly selected pictures should probably also be checked, and finally, the monthly anniversaries should probably also be checked.

Although the January 2014 monthly anniversary reflects my most recent editing , it was not functioning correctly by hiding the edited content, although it is there now.

Addtionally, it would be much appreciated if a person could look at the Selected Articles and Selected pictures for 2009, 2010, 2011, 2012, and 2013. Perhaps reviewing these pages could show how these are intended to be set up as well as errors that have occurred between 2009-2013. Below, in the next section, I have provided the last edit diffs for each page which I am requesting a review so this post can at least appear to be brief. Thanks in advance. --- Steve Quinn (talk) 23:10, 5 January 2014 (UTC)[reply]

Requested review pages

Hopefully, a section like this doesn't cause confusion. If it does just go ahead and remove the section head and this content to the original post above. Here are the last edit diffs for each of the requested pages:

Selected article:

Selected pictures

- Steve Quinn (talk) 23:19, 5 January 2014 (UTC)[reply]

I've fixed an error in the "Edit" links at Portal:Physics/2014 Selected articles and repaired the February page. The 2009-2013 pages look OK to me. -- John of Reading (talk) 08:18, 6 January 2014 (UTC)[reply]

WP DB

How can i browse wikipedia database? XXN (talk) 01:27, 6 January 2014 (UTC)[reply]

You can download a database dump and browse it on your own computer. Wikimedia Labs and the Toolserver also hold live replicas of the databases; anyone with an account on either system could query the database for you. Also see Wikipedia:Database queries. – PartTimeGnome (talk | contribs) 00:57, 7 January 2014 (UTC)[reply]

Can't display a page in a frame

Wondering what de:Denkmal was talking about, I went to Google Translate and told it to translate http://de.wikipedia.org/wiki/Denkmal, but I got a message (apparently from my browser, IE11) saying "This content cannot be displayed in a frame" and a little explanatory note for non-techie types like me. A link to open the content in a new window was provided, but something went wrong, because clicking the link caused new windows to proliferate like Hydra heads. The same happens when I try to translate an English article into German. This is seemingly rather new, because it's not been that long of a time since last I got an entire page in another language (German?) translated into English this way. Three questions: (1) Is this no-frame thing just a problem with some of the Wikipedias, or is it something that affects all WMF sites? (2) Is there anything we can do about it? (3) Could it be a browser thing? I was using IE8 until my previous computer died several weeks ago, and I don't remember encountering this kind of problem with it. Nyttend (talk) 02:27, 6 January 2014 (UTC)[reply]

I tried going to http://translate.google.com using IE11 and Firefox 26. When I typed "http://de.wikipedia.org/wiki/Denkmal" in the box, it then provided a link I could click to see the translated page. (It also provided a "Drag and drop link here to translate the page" box that did not work.) However, I couldn't reproduce your issue with frames. GoingBatty (talk) 03:20, 6 January 2014 (UTC)[reply]
Did you click the link to see the translated page? Problems arise only when I click the link. Nyttend (talk) 03:54, 6 January 2014 (UTC)[reply]
Sorry for not saying so before: When I clicked on the link to see the translated page, everything looked fine. GoingBatty (talk) 03:58, 6 January 2014 (UTC)[reply]
@Nyttend: Do you get the same issue in other scenarios? (e.g. logged in or logged out, other de.wikipedia pages, other foreign wikipedia pages, other foreign non-WP pages) GoingBatty (talk) 04:09, 6 January 2014 (UTC)[reply]
Hadn't thought to try other languages (I assumed all was the same, since en: and de: were throwing a fit), but that helps: fr:Paris translates (although gibberish, since I accidentally told it to translate English into German on this French page...:-), and I'm getting an English translation of de:Paris as well. Didn't try to log out; since I've not yet set up an email client on this computer, I've been leaving myself logged into Google so that emails will immediately be visible. de:Denkmal is now working fine; I don't know what the difference is, since I've not changed anything. Nyttend (talk) 04:16, 6 January 2014 (UTC)[reply]
I got a similar message looking at a Google map embedded on another website a little while back (using Opera 12). I went back later and it worked fine. I think Google have been fiddling with something related to frames. – PartTimeGnome (talk | contribs) 01:21, 7 January 2014 (UTC)[reply]

Tech News: 2014-02

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

Recent software changes

  • The latest version of MediaWiki (1.23wmf9) was added to test wikis and MediaWiki.org on January 2. It will be enabled on non-Wikipedia wikis on January 7 and on all Wikipedia wikis on January 9 (calendar).
  • The old note-taking site (Etherpad) was removed on December 30, 2013. You can see most of the documents on the new site. [5]

Problems

  • On January 2, Wikimedia Commons, Wikidata and all Wikivoyage projects were broken for 2 hours due to language cache update issues.
  • On the same day, it was not possible to edit most wikis for about 30 minutes, due to a database replication problem.

Future software changes

  • The new search tool (CirrusSearch) will be added as the default search method for Italian Wikipedia, French Wikisource, Wikidata and all Wikivoyage sites, and as a second search method for the German Wikipedia and all Wikibooks sites on January 6. [6]
  • Spanish, French, Portuguese and Russian Wikipedia users will also be able to enable CirrusSearch in their Beta Features options. [7]
  • Plural form rules for some languages will be changed. Many translations of the user interface for Belarusian, Russian, Serbian, Ukrainian and other languages will need to be changed. [8] [9] [10]
  • You will see a warning when you try to delete a page linked to from other pages. [11] [12]
  • You will be able to hide redirect pages on the list of protected pages. [13] [14]
  • You will be able to use keyboard shortcuts in the Translate tool, by pressing Alt+1 and similar key groups. [15] [16]
  • E-mails sent by MediaWiki will include the name of the site in their From: line. You will be able to change this name on your wiki by editing the MediaWiki:Emailsender page. [17] [18]
  • Images viewed in the Beta Features media viewer will load faster. [19] [20]

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

08:35, 6 January 2014 (UTC)

wiki:

Is there a reason, why wiki: redirects to http://c2.com/cgi/wiki? Armbrust The Homunculus 11:10, 6 January 2014 (UTC)[reply]

@Armbrust: Yes, because that is the original wiki: WikiWikiWeb. Matma Rex talk 11:12, 6 January 2014 (UTC)[reply]
There has been discussion for some time about removing this misleading interwiki prefix. In fact, it is slated to be removed with the next interwiki map synchronisation. See m:Talk:Interwiki map#Wiki. — This, that and the other (talk) 11:23, 6 January 2014 (UTC)[reply]
Also, WP:DAW. --Redrose64 (talk) 17:53, 6 January 2014 (UTC)[reply]

The wikilink to a recently created article, Den Chai Railway Station on the page State Railway of Thailand#Network is being displayed in red as a dead link, despite the article being there. I've had a quick look in various browsers, cleared my cache and tried from a different computers and the link remained red. I created a link from my own sandbox and it didn't have a problem, so it seems to only be a problem with the State Railway article. There are lots of route diagram templates on the page so it could be that one of them has a bit of incomplete syntax or wikimarkup that's affected the material on the page - though I can't see anything obvious and it seems unlikely to just affect one link. Could it be that something just isn't updating properly and it'll fix itself soon? Altogether I'm a bit clueless as to what could be causing it so I'd appreciate it someone could take a look. Here's a link to the user who created the station article's talkpage (he spotted the problem). Thanks in advance for any help! Jr8825 • Talk 12:15, 6 January 2014 (UTC)[reply]

It was red for me, too, and I turned it blue (for me) by purging Wikipedia's cache. I don't know whether that purges it for all readers or only those fed by a particular server. If it is still a redlink for you, click "edit source" for the page, and in the address bar replace "action=edit" with "action=purge". Something seems to be wrong which make purging necessary much more often than usual - see discussion under "Display slow to update" above. It's a pain, and I wish it could be fixed. JohnCD (talk) 12:35, 6 January 2014 (UTC)[reply]
This has been happening for all red-links I've turned blue over the last week or so. Doing a false edit, or refreshing the page clears it, but it's something that needs to be fixed. Lugnuts Dick Laurent is dead 19:14, 6 January 2014 (UTC)[reply]
A purge should work for all readers. – PartTimeGnome (talk | contribs) 01:28, 7 January 2014 (UTC)[reply]
The simpler way to purge is to enable either Preferences → Pending changes → Add a clock in the personal toolbar that displays the current time in UTC (which also provides a link to purge the current page) or Preferences → Pending changes → Add a "Purge" tab to the top of the page, which purges the page's cache when followed. --  Gadget850 talk 19:50, 7 January 2014 (UTC)[reply]

Proposal : creating an automatic alert for invalid usernames upon new account creation?

Hello Wikipedia Team...great job !

Just an idea : basing on my personal experience, it can be sometimes harsh to make one's first steps as a new contributor (despite the fundamental principles :"Assume good faith" and "don't bite newcomers"...). So here is a small suggestion for Wikipedia's great platform to still improve in conviviality-and especially indulgence towards newbies.. !

(I hope I am addressing the right recepient!)

I would like to suggest that action is taken preventively, so that new users don't infrige the policies and get blocked right after their very first contribution (for instance on ground of invalid username).

Couldn't it be done simply by the same automatic programm responsible for the block? Let it notify the user beforehand that the account he is creating contains words that are likely to result in a block, such as Society, Foundation, Group, etc...

This would prevent the blunt barring a posteriori of good willing contributors, who just wished to contribute to the common knowledge. This type of proactive action is applicable to other domains of course.

For further reading, here is my short story: I assembled material, with the help of a few friends, to create and expand some articles that we thought interesting and missing on Wikipedia. It took us a few days to carefully complete the work (although we are well aware it is still highly perfectible). Putting the first part of the work online, as a token of consideration for my collaborators, I created an account with the name of this (unformal) group. No promotional purposes in that ! (This association is totally non-profit, its goal is mainly to raise public awareness about the environment on a tiny island in the Aegean).

BAM : blocked !

I realize I did unwittingly infrige Wikipedia policy, that is clearly specified. I apologize and wish to correct this. But please consider that Wikipedia's guidelines, policies and regulations span over dozens of pages, making it difficult for newcomers to absorb them all at once.

I suppose most contributers are like us, regular users of Wikipedia who simply wish to contribute to the common knowledge in their turn, in good faith...Assuming that sticking to the Five Pillars is fair enough. Be bold, they say ! So the blunt barring of a user- for an easily remediable problem - seems somewhat brutal. How could it be a motivating pedagogy ?


Still, congratulations for the remarkable achievement of Wikipedia and thank you for this worldwide epistemic adventure.

Lonaïs

Velanidia Foundation (talk • contribs) 14:37, 6 January 2014 (UTC)[reply]

@Velandia Foundation: FYI, the process for checking usernames is not automated, it is an editor based process. But yes you are right that it the terminology is somewhat 'scary'. In this case I would personally suggest we use the term 'locked account' instead of 'blocked account'. The technical result is the same, but it's less offensive to people I think . Also User:Steven (WMF) has promised in the past that there would be further improvements to the Create Account page that would give users more feedback/instructions about the usernames and passwords while you type them. This functionality had been held back for deployment a couple of months ago, but is still planned I think. Thank you for your feedback and please be free to point out any similar problems that you encounter. —TheDJ (talk • contribs) 15:22, 6 January 2014 (UTC)[reply]
We already use the term "locked account" for accounts that can't even be logged in to. How would we differentiate between these situations? Jackmcbarn (talk) 16:37, 6 January 2014 (UTC)[reply]
TheDJ misspelled @Velanidia Foundation: above. See meta:Global locks for the normal meaning of locked account. I think it would cause confusion to have two terms for blocked accounts, also if the terms aren't used for other things. I don't think the poster complains about the word blocked, but about being blocked so quickly. PrimeHunter (talk) 16:57, 6 January 2014 (UTC)[reply]
BTW, one of the reasons we block group usernames is because a user account should only be controlled by one person, and a group name gives the impression it is not. It's not just concerns about promotion. – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)[reply]

"I don't think the poster complains about the word blocked, but about being blocked so quickly." Indeed! Thank you PrimeHunter for clarifying. Locked or blocked, neither of those are likely to feel good for a newbie, who just would like to add his little contribution to the grand puzzle. The point is to prevent those hiccups from happening. At least why not give prior notice? Thanks! 18:22, 6 January 2014 (UTC)Velanidia Foundation — Preceding unsigned comment added by Velanidia Foundation (talk • contribs)

I don't see any reason why we couldn't give WP:NOSHARE accounts a few days' warning before blocking them. With WP:Flow, it might even be possible to get automatic follow-up reminders to reduce hassle for the admins. The main complaint in the past is that admins can't track these warned accounts efficiently, so "one week's fair warning, during which you need to get your name changed" turns into "indefinite freedom, because I can't remember who I warned". But if a Flow process automagically told you when the time was up, then you wouldn't have to remember anything. (Hey User:Quiddity (WMF): I want another pony for Christmas, okay?) WhatamIdoing (talk) 19:27, 6 January 2014 (UTC)[reply]
I agree that the problem identified should be addressed. I tried a more comprehensive approach:User naming convention proposal. I still think it has merit, and this proposal is further evidence that there is a problem.--S Philbrick(Talk) 19:52, 6 January 2014 (UTC)[reply]
I have given such accounts warnings before using {{uw-username}}. I was rather disappointed to find that admins block accounts that have been given such warnings rather quickly (after about a day), even if they haven't used the account since the warning. I don't think there's any worry about admins having difficulty tracking warned users. (The template categorises the users into Category:Wikipedia usernames with possible policy issues, making them easy for admins to find.) – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)[reply]
@PartTimeGnome and WhatamIdoing: Timer-based workflows (or "reminder Notifications" as my note on the scratchlist calls them) are definitely something Flow aims to improve. Anything from individual-editor-reminders ("A week has passed since I commented on X that I'd be back in a week"), to systemwide-workflows ("category of editors who've been warned for 5 days about username issues, and need followup action"). It's not being rushed, so will take a while to reach that level of complexity, but with our guidance and patience over the coming months, it will fix hundreds of small problems like this. (No more ponies for you, WhatamIdoing, they've all been hired by as extras for some tv show...) Quiddity (WMF) (talk) 00:50, 9 January 2014 (UTC)[reply]

Categorizing non-mainspace redirects

Per discussion on my talk page, is there a better or more obvious way to categorize general redirects located outside of mainspace? There were two suggestions brought up, that we should "consider removing the namespace restrictions on the r from/to plural templates" or that we should "create new 'r from/to plural in non-main namespace' templates". See also here for a more complete discussion. I understand that primarily the {{R from plural}} template is meant to produce the Category:Unprintworthy redirects insofar as to prevent the redirect showing up should a user wish to download files from the Wikipedia website (or Jimmy to construct his book) but there should be an easier way to categorize non-mainspace redirects. TeleComNasSprVen (talk • contribs) 18:35, 6 January 2014 (UTC)[reply]

There would be no need for a separate "R from plural in non-mainspace" template. {{R from plural}} could use a template like {{main other}} to detect where it is used, and output the appropriate categories for that namespace. In fact, I see it already does so – Category:Unprintworthy redirects is omitted when the template is used outside of mainspace.
As for Category:Redirects from plurals, this is a tracking/administration category, not an article category, so IMO there's nothing wrong with it containing redirects from mixed namespaces. The main question to answer is if there is any benefit in splitting main and non-main redirects, or would it just make things more awkward? – PartTimeGnome (talk | contribs) 01:17, 7 January 2014 (UTC)[reply]
The problem is that I don't see it categorizing non-mainspace redirects into Category:Redirects from plurals even if it says it does, which it honestly should. I'm fine with excluding it from Category:Unprintworthy redirects as things outside of mainspace should not be printed in the first place. TeleComNasSprVen (talk • contribs) 23:37, 7 January 2014 (UTC)[reply]

How long does the average reader spend looking at a Wikipedia article?

Is there a tool that tells me this for individual articles or for en.Wikipedia articles in general? --Anthonyhcole (talk · contribs · email) 22:13, 6 January 2014 (UTC)[reply]

No. Wikipedia does not record when a user leaves a page or the site, so we can't know how long they were reading. – PartTimeGnome (talk | contribs) 02:40, 7 January 2014 (UTC)[reply]
Yeah; it wouldn't really be possible to track anyway. There's no 'reading a page' period - you make a GET request, you retrieve the page, it lives in your browser until you close the window and (short of active connections maintained between the site and the client, or further requests from the client) there's no further interaction. Ironholds (talk) 04:05, 7 January 2014 (UTC)[reply]
OK. Thanks. It would have been nice to know what proportion of readers stays on a page long enough to read more than the infobox and lede. --Anthonyhcole (talk · contribs · email) 04:27, 7 January 2014 (UTC)[reply]
You could probably do something with the "onunload" hook, but 1. it would only work for people with JS enabled, 2. people could submit false data, 3. it would be a huge invasion of privacy. πr2 (t • c) 18:47, 7 January 2014 (UTC)[reply]
Perhaps average pageview duration was a simple calculation of total pageviews per month divided by number of unique usernames/IPs per month, to split the month into seconds per pageview per user. -Wikid77 21:09, 8 January 2014 (UTC)[reply]
I quite frequently come upon an article I think I could improve, and might have time "later that day" or tomorrow. I will just leave that page open in one browser tab, and continue my current work in other browser tabs. That means the article is open, but I'm not reading it. We're asking for technical data to give us information on human behaviour. There may not be a great correlation. HiLo48 (talk) 03:22, 8 January 2014 (UTC)[reply]

Year in other calendars!!

https://en.wikipedia.org/wiki/Template:M1_year_in_topic

Please look at the link above. It's an internal link but I've formatted it as an external link. Within it I see hyphens used where minus signs belong. I cannot edit those. Wikipedia is supposed to be editable. How can I edit this? And who is so rude? Michael Hardy (talk) 05:51, 7 January 2014 (UTC)[reply]

@Michael Hardy: It's not rudeness - it's just templates embedded in templates. Try Template:M1YearInTopic (no calendar) and Module:Year in other calendars, and try posting on the associated talk pages if you need assistance. Happy editing! GoingBatty (talk) 05:59, 7 January 2014 (UTC)[reply]
I find this:
-1344 – -1343
There you see two hyphens where minus signs belong. Journalists are stupid and one expects nothing better of them, but one certainly does expect better than that from people who edit Wikipedia articles. Nothing in the links you cite gives me any way to edit these. Michael Hardy (talk) 06:25, 7 January 2014 (UTC)[reply]
Template:Year in other calendars uses mathematical functions in Module:Year in other calendars to compute the years. It wouldn't be practical to manually edit the numbers for thousands of years. Module talk:Year in other calendars redirects to Template talk:Year in other calendars, so that's where to post a request that hyphens in negative numbers are automatically converted to minus signs. PrimeHunter (talk) 07:27, 7 January 2014 (UTC)[reply]
Hi Michael - I'm the rude one who wrote Module:Year in other calendars. :) You can indeed edit that, but it might get a bit technical as all the years are calculated automatically. I probably should have coded in proper minus sign support when I first wrote it - that was an oversight. Still, it's an improvement on the old wikitext template which displayed negative year ranges as e.g. "-100–-99". In any case, there should be a fix coming along fairly soon to add proper minus signs, as you can see from the conversation below. Best — Mr. Stradivarius ♪ talk ♪ 16:52, 7 January 2014 (UTC)[reply]
It would be safer to only replace hyphens before a digit. There could also be a common function to format a potentially negative number, similar to {{Exprsign}}. If a calendar forgets to use the function then an occasional hyphen may be better than risking unwanted minus signs. PrimeHunter (talk) 17:11, 7 January 2014 (UTC)[reply]
  • I would prefer each calendar to format the negative numbers, and add spaces around dashes, rather than gsub the entire text to filter the hyphens. Start with the most-likely negative calendars, and others could wait until a later update. Retro-formatting of text almost always turns the "creeping featurism" into "featured creepyism". -Wikid77 17:23, 7 January 2014 (UTC)[reply]
  • Fair enough, and now done. Only numerical year input and year ranges are automatically formatted; years input as strings must now do the formatting themselves. The formatting is done by a new function "formatNegative" which only changes hyphens to minus signs if they appear immediately before a number. Michael Hardy, is that looking better? (If you don't see an update you might need to purge the page cache.) — Mr. Stradivarius ♪ talk ♪ 05:21, 8 January 2014 (UTC)[reply]

"Image" display anomaly

I'm having a "file" problem that must be unique to me. I can't view:

log cabin

[[Image:Cjd P7160326.JPG|left|thumb|300px|log cabin]]

But I can view:

log cabin

(Dropped one parameter, 300 px). Both images are viewable by another editor. (We each thought the other was crazy and tried to get the other blocked for insanity!  :) I'm using Mozilla Firefox. Don't know what the other editor is using.

Any ideas? Thanks. Student7 (talk) 18:48, 7 January 2014 (UTC)[reply]

Sounds like a purge did not arrive at one of the caching centers. This happens at times and can be troublesome to recover from. A normal purge usually does not suffice. I have now, purged, regenerated the 300px image and purged the page again, which should bust the cache of the server in the caching center. If you bypass your browser cache is is visible for you now ? If it still isn't visible, please let us know, there might be a problem with all purges failing to reach one of the caching centers in that case. —TheDJ (talk • contribs) 19:12, 7 January 2014 (UTC)[reply]
Using IE8 I can see both log cabins. GoingBatty (talk) 20:01, 7 January 2014 (UTC)[reply]
Thanks TheDJ. "Windows F5" worked perfectly. So I don't contend with another valid edit, what should I do permanently?
(And thanks GoingBatty. I have reservations about IE). Student7 (talk) 00:55, 10 January 2014 (UTC)[reply]

Unable to click Discuss and go to the discussion

In the article Halite, I proposed that that article be merged into Sodium chloride and indicated where the discussion should take place by writing 'Discuss=Talk:Sodium chloride#Merge Halite into this article' and clicking Discuss still brings me to the beginning of the entire talk page instead of the section that the edit page indicated. I'm wondoering if it's anything to do with the fact that I changed halite to Halite in the section title before I proposed the merger. The Discuss link in the article Sodium chloride only takes me to about a section and a half before where it's supposed to take me. Blackbombchu (talk) 19:25, 7 January 2014 (UTC)[reply]

I've fixed Halite - the parameter should be named "discuss" not "Discuss". The link at Sodium chloride is working for me. -- John of Reading (talk) 19:51, 7 January 2014 (UTC)[reply]
Now they both redirect to a few lines above the title of the discussion section. Blackbombchu (talk) 21:53, 7 January 2014 (UTC)[reply]
The heading at Talk:Sodium chloride#Merge Halite into this article is near the end of the page. I guess your browser window simply doesn't have room to scroll further down. PrimeHunter (talk) 22:05, 7 January 2014 (UTC)[reply]

New template not really taking effect

I recently changed the navbox Template:Jasper Fforde, replacing one of the horizontal lines with a navbox subgroup template, following closely the Template:Navbox subgroup#Example of Protected Areas in Colorado. The new Template looks fine on its Template page, it looks fine when transcluded on the Jasper Fforde page, but on all the other pages where the Template is invoked, it shows up as the old Template, as if the old Template had been substituted back in the day. Of course, it hasn't been substituted. I changed the one on The Eyre Affair to explicit state=autocollapse, and that works, showing the new Template. I toyed around with the state line in the Template itself, even changing the state to match the actual Template:Protected Areas of Colorado, to no effect. I'm stumped. Choor monster (talk) 20:06, 7 January 2014 (UTC)[reply]

When a template is changed, the software makes a note that other pages need to change, but doesn't do it immediately - the "job queue". You can force a page to display the latest template by purging it. -- John of Reading (talk) 20:14, 7 January 2014 (UTC)[reply]

Link to a nonexistent article

The last section of my talk page says the page Wikipedia:Articles for deletion/Google Feedback doesn't exist but it does exist. Blackbombchu (talk) 21:55, 7 January 2014 (UTC)[reply]

You mean the link was red. I have purged your talk page so it updates and registers the page exists now. The poster used Twinkle which makes edits so quickly that MediaWiki doesn't always register the page was created a moment before. PrimeHunter (talk) 21:59, 7 January 2014 (UTC)[reply]
A similar glitch is happening with the Reportum link in Wikipedia:Articles for deletion/Reportum after I added a redirect from Reportum to Adverse Event Reporting System. There's no need for you to go an fix it if it's going to fix on it's own later. My real purpose in mentioning this technical issue is so that Wikipedia will change it's system to avoid that glitch on future links to Wikipedia pages. Blackbombchu (talk) 01:44, 8 January 2014 (UTC)[reply]
Whenever you see a redlink that should be blue (or a bluelink that should be red), the first thing to try is a WP:PURGE. If that doesn't fix it, try a WP:NULLEDIT, and if that doesn't work, WP:BYPASS. There's no need to being them to VPT. --Redrose64 (talk) 13:36, 8 January 2014 (UTC)[reply]

Typography refresh beta feature

Hi everyone,

This an update regarding the "typography refresh" beta feature, which is live on all wikis that have Beta Features available. The following changes I describe will be live on Thursday, January 9th.

The first version of the typography update certainly wasn't perfect, but the UX design team wanted to get it out there and see what people thought about some of the ideas included. Well, we've recevied a ton of feedback on the Talk page.

Changes made based on your feedback

Almost all of the feedback was constructive, and some showed a really keen understanding of the issues with typography on Wikipedia. Thank you to everyone who stopped by and left a message. Based on the feedback we got, we made the following changes:

  1. Reverted the size of the personal toolbar menu and lefthand sidebar back its previous size (.8em)
  2. Reverted the black/grey links in the sidebar and personal toolbar back to blue
  3. Reverted the width of the left-hand back to its previous width, to avoid line breaks in those links
  4. Increased the body content size to 1.1em. While we did not originally increase the body content size, we saw that many people brought up this idea, and we think it's a good strategy for improving readability. This also allows us to emphasize the main content more without decreasing the size of toolbar or sidebar links, etc.
  5. Increased the size of page titles and their line height
  6. Tweaked the whitespace between section/subsection headings and around blockquotes. We hope this version provides better balance.
  7. Reprioritized the font family CSS for headings, placing the free and open source variant "DejaVu Serif" first

Additional ideas we're trying out in this release

  1. Placing a maximum width on page contents of 715px. It is widely accepted that text columns with a line length which spans the entire width of a (desktop or laptop) screen are not ideal for reading/scanning.[21], [22], [23],[24] The max width will not apply to Special pages (like Prefences) or to actions on an article, like viewing history.
  2. Removing the border around thumbs, increasing the whitespace around them, and changing the text styling on thumbcaptions. Vector and Monobook styles are both overly reliant on border styles to demarcate page elements. Numerous borders, especially with right angles, increases cognitive load when scanning a page.
  3. Changing disambiguation and row links to have the same type as thumb captions.

Other things we have retained in the beta. For example, serif headings were a source of complaints, but were retained since one of the goals is consistency with the mobile skin for Wikimedia projects.

On behalf of the design team, Steven Walling (WMF) • talk 23:16, 7 January 2014 (UTC)[reply]

P.S. Best place to leave feedback is this discussion page, linked to from within the Beta preferences.

Raging thanking dragon

Tracked in Phabricator
Task T61807

Sending "thanks" now redirects to a separate page that requires yet another confirmation. What is this?? Why do I need to 'confirm' that I want to thank an editor?? Is this system of positive feedback being 'abused' by some hideous thanker of excess?If we want users to use this system, it has to be easy to use; redirecting to a separate page with yet another button and system is ridiculous, and in terms of usability deprecates one of the only features that promotes positive feedback between editors. Am increasingly dissatisfied with the way Wikipedia changes around me with no easily-accessible consultation or notice. LT910001 (talk) 23:44, 7 January 2014 (UTC)[reply]

I think it's because it's so close to the "undo" link that if you're not careful when going for "undo" you might hit "thank" by mistake, and so give the opposite impression to what you intended (hey! I'm so glad that you inserted "poop" into this page!) --Redrose64 (talk) 23:56, 7 January 2014 (UTC)[reply]
I've opened a bug report to request that a preference be added. Jackmcbarn (talk) 23:56, 7 January 2014 (UTC)[reply]
The confirmation was added because people kept 'thanking' people for edits when they meant to undo them. I believe that the day after the confirmation step was added, completed thanks dropped by a quarter and complaints about people mis-thanking dropped to zero. I'm certainly very happy about this, since I made that mistake several times.
But I've not heard of it redirecting people to another page. It normally has a small pop-up. You click twice: 'Thank' and 'OK'. The confirmation step adds about an extra three seconds. It doesn't strike me as unreasonable. WhatamIdoing (talk) 05:28, 8 January 2014 (UTC)[reply]
Depends if you have JavaScript enabled. --MZMcBride (talk) 22:32, 8 January 2014 (UTC)[reply]
Also, if you click the "thank" link before the page has fully-loaded (as I managed to do a few days ago) it will take you to Special:Thanks (with the revision number filled in properly) instead of triggering the pop-up confirmation box. –Quiddity (talk) 21:15, 9 January 2014 (UTC)[reply]

Give Users Support

How could it be, that an user does not use preview, give no edit summary and does not sign for more than six years contributing to wikipedia. Compare Newest contributions 2014 >><< Oldest contributions 2007 Is it possible to create a tool to detect / filtersuch editors and give them a some help? > {{subst:uw-preview}} {{subst:uw-editsummary}}--Frze > talk 07:06, 8 January 2014 (UTC)[reply]

Huh? There's no requirement to use edit summaries or preview. The editor has signed their edits on a few occasions just at a quick glance (first two I clicked on): [25], [26]. Legoktm (talk) 07:10, 8 January 2014 (UTC)[reply]
Hah? Use template {{subst:uw-editsummary}} --Frze > talk 13:56, 8 January 2014 (UTC)[reply]

Edit summary needed

Information icon Thank you for your contributions to Wikipedia. Please make sure to include an edit summary with every edit. Please provide one before saving your changes to an article, as the summaries are quite helpful to people browsing an article's history.

The edit summary appears in:

Please use the edit summary to explain your reasoning for the edit, or a summary of what the edit changes. Thanks! Frze > talk 13:51, 8 January 2014 (UTC)[reply]

We have templates for all kinds of things. Edit summaries are encouraged but not required. Leaving them out has the side effect of making RecentChanges patrollers assume that you're up to no good. If you don't mind people being even more suspicious of your work, then you, too, may omit them. I don't recommend it, but you are permitted to make that choice. WhatamIdoing (talk) 16:59, 8 January 2014 (UTC)[reply]
Every now and then, there's a suggestion to make edit summaries mandatory. Here's the latest. Personally, I've opted-in by setting "Prompt me when entering a blank edit summary (or the default undo summary)" at Preferences → Editing. --Redrose64 (talk) 18:20, 8 January 2014 (UTC)[reply]
Wikipedia:Perennial proposals#Automatically prompt for missing edit summary. --  Gadget850 talk 18:24, 8 January 2014 (UTC)[reply]
I used to be this way, until it became apparent to me that no one cares about the 90% or so edits that I do, when the section link is all that's really necessary, and sufficient to get the point across, more so than a short "reply". TeleComNasSprVen (talk • contribs) 16:20, 9 January 2014 (UTC)[reply]

Can File:Lido EP.jpg be moved to English Wikipedia

I have tried everything that I can think of, but the "Upload" button for pictures on English Wikipedia file upload remains greyed out after I fill out every row of information. --Jax 0677 (talk) 16:36, 8 January 2014 (UTC)[reply]

this has often annoyed me too. When the commons image exists with the name it will not let you load over the top of it. I believe you have to use the old upload form special:upload. Graeme Bartlett (talk) 22:25, 8 January 2014 (UTC)[reply]
Or you could ask for it to be deleted off commons, as the image there is almost certainly out of policy as it would be used under fair use only. Graeme Bartlett (talk) 22:29, 8 January 2014 (UTC)[reply]
Reply - I tried to upload the file when there wasn't such a file on Wikipedia, but the Upload button remained greyed out. I therefore used the old English Wikipedia photo upload form. --Jax 0677 (talk) 22:39, 8 January 2014 (UTC)[reply]
@Jax 0677 and @Graeme Bartlett: Uploading a file to enwiki with the same name as a Commons file requires the reupload-shared permission, which is only given to administrators. jcgoble3 (talk) 01:12, 9 January 2014 (UTC)[reply]
Resolved - The issue has now been resolved. --Jax 0677 (talk) 01:14, 9 January 2014 (UTC)[reply]

Login problem

OTRS received a request VRTS ticket # 2014010510006699 Is there someone comfortable with login problems who could help?. The person has asked for password reset, but it hasn't worked. She is now asking for a password reset to a new email address. This isn't my area of knowledge, but I thought such a thing would not work doesn't the password reset have to go to the address used to setup the name?--S Philbrick(Talk) 14:33, 9 January 2014 (UTC)[reply]

If she doesn't remember the email address associated with her account, or can no longer receive email at that address, I think that she is out of luck. There is no way for us to change the email address on her account, and for security reasons, that wouldn't be prudent, anyway. ​—DoRD (talk)​ 15:09, 9 January 2014 (UTC)[reply]
OK, thanks, I feared that was the case. I am writing to the user with other options.--S Philbrick(Talk) 16:19, 9 January 2014 (UTC)[reply]
wmf:Privacy policy says: "Users whose accounts do not have a valid email address will not be able to reset their password if it is lost. In such a situation, however, users may be able to contact one of the Wikimedia server administrators to enter a new e-mail address." I don't know anything about if and when this is done in practice. Presumably it would at least require good evidence of the user's identity. If "valid email address" is interpreted as one which originally worked then I don't know whether users who lost access to the address can get help. At the English Wikipedia we usually just tell users they have to create a new account if they cannot remember the password or retrieve mail at a stored address. PrimeHunter (talk) 16:59, 9 January 2014 (UTC)[reply]
In practice this is rarely done anymore, because proving your identity is thoroughly difficult and doing it for many people is a very resource intensive task. So basically for this procedure, you need to have a lot of edits to make it worth everyone's time and then either a {{User committed identity}} or subject yourself to a voluntary checkuser investigation and have some good proof of email identities and an acceptable story on why you lost your password that will pass sysadmin's criteria (those criteria are likely extremely high). Translated this means for 99.5% of users, no email means not recoverable by sysadmins. —TheDJ (talk • contribs) 17:20, 9 January 2014 (UTC)[reply]
Thanks for the information. I will continue to tell users to create a new account and not mention server administrators unless there are special circumstances like thousands of edits or a user right admins cannot grant (but then they probably have thousands of edits). PrimeHunter (talk) 18:05, 9 January 2014 (UTC)[reply]

hilite template is partly broken

Last night I discovered a bug in a template. I don't know much about how templates work at their back end, so I didn't even try to fix it . The Talk page hasn't been touched in a year, so I figured anything I wrote there would not be noticed, and came here.

But the Village Pump page says this Technical section is "To discuss technical issues. For wiki software bug reports, use Bugzilla", so I went to Bugzilla and filed a detailed report (below).

This morning I got an answer there (also below), telling me to BE BOLD or go to the Talk page. Enough already. I'm done with it. --Thnidu (talk) 16:42, 9 January 2014 (UTC)[reply]


Bug 59855 - some examples in Template:Hilite/doc are broken

The hilite template doc page on Wikipedia, https://en.wikipedia.org/wiki/Template:Hilite/doc , has examples of five ways to parameterize the template (including null). The third and fourth, which should have pink and yellow highlighting respectively, have none. I am using a 13-inch, Mid 2011 MacBook Air with Mac OS X Lion 10.7.5 (11G63b). I discovered the bug in Firefox 26.0 and have replicated it in Chrome 31.0.1650.63 and Safari 6.1.1 (7537.73.11).

Examples

code output notes
{{hilite | text }} text
{{hilite | text | lightblue }} text
{{hilite | text | pink | 2011-01-01 }} text
{{hilite | text || January 1, 2114 }} text Note the color parameter, left blank, is still represented
with a pipe (followed by the expiration parameter pipe)
{{hilite | text | #00FF00 | 1 January 2015 }} text 
Comment 1 Andre Klapper 2014-01-09 15:01:07 UTC

Thanks for taking the time to report this!
Has this been brought up on
https://en.wikipedia.org/wiki/Template_talk:Hilite/doc ? 
Sounds like the more appropriate page to reach its developers (or [[WP:BE
BOLD]] by fixing the docs if you have time and expertise), as Bugzilla's
"Template" component refers generally to loading templates and not to specific
ones on specific websites (so I'm closing this as INVALID but only because
Bugzilla isn't a good place for this, not because the issue you report does not
exist). This should be fixed on-wiki instead.
@Thnidu: Please note how the documentation mentions an expiry functionality. Now guess how the date in your broken examples effect the color of the text :D I've reset the 4th example to a more distant date to show the effect. —TheDJ (talk • contribs) 17:01, 9 January 2014 (UTC)[reply]
I have tweaked the examples and notes further.[27] If you have problems using a template and have limited template knowledge then Wikipedia:Help desk is often a good place. Bugzilla is common for all Wikimedia projects and should rarely be used for problems with a template, since templates are edited locally at each wiki. PrimeHunter (talk) 17:51, 9 January 2014 (UTC)[reply]
Thanks TheDJ and PrimeHunter! --AKlapper (WMF) (talk) 22:06, 9 January 2014 (UTC)[reply]
YES, thanks! To TheDJ for the explanation, and to PrimeHunter for making it clear on the page. --Thnidu (talk) 22:32, 9 January 2014 (UTC)[reply]

Looks like Javascript is working sporadically

I just viewed one page, then went to another and found no javascript menus, no usual wikipedia menus on top. I've cleared my cache (Using Chrome ) and came here, it also showed no menus on top, however, when I went in to edit the menu's (all of them ) re-appeared again.

Anyone else experiencing this ?  KoshVorlon. We are all Kosh   19:16, 9 January 2014 (UTC) [reply]

Interface (Typography refresh problem)

Tracked in Phabricator
Task T61815
Invalid

The interface off looks like crap. There's no skin or JS. I've trying purging and clearing my cache but no luck.—cyberpower ChatOffline 19:19, 9 January 2014 (UTC)[reply]

(Merged two sections about the same issue) Yep. bits.wikimedia.org is being slow and sometimes failing. My watchlist loaded with absolutely no JavaScript or CSS. Somebody should ping the devs on Bugzilla. jcgoble3 (talk) 19:21, 9 January 2014 (UTC)[reply]
(seems to be) back to normal now. Jared Preston (talk) 19:25, 9 January 2014 (UTC)[reply]
It's squashing content into the left 2/3rds of the screen for me, but not on Special: pages.--Gilderien Chat|List of good deeds 19:29, 9 January 2014 (UTC)[reply]
(edit conflict) sometimes happens after version upgrade (we are on wfm9 now). try deep purging of browser's cache (what works best for me is hitting Ctrl+⇧ Shift+Delete (works on big-3 windoze browsers + big 2 on linux) and selecting "delete temporary files" or "clear cache" or whatever else your browser chooses to call deep cache-purging. for opera try "settings => delete private data") dunno how to do same on mac. after this, and a couple more ⇧ Shift+F5, everything should go back to normal. peace - קיפודנחש (aka kipod) (talk) 19:33, 9 January 2014 (UTC)[reply]
@Gilderien: The "2/3rds of the screen" is part of the latest revision of the "Typography refresh". I've just disabled this beta feature in my preferences. -- John of Reading (talk) 19:35, 9 January 2014 (UTC)[reply]
Same for me. Here's a screenshot. Marcus Qwertyus (talk) 19:46, 9 January 2014 (UTC)[reply]
i do not believe disabling "Typography refresh" is required. from what i see, if you perform aggressive refresh/purge cache, everything should go back to normal, even if you have "Typography refresh" enabled. peace - קיפודנחש (aka kipod) (talk) 19:49, 9 January 2014 (UTC)[reply]
Note that the content squashing is actually intentional, see mw:Talk:Typography_refresh#Additional_ideas_we.27re_trying_out_in_this_release. Legoktm (talk) 19:54, 9 January 2014 (UTC)[reply]
Yes, I posted this above at #Typography refresh beta feature. It is not be related to any lack of skin CSS or JS though. Steven Walling (WMF) • talk 21:41, 9 January 2014 (UTC)[reply]

I wish there were an easy way to have Special:WhatLinksHere optionally (or even by default) not include links that only link through navigational templates. It there are way? Could there be?

My problem is that when I look at Special:WhatLinksHere for an article to find other articles with an interest in this article, the results can be overwhelmed by links that only exist in a navigation template. Now while navigation templates are good, the incoming links they generate are not so useful. --SmokeyJoe (talk) 00:12, 10 January 2014 (UTC)[reply]

AFAICT, this can't be done right now. I'd like it, too.
Does anyone know if this could be handled by a user script, or if we'd need the devs to support it? WhatamIdoing (talk) 01:14, 10 January 2014 (UTC)[reply]
It's a frequently requested feature but the developers will not implement it. See for example bugzilla:1392 and bugzilla:3241. PrimeHunter (talk) 01:17, 10 January 2014 (UTC)[reply]
It's bugzilla:1392. I believe that priority setting translates to is "if you write it, then we'll (maybe) merge it, but we won't spend any time on this ourselves".
Could something be built at Labs to produce the same effect? It doesn't have to be onwiki. WhatamIdoing (talk) 01:22, 10 January 2014 (UTC)[reply]
It would require a re-design of the database in order to achieve it. Right now all links (from templates, Lua, and article text) are combined, duplicates are removed, and the resulting list is in the database. Werieth (talk) 01:24, 10 January 2014 (UTC)[reply]
Would the redesign be so bad. Exclude all links from transcluded templates, but keep the links from the template itself? --SmokeyJoe (talk) 03:43, 10 January 2014 (UTC)[reply]
What I used to do (and this still works but takes much, much longer than it did before) was to edit the navbox so that the link that I was interested in was modified in some way, but not actually broken - such as going through a redirect, like this. Over the coming minutes, whilst the job queue was updating the link tables, I would monitor "what links here" for the page that I was interested in. Once it stopped growing shorter, I would wait ten or fifteen minutes more to make sure, and then I would make any edits consequent on the remaining incoming links. Having completed that task, I would then revert my edit to the navbox, like this. However, in about May or June 2013, something happened to the job queue so that the wait is now measured in days or even weeks instead of minutes. It's just not practicable any more. --Redrose64 (talk) 21:52, 10 January 2014 (UTC)[reply]

Site Resolution for Wikipedia Articles

Is anyone having issues with the resolution on articles? (See image below) I first noticed this issue this morning (about 12 hours ago). Any ideas on how to fix this?

File:VP-Wikipedia-Display-Issues.png

Thanks, -- ТимофейЛееСуда. 00:15, 10 January 2014 (UTC)[reply]

See the section #Typography refresh beta feature above. They are testing out narrower articles (715px), as there is evidence this improve readability. I'm not so sure, personally. — Huntster (t @ c) 00:21, 10 January 2014 (UTC)[reply]
Oh dang. This is terrible. I don't know if I can still edit with the articles like this. Is there a way I can disable this? -- ТимофейЛееСуда. 00:23, 10 January 2014 (UTC)[reply]
Nevermind. I figured it out. Thats just yucky. Sorry for opening a new discussion. -- ТимофейЛееСуда. 00:26, 10 January 2014 (UTC)[reply]
It's good for mobile browser (using desktop view) but definitely bad for non-mobile device which has larger screen/resolution. -- Sameboat - 同舟 (talk) 01:36, 10 January 2014 (UTC)[reply]
See #Article alignment below. --  Gadget850 talk 16:03, 10 January 2014 (UTC)[reply]

A Multimedia Vision for 2016

Happy new year!

Many thanks to all of you who contributed to our multimedia programs last year! Now that we have a new multimedia team at WMF, we look forward to making some good progress together this year.

To kick off the new year, here is a proposed multimedia vision for 2016, which was prepared by our multimedia and design teams, with guidance from community members.

This possible scenario is intended for discussion purposes, to help us visualize how we could improve our user experience over the next three years. We hope that it will spark useful community feedback on some of the goals we are considering.

The best way to view this vision is to watch this video:


File:Multimedia vision 2016.webm
Multimedia Vision 2016, presented by Fabrice Florin at a Wikimedia Meetup in San Francisco on Dec. 9, 2013.


You can also view this five-minute video in other file formats on YouTube and Vimeo -- or browse through these annotated slides, at your leisure.

Multimedia Vision Slides

This vision explores ways to integrate Wikimedia Commons more closely with Wikipedia and other MediaWiki projects, to help you contribute more easily to our free media repository -- wherever you are.

After you’ve viewed the video, we would be grateful if you could share your feedback in this discussion. We would like to hear from all Wikipedians who benefit from Commons, even if your work takes place on other sites.

In coming weeks, we will start more focused discussions on some key features outlined in this presentation. If you would like to join those conversations and keep up with our work, we invite you to subscribe to our multimedia mailing list.

We look forward to hearing from you -- and to more great collaborations in the new year! Fabrice Florin (WMF) (talk) 01:01, 10 January 2014 (UTC)[reply]

Deletion warning in new version of MediaWiki

With the latest update, we get a warning when attempting to delete most pages: "Warning: Other pages link to the page you are about to delete". Most of the time, a page's creator will be warned about its deletion, many deletion-taggers log their tagging on a dedicated page (example), and many pages in CAT:CSD will end up being linked by userspace or WPspace pages (example) that are set up to track CSD-tagged pages. Is there any benefit to using it here, or any benefit to paying attention to it? Nyttend (talk) 06:36, 10 January 2014 (UTC)[reply]

I haven't tried it myself yet, but it sounds like it would be very useful if it could be configured to display a warning if the page had incoming redirects or transclusions, rather than just links. And maybe links from mainspace would be useful too? — Mr. Stradivarius on tour ♪ talk ♪ 07:45, 10 January 2014 (UTC)[reply]
This was the result of feature request 35485 —TheDJ (talk • contribs) 07:51, 10 January 2014 (UTC)[reply]
I would add that this feature is probably more useful for small wikis. Pages up for deletion here will almost always have incoming links. I suppose we could just blank the message if we don't want it. — This, that and the other (talk) 10:10, 10 January 2014 (UTC)[reply]
Restrict it to mainspace links, redirects, and transclusions, and I'd welcome it, and I can see how this would be much more of a thing for smaller wikis. Wouldn't complain about blanking either. Nyttend (talk) 23:02, 10 January 2014 (UTC)[reply]
I agree with Nyttend. The message as it is is meaningless, and I would welcome a facility to turn it off, because it will be a very rare page which doesn't have any incoming links. JohnCD (talk) 23:08, 10 January 2014 (UTC)[reply]

Collapsible navboxes broken

It looks like a recent change broke all of Wikipedia's collapsible navboxes. I'm seeing a lot of space to the right-hand-side of the boxes, but the outer border extends all the way to the end of the page. This happens whether the box is collapsed or not. Here are some screenshots: collapsed, uncollapsed. This doesn't seem to be connected to the typography update discussed above, as it happens even after I turn that feature off in my preferences. Does anyone know what changed to cause this? — Mr. Stradivarius ♪ talk ♪ 09:18, 10 January 2014 (UTC)[reply]

Update: This doesn't happen when I'm logged out or logged in to my alternate account, so it must be something in my settings. I'll have a go at tracking it down. — Mr. Stradivarius ♪ talk ♪ 09:31, 10 January 2014 (UTC)[reply]
It's the Nearby beta. It pulls in tablet.styles module, which has a rule to set navboxes to receive 'display:inherit'. This causes the effect you are witnessing. —TheDJ (talk • contribs) 09:33, 10 January 2014 (UTC)[reply]
Yep, I just found it. I can confirm that the issue goes away when I turn the "Near this page" feature off. — Mr. Stradivarius ♪ talk ♪ 09:37, 10 January 2014 (UTC)[reply]
It's also affecting {{collapse top}}, which uses the navbox class for some reason. — Mr. Stradivarius ♪ talk ♪ 09:52, 10 January 2014 (UTC)[reply]

I reported this to the team btw. here. —TheDJ (talk • contribs) 20:25, 10 January 2014 (UTC)[reply]


I have a similar problem on ro.wiki. I created template Navbox-test (copy of Navbox). It uses ro:Module:Navbox (+ ro:Module:HtmlBuilder and ro:Module:Navbar). Everything in them are copied from enwiki, but result is not the same - navbox is broken. See here an example ro:User:XXN/teste2. How you can see the 3 buttons: view, talk and edit template - are not at their place, and when i collapse template it retracts in upper-left corner. What is the problem? XXN (talk) 23:15, 10 January 2014 (UTC)[reply]
  • All the inboxes for {{Infobox horseracing personality}} have had a major parameter collapsed when it's not the default, and there is no "show" option to uncollapse them. See, e.g. Rosie Napravnik. It's not in the history of that template, so must be some parent set of templates, but it's not happening everywhere. Earlier, someone broke everything at Infobox person, but that was fixed. Who is screwing around with these parameters and where? Montanabw(talk) 23:50, 10 January 2014 (UTC)[reply]

Visual impairment

I've heard that visually impaired editors commonly find blue on yellow easier to read than conventional display. Do we/could we have options that enabled this in people's monobook and vector css or better still preferences? ϢereSpielChequers 11:13, 10 January 2014 (UTC)[reply]

Article alignment

Hello, logging onto Wikipedia today it seems that the layout/skin has changed so that all the text is squashed to the left (see this screenshot). It doesn't happen when I log out, or when I change skin. I'm currently using the Vector skin with Google Chrome. Any help would be appreciated. —JennKR | ☎ 15:37, 10 January 2014 (UTC)[reply]

You have Preferences → Beta features → Typography refresh enabled. I like it, except for the screen width, which is supposed to make it match the mobile display. You can disable the max width by adding this to your CSS:
.action-view #bodyContent {
  max-width: none !important;
}
--  Gadget850 talk 15:43, 10 January 2014 (UTC)[reply]
That's done the trick! Thank you very much! —JennKR | ☎ 15:46, 10 January 2014 (UTC)[reply]
See #Additional ideas we're trying out in this release for the reason for the 715px max width. --  Gadget850 talk 16:04, 10 January 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=590149902"