Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPT)
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please, follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Older discussions, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159


Proposal: XTools ArticleInfo gadget

Hello! The XTools team is happy to announce the revival of the popular XTools gadget. Before this was offered as a user script (meta:User:Hedonil/XTools), but now we'd like to propose it as a proper gadget here on the English Wikipedia, meaning you could turn it on in your gadget preferences. The gadget will work with all skins. Here's a screenshot:

The XTools ArticleInfo gadget, as seen when viewing the English Wikipedia article on Jimmy Wales.

Documentation can be found at mw:XTools#ArticleInfo gadget. If you'd like to try it out now, add the following to your common.js (or global.js to install for all wikis):


Thank you for your consideration! MusikAnimal talk 19:44, 29 August 2017 (UTC)

Seems useful, works, no objections from my part. —TheDJ (talkcontribs) 21:07, 30 August 2017 (UTC)
Agree with TheDJ. Can't hurt to have as a gadget. Regards SoWhy 07:57, 1 September 2017 (UTC)
 Done I'm hoping this is OK based on this limited but positive feedback :) MusikAnimal talk 01:45, 6 September 2017 (UTC)
@MusikAnimal: Could you change the HTTP links to HTTPS links? Jc86035 (talk) 11:27, 9 September 2017 (UTC)
All the links are using HTTPS for me, except the links to XTools itself. I'm not sure why our framework isn't returning HTTPS when we're querying the service over HTTPS, but either way phab:T170989 will redirect any non-secure requests to HTTPS. We'll hopefully have that done before too long MusikAnimal talk 18:22, 9 September 2017 (UTC)

Wikipedia:Graphics Lab/Photography workshop

Resolved sections on this page are not being archived anymore. Could someone please attempt to fix that issue? Thanks. --Leyo 08:25, 30 August 2017 (UTC)

