Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 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.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See bug 1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For server or network status, please see Wikimedia Metrics.
« Archives, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176

Contents


Is there a way to force a purge of PAGESINCATEGORY ?[edit]

{{PAGESINCATEGORY:Articles with redirect hatnotes needing review|pages}} is showing a higher count (8) than the actual number of pages in the category. Is there a way to force a purge of this counter to get it synched with the actual count again? wbm1058 (talk) 18:56, 9 October 2019 (UTC)

Pretty sure there are archived threads on this, also phab tickets. It's why the word "approximately" was added to the message "The following 200 pages are in this category, out of approximately 9,999 total". In short: it's a bug, they know, they've not fixed it yet. --Redrose64 🌹 (talk) 19:20, 9 October 2019 (UTC)
Oh, I see: Wikipedia:Village pump (technical)/Archive 46 § Incorrect counts from PAGESINCATEGORY function. (September 2008) – wbm1058 (talk) 19:42, 9 October 2019 (UTC)
But T15683, {{PAGESINCATEGORY}} sometimes returns a negative number, was closed in May 2008 after r34870, "if the number of pages (or subcats or media files) is negative on initialization, we just do a recount."
More recently, T16237, PAGESINCATEGORY should differentiate between pages and subcategories, was closed in 2012 after this update.
Added PAGESINCATEGORY: magic word in April 2008.
My phabricator search isn't finding any open bug report for the issue reported on Village Pump in September 2008. Is it possible that a formal bug report was never submitted for this? wbm1058 (talk) 11:26, 10 October 2019 (UTC)
@Wbm1058: to your specific question, it looks like phab:T85696, for the general problem it appears to have all rolled up in to phab:T221795. — xaosflux Talk 11:43, 10 October 2019 (UTC)
So, having been annoyed by this for over a month, and losing my patience in waiting for a better fix, I tried deleting and restoring the category, and, voila, the count was refreshed to the correct number! wbm1058 (talk) 02:48, 18 October 2019 (UTC)

Preserving my anonymity when not logged in[edit]

I have a question about how best to preserve my anonymity when not logged in. I have one solution in mind that would require IA help. But before I try WP:IANB, I thought I'd air the issue here first, to see if there may be a better/easier solution.

My goal is to avoid inavertently making changes when when not logged in, so I don't out my IP if I save something with a recognizable pattern. I imagine that one approach, is to somehow warn myself before hitting "Publish". I've taken a sort of mirror-image approach to this, via a change to my common.css, which turns my "Publish" button green when logged in, as suggested at the Help Desk in 2012. This doesn't warn me when I'm not logged in, but it (hopefully) will get me used to a green Publish button, so that when I'm not logged in and don't see it, my spidey sense will tingle. Only, I have a crappy spidey sense, so I don't think that will work. (At that same discussion, someone pointed to a "MediaWiki: Prevent anon editing script" that apparently works with Firefox—not my habitual browser—but in any case, that link is now dead.)

The idea I had for the solution, is to copy the code I have in my common.css, to [[User:<my-actual-ip-address>/common.css]], and change the color of the Publish button to red (and maybe also add a CSS ::before selector to generate added text "Are you sure?" right before the button as well). So, I was going to request an IA to add the common.css for me (after passing the IP via email, and checking with a CU, if necessary, to verify it's me). But that's rather costly in limited human resources, and it occurs to me that there might be an easier or better way. Is there? Mathglot (talk) 01:16, 10 October 2019 (UTC)

Not an answer to your specific question, but you might be interested in m:IP Editing: Privacy Enhancement and Abuse Mitigation. -- RoySmith (talk) 01:21, 10 October 2019 (UTC)
Being able to run scripts for the next user of any IP address you use would be a disaster waiting to happen. For this reason you need to be logged in to run customisations in your userspace on Wikipedia. The solution would be to host the CSS in your browser - there are probably many extensions/plugins/browsers capable of doing that. I personally use the green button thing, as well as some other UI changes when I'm logged in, and I find it actually kinda works. -- zzuuzz (talk) 01:22, 10 October 2019 (UTC)
This. Assuming you usually use the same browser, you can do tons of stuff, the page source has information such as the logged in user information - if it is not there you could just remove the button with local javascript. — xaosflux Talk 01:36, 10 October 2019 (UTC)
Custom JS and CSS are loaded only for logged-in editors. Any code in the js/css subpage of an IP address won't work. The solution to your problem, as mentioned above, is to deploy custom JS/CSS through your browser. SD0001 (talk) 07:01, 10 October 2019 (UTC)
@Mathglot: Your mirror-image approach is the "right" way to do this. It's what I do and while it might take a little bit, once you adjust, seeing a different color will be quite jarring. There are other things you can tweak too, for an even greater difference, and that's not even counting using a different skin or noticing your gadgets aren't loading. ~ Amory (utc) 09:56, 10 October 2019 (UTC)
The dead script link is mirrored at https://userscripts-mirror.org/scripts/show/7209 with source code at https://userscripts-mirror.org/scripts/review/7209. You can ask for help at Wikipedia:Reference desk/Computing if you name your browser. PrimeHunter (talk) 12:10, 10 October 2019 (UTC)

The only good thing about them changing the default skin from monobook to vector is that I immediately notice when I'm not logged in. ―cobaltcigs 06:56, 18 October 2019 (UTC)

Template "Whos Who" not working[edit]

Template:Who's Who has stopped generating the correct links, at least when the type = was is selected, returning a 404 error. DuncanHill (talk) 20:25, 10 October 2019 (UTC)

I have fixed it by simply ignoring type = was.[1] I couldn't make any save of the template, not even a null edit, until I removed transclusion of the documentation. All attempts failed with "Syntax error in JSON (help)". I never learned TemplateData syntax so I'm not trying to fix Template:Who's Who/doc. PrimeHunter (talk) 22:22, 10 October 2019 (UTC)
Thanks, the template hadn't been changed since it was working. DuncanHill (talk) 22:32, 10 October 2019 (UTC)
TemplateData needs to be in valid JSON format. When there are single braces { ... } these indicate an object, which is a comma-separated list of zero or more name:value pairs; there should not be a comma after the last pair. This edit by Snaevar (talk · contribs) fixed it. --Redrose64 🌹 (talk) 22:49, 10 October 2019 (UTC)
Yeah, that's a wonderful trap awaiting template editors: "Syntax error in JSON" when trying to edit a template, and the JSON programming code is in the (unprotected) documentation. I dropped a note at a MediaWiki talk page, but it might be worth a phab bug report. – Jonesey95 (talk) 23:02, 10 October 2019 (UTC)
Based on a search "Syntax error in JSON" intitle:doc we have at least 68 such traps lying around. I was unable to save a null edit on any of the tested corresponding templates, e.g. Template:Douban/doc. Maybe we should add a tracking category to MediaWiki:Templatedata-invalid-parse. PrimeHunter (talk) 00:57, 11 October 2019 (UTC)
AFAICT, the problem here is explained in T214984, which basically says that the old parser, HHVM, used to (mistakenly) allow saving of some buggy JSON, and the new parser, PHP7, does not. I think this means that if you try to edit a buggy page, the new parser will complain. The solution, I think, is to edit the /doc subtemplate, copy and paste the TemplateData code into JSONlint, fix it, and paste it back into the /doc subtemplate. Then you'll be able to edit the template. There may be a simpler way, and what I know about all of this couldn't fill a thimble, so feel free to correct/strikeout/trout anything I got wrong.
And yes, please add a tracking category that will appear in the list at Special:TrackingCategories. Thanks. – Jonesey95 (talk) 02:06, 11 October 2019 (UTC)
Special:TrackingCategories lists tracking categories which are part of MediaWiki itself. A wiki cannot add new categories there. We can make subcategories like Category:Templates with TemplateData errors in Category:Wikipedia template cleanup or the large Category:Tracking categories. But it appears that HHVM use is ending and Rchard2scout has already fixed most doc pages in my search so maybe there will soon be no need for tracking this issue. PrimeHunter (talk) 09:38, 11 October 2019 (UTC)
Yeah, I saw this discussion, and thought I'd just clean it all up. Sometimes a bit of honest gnoming is the easiest solution. Most of them were commas after last items (which aren't allowed, which I think is a stupid requirement of the JSON standard), and some newlines which had to be converted to \n. PrimeHunter's search now turns up zero results, and I expect in the future it will be practically impossible to make new mistakes, given almost everyone is probably being moved over to the new editors/parsers. rchard2scout (talk) 10:07, 11 October 2019 (UTC)
I have linked Category:Tracking categories in MediaWiki:Trackingcategories-summary which is displayed at top of Special:TrackingCategories. PrimeHunter (talk) 09:49, 11 October 2019 (UTC)

Problem using JSON with <mapframe>[edit]

There is a problem using json data with <mapframe>, which now generates the error "<mapframe>: Couldn't parse JSON: Control character error, possibly incorrectly encoded". It seems to be a change in how control characters are handled. I fixed the map at List of state highways in Kerala by replacing linefeeds with "\n" (this edit). This is unsatisfactory as it makes it very difficult to understand the query. Any ideas what changed and how to fix it or where to report it?   Jts1882 | talk  09:21, 12 October 2019 (UTC)

@Jts1882: This is related to #Template "Whos Who" not working above. --Redrose64 🌹 (talk) 12:50, 12 October 2019 (UTC)
Ah, T214984 mentioned above explains the problem. This change to the JSON parsing affects a large number of pages using JSON data with maps. Is it possible that there could be a general fix through <mapframe> or will all the pages have to be fixed individually? I'm thinking it will have to be the latter.   Jts1882 | talk  13:17, 12 October 2019 (UTC)
It looks like there are roughly 86 of these in article and template space. – Jonesey95 (talk) 14:23, 12 October 2019 (UTC)
Here's one way to fix the problem, but Jts1882 is correct that it makes the query a lot less easy to read. Is there a better way? Wikicode can use HTML comments to format long lines to make them more readable; I don't know if there is a way in JSON to achieve a similar effect. – Jonesey95 (talk) 14:50, 12 October 2019 (UTC)
JSON doesn't have comments. 77 of those 86 may be sorted by fixing Template:Kerala State Highways Network. --Redrose64 🌹 (talk) 15:26, 12 October 2019 (UTC)
I've fixed that one with "\n" additions, but it doesn't clear 77 instances. A number of them use map data pages such as Wikipedia:Map data/Australian LGAs/Tasmania/Central Highlands and have additional linefeeds at the beginning and end, plus a comma at the end. I've fixed some of them.   Jts1882 | talk  17:07, 12 October 2019 (UTC)

───────────────────────── Side note: There's some explanation about JSON in templates at mw:Topic:V6u2mpy11qiu9705, if anyone wants background information. Whatamidoing (WMF) (talk) 20:59, 18 October 2019 (UTC)

Page file size graph[edit]

Is there a tool that graphs the change to a page's file size over time? ―Mandruss  21:35, 10 October 2019 (UTC)

Rough draft user script here: User:Cobaltcigs/HistoryGraph.js
  • Example output: screenshot
  • Activate by calling AddGraphLink(); function after pageload.
  • Adds a link called "Show graph" (see cursor arrow location) to action=history pages.
  • Depicts (in a popup div) whatever series of revisions is currently visible on said history page.
  • Has, therefore, a hard maximum of 5000.
  • Requires a browser capable of rendering an <svg> element defined within the html document. I don't have a list of these, but I'm guessing that means not Internet Explorer.
cobaltcigs 10:12, 11 October 2019 (UTC)
@Cobaltcigs: Thanks for the effort! I don't know how to get more than 500 on a history page. Even if I did, 5,000 wouldn't be enough for my immediate need, which is to show fluctuation over a period of several years at a high-activity article. ―Mandruss  17:13, 11 October 2019 (UTC)
@Mandruss: There is also a chart showing yearly granularity at https://xtools.wmflabs.org/articleinfo. E.g. see the orange line at [2]. MusikAnimal talk 17:26, 11 October 2019 (UTC)
@MusikAnimal: Thanks. That looks like what is available via the "Page statistics" link on the history page. I need at least month granularity. ―Mandruss  17:41, 11 October 2019 (UTC)
@Mandruss: A history page typically shows 50 revisions, but can show anything from 1 to 5,000 revisions (if they exist). The links for 20, 50, 100, 250, 500 are merely samples of what's possible - to show any other amount, click any of those links (20 is best because the subsequent fetch and display is quickest), then go to your browser's address bar where you should find that the right-hand end of the displayed URL now looks something like this: &offset=&limit=20&action=history. Alter the value following limit= to any positive integer between 1 and 5000 inclusive and then press ↵ Enter. When doing this, make sure that you don't remove any ampersands by mistake; and don't use a comma in values 1000 up. --Redrose64 🌹 (talk) 20:58, 11 October 2019 (UTC)
Thanks, I'll try to remember that. It may come in handy, but as I said above it's no help in this case. ―Mandruss  21:00, 11 October 2019 (UTC)
@Cobaltcigs: Upon reflection, I guess I could make do with multiple 5000-revision graphs. The real problem is that (I'm guessing here) your X axis is scaled to revisions instead of time; i.e., the X-distance between consecutive revisions is the same whether they are a minute or a day apart. I'd need that fixed at a minimum, and it would then be extremely useful to have single-letter month labels on the X axis (JFMAMJJASONDJFMAMJJASOND...), with the year shown vertically below the J for each January (or horizontally below each JFMA). If any of this is more than you feel like taking on, I completely understand. ―Mandruss  21:52, 11 October 2019 (UTC)

So I'm re-learning how to use the API, which would allow getting the entire history through several incremental requests (to wit, 500 per). Above assumption is correct and the timestamps are not currently even looked at. Parsing these and converting to a floating point number is trivial. The hard part is deciding how to handle the inherent problem of scaling by time, which is that the ratio of revisions to amount of time represented by a pixel of screen width (let's call that, roughly, "edits per day") will vary drastically from one page to the next, or even between different eras of the same page. Depending on density, the graph's general appearance could vary from sand dunes, to a liar's polygraph, to calligraphy. So some sampling/averaging strategy might be needed to reduce noise (i.e. avoid trying to show several size values at the same x position). An onscreen interface to tweak the settings of same might also be helpful. ―cobaltcigs 13:11, 12 October 2019 (UTC)

@Cobaltcigs: My strategy, were I working on the platform where I have competence, would be to plot the file sizes at 12:01 am on the first day of each month (UTC). You'll rarely have a revision at that time, but that file size will be shown in the last revision before that time. In other words you're not plotting all revisions, but only one per month – so density is not a factor. ―Mandruss  19:44, 12 October 2019 (UTC)
Assuming the risk that any given page had blanking or crapflooding vandalism at the end of one month (that went unreverted until the beginning of the next month) is low enough to be acceptable, then yes, that would be easier. ―cobaltcigs 07:23, 14 October 2019 (UTC)
That would be ok with me. So you think you can do this? Any time frame? ―Mandruss  14:08, 14 October 2019 (UTC)
Alternatively, you could plot the average size for each month. You decide which is better, I'm ambivalent. ―Mandruss  15:08, 14 October 2019 (UTC)

Update:

  • Screenshot
  • Singly grabs last revision before YYYY-MM-01T00:00:00Z of every month, from the API.
  • No longer connected to the history tab, is now a separate tab with its own "fake" action.
  • Takes about 10 seconds per year on my system.
  • Expands off the right side of the screen when graphing older pages.
  • Has month/year labels, positioning of which is a bit dodgy. Added longer vertical line to January for clarity.

cobaltcigs 10:27, 16 October 2019 (UTC)

@Cobaltcigs: That looks pretty good. How about some extra guidance on installation and, if not self-explanatory, usage. ―Mandruss  06:37, 17 October 2019 (UTC)
So you should be able to importScript('User:Cobaltcigs/HistoryGraph.js');, then see a "graph" tab, right after the history tab of any page that has an edit history (i.e. neither a "Special:" page nor a red link). See red arrow in same-as-above screenshot (which uses "monobook" skin).
Note: Based on suspicion that you may instead be using the "vector" skin, I tested it there too. To my surprise it seems to function the same, except the "graph" link becomes hidden in a drop-down menu under a tab titled "More" rather than appearing as a separate tab. I have no idea why that is, or how to correct it. (I also noticed the "move" link is hidden in the same place, which seems like it would suck—glad I don't use vector.) All other skins remain untested at this time.
In any case after you find this link and click on it, navigating to a url with the fake &action=graph, the content area should begin populating with a list of timestamps to show API loading progress. This may take a few minutes on very old pages. After loading these, the fully rendered graph should appear in the same place. You may then have to scroll to the right to see the whole thing.
Note: I'm not aware of any way to activate rsvg on the server side to produce a PNG thumbnail from an arbitrary string of SVG/XML text (or from anything not uploaded in the File: namespace). Also (at least in my browser) right-clicking on the graph (an embedded SVG element) does not offer a "Save as..." option to download the SVG. So if that's what you actually want to do, it may require adding a "download" button using one of these techniques (which doesn't seem very difficult).
cobaltcigs 07:46, 17 October 2019 (UTC)
@Cobaltcigs: Presently in vector, the menu does appear after the History button if you've a wide-enough monitor, but it looks oddly disfigured. You should use the code mw.util.addPortletLink('p-cactions', `/w/index.php?title=${wgPageName}&action=graph`, 'Graph', 'ca-graph') to place the menu button. Apart from being a one-liner rather than 10 lines, this will also correctly place the menu across all skins (which is inside the "more" dropdown for vector - i think that's ok as vector users are used to seeing custom script buttons in the more dropdown).
Also it looks like the script sending the api calls only after the previous one's response has been received, rather than send them parallely, making it quite slow for articles with long histories (eg. try it on the article History). SD0001 (talk) 08:32, 17 October 2019 (UTC)
Thank you for the feedback. I'll go ahead and use the addPortletLink function which I was unaware of.
As for the API requests, I did it that way to ensure they're all received and pushed into the array in a predictable order. If they're all sent at the same time, I'd probably have to switch to some key-value mapping like sz[`${yyyy}-${mm}`] = parseInt(ms[1]); (which I know how to do), then convert this object into an array of sizes sorted by said YYYY-MM keys (which I also how to do), but only do this after determining that the last response is complete (which I really don't know how to do in a parallel-thread situation).
Also the number of months to go back is not known in advance. It only quits after finding a beginning-of-month timestamp with zero preceding edits. I suppose I could try looking forward from an impossibly early (pre-Wikipedia) timestamp to determine first edit date, then simultaneously fetch 1 edit backward from the first of every month between that date and the present. Seems like that approach would reveal an expected key/value count (of the object above) to determine completion of the last request. But from what code in what thread? Should it just keep checking back at an arbitrary setInterval()?
cobaltcigs 09:08, 17 October 2019 (UTC)
@Cobaltcigs: Ok, it's working. Yes, I'm Vector skin. AFAIK that's still the default skin so it's going to be the most commonly used by far. I'm happy with Vector.
I do need a way to capture the graph so I can share it in a discussion. For my immediate purpose I can just take a screenshot of the right end of the graph, showing May 2014 through present. Whether that will be adequate for future needs by me and others, I don't know. I don't care to attempt one of those techniques that don't seem very difficult (to you).
That means the Y axis is not on screen, so it would be great to have it repeated on the right side. ―Mandruss  09:30, 17 October 2019 (UTC)

I've added the download button. SVG file should appear in your browser's download folder with a title like HistoryGraph-${wgPageName}.svg. Converting to other formats is left as an exercise. GIMP is recommendable. ―cobaltcigs 10:14, 17 October 2019 (UTC)

Missing section edit links[edit]

Why don't I see any section edit links at Template:Talk archive navigation/doc? As a control case, page Template:Talk header/doc appears with section edit links as expected. Possibly relevant:

Looking at the page source for section Usage in each case, I see this:

<h3><span class="mw-headline" id="Usage">Usage</span></h3>

and

<h2><span class="mw-headline" id="Usage">Usage</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Template:Talk_header/doc&action=edit&section=1" title="Edit section: Usage">edit</a><span class="mw-editsection-bracket">]</span></span></h2>

respectively. Is this because someone went straight to H3, skipping level 2 headers in the doc? Why should that suppress edit links, even if it is an unrecommended habit per MOS:SECTIONS? Mathglot (talk) 22:38, 12 October 2019 (UTC)

@Mathglot: Template:Talk archive navigation/doc transcludes {{Talk archive navigation}} in the "Optional parameters" section. That template adds a __NOEDITSECTION__, presumably to discourage inexperienced editors from replying to archived messages. Suffusion of Yellow (talk) 22:44, 12 October 2019 (UTC)
To amplify: heading levels (n.b. not header levels) have nothing to do with it. In the rare cases that a page has no section edit links and nothing is using or transcluding __NOEDITSECTION__, it usually comes down to bad Wikimarkup - such as a pair of opening braces that are not followed by a valid template name, and are also not balanced until much later in the page. --Redrose64 🌹 (talk) 23:24, 12 October 2019 (UTC)
Thanks, @Suffusion of Yellow and Redrose64: In that case, shouldn't the __NOEDITSECTION__ be enclosed inside <includeonly>...</includeonly>? Mathglot (talk) 23:58, 12 October 2019 (UTC)
That wouldn't matter. The template is transcluded in the documentation so it would still run code in <includeonly>...</includeonly>. There are other ways to avoid activating __NOEDITSECTION__ but it's hardly worth it for a single doc page. PrimeHunter (talk) 00:06, 13 October 2019 (UTC)
K, thanks. This page just stuck out, because I hadn't seen that behavior before. Am willing to let it drop here. Thanks again, for all the responses! Mathglot (talk) 00:14, 13 October 2019 (UTC)

Final thought: kind of unrelated—I think—but since we're all here: shouldn't all those H3 headings at Template:Talk archive navigation/doc be H2's instead? Mathglot (talk) 20:48, 13 October 2019 (UTC)

Some of them, yes. --Redrose64 🌹 (talk) 21:49, 13 October 2019 (UTC)
I'm also missing section edit links on Portal talk:Australia; there may be a transcluded __NOEDITSECTION__ but it's not obvious. Certes (talk) 10:58, 17 October 2019 (UTC)
I found the right place with Special:ExpandTemplates and removed __NOEDITSECTION__ from the output with {{replace}}.[3] PrimeHunter (talk) 11:25, 17 October 2019 (UTC)

Why are unpatrolled Wikidata changes rendered immediately at Wikipedia?[edit]

There is currently a discussion going on at Wikidata that folks here may be interested in commenting on. In brief: a vandal's change to the "description" field at the Wikidata Gay (Q592) item showed up immediately as the "short description" at the top of Wikipedia's Gay article.

Although it affects Wikipedia, the locus of the problem appears to be Wikidata, so the discussion is being hosted there. Your feedback would be appreciated at WD:CHAT. Thanks, Mathglot (talk) 01:15, 13 October 2019 (UTC)

It's for precisely this sort of problem that we've gone to the trouble of setting up WP:WikiProject Short descriptions and are working on supplying 2 million articles with local short descriptions. The locus of this particular problem is not at Wikidata. It's at Gay where someone on a mission decided to remove the local short description "Term for person with same-gender attraction" and left the article open to display vandalism from Wikidata, which inevitably happened soon after. --RexxS (talk) 02:56, 13 October 2019 (UTC)
RexxS, If that is truly the reason that the WikiProject was set up, then I have to say I am stunned. It sounds like you are saying, "Since Wikidata can't be trusted, we're creating millions of entries on Wikipedia in order to override it." Or am I misreading you? I had assumed that the reason for WP:WPSHORTDESC was to supply descriptions until Wikidata, which is a smaller group, could catch up. Was I wrong about that?
Secondly, I can assure you that the editor who removed the local short description at Gay is not "someone with a mission", and certainly did not remove the value in order to leave the article open to vandalism, but to allow it to default to a value judged better at the time. User:Crossroads is a respected editor who is HERE for no other reason than to improve the encyclopedia, as evidenced by his numerous improvements at articles and his cogent and informed reasoning at Talk pages.
As far as where the locus of the problem resides, if our trust level of Wikidata is such that we are overriding its data through great effort at Wikipedia, that means the problem resides with Wikidata, especially if it's true that fields are "inevitably" vandalized there. The fact that we are fixing the problem here, is equivalent to stopping the importation of faulty car parts from a bad supplier; we may have fixed it, but the problem is not on our side. If this is what's happening here, then one solution would be to shut down importation of Wikidata short description until it is judged to be reliable enough. Are we to the point where that is a discussion that needs to be aired? Mathglot (talk) 18:24, 13 October 2019 (UTC) updated to redact double quotes (even though the strike is too low); by Mathglot (talk) 20:37, 13 October 2019 (UTC)
The WikiProject was created after the close of Wikipedia:Village_pump_(proposals)/Archive_145#RfC:_Populating_article_descriptions_magic_word. There is already a consensus to eventually shut down the use of Wikidata for short descriptions, but the WMF won't allow it until there are enough local short descriptions. Galobtter (pingó mió) 18:48, 13 October 2019 (UTC)
@Mathglot: No, what I'm saying is that "Since the description field on Wikidata has no means of being sourced, it is unverifiable and therefore directly contradicts WP:5P2: All articles must strive for verifiable accuracy, citing reliable, authoritative sources." Nobody here asked the WMF to force the contents of Wikidata description fields into English Wikipedia's articles, and despite a strong consensus against them, the WMF team refused to turn them off. The compromise that was hashed out was that we were given a new "magic word" that allowed us to use local descriptions instead of those drawn from Wikidata; and that the Wikidata feed would be turned off when 2,000,000 articles had local short descriptions. That's why we have the WikiProject. We are actually creating descriptions for articles that are locally editable, subject to our anti-vandalism patrols, and governed by the English Wikipedia's sourcing policies, in particular BLP. Those descriptions could be exported to Wikidata, of course, but I'm not sure of their value there, since each language has its own description and (unlike most other parts of Wikidata) they are not intrinsically useful to other projects.
As for Crossroads, an edit summary of Wikidata description is more accurate. "Gay" is used far more for men than for women; and homosexuality is most often referred to in RS as same-sex attraction and not same-gender attraction. While our article lead on Homosexuality allows for both, it puts "sex" first. certainly had the appearance to me of someone trying to make a point through original research - YMMV. The effect, of course, was the same whatever the intent: it opened up our article for vandalism from Wikidata and left it so that editors had no indication that they had to go to another project to fix it. If you think that my use of "inevitably" deserves scare quotes, then perhaps looking at the edit history of gay (Q592) might persuade you otherwise.
"if our trust level of Wikidata is such that we are overriding its data through great effort at Wikipedia, that means the problem resides with Wikidata" That's an incorrect inference. The problem resides with a WMF development team who unilaterally decided that it was okay to import unsourceable information into the English Wikipedia against the advice of enwiki editors. A better analogy for us fixing the problem locally would be the situation where we are importing faulty car parts from an otherwise good supplier; we say we don't want any more faulty ones; but the importer keeps sending them and we are forced to keep using them until we can make them ourselves locally. Whose side is the problem on now?
Look, I know I'm coming across as exasperated, but that's what I am. I've been wrestling with this problem since it was first proposed, and I've explained what will go wrong a hundred times, and I'm sick of saying "I told you so" after the event. For others who still aren't familiar with the issues, please read at least some of the discussions linked from Wikipedia:WikiProject Short descriptions#History 2. Then if you want to criticise me for being annoyed, I'll be happier to accept it. Cheers --RexxS (talk) 20:21, 13 October 2019 (UTC)
No, I don't want to criticize you, on the contrary, I want to thank you for taking the time to give such an informative background, for something you've obviously had to say more than once before. I'm just sorry you're frustrated. (I know what that feels like, in a completely different corner of the encyclopedia; happy to discuss that over on my Talk page.) I also appreciate your extending the analogy in order to give me a better view of what's going on. I'm going to have a look at some links to try and get up to speed, and then try to help out on the project a bit, as I'm able, to try to get you to 2M. For what it's worth, my entry point to this whole issue was also from 5P2, when I realized what was going on at Gay and that we had no control over the reliability of such data; so you might say I got here by the side door. Thanks again for your feedback, and your work on the project. Mathglot (talk) 20:32, 13 October 2019 (UTC) P.S. Those were intended as real quotes, not scare quotes, sorry. Mathglot (talk) 20:37, 13 October 2019 (UTC)
I appreciate Mathglot's explanation of what I did. I'd also like to point out that the shortdesc I removed (undid, actually) had been up for less than 1 hour. It was not some long standing thing. And the meaning of that shortdesc was significantly different, as I explained. I don't think I'm expected to cite a bunch of sources in a shortdesc or edit summary. Rather, the shortdesc should be based on the sourced content in the article, which the one I removed certainly was not. -Crossroads- (talk) 21:00, 13 October 2019 (UTC)
One thing I think I've learned from this, is that in cases where the Wikidata description at a given point in time happens to be better than the content given in the {{short desc}} template on a Wikipedia article, rather than simply remove the template from the article and let the text from Wikidata be imported by default, instead, we should copy and paste the value from Wikidata into the template. That way, if the Wikidata item is vandalized later, we've already preserved the good value in the template, and the vandalized value won't be displayed. Adding Crossroads. Mathglot (talk) 22:02, 13 October 2019 (UTC)
I was thinking the same thing. -Crossroads- (talk) 23:37, 13 October 2019 (UTC)
I know the whole short descriptions stuff has already been exhaustively discussed, but is there an equivalent to our ClueBot NG over at Wikidata? I feel like the Wikidata change that Mathglot showed would've been caught by it. Enterprisey (talk!) 20:11, 13 October 2019 (UTC)
Enterprisey: Wikidata uses ORES to flag edits. ORES did flag the change Mathglot found.(lookup) Whether they have an bot using that information, I do not know. In addition, their main extension, Wikibase, blocks edits on statements which are not used as the community intended. Wikidata has of course also common anti-vandalism extensions like AbuseFilter, etc.--Snaevar (talk) 00:56, 15 October 2019 (UTC)

Actually, one other thought, RexxS, inspired by your comment,

I've been wrestling with this problem since it was first proposed, and I've explained what will go wrong a hundred times... please read at least some of the discussions linked from <link>...

A situation like this is tailor-made for exposition in an essay. Have you considered writing one? Make a distillation of all your best arguments from your hundred explanations, and lay it all out in one place. Those past discussions about the topic that aren't already wikilinked in the essay body, you can throw into the See also section. Then, when the 101st person (me?) comments or asks about it, point them at the essay. Sounds like you'd have plenty of company to help write it. Willing to start one? Sure seems like there's a need, and that others would find it useful to enlist in their discussions, as well. Mathglot (talk) 21:54, 13 October 2019 (UTC)

Pinging DannyH (WMF), as the one took the lead on the Foundation side when there was there was a clear consensus to roll back deployment of this (mis)feature. Danny, please turn off the Wikidata descriptions already. Alsee (talk) 17:00, 20 October 2019 (UTC)

How does Module:Labelled list hatnote convert number sign hash marks to section symbols?[edit]

{{see also}} is mostly the Lua code at Module:Labelled list hatnote. Where and how does it change wikilinks to specific sections like Article#Section into Article § Section? EllenCT (talk) 00:46, 13 October 2019 (UTC)

The magic happens in Module:Hatnote, specifically in the "Format link" section. See also {{Format link}} if you're just looking for a way to make that link formatting yourself. – Jonesey95 (talk) 00:59, 13 October 2019 (UTC)

Ewwww. More importantly, why does it do this and how do you make it not? ―cobaltcigs 16:42, 14 October 2019 (UTC)

You shouldn't. Why it does it is because # isn't understood as an indicator of a section IRL. §, the section sign, is. We even have a template for that. Nardog (talk) 16:52, 14 October 2019 (UTC)
The scope of such understanding is, roughly, lawbooks vs. the entire internet. But I'd be okay with this, given a software change that makes '§' (a) an illegal title character, and (b) interchangeable with '#'—in exactly the same way all space characters exist as aesthetically favorable alternatives to '_' in links. This way linking to [[List of Foo§Bar]] would produce <a href="/wiki/List_of_Foo#Bar" title="List of Foo">List of Foo§Bar</a> and pasting a title with '§' into the address bar would behave exactly like that title existed as a section redirect. Then we'd all be happy. But pretending on such a broad scale that this equivalence exists when it doesn't is a WP:PLA violation. ―cobaltcigs 15:02, 17 October 2019 (UTC)

Generating a gallery from a pool[edit]

I'd like to set up a gallery where the gallery itself shows fifteen images randomly drawn from a pool of perhaps fifty or sixty images, and each time the page is refreshed or purged, the gallery resets with a new set of fifteen images from that pool. Is that possible? bd2412 T 02:30, 13 October 2019 (UTC)

@BD2412: Yes, an expansion to Module:Carousel (which returns a single image from a pool) should be able to meet your needs if you're happy to purge the page to get the new gallery. Unfortunately, Scribunto-based solutions don't refresh on a reload because of caching. You may be able to do better using client-side JavaScript, but it's doubtful whether you'll get agreement to implement JavaScript that purges a page without having to click okay on a popup. This is to prevent vandals loading the servers by repeatedly requesting a page reload at high speeds. --RexxS (talk) 03:18, 13 October 2019 (UTC)
Interesting - thanks. bd2412 T 03:25, 13 October 2019 (UTC)

Image creates strange blank space[edit]

Could you have a look at Lou Andreas-Salomé#Death? The image on the right creates a strange blank space. Thank you very much, --Epìdosis 12:05, 13 October 2019 (UTC)

I have shifted the image to the spot before the maintenance tag, this looks better. SD0001 (talk) 12:47, 13 October 2019 (UTC)

It's 2019, why is unicode still so hard?[edit]

In Milutin Babović-Telegraph, the references are rendering as blobs of hex escape junk. If I copy-paste reference #3 into my sandbox, it renders properly in cyrillic characters. What's the issue here? -- RoySmith (talk) 15:34, 13 October 2019 (UTC)

Ugh, I think I copies the wrong example. -- RoySmith (talk) 15:47, 13 October 2019 (UTC)
@RoySmith: are you referring to the bare url references? They are displaying exactly they way they were input, as bare urls. If you want to show a title, use a citation template and the title parameter. — xaosflux Talk 16:58, 13 October 2019 (UTC)
@RoySmith: see https://tools.ietf.org/html/rfc3986#section-1.2.1 and percent-encoding. TL;DR: URLs are written in US-ASCII by design. Incnis Mrsi (talk) 18:31, 13 October 2019 (UTC)

This is a comedy of errors. First, I was trying to use reFill to expand those bare references, and it wasn't doing anything with them. But, now I just tried that again, and it successfully converted the references. And, in the process of debugging why reFill wasn't doing anything, I managed to accidentally copy the wrong reference into my sandbox for testing, and failed to notice that. -- RoySmith (talk) 19:27, 13 October 2019 (UTC)

Who do we approach to delete search suggestions in Special:Log?[edit]

Hi all,

Recently, I wanted to see the Special Log of a fellow administrator (I'm deliberately not naming them). And when I clicked on their name in the "Performer" field, the search suggestions that sprung up were abusive. How does one get that removed? Thanks, Lourdes 10:59, 14 October 2019 (UTC)

Either the abusively named accounts need to be renamed, or there is some form of suppression that can be placed on them. I think the latter is preferred. –xenotalk 11:45, 14 October 2019 (UTC)
I guess such accounts are reported to the stewards (privately) for global lock and suppression. This will remove them from the logs. SD0001 (talk) 12:03, 14 October 2019 (UTC)
I once submitted an oversight request (Ticket#2019042710003636) about this. The response was The content in question is under discussion by the Oversight team, and we will get back to you with our decision after we agree upon the appropriate course of action under the oversight policy <https://en.wikipedia.org/wiki/Wikipedia:Oversight>. I'm not sure we can do anything about that, but something should certainly be done about it -- RoySmith (talk) 12:21, 14 October 2019 (UTC)
Since all user accounts are now global, I don't think enwiki oversighters can do anything about this. But I'm guessing that stewards can rename the account, and then suppress the log action of the rename. So that the abusive name is completely gone from public records. SD0001 (talk) 13:15, 14 October 2019 (UTC)
I actually think they have a button that will do it all without the renaming. @Ajraddatz and MBisanz: jog my memory? –xenotalk 13:32, 14 October 2019 (UTC)
Yes, stewards can suppress the account globally. It will remove all instances of the username, except where it has been manually written by someone else or auto-populated by rollback or undo actions. It will hide the abusive names from search results as well. -- Ajraddatz (talk) 14:55, 14 October 2019 (UTC)
Likewise, local oversighters can take care of it here, but if we think it warrants suppression we'll just contact the stewards anyway to take care of things globally, so, you know, two birds one stone and all that. I believe renamers would specifically not rename such an account, as oversight/steward tools are built for the purpose and would be desired regardless, so creating a bunch of log entries across several wikis would be counterproductive. ~ Amory (utc) 01:31, 15 October 2019 (UTC)
This is not an isolated phenomenon. Typing in the name of any number of regular names who have been around a while, it often pulls up such abusively named accounts. It's been that way for years on the ones I know about, and nothing has been done. Who knows how many there are out there like that. Maybe oversighters should have a system to get rid of these, without having to be notified one by one. — Maile (talk) 01:43, 15 October 2019 (UTC)
Well, a lot has/is being done. There have been about 30 global suppressions of such names within the last week. But we do not have the capacity to go and find all of them ourselves, so we rely on reports for anything that is missed. -- Ajraddatz (talk) 22:53, 15 October 2019 (UTC)

Where is the article I created?[edit]

This is the problem edit. It is a copy and paste merge. I thought in order to make the move happen, the title of my article would change in order to preserve the history. I probably wrote the entire article so if that's the case it's not a real problem.— Vchimpanzee • talk • contributions • 21:29, 14 October 2019 (UTC)

Several moves have caused some confusing logs. The page you merged content from currently has its page history at McNeely–Strachan House. You were the only contributor. PrimeHunter (talk) 22:36, 14 October 2019 (UTC)
Thanks. I didn't think about that.— Vchimpanzee • talk • contributions • 14:49, 15 October 2019 (UTC)
I just thought of something. It's too late to do anything now, but what I had expected that a move would take place that would change the name of the article in my edit summary in the above edit. No, wait, that only happens in my contributions, where it says what article I edited.— Vchimpanzee • talk • contributions • 16:35, 15 October 2019 (UTC)
Here is my solution. That should clear things up for anyone who is confused.— Vchimpanzee • talk • contributions • 16:40, 15 October 2019 (UTC)

Article seems corrupted[edit]

I don't know whether someone might be able to take a look at Talk:Marathon_world_record_progression#Sections_are_displaying_in_the_wrong_order? The article seems somehow corrupted, but I don't know whether the issue will get any attention there. 2A00:23C5:4B91:AB00:6CCD:D471:9CF7:2B7F (talk) 22:14, 14 October 2019 (UTC)

If tables are displayed later then it's usually because the table end |} is missing. I have added it.[4] PrimeHunter (talk) 22:43, 14 October 2019 (UTC)
@PrimeHunter:. Thank you, that's fixed it! 2A00:23C5:4B91:AB00:FCD5:6B0E:A54A:8E8E (talk) 23:07, 15 October 2019 (UTC)

Tech News: 2019-42[edit]

23:32, 14 October 2019 (UTC)

How to find HTML markup[edit]

The dBase article has a hat stating there is HTML markup that should be removed. It's a long article, is there an easy way to find it all? Maury Markowitz (talk) 13:55, 15 October 2019 (UTC)

I think this edit took care of them. DMacks (talk) 14:07, 15 October 2019 (UTC)

Edit watchlist page groups[edit]

The Edit watchlist used to be organized in groups with their own titles in MonoBook. Now they are all in one group. I noticed 'Hide categorization of pages' in preferences, but unchecking that did nothing. I would like them to be separate again. Smarkflea (talk) 15:59, 15 October 2019 (UTC)

This is phab:T235137. --Izno (talk) 16:07, 15 October 2019 (UTC)

Tools for removing non-section redirects in templates?[edit]

Is there a tool that would help with removing redirects in templates? For example Template:Aboriginal peoples of the Northern Territory still has over a dozen.Naraht (talk) 07:08, 16 October 2019 (UTC)

@Naraht: I added the following to my Special:MyPage/common.css, which makes it easier to identify redirects so that I can manually resolve them:
.mw-redirect {
	background: url(https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Insert_redirect.png/12px-Insert_redirect.png) center right no-repeat;
	padding-right: 13px;
}
It will make redirect links look like thisInsert redirect.png. --Ahecht (TALK
PAGE
) 19:46, 16 October 2019 (UTC)
I use similar CSS, .navbox .mw-redirect, .vertical-navbox .mw-redirect { font-style: italic; color: red; }, which makes redirects stand out as italic and red. --Izno (talk) 23:45, 16 October 2019 (UTC)
For this I've found using a background-color works better. Seems like italic red would be barely distinguishable from an actual red link (referring, perhaps, to a film title) which may appear elsewhere in the same navbox. Another option would be keeping the link text blue but adding a differently colored underline like .mw-redirect { border-bottom: 1px solid red; }. ―cobaltcigs 08:25, 17 October 2019 (UTC)

I think by "removing redirects" the OP probably means:

While editing the template, click some button to replace each redirect link with a link to its target (unless said target contains #, which would suggest the redirect may someday become a separate article)

You'd need javascript with some API calls to determine these things. The suggested CSS would only alert you, prior to editing, that redirects are present (which the OP already realizes). ―cobaltcigs 06:12, 17 October 2019 (UTC)

cobaltcigs, Izno that is a good restatement. I'd be just fine with an external tool as well, but AutoWikiBrowser doesn't appear to be that tool.Naraht (talk) 08:12, 17 October 2019 (UTC)

Try this: User:Cobaltcigs/NavboxStuff.js

  • Activates automatically when you edit a template identified as a navbox (including from the "v·t·e" links). Let me know if that's too extreme and you need a separate button.
  • Disregards redirects that point to a section anchor, as specified.
  • Normalizes irregular spacing found in any #redirect [[ Like_this _ _ shit__]].
  • Fully replaces, rather than piping, any link that wasn't piped before. e.g. [[Jalapeno]] becomes [[Jalapeño]], never [[Jalapeño|Jalapeno]] (the latter pattern is a common problem).

Feedback is welcome. ―cobaltcigs 12:41, 19 October 2019 (UTC)

New gadget proposal for undoing edit from mobile diffs[edit]

It has been proposed that a new gadget be installed that allows editors to revert edits from mobile diffs (Special:MobileDiff). See the discussion at Wikipedia_talk:Gadget#proposal_for_undo_gadget. Thanks, SD0001 (talk) 08:15, 16 October 2019 (UTC)

404 at wmflabs edits by user[edit]

I'm getting 404 when clicking the Find edits by user link on the History page of articles. I.e., usersearch.py. Mathglot (talk) 10:57, 16 October 2019 (UTC)

@Σ: maintains that tool. Σ, is it coming back? If not we can just remove that from the history legend. — xaosflux Talk 11:36, 16 October 2019 (UTC)
You can use User:Ale jrb/Scripts/userhist.js for finding edits by user on a page. SD0001 (talk) 14:14, 16 October 2019 (UTC)
There is also XTools Top Edits. I have changed the link in Histlegend to point there, until Sigma's tool is restored. MusikAnimal talk 15:32, 16 October 2019 (UTC)
Odd, because I'd restarted it just a few days ago. But I restarted it again and it is now up and running again. Σσς(Sigma) 04:23, 18 October 2019 (UTC)
@Xaosflux, Mathglot, and MusikAnimal:Σσς(Sigma) 04:24, 18 October 2019 (UTC)
Thanks all! Mathglot (talk) 08:33, 18 October 2019 (UTC)
I was going to report the same problem. It is still not working with me.--SharabSalam (talk) 18:46, 19 October 2019 (UTC)

Wiki-Map[edit]

I have been using Wiki-Map to locate articles to add to categories but after I click "Show Map" and it starts showing the places I get "This page didn't load Google Maps correctly. See the JavaScript console for technical details.". This appeared to be something that started happening in 2016 when Google reduced its free maps or something but with Wiki-Map this didn't happen until a few weeks ago (although I've only been using it a few months). Crouch, Swale (talk) 16:30, 16 October 2019 (UTC)

Crouch, Swale, That site isn't hosted on Wikimedia servers, so you'll have to contact them directly using the link at the bottom of the page. There are almost certainly other tools that serve a similar function, such as toolforge:wikishootme. --AntiCompositeNumber (talk) 13:04, 17 October 2019 (UTC)
Thanks, I'll use that then especially given that is looks like it has more features. Crouch, Swale (talk) 13:09, 17 October 2019 (UTC)

WMF sites down[edit]

Did anybody get a 503 backend Fetch error upon trying to access any Wikimedia site, in the past few minutes? WBGconverse 17:32, 16 October 2019 (UTC)

  • No issues from Colombo or London. Cheers, Rehman 17:34, 16 October 2019 (UTC)
Winged Blades of Godric, it is likely. WMF Ops is aware and working on it. --AntiCompositeNumber (talk) 17:36, 16 October 2019 (UTC)
It's best to report these to Phabricator so they are aware of the incidents and how widely it affects (they have stats anyway). --qedk (t c) 16:56, 19 October 2019 (UTC)

Editing News #2 – Mobile editing and talk pages – October 2019[edit]

Read this in another languageSubscription list for this multilingual newsletter

Inside this newsletter, the Editing team talks about their work on the mobile visual editor, on the new talk pages project, and at Wikimania 2019.

Help[edit]

What talk page interactions do you remember? Is it a story about how someone helped you to learn something new? Is it a story about how someone helped you get involved in a group? Something else? Whatever your story is, we want to hear it!

Please tell us a story about how you used a talk page. Please share a link to a memorable discussion, or describe it on the talk page for this project. The team would value your examples. These examples will help everyone develop a shared understanding of what this project should support and encourage.

Talk Pages[edit]

The Talk Pages Consultation was a global consultation to define better tools for wiki communication. From February through June 2019, more than 500 volunteers on 20 wikis, across 15 languages and multiple projects, came together with members of the Foundation to create a product direction for a set of discussion tools. The Phase 2 Report of the Talk Page Consultation was published in August. It summarizes the product direction the team has started to work on, which you can read more about here: Talk Page Project project page.

The team needs and wants your help at this early stage. They are starting to develop the first idea. Please add your name to the "Getting involved" section of the project page, if you would like to hear about opportunities to participate.

Mobile visual editor[edit]

The Editing team is trying to make it simpler to edit on mobile devices. The team is changing the visual editor on mobile. If you have something to say about editing on a mobile device, please leave a message at Talk:VisualEditor on mobile.

Edit Cards[edit]

What happens when you click on a link. The new Edit Card is bigger and has more options for editing links.

Toolbar[edit]

The editing toolbar is changing in the mobile visual editor. The old system had two different toolbars. Now, all the buttons are together. Tell the team what you think about the new toolbar.
  • In September, the Editing team updated the mobile visual editor's editing toolbar. Anyone could see these changes in the mobile visual editor.
    • One toolbar: All of the editing tools are located in one toolbar. Previously, the toolbar changed when you clicked on different things.
    • New navigation: The buttons for moving forward and backward in the edit flow have changed.
    • Seamless switching: an improved workflow for switching between the visual and wikitext modes.
  • Feedback: You can try the refreshed toolbar by opening the mobile VisualEditor on a smartphone. Please post your feedback on the Toolbar feedback talk page.

Wikimania[edit]

The Editing Team attended Wikimania 2019 in Sweden. They led a session on the mobile visual editor and a session on the new talk pages project. They tested two new features in the mobile visual editor with contributors. You can read more about what the team did and learned in the team's report on Wikimania 2019.

Looking ahead[edit]

  • Talk Pages Project: The team is thinking about the first set of proposed changes. The team will be working with a few communities to pilot those changes. The best way to stay informed is by adding your username to the list on the project page: Getting involved.
  • Testing the mobile visual editor as the default: The Editing team plans to post results before the end of the calendar year. The best way to stay informed is by adding the project page to your watchlist: VisualEditor as mobile default project page.
  • Measuring the impact of Edit Cards: The Editing team hopes to share results in November. This study asks whether the project helped editors add links and citations. The best way to stay informed is by adding the project page to your watchlist: Edit Cards project page.

PPelberg (WMF) (talk) & Whatamidoing (WMF) (talk) 16:51, 17 October 2019 (UTC)

User script for watching pages temporarily[edit]

New user scripts are not usually announced here but I think this one is sort of epic. Seeing that watchlist expiry was #7 on last year's Community Tech wishlist, I have recently created a new user script that enables watching pages temporarily - see User:SD0001/T-Watch. Being a user script, of course, the implementation is quite different than how the WMF is going to implement it. But until such a feature becomes a part of core MediaWiki - which I guess is going to take quite a while, I think this script would be useful. Any feedback is welcome. Enjoy! SD0001 (talk) 18:16, 17 October 2019 (UTC)

Now updated to provide elegant menus for vector and monobook skins, to avoid the watch links from cluttering the "more" dropdown (in vector) or the p-cactions toolbar (in monobook). SD0001 (talk) 12:06, 18 October 2019 (UTC)
Interesting, I'll definitely give this a go and let you know of anything odd. Nosebagbear (talk) 13:31, 18 October 2019 (UTC)

Thumbnails in Category[edit]

Why does Category:Copy to Wikimedia Commons reviewed by a human show image file thumbnails if I edit and preview it, but not if I just access it normally? -- Begoon 02:58, 18 October 2019 (UTC)

It contains {{file category}}, which contains (as a default setting) the __NOGALLERY__ directive, which is ignored on category preview, which has been known about since the feature was first added in 2006. ―cobaltcigs 03:11, 18 October 2019 (UTC)
cobaltcigs, thank you. I added a |showthumbs= to {{file category}} to allow overriding that default, and it works now. Cheers. -- Begoon 03:28, 18 October 2019 (UTC)

It looks like that template is supposed to infer whether to show/hide galleries based on the {{{free}}} parameter, so you'll want to be mindful of image copyright status when overriding. But in this particular case (where humans have deemed the files suitable to copy to commons), free=yes seems like a reasonable presumption. Simply using that would have the same effect. ―cobaltcigs 04:27, 18 October 2019 (UTC)

A fair point, but I think it should be ok here for the reasons you say. You can trust me to be over-elaborate when solving a problem, but I think I'll leave the parameter there anyway as doing no real harm. Thanks. -- Begoon 05:08, 18 October 2019 (UTC)
Although, on second thoughts, I've rolled back the changes, because once I got to browsing that category there are quite a few "questionable" images in it, where I'm not convinced the "free" licensing is completely solid. The "human" reviews seem quite a bit less thorough than I would have hoped. I can always take advantage of the "preview" quirk and use it that way if I want to. Face-smile.svg -- Begoon 05:40, 18 October 2019 (UTC)

pct |sigfig=[edit]

I found no way I could input the output of Template:Pct into Template:Sigfig, so asked in Template talk:Percentage to add |sigfig= as an option, as it currently already exists in Template:Convert. What's the best way to go about this? Guarapiranga (talk) 21:59, 18 October 2019 (UTC)

"Editor Interaction Analyzer" is down[edit]

Resolved

Back up. --qedk (t c) 07:06, 20 October 2019 (UTC)

Editor Interaction Analyzer🔖--Moxy 🍁 04:47, 19 October 2019 (UTC)

@Σ: Hopefully just needs a restart. --qedk (t c) 16:54, 19 October 2019 (UTC)

Public Oversight warning template[edit]

Current draft exists here and template should be called {{uw publicoversight}}. Please approve. Monniasza talk 16:42, 19 October 2019 (UTC)

@Xaosflux: Do you accept my template?
Pings don't work unless signed, there is no template acceptance process (and by transitivity, Xaosflux cannot be related to one, they are an intadmin though). --qedk (t c) 18:44, 19 October 2019 (UTC)

Conditional templates and file extensions[edit]

For a template that is transcluded in File: namespace pages, is there a way to apply conditional template code—e.g., placing the file in one category versus another—based on the file's extension (e.g., ".jpg" versus ".ogg")? Thank you, -- Black Falcon (talk) 20:37, 19 October 2019 (UTC)

Sure, {{PAGENAME}} gets the name including a file extension. {{lc:{{#invoke:String|match|{{PAGENAME}}|%.(%w*)$||||}}}} retrieves the file extension as lowercase (empty if none is found). Then you can e.g. use switch:
{{#switch:{{lc:{{#invoke:String|match|{{PAGENAME}}|%.(%w*)$||||}}}}
|jpg = ...
|png = ...
|gif = ...
|ogg = ...
}}
PrimeHunter (talk) 21:12, 19 October 2019 (UTC)
Thank you very much! -- Black Falcon (talk) 21:31, 19 October 2019 (UTC)

Created {{file extension}} based on above. ―cobaltcigs 14:24, 20 October 2019 (UTC)

Problems with site?[edit]

Is anyone else having issues with the site. Some of the wikipedia pages I search for lead to getting a "wikimedia is having a problem at the moment" page.

The problem tracker sites are giving slight bumps up in the last hour for problems with the site.

Anyone experiencing similar or has some knowledge? Nosebagbear (talk) 21:47, 19 October 2019 (UTC)

Same thing is happening with Commons. Looks like a global problem. Masum Reza📞 21:51, 19 October 2019 (UTC)

Expansion depth and template include size exceeded on multiple cite templates[edit]

It seems that Template:Cite web is expanding too much, so is hitting the mediawiki expansion limit and template include size limit. This (at least for me) is causing the documentation template not to render. Were there any changes to the module which caused this or was/is the global loading issue for sites to blame? Dreamy Jazz 🎷 talk to me | my contributions 22:01, 19 October 2019 (UTC)

Raising it here as it would and is causing confusion to new users. Purging does not seem to fix the issue either. Dreamy Jazz 🎷 talk to me | my contributions 22:04, 19 October 2019 (UTC)
Also, no changes have been made to Module:Citation/CS1 recently. A change might have been made in a template / module used by this module, but I haven't been able to see anything obvious. As far as I am aware, it is only affecting the template page and not the output in pages. Dreamy Jazz 🎷 talk to me | my contributions 22:12, 19 October 2019 (UTC)
Furthermore, the limits being exceeded are also on Cite journal, book, news, AV media, magazine, sign, press release, report, encyclopedia and others. Dreamy Jazz 🎷 talk to me | my contributions 22:16, 19 October 2019 (UTC)
Where? Because cs1|2 templates are at the end of the page they are often the symptom of just-too-many-templates on the page.
Trappist the monk (talk) 22:52, 19 October 2019 (UTC)
(edit conflict) It was this edit by Trappist the monk (talk · contribs), which I have reverted. --Redrose64 🌹 (talk) 22:53, 19 October 2019 (UTC)
Redrose64, all good now then. Thanks for the help. Dreamy Jazz 🎷 talk to me | my contributions 22:57, 19 October 2019 (UTC)
Give me a page where this has happened. So far, none of the pages that I've checked in either of Category:Pages where expansion depth is exceeded and Category:Pages where template include size is exceeded use Module:Lang (and MediaWiki is rapidly clearing those categories).
Trappist the monk (talk) 23:04, 19 October 2019 (UTC)
1440s, 2019 Belarusian Premier League, 2019 Moldovan "A" Division, Acephali, Bangkok, Capital ẞ, Edward V of England, Friday, several others. To find more, go to Category:Pages where expansion depth is exceeded, choose a page, and click the "Edit" tab. Then check the "Pages transcluded onto the current version of this page" list, and if Module:Lang is present, save without changing (i.e. perform a WP:NULLEDIT), then return to the cat and refresh the page. If the article disappears from the cat, then it was affected. --Redrose64 🌹 (talk) 23:15, 19 October 2019 (UTC)

Main page on the Dutch Low Saxon Wikipedia[edit]

Hi there! Is there anyone who could assist me with setting up the mobile version of the Dutch Low Saxon main page? I've tried to set it up myself, but I can't seem to figure out how it works exactly. I also tried using an empty main page with 2 templates (consisting of only wikitext and div id) and 1 template (with a table), which is almost identical to the Frisian Wikipedia where it is displayed correctly. It would be highly appreciated. Servien (talk) 11:49, 20 October 2019 (UTC)

Servien, Frysian Wikipedia (like English) is on the old deprecated method of presenting the main page on mobile. The way to do it now, is to use CSS and make the page responsive to the dimensions of the viewport. —TheDJ (talkcontribs) 08:58, 21 October 2019 (UTC)

Help for programmers with modules: a debug module[edit]

Because I'm improving a fairly complex module (more than two thousand lines of code). I created a module to make easy the debugging of any other module, because I found nothing similar in this wiki.

Justification: Although many times with an error() to see a variable is more than enough, but sometimes you want to see what happens with more than one variable and/or in several points. Module:SimpleDebug solved this problem easily.

I make publicity of this module in Help:Lua#Debugging modules.

--Jmarchn (talk) 14:36, 20 October 2019 (UTC)

The use of ASCII hyphens (U+002D) as separators is disgusting. Better to separate by a character which may unlikely be found in strings on Wikipedia. Incnis Mrsi (talk) 15:02, 20 October 2019 (UTC)
Thanks for this useful work! I think Incnis Mrsi meant to say that it might be better to use • as a separator (you can copy that character into the module to replace the hyphen). Also see Module:Dump which I have used. The built-in mw.log and mw.logObject functions are also useful, and mw.dumpObject can be used with error() although dump usually gives a prettier result. This might also be discussed at WT:LUA. Johnuniq (talk) 00:39, 21 October 2019 (UTC)

Script installer[edit]

I added several scripts using the install feature, but it prompted me to okay the import each time. I then clicked the box to not show this again and now I can't install with one click. Any help is appreciated. Than you. Demetrius Tremens (talk) 15:45, 20 October 2019 (UTC) Nevermind. Seems to have fixed itself. Demetrius Tremens (talk) 15:55, 20 October 2019 (UTC)

Find and replace[edit]

Is there tool like "find and replace" which would let me automatize some edits? Eurohunter (talk) 19:00, 20 October 2019 (UTC)

In the wikitext editor, click Advanced then click the quizzing glass at far right. Search and replace; even has regex.
Trappist the monk (talk) 19:02, 20 October 2019 (UTC)
@Trappist the monk: I use old toolbar and I would like to have easy access to it. Eurohunter (talk) 19:05, 20 October 2019 (UTC)
Special:Preferences#mw-prefsection-editing and check 'Enable the editing toolbar'. I guess that's not the 'old' old tool bar but it ain't that abomination that is ve.
Trappist the monk (talk) 19:10, 20 October 2019 (UTC)
@Trappist the monk: But its bad toolbar. It increases space beetwen characters so it make text unreadable for me and takes too much space in editor and all tools are hidden (for what?). Eurohunter (talk) 19:20, 20 October 2019 (UTC)
That is not my experience. If you see that across several browsers, perhaps you should report it as a bug.
You might just have to resort to copying the text into a plain-text text editor and do search-and-replace that way. I have used Notepad++ successfully for that.
Or, there is a different editor for modules / javascript, etc so you might edit Module:Sandbox/Eurohunter paste your text there, search and replace (crtl-f, the + in the search box gets you into replace) copy it all back to the source page. You might have to click the <> button at far left to get the non-toolbar editor.
I'm out of suggestions.
Trappist the monk (talk) 19:31, 20 October 2019 (UTC)
@Trappist the monk: This feature is avaiable at PLWiki so it should be here too. Eurohunter (talk) 21:23, 20 October 2019 (UTC)
Eurohunter, which of the many mw:Editors are you using? Whatamidoing (WMF) (talk) 21:25, 20 October 2019 (UTC)

Module tracking of template parameter's raw content[edit]

How do I track the raw content of an template's parameter? In this case, I'm wanting to track the parameter |WrittenBy= in the {{Episode list}} template.

For example, the Be Cool, Scooby-Doo! article uses |WrittenBy=''Story by'': Ken Daly and John Matta<br />''Teleplay by'': Ken Daly, John Matta and Jon Colton Barry, when it should be using |WrittenBy={{StoryTeleplay|s=Ken Daly and John Matta|t=Ken Daly, John Matta and Jon Colton Barry}}. I'm wanting to track the cases where the former format is used instead of the latter templated format.

Now, here I attempted to add tracking to Module:Episode list by checking if the parameter included ''Story or ''Teleplay. However, I remembered that templates are parsed from the inside out, so this tracking would automatically include parameters that already use {{StoryTeleplay}}, as the template gives the same output (i.e. ''Story and ''Teleplay), just formatted elsewhere differently.

So, can I track the value of |WrittenBy= by its raw value, before the value (and thus any templates the value contains) is parsed? -- /Alex/21 21:21, 20 October 2019 (UTC)

{{StoryTeleplay}} does call {{Italics colon}} which calls {{hair space}} which includes &#8202; in the final rendering:
{{StoryTeleplay|s=Greg Berlanti & Andrew Kreisberg}}
''Story by''&#8202;: Greg Berlanti & Andrew KreisbergStory by : Greg Berlanti & Andrew Kreisberg
So, perhaps looking for the specific string: ''&#8202;: in |WrittenBy= will get you most of the way there.
You can also have the module read the unparsed page content
local content = mw.title.getCurrentTitle():getContent(); -- get unparsed wikitext of current page
local written_by = content:find ('|%s*WrittenBy%s*=%s*{{%s*StoryTeleplay');   -- look for |WrittenBy= parameter with {{StoryTeleplay}}
if not written_by then
--do something appropriate here
else
--do something else appropriate here
end
Trappist the monk (talk) 22:16, 20 October 2019 (UTC)
Thanks for the reply! I was thinking I'd have to check for the hair space, but I thought I'd check to see if I could check the parameter's raw content first; I guess not! So I've implemented the following. Thanks again. -- /Alex/21 23:38, 20 October 2019 (UTC)

Marking minor edits in mobile[edit]

I have recently been editing a lot from mobile, and the main thing I'm missing is the ability to mark edits as minor. Would it be possible to add that feature? Sdkb (talk) 22:02, 20 October 2019 (UTC)

phab:T123694. --Izno (talk) 22:10, 20 October 2019 (UTC)
Thanks for the link! Sdkb (talk) 23:27, 20 October 2019 (UTC)

Graph:Chart issues[edit]

The showSymbols parameter in {{Graph:Chart}} doesn't respect opacity values. Here's a clearer/simpler example. The lines conform to the opacity of #40FF0000 (#FF0000 at 25% opacity); the symbols do not (they display as #FF0000 at 100% opacity).

Any comments as to how this can be fixed? -- /Alex/21 23:40, 20 October 2019 (UTC)

Novel form of vandalism???[edit]

When I open Einstein Papers Project in the Wikipedia App on my iPhone, I see "Nahom is Physicist" immediately below the subject line, as seen in the following screen capture: https://drive.google.com/open?id=1Dre17ZwAEm1VoC3toxRWqPRyWLnuAHCU

These words do not appear on the Desktop nor on the Mobile versions of the article. I do not see these words anywhere in the source text. Does anybody know how these words could have been introduced to the Wikipedia App version of the article? Prokaryotic Caspase Homolog (talk) 02:32, 21 October 2019 (UTC)

It's a Wikidata thing,[7] now reverted. -- zzuuzz (talk) 02:34, 21 October 2019 (UTC)
Thanks! Prokaryotic Caspase Homolog (talk) 02:39, 21 October 2019 (UTC)

Is it possible to force display of plaintext instead of emojis in articles?[edit]

Someone wrote two years ago at Wikipedia:Village_pump_(technical)/Archive_158#Some_mathematical_etc._symbols_replaced_by_emoji that emojis were popping up in all sorts of places, like mathematical equations. And we seemed to think that Chrome, Apple, etc were going to do something about it. That obviously didnt happen. But is it possible that we can somehow make it so that symbols that are potentially going to be rendered as emojis will instead show up in an old-school font that doesnt have them? Does the browser automatically replace all such symbols with colored emojis in all fonts? e.g. right now, in the edit window, ↗ and ↘ have their classical appearance: two thin diagonal black lines with arrowheads at the end. But on Romanian_phonology#Intonation they are large, colorful emojis that break up the flow of the text. Is there any way that we can get the edit-window style appearance to show up in the article? Thanks for any answers, Soap 04:13, 21 October 2019 (UTC)

It shows up normal for me with chrome and edge on Windows 10. What device and browser are you using? Someguy1221 (talk) 04:17, 21 October 2019 (UTC)
I don't see any emoji either both on the page and in edit window using Chrome on Mac. Possibly has to do with your browser/system. – Ammarpad (talk) 05:00, 21 October 2019 (UTC)
Yes, I suspect so too, but .... I also suspect it's coming to all of us whether we want it or not. I only noticed it on that page today after I updated Chrome ... and that happens automatically for most users.
Sorry, I should reply fully .... I'm on Windows 7 on a fairly old computer. But the browser is up to date, because I never turned off auto-update on this computer (and in my experience it's pretty hard to stop Chrome from updating when it really wants to.) I cant say for sure if the browser update is the reason for the change, but it's my best hunch. Soap 05:54, 21 October 2019 (UTC)
Here is the text copied from the article: [ai stins lu↗mi↘na]. What do you see here? I see "lu" then a north-east arrow, then "mi", then a south-east arrow, then "na". Try editing this section and replacing "mi" with "xyz". What do you see on preview? What do you see in the history of this page (I pasted the text in my edit summary)? Johnuniq (talk) 06:41, 21 October 2019 (UTC)
I'm now on a Windows 7 machine using the newest version of chrome, looks normal to me. Firefox's latest version is also displaying it just fine. Someguy1221 (talk) 07:30, 21 October 2019 (UTC)
Thanks. The edit history now has the emojis too. Im pretty sure that copypaste works normally so long as the user sees the classical glyphs. Your paste worked just fine ... but my browser sees those glyphs as emojis, and there's nothing you can do on your end that will make them appear normal.
Everything in the edit window still appears with its classical form, which leads me to believe that — if the time ever comes when the emoji appearance becomes default and if other people complain — we might be able to work out a solution on our end to make it appear that way all over. Because I dont think we can count on Google and Apple. But you just reminded me of something else ... when the glyphs appear in their emoji form, I cannot copy/paste them ... so there may be more to this than just an aesthetic preference, and I think I won't be alone at wanting it back the way it used to be. This, again, assumes that I'm right that the change is coming, one way or another, and we will all soon see what I see. Thanks again for your replies. Soap 07:42, 21 October 2019 (UTC)
Well, one more thing, .... again I apologize for the many small edits .... I used a hotspot for nearly 3 years and totally lost the habit of using Preview .... but it's possible the broken copy/paste is a WikEd bug, since I was able to paste them normally into a Word document as images, and into Notepad as text. It's still not ideal, if things are going to turn into images, but perhaps copypaste isn't totally broken. Soap 07:47, 21 October 2019 (UTC)
I see the emoji too, on Edge 44 with Windows 10 version 1903. See screenshot. The characters appear as non-emoji in Chrome 77 on the same system. This, that and the other (talk) 10:36, 21 October 2019 (UTC)
I too see the emoji while using Edge on Windows 10 (but not on Chrome) - I see them in both reading and editing views, which is surprisingly because I use the plain simple monospaced edit font. These characters can be forced to render in non-emoji form (in reading view) by appending the unicode control character U+FE0E just after the character. @Soap: I guess this text would look normal to you: [ai stins lu↗︎mi↘︎na]. SD0001 (talk) 11:15, 21 October 2019 (UTC)
Unfortunately not (for me) on Chrome 77/Windows 10. --Izno (talk) 11:57, 21 October 2019 (UTC)
Looks like U+FE0E fails to do its magic in certain fonts, including the one used by the Timeless skin. You're using Timeless, right? You should see the non-emoji form in any other skin. On my end, with Timeless skin, I see one of those two characters as emoji and the other as non-emoji (whether or not appended by U+FE0E). Weird. SD0001 (talk) 12:19, 21 October 2019 (UTC)

Tech News: 2019-43[edit]

14:18, 21 October 2019 (UTC)