@Leyo: it's because ClueBot III (talk · contribs) is down (again). So it's a problem for the botops, nothing we can do here at VPT. --Redrose64 🌹 (talk) 09:54, 30 August 2017 (UTC)
The last archiving was 15 July [1]. ClueBot III has only been down since 25 August. PrimeHunter (talk) 10:16, 30 August 2017 (UTC)
Indeed, but this disabling of the archiving was not re-enabled until 22:33, 28 August 2017 - after the bot went down. That "temporarily disable autoarchive" on the part of AntiCompositeNumber (talk · contribs) explains the lack of archiving between 15 July and 28 August. --Redrose64 🌹 (talk) 12:20, 30 August 2017 (UTC)
Oh right. So I wasted a lot of time investigating the situation because Leyo failed to say that archiving had been disabled until two days ago. Sigh. I did look for recent edit summaries mentioning archiving but Leyo didn't say it when enabling it. PrimeHunter (talk) 15:39, 30 August 2017 (UTC)
I didn't expect that digging into the history was needed to answer the question. Sorry about that. Let's hope that the issue ClueBot III will get resolved soon. --Leyo 22:13, 30 August 2017 (UTC)
@Leyo: and everyone else, I disabled the archiving because the current configuration will archive every section, as the appears the same as {{resolved}} to ClueBot. The proper way to fix that would be to change the instructions to an edit notice. I started working on one at Template:Graphics Lab/editnotice. Now that I'm back from wikibreak, I'll also be manually archiving the page regularly again, at least until we can get the bot working as intended. --AntiCompositeNumber (Ring me) 01:00, 3 September 2017 (UTC)
@AntiCompositeNumber: I'm having difficulty understanding your phrase "as the appears the same as {{resolved}} to ClueBot". Have you missed something out here? --Redrose64 🌹 (talk) 08:23, 3 September 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Based on the source, AntiCompositeNumber may have tried to display "as the <nowiki/> appears the same as <nowiki>{{resolved}}</nowiki> to ClueBot". I'm not sure what it means but I think I know the archiving problem. The new request link at Wikipedia:Graphics Lab/Photography workshop preloads Template:Graphics Lab/new request/preload which includes: <!-- mark request as {{resolved|1=~~~~}} when finished or {{stale|1=~~~~}} when inactive for at least one month -->. The removed archive instructions [2] said: |archivenow=<nowiki>{{resolved|</nowiki>. See User:ClueBot III/ArchiveThis#Optional parameters for archivenow. It causes the bot to archive all sections with the preloaded text because the comment contains the archivenow string.[3]. It was only intended to archive sections where an editor has added {{resolved}}. A possible but inelegant solution would be to complicate the preloaded instructions like: <!-- mark request as {{RESOLVED|1=~~~~}} but with lowercase "resolved" when finished, or {{stale|1=~~~~}} when inactive for at least one month -->. If a user keeps uppercase {{RESOLVED}} then the template works via a redirect but the bot doesn't archive until an editor changes it to lowercase. PrimeHunter (talk) 10:43, 3 September 2017 (UTC)

Exactly. I should really stop using {{subst:CoNo}} and ignoring it in the preview, it seems to cause more trouble than it's worth. --AntiCompositeNumber (Ring me) 12:12, 3 September 2017 (UTC)
@AntiCompositeNumber: Are you aware of the various template-linking templates? The basic one is {{tl}}, but I find {{tlx}} to be more useful, also {{tlxs}}. So in your last comment you could have written {{tlxs|CoNo}} which displays as {{subst:CoNo}}; and earlier on you could have used {{tlx|resolved}} which displays as {{resolved}}. --Redrose64 🌹 (talk) 13:10, 3 September 2017 (UTC)
@Leyo: ClueBot III was restarted at 01:23, 6 September 2017 and archiving of Wikipedia:Graphics Lab/Photography workshop occurred at 22:40 the same day. --Redrose64 🌹 (talk) 10:33, 7 September 2017 (UTC)
Well, but it's done incorrectly as you can see in the diff you provided. --Leyo 18:53, 9 September 2017 (UTC)
You wanted to know why it wasn't being archived. We explained it. Archiving started again. Why is it now a problem? --Redrose64 🌹 (talk) 22:57, 9 September 2017 (UTC)
I explained why it archives too much above and gave a possible but inelegant solution. You have to do something or the same will repeat every day. PrimeHunter (talk) 23:11, 9 September 2017 (UTC)
@PrimeHunter: I am not sure if I got your solution right. Could you implement it so that we may see, if it really works? --Leyo 07:41, 13 September 2017 (UTC)
Done.[4][5] PrimeHunter (talk) 10:33, 13 September 2017 (UTC)
It worked.[6] Only sections with lowercase {{resolved| were archived. PrimeHunter (talk) 00:55, 14 September 2017 (UTC)

Mobile app localization?

Hello. I'd like to know if and how I can localize the Wikipedia app to show the featured article and picture, in the news, and DYK on the Scots version. --AmaryllisGardener talk 17:51, 2 September 2017 (UTC)

@AmaryllisGardener: See mw:Translation of app string resources. --AKlapper (WMF) (talk) 21:07, 3 September 2017 (UTC)
@AmaryllisGardener: Actually to get the content, which I think is what you mean, you apparently need to configure Featured feeds. We have then on English Wikipedia as well, see (talkcontribs) 11:45, 4 September 2017 (UTC)
@TheDJ: You're right, that was exactly what I was looking for. Thanks! --AmaryllisGardener talk 16:50, 4 September 2017 (UTC)
@AmaryllisGardener: Once that is done for the featured article please ping me and/or file a Phabricator task with the tag Mobile-Content-Service. Then I'd be happy to test and add the new language to the feed for the apps. Thanks! The other entries are a different: POTD comes from Commons. DYK is not yet included in the feed but it wouldn't hurt to add the appropriate pages to the MediaWiki namespace for it. BSitzmann (WMF) (talk) 16:34, 11 September 2017 (UTC)
@BSitzmann (WMF): I've already done those. Thanks in advance! --AmaryllisGardener talk 16:43, 11 September 2017 (UTC)

Wikidata description editing in the Wikipedia Android app

Wikidata description editing is a feature being rolled out on the Wikipedia app for Android. While this primarily impacts Wikidata, the change also addresses a concern about the mobile versions of Wikipedia. Now the mobile users will be able to directly edit the descriptions shown under the title of the page and in the search results from the Wikipedia app. We began by rolling out this feature months ago to a pilot group of Wikipedias in the beginning (Russian, Hebrew, and Catalan), then to all the others, and have seen very positive results including numerous quality contributions in the form of new and updated descriptions, and a low rate of vandalism. We are now ready for the last phase of rolling out this editing feature, which is to enable it for English in a few weeks.

As always, if you have any concerns, please reach out to us on wiki at the talk page for this project or by email at [email protected] Thanks!

Elitre (WMF) (talk) on behalf of-DBrant (WMF), 13:31, 4 September 2017 (UTC)

We have recently removed the Wikidata description from the mobile site, see Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP, where the reading team agreed to turn this off. Either this description is not visible in the app, in which case this new "feature" will do absolutely nothing here, or it will at the same time make the description again visible, which would be rather surprising and premature. Like I said at the RfC, this is the wrong solution for this problem (but a typical effort in pushing Wikidata instead of looking for the easiest and best solution). Descriptions, being language-dependent, don't belong in Wikidata, which is meant for common things across language versions. Descriptions should be (if we need them at all) stored on local wikis, where changes to them will be much easier and faster spotted by people fluent in the language and actualy watching the article, and then wouldn't require an extra "edit wikidata through this link" on every page.
Please don't rollout this "feature" here.
Oh, and I don't edit Mediawiki, and these discussions should be out in the open, not done by email, so please check concerns here instead. Fram (talk) 14:07, 4 September 2017 (UTC)
Hi Fram, I think some clarification will help here, but definitely let us know (I know you will ;)) if you continue to have concerns. Wikidata descriptions have been in the Android and iOS apps for several years now and we are talking about a feature in the Android app that will allow a user to edit what they see. For the apps, this makes the feature more robust, solving a primary concern people have raised about having something appear that previously could not be edited from Wikipedia. We have launched it in all languages except English (English is our last) and the contribution quality and rate has been stunning. The mobile web is a different situation: Wikidata descriptions were launched on the mobile web of en-WP in January of 2017, and the RFC in March was to remove them from mobile web of en-WP, which we did. We are not talking about rolling any new features out onto the mobile web at this time.
As to the overall issue mentioned in the RFC about wikidata description storage in the first place, I agree that descriptions, being language specific, add the least marginal value to being in Wikidata--I think the argument for having them becomes one of simply storing all of the structured data in one place. If we store them instead on each Wiki, it becomes very hard to pull it, as each project uses different rules, etc and Wikidata is expressly designed to store this effectively. But you are right that there are downsides, which the team has acknowledged from the beginining. If we make it so that you can edit it from Wikipedia and you can track it from wikipedia (as though it were an article edit), I think we can get the benefits without the downsides of storing it on Wikidata. This feature is a step in the direction of mitigating an issue that has been there for several years as we progress towards making it even better. Jkatz (WMF) (talk) 15:41, 4 September 2017 (UTC)
Let me get this straight (as I may misunderstand): when we discovered that Wikidata descriptions were shown in mobile (which most admins and editors, being editors, don't use that often if ever), we got you (WMF) to remove it after some discussion. But no one at your side thought to inform us that the same descriptions, with the exact same serious issues, where also shown in the andoid app (and presumably elsewhere), and that they should have been removed there as well at the same time? That's... staggering.
The feature doesn't make this "more robust", that's like calling two snowflakes more robust than one; it makes it marginally less problematic, while adding a link and siphoning mobile editors to Wikidata, which is problematic (as these editors now will have to learn mutliple editing environments instead of one, with different approaches and policies (or in the case of Wikidata, a severe lack of them)).
Please first remove the Wikidata descriptions from anywhere they are shown on enwiki, and then discuss a) solutions and b) timelines to roll them out. Fram (talk) 15:54, 4 September 2017 (UTC)
I'm glad we can at least agree that the present change (enabling users to edit descriptions in a situation where they already see them, rather than "mak[ing] the description again visible") is a step in the right direction regarding the concerns raised in the context of the RfC, even if we disagree about the step's size ("marginally" - I think it's actually a large and important step; it was listed as blocker back then). Regarding "adding a link and siphoning mobile editors to Wikidata": The new feature is limited to editing descriptions and no other Wikidata content, while keeping the app's full existing Wikipedia editing capability. The feature includes an onboarding experience educating users about what content is appropriate (based on the corresponding content guideline, which does actually exist, despite the insinuation above), plus notifies them if their edit has been reverted. In both aspects, this is ahead of the normal (Wikipedia) editing experience on mobile (web or app).
"when we discovered " - who exactly is "we"? "thought to inform us" - As far as I recall, the fact that the app shows these descriptions had been highlighted and discussed several times on enwiki village pump pages since 2014, both by WMF staff and volunteer editors. And in the context of the withdrawn March/April 2017 RfC, several WMF staff mentioned the app too, e.g. Chris ("They [Wikidata descriptions] are used in the mobile app for searching and in the articles as short descriptions"), and Olga (the product manager of the team responsible for mobile web) who highlighted the exact Android app editing feature that we are talking about now. The need for such a feature was also expressed subsequently in a thread on this very page: "How can I edit the subtitle used in the official (Android) mobile app?".
BTW: '"most admins and editors, being editors, don't use [mobile versions of Wikipedia] that often if ever" - I find that a rather surprising claim. Is there data to back it up? (The fact that most editing happens on desktop does not imply that people make edits are not also using their phones to read Wikipedia in other situations.)
Regards, Tbayer (WMF) (talk) 18:01, 4 September 2017 (UTC)
@Tbayer (WMF): You misunderstood me, I didn't claim that this is "a step in the right direction", I consider it a step in the wrong direction, a band-aid across a festering wound. Please link to the appropriate content guideline which you claim exists. ""when we discovered " - who exactly is "we"?" The enwiki admin and editing community which cares about these things? When I raised this issue for the first time, most editors indicated their surprise (and dismay) about this. ""thought to inform us"" at the RfC, where the WMF indicated that they would remove this from the mobile view. Instead of asking these questions, you could have read the discussion I linked to in my first post, and the discussions linked to from there, like Wikipedia:Administrators'_noticeboard/IncidentArchive950#Hard_to_detect_mobile_vandalism. Then you would see that this came to many people as a surprise, and that the request was to remove these descriptions from mobile view (without an exception for e.g. the android app). The official communication from the WMF was "Hi all, based on the raised concerns, we have decided to turn the wikidata descriptions feature off for enwiki for the time being." I don't see anything there indicating "but we will keep it on the app, and perhaps on other places as well, haha!". At no time in that RfC was there any indication that this feature was kept alive at the app (and perhaps elsewhere?).
As for that later Village pump discussion; comments include "You can only edit it on what's rapidly becoming my least favorite website, Wikidata", "I will leave it to the community to decide if the spirit of the RFC is being complied with by those results.", "this is not just a problem when viewing a page (which the English Wikipedia community has expressed concerns with) but that this non-enwiki data is also being shown on English Wikipedia search results. Is this being addressed? ". I don't see any enthusiasm for getting that description from Wikidata though. Fram (talk) 06:57, 5 September 2017 (UTC)
So you made an assumption about mobile web and the app being the same thing and now that your assumption is proven wrong you make this someone else's problem ? That doesn't seem entirely fair to me either. I'm sure assumptions were made by multiple people. —TheDJ (talkcontribs) 09:09, 5 September 2017 (UTC)
?? No. I made the assumption that WMF people would be competent and fair. Why I still make that assumption is not clear, I am probably fooled by those that are and forget that usually one encounters the other type (most only lacking one or the other trait, sometimes both). Please indicate how and where at the RfC it was made clear that the app would not be affected by the promised shutdown by the WMF, considering that it was included in the discussion and faced the exact same problems? The RfC was to remove descriptions from mobile view, and one of the ways to get a mobile view of enwiki is through the android app (see List of Wikipedia mobile applications and Help:Mobile access). How you can equate this with "make this someone else's problem" is not really clear. Fram (talk) 09:41, 5 September 2017 (UTC)
We were having an RFC where we directly talked to the mobile WEB team, and hardly ever mentioned the mobile apps (it was clearly in the original complaint, but not so explicit in the RFC). There is also a BIG difference between app development and web development, as releases for the App team are much more involved and rare than for the weekly web releases and they have different product managers and teams. The feature was also already enabled in apps for months, before it was intially brought to mobile web, so I don't think it's illogical for the mobile web product manager to not consider the desired and 'assumed' impact for a totally different team. If you want to be combatitive about something like that, then that is up to you, but I prefer to keep this discussion constructive. —TheDJ (talkcontribs) 10:02, 5 September 2017 (UTC)
No, we were having an RfC where we talked to the WMF, and everyone (bar you) could give a flying fuck what TEAM we were talking with. Furthermore, according to the RfC, our contact at the WMF was someone from the Reading team, not the mobile WEB team or the App team or whatever. I would much like to see some constructive criticism from you here, instead of the obstructive comments you have made so far. When we get a promise from the "WMF reading team" (their words), and when the "Senior Director, Head of Reading" is directly involved as well, I don't think it is really useful or fair to claim that it should have been obvious that we were talking to the mobile web team only, and that they are incapable of contacting other WMF teams to raise our concerns. Fram (talk) 10:11, 5 September 2017 (UTC)
I'm walking away from this 'discussion', as this will not lead to anything good. —TheDJ (talkcontribs) 11:05, 5 September 2017 (UTC)
"Discussion" as in "The DJ tells something wrong, gets corrected, tells something else that's even more incorrect, gets corrected again, and walks away"? No idea why you even bothered to show up. Fram (talk) 11:24, 5 September 2017 (UTC)
Before the RfC started, TheDJ actually tried to clarify the issue (in a post you replied to) at Wikipedia:Village pump (technical)/Archive 154#Wikidata description in mobile view on enwiki: "It should be pointed out that the descriptions are used in many more areas (including the mobile app, search results and dozens of downstream tools like etc). I don't see how turning it off in one place, would move us much forward, and I fear that with reduced visibility of Wikidata labels the problem will become larger instead of smaller." PrimeHunter (talk) 16:11, 5 September 2017 (UTC)
Good for him. That doesn't change the mistakes in his above statements, making it seem as if it is our (or my) mistake that this is only turned off in one form of mobile Wikipedia view and not others, because I only talked with the Reading team which obviously only deals with one kind of reading and not others. Urging the WMF to turn the descriptions off in those other areas would be much more useful. Fram (talk) 04:53, 6 September 2017 (UTC)

(Moving and outdenting the following two comments, as they appear to pertain to the original post rather than forming part of the subsequent conversation. --Tbayer (WMF) (talk) 03:02, 9 September 2017 (UTC))

I can't help but have misgiving about this Having had a rash of image vandalism recently where the vandalism even after purging on the desktop or mobile sites remains visible on the app, we now have the facility to easily vandalise article descriptions that is a) not going to be seen by most people who are in a position to do something about it and b) may remain visible even after the descriptions are corrected on Wikidata. Doesn't sound like the best advert for Wikipedia, and yes I have read the mediawiki page and the protections proposed. Nthep (talk) 21:54, 4 September 2017 (UTC)
I don't see the logic here. We have seen similar problems with google, apple dictionary and museum websites etc after vandalism. If we don't want to have an open door for vandalism, get pending changes introduced already and stop pretending that we are an open wiki. As long as make things as complicated for ourselves as we do, problems like these are inevitable and you should just file bug reports for them. —TheDJ (talkcontribs) 09:07, 5 September 2017 (UTC)
For the record, the image vandalism was referring to the "In the news" problem reported above, now being investigated at phab:T174993. This looks unrelated to the descriptions (it's a different part of the app and a different data source).
In general, vandalism is of course always a possibility, both on Wikipedia and Wikidata. Enabling users to fix it if it happens (or to make other improvements) is in fact among the benefits of this new editing feature on the app. Conversely, ensuring that contributions via that new button aren't becoming a major new source of vandalism on Wikidata has been very much on the team's mind when developing the feature. (As a reminder, the main (Wikipedia) article content has been editable from the app for a long time.)
At this point, over 60,000 description edits have already been made with this app feature; and we have been monitoring it closely (in particular the revert rate) since February, when it was activated for the first few Wikipedia languages. Nthep, you mentioned that you already looked at feature's documentation page which mentions e.g. the tools that the Wikidata community has made available this year which allow improved monitoring of description edits. There is also a subpage with the results of the data analysis.
When the initial data looked good, the feature was gradually rolled out to more languages. Since July, it has been active on all languages except English. Of course the positive results in the other languages do not offer an absolute guarantee for English, so we're going to monitor the impact of the rollout there as well. Regards, Tbayer (WMF) (talk) 03:02, 9 September 2017 (UTC)
There have been plenty of other WMF "improvempents" which have been accepted by all or most other wikis and rejected by enwiki, for whatever reason. Perhaps because we are more critical, perhaps we have more power to actually force the WMF to sometimes accept the negative opinion from here, perhaps beecause the benefit of these new tools and features is much less significant for enwiki than for small language versions (e.g. much of the info on Wikidata comes from four or five big wikis, including enwiki; for small wikis Wikidata may be a source of information, but for enwiki the roles are usually reversed). "In general, vandalism is of course always a possibility, both on Wikipedia and Wikidata. Enabling users to fix it if it happens (or to make other improvements) is in fact among the benefits of this new editing feature on the app." Of course, when you didn't pull this from Wikidata, all vandalism could already be easily monitored and reverted. Removing the Wikidata descriptions from the app, which was what the RfC clearly wanted, would also prevent all description vandalism from reaching enwiki. I really don't care that you are "going to monitor the rollout" when the rollout is not what we want here in the first place. Fram (talk) 07:15, 11 September 2017 (UTC)
  • This is absolutely unacceptable. This is a governance issue. The WMF has no right whatsoever to interfere with content. The en-WP community made this clear to you people in the RfC that we already had - this also made clear the policy issues with BLP and Verify - these are core policies in en=WP and Wikidata has no such policies. I am stunned to hear that you all interpreted the RfC about mobile in some narrow lawyerly sense. Of course that applies to apps etc.
Do we need to waste the community's time with another RfC?
Again - The WMF has no right to mix and match content among projects. NONE. This is deeply wrong and misguided. Jytdog (talk) 05:16, 11 September 2017 (UTC)
  • Comment - I have the impression that since descriptions are article as well as language-specific so closely bound to articles, a solution may be to provide an optional template allowing to add those at the top of articles (i.e. {{description|1=...}}). Internally it would not matter how those were processed/cached/displayed/stored (including on wikidata), but the source would remain directly as part of the article and managed/patrolled by the same language-specific project editors... —PaleoNeonate – 05:39, 11 September 2017 (UTC)
  • we said no to this, unambiguously. Jytdog (talk) 05:41, 11 September 2017 (UTC)

I have posted about the problem with the Wikidata descriptions at Wikipedia:Village pump (policy)#Wikidata descriptions still used on enwiki. Fram (talk) 14:38, 11 September 2017 (UTC)

Should we ask for mapframe to be turned on?

Mapframe is an extension that is being developed by the WMF to show small OpenStreetMap maps in articles. Background information is at mw:Help:Extension:Kartographer. It is currently enabled on some Wikipedias that have opted in, and I think it would be useful here as well. Personally, I'm interested in using this in Wikidata-driven infoboxes such as the one at Lovell Telescope to replace {{Location map}} with OSM data, but it also has wider applications. I don't think that it interferes with existing coding here, so it just adds functionality that we can use. I can't spot any previous discussions about this, so I'm starting this discussion here to try to determine consensus. Also see phab:T138057 and phab:T175102 Thanks. Mike Peel (talk) 00:29, 6 September 2017 (UTC)

Agree I think it would be a major benefit to have proper interactive maps in all Wikipedias, not just the ones that opted in. <mapframe> functionality has not caused any technical issues on any other wikis. Map code is already deployed to all Wikipedias as <maplink>, so enabling it would be as simple as flipping a switch. --Yurik (talk) 00:41, 6 September 2017 (UTC)
Support This should've been done waaay sooner. Ladsgroupoverleg 10:58, 6 September 2017 (UTC)
Support. Also support T137253 converting Earth coordinates in {{Coord}} to use <maplink> as well. Jc86035 (talk) 11:27, 6 September 2017 (UTC)
Support, would be especially useful to have mapframe maps in the infoboxes of road articles. See commons:User:Evad37/sandbox/maps for some examples - Evad37 [talk] 23:48, 6 September 2017 (UTC)
Note from the Wikimedia Foundation product team: This is a totally reasonable thing to request as better maps on Wikipedia could improve the user experience and would make a lot of people happy. Previously, we had internally decided on a process to enable mapframe for new Wikipedia projects by request on a batch basis every 6 months. However, the future of maps support from the Wikimedia Foundation is uncertain and at this point I think all new communities considering adding maps should be made aware of it.
The Reading product team has been working to try to figure out how to support the existing maps implementation, and our initial analysis is that maps requires significantly more resources than were assigned to the project at inception. We are currently working on establishing if we can prioritize resources to get maps into a stable, healthy state and will update folks on a plan as soon as we have a draft for comment. It has taken longer than we would have liked to get more clarity, due to organizational changes, but I think we are making progress and should have a clearer answer by the end of September, 2017.
The current situation is that over the last several months the maps project has relied on the goodwill of individual engineers at the Wikimedia Foundation to keep it up and running in addition to individual volunteers contributing support. We also have a contractor, working on a cartographic re-skin as well as dealing with some other maps issues like disputed borders.
I am personally very nervous about having maps on English Wikipedia because we don’t know what kind of support we will be able to offer in the future and I want to minimize the amount of editor effort going into a feature that is at risk. We are frankly concerned that the resources required to maintain and make necessary upgrades to the map service are more than we can commit to.
We’d like to propose that we revisit this question in October when we have more clarity over the path forward for maps. Thoughts? Jkatz (WMF) (talk) 00:23, 7 September 2017 (UTC)
@Jkatz (WMF): Thank you for the background information on the development work. I think that there are two different issues here that can be handled in two separate stages. First, do we want to have this functionality available on enwp? That is what this discussion will hopefully decide. Second, is WMF ready to support the deployment? That is something that the WMF has to decide, and if the answer to the first question is 'yes' then the timing of the deployment is up to the WMF; if it is 'no' then the WMF is off the hook. ;-) I think that delaying this until next month doesn't help with either question, so it's still worth asking & answering the first question now. Thanks. Mike Peel (talk) 01:06, 7 September 2017 (UTC)
@Mike Peel: I think that is a totally reasonable approach. Am I correctly interpreting your intent when you say "if it is 'no' then the WMF is off the hook." to mean that if the Wikimedia Foundation is not ready to support the deployment, we will have a discussion and that you wouldn't deploy until we were? This interpretation seems like a great way to break down and approach this problem (thank you!). If, instead you mean you would deploy without our support, it makes me very uncomfortable, as it would mean deploying map infrastructure we are responsible for supporting and maintaining at a time when we are suggesting we might not be able to support and maintain it. Can you confirm that I am reading your intent correctly? Thanks. Jkatz (WMF) (talk) 03:18, 7 September 2017 (UTC)
@Jkatz (WMF): My understanding was that someone at the WMF would have to flip the switch to deploy this. Even if that's not the case, I don't think it makes sense to deploy it until the WMF is ready to support and maintain it. So let's answer the first question here (do we want it here), and then we can move over to phabricator and the WMF/devs can determine when to deploy it. Thanks. Mike Peel (talk) 12:15, 7 September 2017 (UTC)
@Mike Peel: Makes perfect sense. Thanks for clarifying! I'll probably add my note with our concerns to the phab ticket too, just so it's in the relevant places. Jkatz (WMF) (talk) 18:12, 7 September 2017 (UTC)
I'll support.. I've been playing a bit with maps, and it could really use and benefit from some more exposure and feedback by a bigger audience. —TheDJ (talkcontribs) 20:00, 13 September 2017 (UTC)

Cannot move page that has template-protection for its move protection

Something strange is going on here. The protection levels on move protection for Template:MathSciNet and Template:MR were recently downgraded from "full" (requires an administrator) to "template protection" (must be a template editor). However, when I attempt to move either page, I receive he message "(Green lock) This page is currently protected so that only administrators can move it." with alternatives about how to move these pages. I'm not sure why this is happening: I should be able to move these pages since I am a template editor, and the protection levels for move protection on these pages have been downgraded to template protection. What is going on? Steel1943 (talk) 20:04, 7 September 2017 (UTC)

Interesting, you are indeed a template editor, so should be able to move these templates, which as you say have move protection to TE level (and edit protection to semi level). Maybe a recent software change? --Redrose64 🌹 (talk) 20:28, 7 September 2017 (UTC)
Now I can move both pages. And a template editor has since moved the pages. I suppose there is some lag someplace regarding the protection level change... Steel1943 (talk) 21:18, 7 September 2017 (UTC)
I saw (and still see)
WARNING: This page has been protected so that only users with administrative rights can move it.
  • <log entry>
View full log
I moved it anyway. — JJMC89(T·C) 22:01, 7 September 2017 (UTC)
I removed all protection, made an edit, and restored the TE protection. I don't see the admin-only warning that JJMC89 saw. Could someone with TE rights look at the template now? Nyttend (talk) 22:49, 7 September 2017 (UTC)
@Nyttend: I still see the same warning. — JJMC89(T·C) 22:55, 7 September 2017 (UTC)
@JJMC89 and Nyttend: Though I am now able to move the page, I also see the warning message JJMC89 referenced above. Steel1943 (talk) 01:17, 8 September 2017 (UTC)
I suppose then the next question is ... what page in the "MediaWiki:" namespace is being called to display the warning message JJMC89 and I see when moving a page with template-protection-level move-protection? Steel1943 (talk) 01:26, 8 September 2017 (UTC)
@Steel1943: It is MediaWiki:protectedpagemovewarning. I think the switch there needs to be on {{PROTECTIONLEVEL:move|{{#titleparts:{{FULLPAGENAME}}||2}}}} instead of {{PROTECTIONLEVEL:move}}. — JJMC89(T·C) 02:19, 8 September 2017 (UTC)
The interface message has been updated. — JJMC89(T·C) 15:20, 12 September 2017 (UTC)
@Nyttend: In removing all the protection and then re-adding the protection, somehow the edit-level protection was upgraded from confirmed to template editor (without any discussion that I can currently find). I see this request to downgrade the move-level protection from admin/sysop to template editor but I see no discussion of upgrading the edit-protection from confirmed to template editor. Is there a reason for the change and can it be returned to confirmed so confirmed editors can continue editing the template? Thank you. (talk) 09:13, 9 September 2017 (UTC)
Ah, I'm sorry — I see what you mean. When unprotecting and reprotecting, I meant to put things back just as they were; I must have misread the logs, because I thought that the thing had required TE both to edit and to move. [I don't remember ever before seeing TE required to move but autoconfirmed required to edit.] Therefore, when you asked, I thought you were objecting to the very idea of unprotecting and reprotecting, not questioning the reason for the "net upgrade" from semiprotection to TE. Nyttend (talk) 10:47, 9 September 2017 (UTC)
I appreciate you fixing that as I can now appeal to a larger set of editors to get changes made (more editors can respond to {{edit semi-protected}} than {{edit template-protected}}) and I am sure confirmed editors will appreciate being able to directly edit the template again. Thank you. (talk) 12:09, 9 September 2017 (UTC)

Mysterious random popup

I was at MOS:NBSP and switched to another tab, then switched back; and this popup appeared. I know what a half adder is (have done for 40 years) - my question is, how is it relevant, and where has this come from? --Redrose64 🌹 (talk) 20:24, 7 September 2017 (UTC)

Oho, it's Thursday! Wacky new features time! --Redrose64 🌹 (talk) 20:29, 7 September 2017 (UTC)
I just opened Copenhagen and got 'Would this be useful to someone searching for "List of hospitals in Andorra"'. I'd love to know just who sold the WMF whatever algorithm they're using. ‑ Iridescent 20:33, 7 September 2017 (UTC)
Interestingly, we don't even have a list of hospitals in Andorra :-) Nyttend (talk) 22:29, 7 September 2017 (UTC)
But we do have a red link to it in {{List of hospitals in Europe}}. Clicking the link gives an option to search for it. I guess that's how a search got registered and placed in the test, but I have no idea why Copenhagen is suggested. PrimeHunter (talk) 23:42, 7 September 2017 (UTC)

You know what they say about incorrect proclamations. This has nothing to do with Thursday. This wiki is currently still running the prior version of mediawiki. This is likely an A/b test / survey probably to help improve the cirruSearch search engine. 20:38, 7 September 2017 (UTC) — Preceding unsigned comment added by (talk)

You say "A/b test / survey probably to help improve the cirruSearch search engine", I say "yet more fucking about with the interface without consultation or notification". It's probably one of those tricky irregular verbs. ‑ Iridescent 20:45, 7 September 2017 (UTC)
The screenshot includes the string "would they want to read this article". I searched it at Phabricator and got three results: phab:T171740, phab:T171741, phab:T174106. It's an A/B test for Search Relevance. PrimeHunter (talk) 21:15, 7 September 2017 (UTC)
Yes, we're currently running a test for Search Relevance (graded by humans); more information can be found in this ticket: phab:T171740 and the most recent test is detailed here: phab:T174106. DTankersley (WMF) (talk) 22:48, 7 September 2017 (UTC)
I was reading the Adder (electronics) page when one of these appeared. My thoughts were " — there's a pop-up — how did that get here — it seems to be from Wikiepdia itself — it's asking me a question, I'll try to be helpful — it says 'Would you click on this page ...' — would I ever click on a page? — why might I click on a page? —" and before I could come up with a sensible answer, it vanished again. If this is intended as a way of getting useful feedback from users, it's doomed to failure. Maproom (talk) 17:35, 8 September 2017 (UTC)
This reminds me of the Article Feedback Tool. Yuck. (((The Quixotic Potato))) (talk) 19:49, 8 September 2017 (UTC)

The pop-up box is missing an important element - the checkbox or button that says "do not show me this again (ever, on any article)". Mitch Ames (talk) 00:21, 10 September 2017 (UTC)

Personally I don't mind cooperating with it. But if it's going to ask tricky qurestions like "Would you click on this page", it ought to be polite enough to hang around until I've figured out what they mean. Maproom (talk) 19:16, 10 September 2017 (UTC)

Unexpected popup

A strange undocumented popup 2017-09-10 at 2.37.39 PM

While viewing Agarose, a box suddenly appeared in the article, asking "if someone searched for 'red seaweed' would they want to read this article?" I have been unable to find any documentation for this "feature" in Wikipedia, Wikimedia, or Google. The closest I came was an entry in phabricator. Where is the rest of the documentation? What is the extent of this project, in terms of timespan or articles. Comfr (talk) 05:25, 11 September 2017 (UTC)

There is some information at #Mysterious random popup and phab:T174106. PrimeHunter (talk) 10:33, 11 September 2017 (UTC)
I was just scrolling down the page of History of Chinese Americans#Arrival_in_the_United_States, and a pop up appeared in the upper right hand side, looking exactly like the screen shot above, except it asked a different question. Obliterated my view of the image of the man with the queue. My first thought was "malware", and then I remembered this thread. Computer users pay for security software that blocks pop ups, and Wikipedia overrides it and makes us look at popups anyway. — Maile (talk) 13:30, 17 September 2017 (UTC)
The wording can vary. I got this on Film producer: "If you searched for 'focal reducer', would this article be relevant?" PrimeHunter (talk) 13:47, 17 September 2017 (UTC)
I got one of these popups, I don't recall where, but as I recall the search term it asked about was exactly the title of the article. I also don't recall what I clicked, there was no button for "whuh?" Ivanvector (Talk/Edits) 14:40, 17 September 2017 (UTC)

Keep getting asked about search results

Every time I visit the H2S radar page, a pop-up repeatedly appears in the upper right corner of the browser window asking me if this is a suitable article if one is searching for "Lancaster operators". I answer No, trying to be helpful. Then it asks me again. And again. And again. Is this something is doing, or is this perhaps a 3rd party plugin? Anyone know what this is? Maury Markowitz (talk) 13:22, 19 September 2017 (UTC)

It's the enwiki test at #Mysterious random popup. Does it repeat if you reload the page? PrimeHunter (talk) 13:29, 19 September 2017 (UTC)
I'll check. Maury Markowitz (talk) 14:01, 19 September 2017 (UTC)
It does come back after a refresh. Maury Markowitz (talk) 14:11, 19 September 2017 (UTC)
@Maury Markowitz: there was a bug, where there was a unit conversion problem, causing the popup to think it had been 2 days since the last time it asked you, while actually it had been no more than 172 seconds.. A fix will follow. —TheDJ (talkcontribs) 16:28, 19 September 2017 (UTC)
Ok, but why does it ask more than once after I answered? And why only in that article and no others? Maury Markowitz (talk) 17:07, 19 September 2017 (UTC)
I've written a post for the Wikimedia Blog that expands a bit on the reasoning behind the test. As TheDJ pointed out, a bug means you got asked every three minutes instead of every two days. However, I don't think we have anything in place to keep it from asking you on the same article. This is an initial test of the process, so I'll add that to the possible feature list for future versions. Though you are less likely to be on the same article two days later (as opposed to 172 seconds later). As for why that article and no others, the surveys are only on a handful of articles right now, but won't ever be on every article. TJones (WMF) (talk) 18:27, 19 September 2017 (UTC)

Linking to a result in an on-line database

The GlobIZ website allows me to search for various moth taxa; for instance pasting "Agastophanes" into the search field and clicking on the link gives good information that could be used as a reference. However, that page has the same web address as the search page. Is there a way to link directly to the search result? Is there a way to archive a search result? Thanks,  SchreiberBike | ⌨  22:07, 7 September 2017 (UTC)

Normally I'd say to use their permalink feature, but they don't have a permalink feature. Probably the only option is to cite the page and add a little note saying something like "search for agastophanes to obtain specific data". Nyttend (talk) 22:40, 7 September 2017 (UTC)
You can use the at parameter at Template:Cite web#In-source locations, e.g.:
"GlobIZ search". Global Information System on Pyraloidea. Search on Agastophanes. Retrieved 7 September 2017. 
PrimeHunter (talk) 23:29, 7 September 2017 (UTC)
Thanks for the ideas. If there's any other feedback, please ping me as I'm taking this off my watchlist.  SchreiberBike | ⌨  01:54, 12 September 2017 (UTC)

API:Imageinfo returns null for &iiprop=comment

Lately, I have been getting back null for the comment value when making this (action=query&format=json&prop=imageinfo&titles=File%3AExample.jpg&iiprop=timestamp%7Cuser%7Ccomment) Imageinfo API query on File:Example.jpg. I'm expecting to see "Minor tweak to text placement; diminish image height by 1 pixel.". Could someone help confirm if this is a MediaWiki bug, or if I am doing something wrong? Thanks, FASTILY 23:34, 8 September 2017 (UTC)

That should work...I can replicate the lack of a comment every image I give it. I'm not finding anything in Phabricator about it either, you may well have stumbled onto something here. FACE WITH TEARS OF JOY [u+1F602] 02:23, 9 September 2017 (UTC)
Hi 😂. Thanks for the input; I just opened phab:T175443. Regards, FASTILY 06:00, 9 September 2017 (UTC)

Edit conflict options spoiling my edit

I just met an edit conflict. I now have to manage two columns, seven colors, twelve options, and still cannot get it. Right now, a straight F*K YOU is appropriate. -DePiep (talk) 00:38, 9 September 2017 (UTC)

What are you going on about? Edit conflict management is a lot better now. On the right is the current version of the page. On the left in yellow are your changes. I haven't had an edit conflict in a while, but I believe the changes made by the editor who caused the conflict will be highlighted blue. Amaury (talk | contribs) 00:41, 9 September 2017 (UTC)
I said: it is NOT better. I see lots of colors, dozens of options, and loads of textual 'helps'. Two columns, five text squares. Fussed texts. Texts talking about "your text" — which is invisible. -DePiep (talk) 00:46, 9 September 2017 (UTC)
It's not even a process (wizard, step-through). -DePiep (talk) 01:05, 9 September 2017 (UTC)
Wait, isn't the new edit-conflict interface opt-in-only, under beta features? I agree that the old one was plain awful, and I generally had to resort to going back in my browser to retrieve my edit manually. —Cryptic 02:52, 9 September 2017 (UTC)
Yes, it's normally opt-in (at Preferences → Beta features); but if DePiep has "Automatically enable all new beta features" set at the top of that page, it becomes opt-out - but they can't turn off individual beta features without turning off "Automatically enable all new beta features" as well. --Redrose64 🌹 (talk) 07:16, 9 September 2017 (UTC)

{{Archive box collapsible}} seems to be broken when using Google Chrome

I have the following on my Talk page:

{{Archive box collapsible |large=yes|
[[/Archive 1|2007]]&nbsp;&nbsp;&nbsp; 
[[/Archive 2|2009]]&nbsp;&nbsp;&nbsp; 
[[/Archive 3|2011]]&nbsp;&nbsp;&nbsp; 
[[/Archive 4|2012]]&nbsp;&nbsp;&nbsp; 
[[/Archive 5|2013]]&nbsp;&nbsp;&nbsp; 
[[/Archive 6|2014]]&nbsp;&nbsp;&nbsp; 
[[/Archive 7|2015]]&nbsp;&nbsp;&nbsp; 
[[/Archive 8|2016]] (Empty) &nbsp;&nbsp;&nbsp; 

When editing my page, if I choose "Preview", I get this:

  Archives [show]  

In Preview mode, the box is fully functional; clicking on "show" expands it properly. Once I save the edits, however, this is how it appears:


In both instances, the "Archives" is properly linked to Help:Archiving a talk page.

Additionally, none of the examples on the Template:Archive box collapsible/doc page display the [show] element, they are all plain boxes with Archives being the only thing showing. In short, none of the examples, nor the instance on my Talk page, are expandable. I'm using the latest version of Google Chrome (Version 61.0.3163.79 (Official Build) (64-bit)); I don't have these issues when using Firefox. Does anyone have any ideas on how to fix this? Thanks!—D'Ranged 1 | VTalk :  03:18, 9 September 2017 (UTC)

This is unlikely to be a template problem, more like a JavaScript/browser incompatibility, in which case WP:VPT is a much better venue. --Redrose64 🌹 (talk) 07:32, 9 September 2017 (UTC)
Transcluding issue here for help, please.
UPDATE: I just looked at {{Collapse}} and have the same issue. What should be expandable sections don't display the [show] button. So it's apparently something to do with the way Chrome handles that function. Thanks for any help that can be offered!—D'Ranged 1 | VTalk :  10:09, 9 September 2017 (UTC)
Works for me in Google Chrome 61.0.3163.79 on Windows 10. Try updating Chrome and restarting the computer. PrimeHunter (talk) 10:20, 9 September 2017 (UTC)
Most of the time, it means one of your userscripts/gadgets/browser extensions broke. I didn't fully look into your scripts, but at least this from User:D'Ranged_1/vector.js was causing you fatal errors on every page load. Please regularly evaluate what you use, and if it creates errors in your browser's console. See also: Help:Locating broken scripts. —TheDJ (talkcontribs) 10:37, 9 September 2017 (UTC)

Template vandalism somewhere

Hey detectives, I know that there's some template vandalism somewhere, but I'm having trouble tracking it down. I was searching for spam links to There are three articles that contain the links,

The links appear numerous times in various sidebar templates, however I don't see the links in any of those template, so I surmise they're being transcluded from somewhere else. Your help is appreciated. And if you figure it out, I'd appreciate a quick note on how you solved it. Thanks, Cyphoidbomb (talk) 23:43, 9 September 2017 (UTC)

I think I figured it out. A page purge seems to have cleared them. The offending party edited Template:Linkexist... Cyphoidbomb (talk) 23:51, 9 September 2017 (UTC)

Page with wrong latest revision

The revision as of 00:34, 24 July 2010 appears to be the latest revision in the history of User talk:Brendanmccabe/You Lucky Dog (2010 Television Film). However, if you look into the bot's 50 oldest contributions, the revision does not have "(current)" next to it. Also, if you view the 3 user talk pages created by Brendanmccabe, the creation at 18:28, 23 July 2010 has "(current)" next to it. The page's page_latest field in the database was not updated when a new revision was inserted. Finally, the edit summary says "moved", but in fact the page was not actually moved at all. Are there any other pages where the latest revision is wrong? GeoffreyT2000 (talk, contribs) 01:37, 10 September 2017 (UTC)

The bot tried to move the talk page [7] and associated non-talk page [8] to the same Wikipedia talk page. Only the non-talk page was actually moved. Articles for creation was placed in the Wikipedia talk namespace at the time because IP's could create talk pages but not other pages (the draft namespace is newer). I guess the bot was trying to move the talk page along with the draft in the non-talk page. I don't know what happens today if you select "Move associated talk page" while moving a non-talk page to a talk page. In July 2010 it apparently caused a misleading page history entry in the talk page, at last when a bot did it via the API. I don't know whether there are other cases. PrimeHunter (talk) 02:40, 10 September 2017 (UTC)
Can an administrator please fix the problem causing "page_latest" for the above user talk page to be wrong? Try running attachLatest.php on this wiki with "--regenerate-all" set to true, if possible. Otherwise, try deleting and then undeleting the page. GeoffreyT2000 (talk, contribs) 22:32, 12 September 2017 (UTC)
Is there a problem which couldn't be fixed by just making a dummy edit to the page? PrimeHunter (talk) 00:17, 14 September 2017 (UTC)

Image in the Zoey Deutsch article

I recently removed a probably copyvio image from the local Zoey Deutch (edit | talk | history | protect | delete | links | watch | logs | views) article. Checking the links of that image on Commons, I noticed that the Ukrainian version of the article has the same image, but the image is newer than the article. The image was uploaded on 3 September 2017, yet the article version on 14 March 2017 also displays the image. I also checked the infobox of the Ukranian article in edit mode and there is no image link in it. Please see uk:Зої Дойч. How can that happen? The Russian article has similar image-display characteristics. Please see ru:Дойч, Зои. Dr. K. 16:48, 10 September 2017 (UTC)

Infoboxes can be configured to automatically display an image based on a Wikidata parameter. My first guess is that is what is happening here. -- Ed (Edgar181) 18:54, 10 September 2017 (UTC)
Thank you Edgar. In that case, if the image is a copyvio it still gets to be displayed. That's a problem. Dr. K. 18:55, 10 September 2017 (UTC)
The image can be nominated for deletion at Commons and in the meantime, this edit at Wikidata could be reverted. -- Ed (Edgar181) 19:05, 10 September 2017 (UTC)

Can this 🤔🤔🤔 be prevented?

Technically, is there a simple way of preventing Emojis (or whatever these things are called) being added to articles, leaving articles looking like this ?
If so, where would I ask for such prevention to be implemented? - Arjayay (talk) 17:46, 10 September 2017 (UTC)

This could be done through the use of a rather simple edit filter. Pop over to the requests page -- There'sNoTime (to explain) 17:51, 10 September 2017 (UTC)
As mentioned above, an edit filter would work but I don't see the point, as this wouldn't stop vandalism but would stop instances of the legitimate usage of emoji in articles (which is rare but definitely happens). It would be worth adding a tag for repeating emoji, tho. ―Justin (koavf)TCM 18:03, 10 September 2017 (UTC)
Unwanted emojis in articles seems like a minor issue and not worth stopping with an edit filter, but I think emojis in edit summaries are annoying when they display as color images in watchlists, page histories, user contributions and so on. PrimeHunter (talk) 18:27, 10 September 2017 (UTC)
Since this subject came up. Emojis on signatures probably looks cute to the user ... but everytime I see it, I have a knee-jerk reaction that I'm looking at malware popping up with a devilish smile. Maybe Wikipedia should have a policy on displaying emojis, period. I know a lot of online users like these emojis, but I can't help but think Wikipedia has been infested with malware when I see it attached to signatures. — Maile (talk) 18:44, 10 September 2017 (UTC)
There are actually usernames that are emojis. Dr. K. 18:57, 10 September 2017 (UTC)
Hehehe 🙃 (more seriously, this would cause huge problems in talkpages). FACE WITH TEARS OF JOY [u+1F602] 18:54, 11 September 2017 (UTC)
There is already an edit filter for certain unicode emoji ranges added to articles. It gets about 100 hits per day. We filtered these for the same reason we filter people adding "pooop" or "fucker" to articles. No, it won't stop a determined vandal, but experience suggests that a significant fraction of childish vandals give up when a filter objects. Without checking, I would assume that whatever symbol was used isn't part of the ranges that we commonly encounter. Dragons flight (talk) 19:11, 10 September 2017 (UTC)
IMHO, on the basis of damage limitation, if a few editors have to change their fancy signatures, in order to prevent our articles looking like the output of an incontinent fruit machine, they should all be removed, not just from article space, but from all pages. - Arjayay (talk) 19:01, 11 September 2017 (UTC)

A filter for repeating emoji in content namespaces (Article, Template, Category, Module, etc.) would probably be a good idea. ―Justin (koavf)TCM 20:00, 11 September 2017 (UTC)

Watchlist fails to report new edits

My watchlist contains roughly 100 items. It's set to show the last thirty days, with nothing hidden, but for a couple of weeks it has only shown "the last 0 changes in the last 720 hours," ie nothing. The pages I watch are hardly Wikipedia's busiest, so I checked to see if, indeed, there might have been no new edits. It turns out there 'have' been new edits all along. Is there something broken, or am I doing something wrong? ARK (talk) 18:04, 10 September 2017 (UTC)

Wikipedia:Village pump (technical)/Archive 158#Watchlist changes, or if you don't want to search quite so diligently, just above at #Watchlist cuts off at 250 entries. —Cryptic 18:14, 10 September 2017 (UTC)
Changing the watchlist preferences did the trick, thanks! ARK (talk) 18:21, 11 September 2017 (UTC)

I'm about to look into an email sent to Wikimedia that refers to the following page:


It certainly looks like Wikipedia but I don't recognize ""

Can someone enlighten me?--S Philbrick(Talk) 20:36, 10 September 2017 (UTC)

"Recent changes" shows it's a live mirror of the English Wikipedia. See meta:Live mirrors. It's not made by the Wikimedia Foundation. PrimeHunter (talk) 20:53, 10 September 2017 (UTC)
I don't know what the email is about but it may apply equally to our own Randomized controlled trial. PrimeHunter (talk) 20:55, 10 September 2017 (UTC)
Thanks for both comments. I think the email does refer to our own article by the same name, but I was thrown by the URL and wanted to learn more about it before responding.--S Philbrick(Talk) 21:50, 10 September 2017 (UTC)

Not sure what to do

Hi there. I'm not sure what to do with this redirect. The article has been deleted here three time. I don't know if the redirect should be reverted or deleted. Thank you. Magnolia677 (talk) 11:20, 11 September 2017 (UTC)

The user that redirected this seems to have been doing lot of redirecting very recently ! Special:Contributions/Zawl. Maybe his account has been hijacked? This needs looking into. Aspro (talk) 17:18, 11 September 2017 (UTC)
Yes, maybe an admin should put a block on his account quick, until we find out what's happening. Aspro (talk) 17:22, 11 September 2017 (UTC)
Block PDQ. The redirects are still coming ! Aspro (talk) 17:33, 11 September 2017 (UTC)
The account was blocked, but I believe this was the incorrect course of action. Bhad Bhabie was created with substantially more sources than the deleted Danielle Bregoli (personality). Should we not have asked Zawl to explain his thought process before blocking? (he has been unblocked, for the record) 78.26 (spin me / revolutions) 18:59, 11 September 2017 (UTC)

X-Tools not working?

Is X-Tools not working for anyone else? It's not for me, and it wasn't working for me at the beginning of August, either, when I was going to update my edit stats with July on my user page. It's sitting there loading forever this time—the loading circle in the tab isn't even turning blue to indicate the page is about to display, it's just sitting in the state before that forever—but last time I think it threw an error: [9]. Amaury (talk | contribs) 17:32, 11 September 2017 (UTC)

@Amaury: I suggest using the new version (in beta). — JJMC89(T·C) 17:38, 11 September 2017 (UTC)
@Amaury: We've restarted the xtools web server process. It should be working now.
However, JJMC89 is correct in that we will be using the new version. The new version is significantly more stable. ~ Matthewrbowker Say something · What I've done 22:16, 11 September 2017 (UTC)
@Matthewrbowker: I already added it as a bookmark and removed the other one after JJMC89's reply. Face-smile.svg Thank you both! Amaury (talk | contribs) 22:24, 11 September 2017 (UTC)
Face-smile.svg Good to hear. ~ Matthewrbowker Say something · What I've done 00:16, 12 September 2017 (UTC)
I hope that the new one will still be improved before replacing the old one officially, as it only shows me the edit summaries at top (all other details currently require scripts and dynamic loading)... —PaleoNeonate – 22:50, 11 September 2017 (UTC)
"Scripts and dynamic loading" are our solution to handling very heavy database queries (it's a large part of what brought the old one down so often). Work is ongoing, see our workboard on Phabricator ~ Matthewrbowker Say something · What I've done 00:16, 12 September 2017 (UTC)
I can understand if someone doesn't trust JavaScript on the web in general, but I can assure you that XTools is safe :) Please consider whitelisting if you are having trouble. You should be seeing more than just edit summaries, though? All the data except the year/month counts, timecard and global edits are served as raw HTML. While I can't promise we can show you charts, we can make some improvements to show the underlying data to users without JavaScript support. For this I've created T175661. Best MusikAnimal talk 00:33, 12 September 2017 (UTC)

Tech News: 2017-37

19:15, 11 September 2017 (UTC)

Finding noindex tag

A reader ticket:2017090610021534 wondered why Giuseppe Mastromatteo has the code:

<meta name="robots" content="noindex,nofollow”/>

I'm not seeing it, but I also note that a Google search doesn't list this item on the first page so I'm believing it is there. Shouldn't I be able see that tag if I click on edit source?--S Philbrick(Talk) 21:26, 11 September 2017 (UTC)

It's in the html source sent to your browser, not in the wiki source. New articles are noindexed for 90 days unless they are reviewed. See Wikipedia:Controlling search engine indexing#Indexing of articles ("mainspace"). PrimeHunter (talk) 21:34, 11 September 2017 (UTC)
It'a automatic; the article was created at 17:19, 10 July 2017 so isn't old enough yet. --Redrose64 🌹 (talk) 21:36, 11 September 2017 (UTC)
Thanks. However, I thought unreviewed articles had a tag indicating that they had not yet been reviewed, [Mark this page as patrolled], is my recollection flawed?--S Philbrick(Talk) 21:54, 11 September 2017 (UTC)
I see "Curate this article" under Tools in the left pane. If I click that then I get Wikipedia:Page Curation#Curation Toolbar on the right. It includes "Mark this page as reviewed". PrimeHunter (talk) 22:10, 11 September 2017 (UTC)

This crashes the database (talk) 01:12, 12 September 2017 (UTC)

Oh now it's working. It was failing earlier. (talk) 01:22, 12 September 2017 (UTC)
I doubt that it was "crashing the database". More likely the query was simply timing out. Anomie 15:31, 12 September 2017 (UTC)
What Anomie said. There are a few actions that do have the potential to temporarily crash the database, but they're all obscure functions that are at minimum restricted to admins. ‑ Iridescent 15:55, 12 September 2017 (UTC)

Lysteria bot and shadowing

There have been previous discussions about Lysteria bot and non-free images (the most recent one was Wikipedia:Village pump (technical)/Archive 158#Listeria bot and non-free images) and an attempt to get input from the bot's operator Magnus Manske was made User talk:Magnus Manske#Non-free images being added by Lysteria bot, but the bot still continues to inappropriately add non-free images to pages such as User:Stinglehammer/Gothic writers 3 and User:Jane023/Female novelists in violation of WP:NFCC#9.

The two files it keeps adding this time are File:Stevie Smith.jpg and File:Sylvia Townsend Warner.jpg. Both of these files are/were shadowing Commons files (c:File:Stevie Smith.jpg and c:File:Sylvia Townsend Warner.jpg), but one of the Commons files has already been deleted as a copyvio and the other is nominated for deletion for the same reason. It seems that there should be some way for the bot to distinguish between a freely licensed file or a non-free file; otherwise, any time someone (perhaps in good faith) uploads a copyvio to Commons which has the same name as a local English Wikipedia file, the bot is going to add the local file by mistake.

Files shadowing other files is a problem for sure, and if simply moving the local file is the best solution, then fine; however, moving is kind of pointless when the Commons file is almost surely going to be deleted. In this case, the bot still seems to "think" that the Commons file for Sylvia Townsend still exists, and therefore keeps re-adding what it believe to be a Commons file to the two aforementioned pages. If it simply takes a few days for the bot to get this out of its system, then OK if, however, the bot is going to continue to make the same mistake in perpetuity, then something needs to be tweaked to stop this. I'm sure the bot does lots of good work, but there needs to be some way for it to "realize" to not keep re-adding files which have been removed for WP:NFCCP reasons. Perhaps there's some way to tweak the local file's page (WP:HIDDENCAT or WP:MAGIC) to let the bot know not to re-add the file? -- Marchjuly (talk) 02:08, 12 September 2017 (UTC)

It's because the link to that file wasn't removed from Wikidata yet, see this edit. —TheDJ (talkcontribs) 06:00, 12 September 2017 (UTC)
That's fine and thank you for doing that. The question is then whether the bot can subsequently remove any non-free files it mistakenly adds to pages if the file Commons file being shadowed is deleted and the Wikidata has been edited accordingly or the shadowing local file is subsequently renamed. If it can, then it can self-correct any NFCC#9 problems; if not, then maybe it should be set (if possible) to distingusih between non-free and free to avoid such problems. -- Marchjuly (talk) 07:29, 12 September 2017 (UTC)
@Marchjuly: technology can do many things, it just depends how much time you pour into it. If you are asking if it is likely that someone is going to change that specific bot to look for deletions that have been made, then I'd say no. Rather, I think this more points towards the problem that CommonsDelinker currently doesn't remove deleted files from WikiData. This so far has been a minor issue, but i've seen multiple complaints recently, that basically would have been avoided if it did have this capability. I think it is more likely that that bot is adapted and I have left some feedback in the bug system of that project. —TheDJ (talkcontribs) 08:51, 13 September 2017 (UTC)
I wasn't aware that tweaking another bot might be a way to resolve this, so thank for trying to help sort this out. -- Marchjuly (talk) 04:27, 14 September 2017 (UTC)

Place to contact Wikipedia coders for help

Hi, I was advised that this would be the forum for my request – I was wondering if there was some sort of "centralized location" where editors can place help requests for Wikipedia coders to help them out, if they are unable to do the coding themselves.

There is an issue that I and several other editors who edit articles related to music singles and albums have – the majority of those articles use the {{Single chart}} and {{Album chart}} templates which link to the websites of the chart providers in each country, in order to show the peak chart position that the single/album attained in various countries. Additionally, many articles also use {{Certification Table Entry}} (and its myriad of sub-templates) to link to the certifying body in each country to verify the gold or platinum discs a record has received, and the accompanying implied sales figures.

Because these three templates link to many different sources outside Wikipedia, they tend to be quite dynamic: the websites of chart providers and certifying bodies often get revamped and restructured, frequently leading to a lot of broken links. And because of the necessity to use the archive database of these charts, it's not always as simple as just altering the website address in the template to point to the right place.

The problem is that most of the editors who work on these articles are good at creating content, but unable to modify the templates unless it's a basic fix. And the two editors who created the templates in the first place are no longer active on Wikipedia, so we have to ask for outside help. There are a couple of coders who have very kindly been helping us out as and when they can, but it would be nice if we didn't have to pester the same people over and over again, and just place our requests at a centralized help desk staffed by coders, and whoever has some time available can say, "I'll take a look at it". Thanks for your help. Richard3120 (talk) 13:23, 12 September 2017 (UTC)

There are different types of coding. You can ask for template coding at Wikipedia:Requested templates. PrimeHunter (talk) 13:28, 12 September 2017 (UTC)

Become an English Wikipedia Technical Ambassador today!

Hello fellow wikipedians, I'm writing you as one of the active tech ambassadors for English Wikipedia to ask for help! I would like to encourage you to sign up for a role of Tech Ambassador, you can do so, here and read more on what the role consists of here. If you have any questions, feel free to email me or ask me on my talk page. Ⓩⓟⓟⓘⓧ Talk 14:23, 12 September 2017 (UTC)

Repeating table header

What is the Wikipedia way of repeating the header of a long complicated table such as ro:Păsările_Republicii_Moldova? so that the reader always knows what is the meaning of the column she/he is reading. Gikü (talk) 07:39, 13 September 2017 (UTC)

There isn't really a methodology for that. You can either repeat the header cells, or create multiple tables. —TheDJ (talkcontribs) 08:40, 13 September 2017 (UTC)
@Gikü and TheDJ: How about putting the header code into a subpage and transcluding it wherever you want it? Wouldn't that work? Please {{Ping}} me to discuss. --Thnidu (talk) 23:08, 13 September 2017 (UTC)
@Thnidu: Mainspace doesn't have subpages so it should be a template. It would work. I don't know whether it limits the ability to edit the table with VisualEditor but there should be no problems in the source editor. PrimeHunter (talk) 23:56, 13 September 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Templates are intended for multiple-page use, so a template for a single table's column-headers is likely to be deleted, although extremely useful templates for thousands of pages tend to get deleted more than hundreds of peculiar one-off templates. Also perhaps use bold-row token "!" on all header rows, to help other editors notice the column-headers are being repeated. Beware repeat headers in sort-able tables, where the extra headers are likely to sort in strange places. You really want a vertical-scroll table region with fixed stationary headers. -Wikid77 (talk) 00:14, 14 September 2017 (UTC)
  • Scroll wide tables for mobile-phone viewing: If the table might get over-wide, then also consider wrapping entire table inside an extra div-section, as an auto-scrolled table to fit smaller handheld devices, by:
  <div style="width:auto; overflow:scroll">

That div section places the entire table in a scrollable region (on narrow screens) and prevents the tabular format from squeezing the page text as tiny-font, half-screen width on some mobile phones. -Wikid77 (talk) 00:14, 14 September 2017 (UTC)

The mobile version of the websites already does this. You shouldn't do it manually. —TheDJ (talkcontribs) 10:51, 15 September 2017 (UTC)
The original post was about the Romanian Wikipedia ro:. They may have other policies or no relevant policies. Here we dislike single-use templates but I'm not sure we are against single-page templates with multiple uses on that page. PrimeHunter (talk) 00:26, 14 September 2017 (UTC)

Any problems with nested articles

I have created a nested article, "Reverse surge" which trancludes page "{{:Voltage spike}}" while adding a special top hatnote about others as "...see: Surge". However, I wonder are there problems with bottom categories, or other technical issues to beware with nested articles? -Wikid77 (talk) 22:11, 13 September 2017 (UTC)

It would create almost identical articles and we don't do this [15] at the English Wikipedia. We redirect the page per WP:PRIMARYREDIRECT, and consider placing {{Redirect}} at top of the target if the redirected term is ambiguous. {{Redirect|Reverse surge||Surge}} would produce:
Reverse surge has been redirected to Voltage spike without using {{Redirect}}. PrimeHunter (talk) 00:11, 14 September 2017 (UTC)
Whoops. Done it. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 14:39, 14 September 2017 (UTC)

Fixing abuse of list markup (talk page accessibility, etc.)

Our use of wikimarkup : "indentation" for the purposes of threaded discussions is a gross misuse of the underlying <dd>...</dd> HTML markup, which is for (and only for) the definition or explanation of a term or other entry previously given with <dt>...</dt> (; in wikimarkup). Worse yet, any time there's a blank line inserted, it breaks the surrounding <dl>...</dl> list into a separate list after the line break.

The solution to this is technical and should have been proposed and implemented years ago: convert any : indent into a CSS-indented <div>...</div> when it is not immediately preceded by a ; (or explicit <dt>...</dt>). Our talk pages should not be using <dl>...</dl> structures at all, other than for creation of actual description lists we intentionally want to be formatted as such.

While we're at it, we should also do a similar conversion on any line starting with ; (a <dt> entry), and turn it into a boldfaced div, if it is not immediately followed by : producing a <dd> entry.

Both of these should also suppress the parser's creation of surrounding <dl>...</dl> markup, without any actual <dt> or <dd> items to wrap.

These fixes would also clean up a lot of misused of description list (a.k.a. definition list, association list) markup in articles, where it's being abused for boldface and indentation of non-list material.

Similarly, a line starting with * in absence of any other contiguous line of the same sort should be converted on the fly into an indented line with a bullet, not a "list" with one item. In cases where it's actually desired to use a one-item real list (e.g. to match the formatting of longer lists in the same material), explicit <ul>...</ul> and <li>...</li> markup can be used.

I'm not sure I care whether it's fixed by the devs in the MediaWiki parser, or fixed on-site by JavaScript. The former would be better in the long run, since it would apply the fix to all installations, but the approaches aren't mutually exclusive; the latter could be used in the interim.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:13, 14 September 2017 (UTC)

Javascript would not be a good solution for this for many reasons; it sounds indeed that you want to have the mediawiki parser changed, so should bring this up at or on phab, since it would not be only for the English Wikipedia. — xaosflux Talk 02:20, 14 September 2017 (UTC)
@SMcCandlish: see requests such as phab:T6521 that appear similar. — xaosflux Talk 02:22, 14 September 2017 (UTC)
Thanks. Will look into that, and see if that's the right pressure point.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:02, 14 September 2017 (UTC)
Is this not on WP:PEREN? It should be.... FACE WITH TEARS OF JOY [u+1F602] 03:26, 14 September 2017 (UTC)
No, it shouldn't be, because it's not a subjective idea the community keeps rejecting, it's a technical glitch that needs to be fixed because it's causing problems.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:02, 14 September 2017 (UTC)
"The community/communities is/are right because they misuse wikitext"? I see. That's definitely a technical glitch. (<- yes, sarcasm). This comes up every once in a while. As I've argued before, the WMF has a replacement for the predominant use case where these elements are misused that the community has rejected. The community should lie in their mess that doesn't so-affect accessibility that Graham pitches a fit (and you know we all rely on Graham--he has previously said that he gets the gist of talk pages from context). For other uses, the correct solution, as with many other things, is to fix the wikitext. (We might reasonably create a lint error when e.g. ; is not followed by a : or another ; in a content space; I would certainly support such a solution.) -Izno (talk) 11:57, 14 September 2017 (UTC)
I note that HTML5 defines the contents of <dl> as "Zero or more groups each consisting of one or more dt elements followed by one or more dd elements, optionally intermixed with script-supporting elements." So the suggestion here that every ';' must be immediately followed by a ':' and every ':' must be immediately preceded by a ';' is overly restrictive. Anomie 14:19, 14 September 2017 (UTC)
Yeah, technically you can have two or more DTs followed by two or more DDs (e.g. British and American spellings of a term, with multiple definitions from different fields). What's required is that each group have both a DT and a DD. So, what I've suggested works if you extrapolate a little: the parser shouldn't treat a ;-starting line as a DT unless followed by a DD or another DT, nor treat a :-line as a DD unless preceded by a DT or another DD. We don't appear to have any use case for "optionally intermixed with script-supporting elements", and even if we did, there's no reason for markup so advanced it strains the limits of what MW can handle to be something that has to be supported in ;-and-: basic markup mode, rather that requiring dropping into full-on HTML mode with actual <dl><dt><dd></dd></dt></dl> markup.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:21, 19 September 2017 (UTC)

Merging infobox

I was trying to merge {{Infobox Tibetan Buddhist monastery}} with {{Infobox religious building}} but there are too many different parameters. Some of those I am stuck with include |order=, |no._of_monks=, etc. Would anyone like to help? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:01, 14 September 2017 (UTC)

So maybe you shouldn't try to merge them. The same probably is true of {{ infobox XXX church }} and {{ infobox XXX monastery}} (or whatever). What you're trying to do seems to me better done by categorization of the articles involved, and has probably already been done. --Thnidu (talk) 06:00, 14 September 2017 (UTC)
Please see the template, then you would know the result of merge discussion. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:27, 14 September 2017 (UTC)

Bot request

Is it possible to add such cleanup tasks to one f the existing bots or create a bot for such cleanups? These fill up the maintenance cat of unknown parameters unnecessarily. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:27, 14 September 2017 (UTC)

Even GA level articles has such issues. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:54, 14 September 2017 (UTC)
Try Wikipedia:Bot requests. -- GreenC 13:04, 14 September 2017 (UTC)

Improvements coming soon to Recent Changes


In short: starting on 26 September, New Filters for Edit Review (now in Beta) will become standard on Recent Changes. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked (and soon, Special:Watchlist – see below).

Based on a new design, it adds new features that ease vandalism tracking and support of newcomers:

  • Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
  • Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
  • Bookmarking to keep your favorite configurations of filters ready to be used.
  • Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.

You can know more about this project by visiting the quick tour help page.

Concerning RecentChanges

Starting on 26 September, New Filters for Edit Review will become standard on Recent Changes. We have decided to do this release because of a long and successful Beta test phase, positive feedback from various users and positive user testing.

Some features will remain as Beta features and will be added later. Learn more about those different features.

If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).

You will also be able to opt-out this change in your preferences.

Concerning Watchlists

Starting on September 19, the Beta feature will have a new option. Watchlists will have all filters available now on the Beta Recent Changes improvements.

If you have already activated the Beta feature "New filters for edit review", you have no action to take. If you haven't activated the Beta feature "New filters for edit review" and you want to try the filters on Watchlists, please go to your Beta preferences on September 19.

How to be ready

Please share this announcement!

Do you use Gadgets that change things on your RecentChanges or Watchlist pages, or have you customized them with scripts or CSS? You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.

Please ping me if you have questions.

On behalf of the Global Collaboration team, Trizek (WMF) 15:26, 14 September 2017 (UTC)

I suggest we launch the RC change as opt-in for existing users and as opt-out for new users... Otherwise I don't see this ending well. —TheDJ (talkcontribs) 15:41, 14 September 2017 (UTC)
Yep, I'm sure there will be some drama if this is opt-out for existing users. Stryn (talk) 17:02, 14 September 2017 (UTC)
Thank you for your suggestion. I'll report it to the team and we will take a decision. Trizek (WMF) (talk) 18:50, 14 September 2017 (UTC)
Trizek, I have at the moment no opposition to this release, I just have serious misgivings about your statement "If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation)." Why?
  • Why only a delay until 1 October?
  • Why does it matter if the opposition is sensible, consistent with the project, actionable, realistic feedback to oppose?
If a community (not some individuals, but e.g. a speedy RfC) decides that they don't want to have this enabled, for whatever reason, why can't you just say "fine, we'll leave it as it is for your wiki"? Considering that everyone will be able to opt-out anyway (meaning that there isn't a technical reason that after 1 October, the current system can't remain in place), it shouldn't be too hard to set this to "automatic fixed opt-out for everyone" on that wiki. I totally understand that you do not have to cater to every wish or whim of the communities, and that your team has its say in what comments, wishes, blockers are actionable and realistic and which aren't. I have in principle no problem if you would check the comments and come back with a "no can do, take it or leave it". What I don't get is why you instead say "no can do, you have to take it". This really doesn't send a "we are here for you, we want to work together" message but again the typical "we know better so leave us alone" some of us have come to expect. Fram (talk) 08:35, 15 September 2017 (UTC)
@Trizek (WMF): Fram (talk) 07:59, 19 September 2017 (UTC)

Why searching for # takes me to the main page?

Hello. I noticed that putting just the # -symbol to the search box takes me to the main page. Adding text after the # -symbol takes me to that section of the main page, say searching for <#Today's featured picture> takes me to Today's featured picture section of the main page. Adding nonsense after the # simply returns the main page. Just wondered why this happens. Voltteri (talk) 19:17, 14 September 2017 (UTC)

This is phab:T28766. See Talk:Main Page/Archive 139#Should we add "For technical reasons, .23 redirects here .5B....5D see number sign" for an old discussion about putting a hatnote on the main page. PrimeHunter (talk) 19:31, 14 September 2017 (UTC)
Interesting. Thank you for quick response. Voltteri (talk) 19:41, 14 September 2017 (UTC)

ACTRIAL beginning today

Just dropping a note to let folks know that WP:ACTRIAL is beginning today around 23:00–24:00 hours. During this experiement, non-autoconfirmed users will be redirected to Wikipedia:New user landing page whenever they follow a red link or otherwise try to create a new article. They will still be able to create new pages in all namespaces except the main article namespace. We expect this will lead to an increase in submissions to Wikipedia:Articles for creation, so any help with reviewing submissions there would be appreciated during the trial (See Wikipedia:WikiProject_Articles_for_creation/Participants). If you're interested in the research aspect of this experiement, please see meta:Research:ACTRIAL. Kaldari (talk) 19:34, 14 September 2017 (UTC)

This experiment has so many nuisances that it will probably be very hard to quantify. Due to the open nature of wikis, a conspiracy theorist could simply claim that those who want this to succeed (or fail) and know how to game the system will be able to do so.
Also, it might be prudent to avoid the same pitfall as mw:PageTriage, a one trick pony that was only deployed here for apparently the same reasons. All improvements to that extension are certainly very hard to justify because they only help this wiki (or other non-wikimedia wikis that managed to get it working). It might be prudent to deploy this tool at least to, or possibly ask one non-latin based wiki to opt-in. It could even be deployed with a less strict setting that allows users to create articles as normal, but requires them to go through the landing page first. Such a article creation tool should be a basic tool in any wiki, and may even be welcome by many wikis. Although a disclaimer that this may be removed, or that it might not get any new features or bug fixes might be reasonable before allowing any further deployments.
Deploying the tool in at least one extra wiki will provide an extra data source that would somewhat reduce the researcher bias. 21:21, 14 September 2017 (UTC) — Preceding unsigned comment added by (talk)
That precisely makes nil sense.By the way, whose logged-out version are you?Winged Blades of GodricOn leave 10:10, 15 September 2017 (UTC)
I'm very much looking forward to the results of the research. I'm sure it will be open to many interpretations, but at least we will have data. —TheDJ (talkcontribs) 10:46, 15 September 2017 (UTC)

Range contributions coming soon

I'm excited to announce that today phab:T163562 was deployed to English Wikipedia, allowing you to query for IPv4 or IPv6 ranges at Special:Contributions. It does not support wildcards, but the gadget many of you use will continue to work. The native contributions list will simply be shown below the gadget's results.

However historical data is not yet available, making this feature not-so-useful. Backfilling this data is proving to be a big challenge for a large wiki like English Wikipedia. In the meantime, new edits from IPs (since deploy time) are being stored, so if you see edits when querying for a range such as Special:Contributions/2601:401:503:62b0::/64, this is why :)

There is also a new interface message shown when you are viewing an IP range: MediaWiki:Sp-contributions-footer-anon-range (which is empty at the time of writing), as opposed to the normal MediaWiki:Sp-contributions-footer-anon message you see when viewing a single IP. One more important note is that Special:DeletedContributions does not support IP ranges -- yet!

Just wanted to give you a heads up. You can follow phab:T175105 for progress on backfilling the data. I will write back here once it is resolved. Best MusikAnimal talk 03:52, 15 September 2017 (UTC)

Excellent, thanks! Johnuniq (talk) 06:16, 15 September 2017 (UTC)

Indigenous territories of Costa Rica

Could you fix image and its description?--Kaiyr (talk) 09:02, 16 September 2017 (UTC)

@Kaiyr: Each Wikipedia language has its own templates like {{legend}}, and parameters are often different. You can usually not copy template calls directly from other languages. I have fixed it.[16] PrimeHunter (talk) 10:53, 16 September 2017 (UTC)

Wikimedia error

Just for documentation, I've gotten this several times today. However, it may not be Wikimedia. my computer is really slow and making a lot of noise. Usually after a few minutes have gone by after I turn it on all of this starting up activity ends. Something else is going on.— Vchimpanzee • talk • contributions • 16:24, 16 September 2017 (UTC)

Are you sure its a Wikimedia error? My Computer is running alright without making a lot of noise its virtually quiet. What system are you using? Have you checked for any viruses if using MS Windows? S. Little talk 16:58, 16 September 2017 (UTC)
I've had a few messages as well. Aiken D 17:08, 16 September 2017 (UTC)
I absolutely saw the words "Wikimedia error".— Vchimpanzee • talk • contributions • 17:09, 16 September 2017 (UTC)
It could be a glitch on Wikimedia's-side, though since I haven't experienced this problem have you filed a bug report with a detailed report about this? It could be related to them using a newer version of MediaWiki though I'm not sure. S. Little talk 17:51, 16 September 2017 (UTC)
It's just a "high server load" message. They'll know about it, no need for bug report. When you get this message, just use your browser's refresh feature (F5 in Firefox and Opera). You might need to do it two or three times, but don't do it too quickly. --Redrose64 🌹 (talk) 20:32, 16 September 2017 (UTC)
And in fact it doesn't necessarily mean the edit failed -- I had this happen earlier today and tried the edit a couple more times, getting the same error each time; I later found out I'd posted three copies of the same new talk page section. Mike Christie (talk - contribs - library) 22:15, 16 September 2017 (UTC)
Might be phab:T175803 but hard to say without a full error message. --AKlapper (WMF) (talk) 10:01, 18 September 2017 (UTC)
I sometimes get random errors but these are different than in this ticket. Something like the servers are too busy, please refresh. When it occurs it doesn't last long. An unrelated but more serious problem I lately get is when attempting to fix someone's broken signature, where the server worker thread appears to hang until the browser eventually reponds with a broken https connection (I get no error message from the server then, only from the browser). There might be some buggy edit filter involved... In this latter case, retrying the edit consistently reproduced the bug. —PaleoNeonate – 14:38, 18 September 2017 (UTC)
I have gotten the error message starting "Our servers are currently under maintenance or experiencing a technical problem" many times in the last days. The message is shown at Wikipedia:Wikimedia Foundation error but I also get it in other circumstances. Reloading usually works. PrimeHunter (talk) 13:49, 19 September 2017 (UTC)

Email notifications linking pages with parenthetical disambiguators broken?

I'm not sure if it's just my email provider (, but I noticed some time ago (and have largely been ignoring it) that the diffs of "this change" when someone edits a page on my watchlist that happens to include parentheses in the title are always broken, as the link cuts off mid-title; I have been getting emails saying that

  • To view this change, see
which I imagine would be really annoying if the discussion at Wikipedia:Articles for deletion/Cultural health (2nd nomination) were more active and I was receiving piles of useless emails with links to the wrong page.

Any idea why this is? Is it a project-wide problem or is it because of the specific email address at which I am receiving the notifications? Sorry if this has come up before, but I couldn't find it on a brief scan of the archives...

Hijiri 88 (やや) 22:13, 16 September 2017 (UTC)

The mail is sent as plain text saying Mail software (and other software like MediaWiki itself) will often try to convert some text strings to links, e.g. if they start with https://. It's common that they guess a link stops before certain characters like "(" and ".". MediaWiki gets this one right: Help:URL shows percent encoding which could help such software but the link becomes less human readable with encoded characters like %282nd_nomination%29 instead of (2nd_nomination). PrimeHunter (talk) 23:24, 16 September 2017 (UTC)
You can test your mail software by sending this to yourself via Special:EmailUser:
Unencoded plain text:

Encoded plain text:
Both strings are converted to correct links by my mail service. Sending it with your own mail software may invalidate the test by converting plain text to links before the mail is sent. PrimeHunter (talk) 23:41, 16 September 2017 (UTC)

Template help

Can someone add a "next" and "previous" tag (as in elections and sports templates) to the templates at General Debate of the seventy-second session of the United Nations General Assembly and Seventy-first session of the United Nations General Assembly.Lihaas (talk) 19:48, 17 September 2017 (UTC)

If you mean in the infoboxes then they currently (via redirects) use {{Infobox organization}} and {{Infobox summit meeting}}. The latter has the documented parameters follows and precedes. See 30th G8 summit for an example use. Do you mean you want an option to display it more like "← 2008" and "2016 →" at United States presidential election, 2012? {{Infobox organization}} has no next/previous parameters and they would rarely make sense so I don't think the infobox should be complicated with them. It does have predecessor/successor which make more sense for organizations but would sound wrong for General Debate of the seventy-second session of the United Nations General Assembly. PrimeHunter (talk) 22:43, 17 September 2017 (UTC)

HELP: Needs Userbox code?

HELP: Needs Userbox code?

IF Possible - At present, {{User UBX/WikiGlobalEdits}} (or "User:UBX/WikiGlobalEdits" ) on a user page (for example, see userbox below - or - in the middle right column of the "User:Drbogdan" profile) - requires that a specific UserName be manually added to the "Global Edit Counter" ( at ) - and then - the resulting edit counts needs to be manually added to the template ( for example, {{User:UBX/WikiGlobalEdits|[ 55,002]}} )

Wikipedia-logo.png This user has made over
55,002 edits on All Wikis.

QUESTION: Is there a way of performing this procedure more automatically - by adding relevant coding?

Thanking you in advance for any help with this - Enjoy! :) Drbogdan (talk) 21:00, 17 September 2017 (UTC)

You can ask for template help at Wikipedia:Requested templates. I have coded it to automatically make the link based on the page name.[17] Wikitext doesn't have access to edit counts or query results so that part can only be automated if a bot or other tool periodically stores the counts for users of the userbox. They could be stored in a central page like User:UBX/WikiGlobalEdits/counts and automatically be read from there but somebody (not me) would have to code and run the bot. It could be requested at Wikipedia:Bot requests. PrimeHunter (talk) 22:21, 17 September 2017 (UTC)
By the way, the userbox currently says "on Wikipedia" but includes all Wikimedia wikis, e.g. Commons, Wikidata and so on. PrimeHunter (talk) 22:25, 17 September 2017 (UTC)
There also exists a MediaWiki module to allow a special variable to expand to an edit count but it is not enabled and may never be (it was proposed and challenged, if I remember). There's an optional JS gadget for users to see their count (but that obviously doesn't update it for other editors). —PaleoNeonate – 22:37, 17 September 2017 (UTC)
@PrimeHunter and PaleoNeonate: Thank you *very much* for the *Excellent* comments - and suggestions - they're all *greatly* appreciated - may have to do a bit more homework with this to sort things out - in any case - Thanks again for the help - and - Enjoy! :) Drbogdan (talk) 00:19, 18 September 2017 (UTC)

Infobox font size

As a percentage of the page default, what is the font size for the body of an infobox? For verifiability, where in the code can this be seen? ―Mandruss  00:17, 18 September 2017 (UTC)

It may depend on the infobox, but the {{Infobox}} template invokes Module:Infobox which source shows a 125% default which also corresponds to the Infobox template documentation (which also shows abovestyle under its CSS section). I hope this helps, —PaleoNeonate – 00:26, 18 September 2017 (UTC)
I suspect the question was not about the heading but the fields inside the box. Infoboxes have class="infobox" which sets the size in MediaWiki:Common.css:
.infobox {
    font-size: 88%;
PrimeHunter (talk) 00:38, 18 September 2017 (UTC)
"for the body of an infobox" err, yes.Face-smile.svg Thanks, —PaleoNeonate – 00:45, 18 September 2017 (UTC)
Thanks. So, per Template:Small, which says 85%, use of {{small}} within an infobox field produces 74.8% of the page default (0.88 * 0.85), which is below the 85% minimum size specified in the last paragraph at MOS:FONTSIZE. Just wanted to be sure my head is screwed on right about that, and wanted to get the exact numbers. ―Mandruss  01:00, 18 September 2017 (UTC)
Please don't use {{small}} in an infobox; more on a recent similar case at User talk:RexxS#Small caption in infobox. --Redrose64 🌹 (talk) 07:49, 18 September 2017 (UTC)
User talk:RexxS#Small caption in infobox says 90% because it is about {{Infobox solar eclipse}} which uses Module:Solar eclipse where the default 88% is overridden with this: ["bodystyle"] = "width:25em; text-align:left; font-size:90%;",. PrimeHunter (talk) 09:12, 18 September 2017 (UTC)
Rose, I don't use {{small}} in infoboxes. I wanted to get the exact numbers to support my occasional removals of that. ―Mandruss  09:32, 18 September 2017 (UTC)

Edit view slow to load

Can anything be done about how slowly the edit view loads and, worst of all, the accompanying jumps as various elements load in succession? It happens too frequently that when I go to click something as edit view is coming up, the page shifts down slightly and I end up clicking on something else. The worst culprits seem to be the bar directly above and below the edit window: "B I ..." and "Insert – — ° ′ ″ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § ...". Thank you, -- Black Falcon (talk) 01:21, 18 September 2017 (UTC)

@Black Falcon: I don't think they can do much about the speed of how it loads, since it's dependent on how fast your computer and network connection are, but you can turn them off in the Gadgets section of preferences. Jc86035 (talk) 03:26, 18 September 2017 (UTC)
@Jc86035: I don't think it's my network connection as I can load what should be more resource-intensive pages more quickly. It started, I think, after the edit window acquired its more "modern" look—e.g. the blue "Save changes" button instead of the previous grey version. I'll tinker with my preferences to see if I can improve it. Thanks! -- Black Falcon (talk) 04:34, 18 September 2017 (UTC)
Some time ago, I made my edit page loads significantly faster by going to Preferences → Editing and turning off both "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". I also turned on "Temporarily disable the visual editor while it is in beta" (I never use VE apart from trying it in the very early days), just in case the VE javascript is still being sent through when you click "Edit source" - it certainly was at one time. --Redrose64 🌹 (talk) 08:06, 18 September 2017 (UTC)
@Black Falcon: Which of the many toolbars ? there is a long list. —TheDJ (talkcontribs) 09:18, 18 September 2017 (UTC)
I didn't realize there were so many... WikiEditor is the one. It and CharInsert are always the last elements to load. -- Black Falcon (talk) 14:29, 18 September 2017 (UTC)
@Black Falcon: Can you check your preferences for me ? I suspect you have "Show edit toolbar (requires JavaScript)" disabled... It sounds weird (and it's a bug), but if you enable that, the reflow of at least the toolbar will be less. —TheDJ (talkcontribs) 05:22, 19 September 2017 (UTC)
Thanks, Redrose64, I'll try those tips. -- Black Falcon (talk) 14:29, 18 September 2017 (UTC)

Page moves logged twice

If I move a page from name X to page Y, it is logged in the page logs of both pages. OK so far. But as a result, it is also logged twice in my personal contributions list :: is this duplication needed? Anthony Appleyard (talk) 05:54, 18 September 2017 (UTC)

Yes. You can't have an action in a page history without it also being an action performed by an individual, and vice versa. Two on one means two on the other; it's like double entry bookkeeping - "for every credit there must be a debit". --Redrose64 🌹 (talk) 07:51, 18 September 2017 (UTC)
It may often look redundant in the main user contributions page but it can be filtered by namespace, one of the pages might be deleted so contributions are removed, and so on. PrimeHunter (talk) 09:26, 18 September 2017 (UTC)

Tech News: 2017-38

15:31, 18 September 2017 (UTC)

Commons category not working - links to main page

I have added a commons category template in Sveti Đurađ monastery. Hovering over the created link with my mouse pointer, it links to [21] which seems OK and works fine, when i copypaste the link and use it directly in my browser (in the URL edit field in Firefox). However, when I click the link in the article itself, it leads to [22]. Maybe some kind of conversion problem with the special character in the name or a problem within the template? GermanJoe (talk) 12:47, 19 September 2017 (UTC)

It works for me. The Firefox addon NoScript has done things like this as part of a defense against cross-site scripting in url's.[23] I haven't seen reports for a long time but see Wikipedia:Village pump (technical)/Archive 140#Redirect to Commons on one issue if you have NoScript. PrimeHunter (talk) 13:18, 19 September 2017 (UTC)
Thanks for the tip. Yes, it seems to be the same NoScript problem with parentheses and/or coded characters - disabling NoScript (for a second only) "fixed" the issue (for a second). Oh well, just have to remember it the next time not to bug you again :). GermanJoe (talk) 15:00, 19 September 2017 (UTC)

My Sandbox changed by other editors

Are other editors normally permitted to make changes and deletions in my Sandbox? (cf: User:Dthomsen8/sandbox/Streets/Cherry: Revision history)--Dthomsen8 (talk) 12:49, 19 September 2017 (UTC)

Depends on what the changes are really. Sandbox pages shouldn't appear in categories (unless for short term testing purposes), or contain BLP violations or personal attacks. If the sandbox is intended as a draft/collaborative space, they could also do some copy-editing. I don't consider the redirect as something productive. If the sandbox was derelict (or forbidden per WP:WEBHOST or something), blanking would be more appropriate. Headbomb {t · c · p · b} 13:09, 19 September 2017 (UTC)
Or copyright violations, these aren't allowed anywhere. Doug Weller talk 13:16, 19 September 2017 (UTC)
It looks like you copied from the sandbox to the article and not the opposite way but see Wikipedia:User pages#Content copied from mainspace. PrimeHunter (talk) 13:26, 19 September 2017 (UTC)
True, I did, but my concern was that I created the Cherry Street (Philadelphia) article in April, 2015, and liked to have that availabe. In that case, I see that there is a complete history, unlike some other Philadelphhia streets, which were deleted, and returned to me by an Administrator in my Sandbox.--Dthomsen8 (talk) 23:11, 19 September 2017 (UTC)

Email confirmation never arrives "Hotmail"

I asked on the admin boards, they mentioned someone here might help as this has happened in the past with certain email providers. Yes I've checked my spam folder, and requested it be sent several times from here. No luck. Double checked there is no misspelling of the email address and revisited my email preferences. Anything else I should be doing to verify my email address? TIA Peniole (talk) 13:50, 19 September 2017 (UTC)

Is it related to Outlook's other current problems? BBC News - Microsoft confirms Outlook issues ? Cabayi (talk) 13:55, 19 September 2017 (UTC)
See Help:Email confirmation for general help. You can try another mail provider or just live without Wikipedia mail. It isn't required and most users rarely or never use it (but be sure not to forget your password). PrimeHunter (talk) 14:13, 19 September 2017 (UTC)

My watchlist changed: Can't tell which pages are unread

So none of my pages that have changed since I last visited it are being bolded anymore. I highly rely on that. What happened to it?—CYBERPOWER (Chat) 17:11, 19 September 2017 (UTC)

  • +1 - As stated at Help Talk:Watchlist the new watchlist takes a good 10 seconds to load after every refresh (The previous took a second if that),
The other issue I have is that if I go to refresh the watchlist and then go on another tab - the watchlist won't load in the background - I have to physically be on the page for it to load,
IMHO this should be reverted back until the issues can be fixed, Thanks, –Davey2010Talk 18:07, 19 September 2017 (UTC)
@Cyberpower678: @Davey2010: Do you have the "New Filters for Edit Review" beta feature enabled? We changed that beta feature today so that it now puts the new filters on the watchlist as well. If you have the beta feature enabled, please try if disabling it fixes your issues. The styling of unread pages on the watchlist has a number of gadgets and other user/community-maintained things interfering with it. I updated the ones that we know about (e.g.), but maybe you're using something that we didn't know about and didn't update. --Roan Kattouw (WMF) (talk) 19:05, 19 September 2017 (UTC)
Roan Kattouw (WMF) you're a life saver! - I disabled that and it's gone back to the old watchlist, I had no idea New Filters was even enabled but yeah that seems to have been the cause for me, Thanks, –Davey2010Talk 19:11, 19 September 2017 (UTC)
@Davey2010: Well, we should still fix it :) . I think I found the culprit: your user CSS has a line (the last one, with line-watched) that unbolds changed lines. With the new Watchlist UI disabled, the gadget to bold such lines (which you've probably also enabled) wins out over that, but with the new UI enabled it doesn't. Since you seem to want to have bolding, you may want to remove the line in your user CSS that disables bolding. Cyberpower678 has something similar in their global CSS on meta (.mw-special-Watchlist .mw-changeslist-line-watched .mw-title { font-weight: normal; [...] }). --Roan Kattouw (WMF) (talk) 19:19, 19 September 2017 (UTC)
Roan Kattouw (WMF) - I've blanked the CSS and re-enabled New Filters - It took 8 seconds to load so still not overly quick, Also it's now bolded my watchlist which I disliked - Doesn't ever bother me at Commons or at Simple but does here, Anyway the loading time for me is 2 seconds quicker so not really a great improvement, Thanks — Preceding unsigned comment added by Davey2010 (talkcontribs) 19:33, 19 September 2017 (UTC)
  • @Roan Kattouw (WMF): Sorry, but I have all beta features disabled. Something else must have changed. I'd really like to get this function back.—CYBERPOWER (Around) 22:43, 19 September 2017 (UTC)
    The performance on this feature is intolerable. I, too, lost my bolding (which was added in my vector.css file). I just want the bolding back. I don't want the giant widgets, nor do I want the insane load time.Jorm (talk) 00:14, 20 September 2017 (UTC)
    Fixed it: .mw-changeslist-line-watched .mw-changeslist-line-inner { font-weight:bold !important; }
    You have to put "!important" on it now, I guess. Ugh.--Jorm (talk) 00:22, 20 September 2017 (UTC)
    @Jorm: Bolding should work in the beta feature without doing anything special; if it doesn't, that's a bug, or you have user CSS somewhere that overrides it. If you do not have the beta feature, English Wikipedia's confusing stack of gadgets means you have to explicitly enable a gadget to get the bolding, but it was like that before the release too.
    The load time issue is known and tracked at phab:T176250, we've got some patches in review for it already. --Roan Kattouw (WMF) (talk) 02:06, 20 September 2017 (UTC)
    @Cyberpower678: I was confused about what was going on in your case, but my teammate MFlaschen (WMF) figured it out. You have CSS in your global CSS on meta that puts the bold in (I was confused because it looks like it removes it, which it does, but then it puts it back a few lines later). That CSS doesn't work any more because of a change in enwiki's WatchlistBase gadget (the gadget that removes the bolding for everyone except people who choose to have it). There are two ways to fix this:
    1. Enable the WatchlistChangesBold gadget (Preferences -> Gadgets -> "Display pages on your watchlist that have changed since your last visit in bold"); or
    2. Change your global CSS from .mw-special-Watchlist .mw-changeslist-line-watched .mw-title { to .mw-changeslist-line-watched .mw-title {
    Jorm, you may have the same problem (and the same solutions) if you were using user CSS to put the bold in, rather than the gadget that English Wikipedia provides for that purpose. --Roan Kattouw (WMF) (talk) 02:19, 20 September 2017 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (technical)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA