Wikipedia

Wikipedia:Village pump (technical)/Archive 157

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Pink and orange on watchlist

Pardon me if I'm being dense, but a few weeks ago items on my watchlist began to be colored pink or orange -- just a few per day. It seems to have something to do with flagging suspicious edits. Where is this coming from? Did I turn on some preference? Where is the Rosetta Stone that tells me what these colors mean? EEng 15:05, 17 July 2017 (UTC)

@EEng: It is exactly that: flagging suspicious edits. It is a beta feature. The more-severe the color, the more likely the edit is to be out of accord with Wikipedia guideline/policy. Either you have "New filters for edit review" checked or you have "Automatically enable all new beta features" checked, or both. --Izno (talk) 15:14, 17 July 2017 (UTC)
Got it, thanks! A suggestion: could the colors turn off when I've visited that rev? i.e. when the article name is no longer in bold, then I don't need the ORES color either. EEng 15:25, 17 July 2017 (UTC)
I also found it somewhat annoying for ORES highlighting to remain despite having reviewed the change. I however understand that fixing this would technically require more per-editor statekeeping, I don't think that it's a priority considering the trouble. Another possibility would be for editors to be able to flag those as reviewed or false positive, somewhat like we review pending changes... Of course, this would require a right to prevent abuse, but it could be restricted to the existing pending changes reviewer right... —PaleoNeonate - 15:31, 17 July 2017 (UTC)
Well, I don't see why any extra state is needed -- it can simply follow the existing determination of which items are in bold and which are in not-bold: if not-bold, then don't color. Anyway, at least for me it's not a big deal -- I only get one or two items highlighted per day, though those with many vandal-prone articles watchlisted might get more, I suppose. Since it's just a beta feature I wouldn't suggest effort be put into any tweaking for now. EEng 16:32, 17 July 2017 (UTC)
Hi EEng, you can turn off the highlight in your preferences. Trizek (WMF) (talk) 09:27, 18 July 2017 (UTC)
Thanks, I get it. EEng 09:36, 18 July 2017 (UTC)

Clarity of user-rights log messages

Tracked in Phabricator
Task T170513

When user rights are changed, the log usually lists the old rights and the new rights. That is useful in some cases, but other times what I really want to see is what changed, which is difficult when the information is a sentence with lists of words. More clear is what some admins so in their edit summary, saying what right was added/removed rather than just an explanation of why some change was made. Consider the following three examples from the current log (chosen solely for illustrative purposes), listed in increasing order of readability that entails increasing amounts of work by admin:

  • 11:47, 10 July 2017 Alex Shih (talk | contribs | block) changed group membership for Jupitus Smart from autopatrolled, extended confirmed user, new page reviewer, pending changes reviewer and rollbacker to autopatrolled, extended confirmed user, new page reviewer, pending changes reviewer, rollbacker and page mover
  • 12:08, 10 July 2017 Alex Shih (talk | contribs | block) changed group membership for Seppi333 from extended confirmed user and IP block exempt to extended confirmed user, IP block exempt and template editor (Wikipedia:Requests_for_permissions/Template_editor)
  • 11:06, 10 July 2017 Kudpung (talk | contribs | block) changed group membership for Steve Quinn from autopatrolled, extended confirmed user and pending changes reviewer to autopatrolled, extended confirmed user, pending changes reviewer and new page reviewer (+patroller; Requested at WP:PERM; Special:PermaLink/789904243#User:Steve Quinn (using userRightsManager))

The "+patroller" in the third is what I would like to see happen automatically. DMacks (talk) 12:32, 10 July 2017 (UTC)

This is a good idea. I have the same problem, and an elegant solution would be welcome. – Jonesey95 (talk) 13:49, 10 July 2017 (UTC)
I agree that seeing the difference rather than only another list of all groups would be convenient. —PaleoNeonate - 14:05, 10 July 2017 (UTC)

Looking back, it seems like the message used to do this (until sometime in or before December 2009), according to Wikipedia:Village pump (technical)/Archive 69#Rights changes. Apparently prior to that, only the change was stored, so that's all that the log said, but then the old/new perms themselves were stored so the full lists were included in the log instead. I can't find "changed group membership for" in the MediaWiki: namespace of system messages, which might tell us when the current message was created. DMacks (talk) 19:02, 10 July 2017 (UTC)

But anyway, given it's based on a change to the storage (back-end, not front-end) it doesn't really matter how it used to be implemented front-end. Now, it's a front-end issue with parsing the new back-end data in LogFormatter.php getIRCActionText(). I guess we're headed out of VPT into the land of Phab? DMacks (talk) 19:23, 10 July 2017 (UTC)
Filed. DMacks (talk) 04:21, 13 July 2017 (UTC)

Added a discussion on MediaWiki talk:Titleblacklist-forbidden-edit

Hello,

I have added a discussion to the talk page of MediaWiki:Titleblacklist-forbidden-edit. It is considering whether we should add the $1 (entry) and the $2 (title) parameters so that editors understand which entry is causing a problem. For example, I cannot create user subpages with emojis in the title because of the blacklist. Should we edit it?

--UpsandDowns1234 (🗨) 05:06, 13 July 2017 (UTC)

P.S. You can see the talk page for what edit I am proposing before we use the {{tl:editprotected}} template.

Proposal to default references element to column mode

I have started a proposal to switch the default behaviour of <references /> to automatic column mode. —TheDJ (talk • contribs) 14:28, 13 July 2017 (UTC)

Why is Billie Jean King in Category:Articles with unsourced statements from April 2014

I can't find out why this article is in the maintenance category. I looked through wikitext and I found no use of a {{citation needed}} template nor of its many redirects, and even a CTRL+F of either April or 2014 turns up nothing but legitimate uses. I even looked at the many navboxes to see if it wasn't somehow passed through a transcluded template but it doesn't seem so. Any thoughts? ☺ · Salvidrim! · ✉ 04:05, 14 July 2017 (UTC)

@Salvidrim!: {{Chicago Gay and Lesbian Hall of Fame}}, which is transcluded in the article, has {{cn|date=April 2014}}. — JJMC89 (T·C) 04:40, 14 July 2017 (UTC)
Damn. I looked through the hidden cats of the navboxes assuming it would show there (it doesn't). Thanks! ☺ · Salvidrim! · ✉ 04:44, 14 July 2017 (UTC)
Someone added cn templates to links that went to pages about a different person with the same name. I have added (possibly inadequate) disambiguation text to those links and added a source to the template. I also checked most of the other links and added disambiguation to ones that went to the wrong people. – Jonesey95 (talk) 05:17, 14 July 2017 (UTC)

Toolbar missing

On my Preferences > Editor, "Show edit toolbar" and "Enable enhanced editing toolbar" are both checked, but the reftoolbar/2.0. no longer shows for me. I do have JavaScript enabled, and I use Firefox (54.0.1). Is it just me or what? Musdan77 (talk) 05:58, 13 July 2017 (UTC)

It works for me with Firefox 54.0.1 and Vector. What is your skin? Does it work when you are logged out? Does it work at simple:Wikipedia:Sandbox? There may be a problem with a gadget at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 09:02, 13 July 2017 (UTC)
@PrimeHunter:, (1) Skin: modern.js. (2) Yes. (3) Yes, but no "Cite" (but maybe that doesn't have it anyway). (4) There I have "refToolbar" checked, so I thought maybe they were cancelling each other out, so I tried unchecking it, but it didn't help. Musdan77 (talk) 05:27, 14 July 2017 (UTC)
Simple doesn't seem to have Cite. Modern has few users so things may be less tested there. Does vector work when you are logged in? PrimeHunter (talk) 08:13, 14 July 2017 (UTC)
If you mean: Does the toolbar work with vector (for me)? No. —Musdan77 (talk) 18:59, 14 July 2017 (UTC)
@Musdan77: Do your browser's developer tools show any JavaScript error messages? --AKlapper (WMF) (talk) 10:18, 13 July 2017 (UTC)
These also never worked for me but I expect that it may rely on User-Agent (I don't allow OS and precise browser version disclosure via that header). This may also be why I never could try the visual editor, but I don't need those and I understand it's my own problem... But in case you are using custom forged User-Agent, you could try using the default in case it helps. —PaleoNeonate - 10:33, 13 July 2017 (UTC)

Template:Userspace draft

This template has begun displaying an "Expression error: Unexpected < operator" message wherever it appears (even on the template page itself). As a result Category:ParserFunction errors has become bloated with about 2,000 entries for user pages containing the template. The template itself hasn't been edited for about a month, so the problem doesn't seem to arise from such an edit. Can someone please determine what's going on? Deor (talk) 19:04, 14 July 2017 (UTC)

There's your problem. Either restore the redirect from {{HoursElapsed}} to {{Hours elapsed}}, or just switch {{userspace draft}} to use Hours elapsed. (Bad idea, since HoursElapsed has ~40000 transclusions.) -- The Voidwalker Whispers 19:17, 14 July 2017 (UTC)
OK, thanks. I restored the redirect (which I assume was inadvertently blanked). Deor (talk) 19:20, 14 July 2017 (UTC)

II liga

Please switch (move) the "II liga" pages:

Thanks, Maiō T. (talk) 11:53, 16 July 2017 (UTC)

@Maiō T.: This isn't a VPT issue. Instructions for moving pages are at WP:MOVE; there are a number of reasons why you might not be able to move them, and for most such situations, WP:RM is the best route to follow. --Redrose64 🌹 (talk) 19:35, 16 July 2017 (UTC)

Mobile version should include categories

I wish wikipedia mobile version to include the categories of the article. Currently I need to switch to the desktop version to find out the categories. — Preceding unsigned comment added by 114.124.198.189 (talk) 20:01, 16 July 2017 (UTC)

(This should be in FAQ) See archives, for example Wikipedia:Village pump (technical)/Archive 155#Category in mobiles. But there is apparently a gadget, see Wikipedia:Village pump (technical)/Archive 155#Categories on mobile. --Redrose64 🌹 (talk) 22:00, 16 July 2017 (UTC)

XTools 3.0 Beta

The XTools and Community Tech teams are pleased to announce the public beta of XTools 3.0! After a year of work, we have rewritten the code for increased maintainability and stability. We have also redesigned the interface.

You are more than welcome to help us test it at xtools.wmflabs.org. We welcome your bug reports and feature requests on Phabricator (Please tag it with "tool-labs-tools-xtools").

On behalf of the XTools team, ~ Matthewrbowker Say something · What I've done 05:26, 17 July 2017 (UTC)

"Join the WikiWednesday Salon NYC by Union Square at 7PM on July 19!" keeps re-appearing on my Watchlist, even though I hit the "Hide" button. There's no "Dismiss" button. Any ideas why this just started happening? Beyond My Ken (talk) 05:25, 16 July 2017 (UTC)

@Beyond My Ken: Is there an "X" at top right of the banner? It might be subtly coloured; such buttons usually become more obvious when you hover your mouse over them. --Redrose64 🌹 (talk) 19:37, 16 July 2017 (UTC)
No, no "x" that I could find. I did manage to get rid of it by turning off the display of Geonotices in my Preferences, which is OK with me, as I never go to those events anyway - so my problem is solved, but I do wonder if others are having the same problem. Beyond My Ken (talk) 20:06, 16 July 2017 (UTC)
Oh, it's a Geonotice - I had the impression that it was a box-type thing like we use for the fundraisers etc. Anyway, it was set up with this edit and I don't see anything immediately wrong with the JavaScript. --Redrose64 🌹 (talk) 21:52, 16 July 2017 (UTC)
Well it looks like it may be a more general thing, because my watchlist notification of the current RfA, which normally goes away when I "dismiss" it, also keeps coming back. Beyond My Ken (talk) 23:06, 16 July 2017 (UTC)
Also -- and this is quite probably completely unrelated -- in my watchlist "Legend" box, the entry "m" just says "This is a" and doesn't follow with what I believe was a wikilink to WP:Minor edit. I just noticed that yesterday. Beyond My Ken (talk) 23:10, 16 July 2017 (UTC)
It's unrelated. User:Beyond My Ken/monobook.css hides "minor edit" with: 
#minoredit_helplink { display: none; 
}
I assume you only did it to hide the link below the edit summary box to not accidentally click it during an edit. You can try this instead: 
.editCheckboxes #minoredit_helplink { display: none; }
PrimeHunter (talk) 09:52, 17 July 2017 (UTC)
Thanks, that seems to have fixed that problem, and the other has gone away. Beyond My Ken (talk) 20:33, 17 July 2017 (UTC)

Issue with Template:Lang

See Muhammad Husayn Tabataba'i where the wiki code for the first line reads {{lang-fa|علامه سید محمد حسین طباطبائی}}, 16 March 1903 – 15 November 1981 "Persian: علامه سید محمد حسین طباطبائی, 16 March 1903 – 15 November 1981". How can it be fixed? I mean why does the Wikicode seem disordered? --Mhhossein talk 13:11, 16 July 2017 (UTC)

All of that looks fine to me, though I do not read the script in question. What do you see that does not look right? – Jonesey95 (talk) 13:25, 16 July 2017 (UTC)
The display of scripts with right-to-left text and the surrounding text can be browser dependant. If it looks odd in edit mode then I would ignore it. If it looks wrong when rendered then what is your browser and what do you see in your browser? Copy-pasting what you see doesn't work here. You have to describe it. PrimeHunter (talk) 14:40, 16 July 2017 (UTC)
What I get after rendering the code has no problem. My question was why it looked odd in edit mode? --Mhhossein talk 18:30, 16 July 2017 (UTC)
Jonesey95: Can you see the '16' just after {{lang-fa| while in edit mode? It should be {{lang-fa|علامه سید محمد حسین طباطبائی. --Mhhossein talk 18:33, 16 July 2017 (UTC)
@Mhhossein: This might be the same issue that was brought up at User talk:Miniapolis/Archives/2016/December#Shaikh Abdallah Mazandarani. --Redrose64 🌹 (talk) 19:31, 16 July 2017 (UTC)
Mhhossein Yes, in edit mode the number 16 is in the wrong place. I don't know that it really matters because it looks all right in regular view, but I'm sure there must be a way to move the 16 to the right place even in edit mode. Have you tried using one of the four solutions proposed by Redrose64 in the discussion linked just above?  – Corinne (talk) 12:58, 17 July 2017 (UTC)
This is not something that is easily solved and a side effect of mixing two languages with different directionality. The templates fix this when the HTML is rendered, but unless we start adding invisible characters around all of these words (which can be very confusing for editors and even for those copy pasting resultant text), there is simply no way around this problem in wikicode text as far as I'm aware. We can disable the bidi algorithm, but that would break the rendering of the arabic text itself. —TheDJ (talk • contribs) 13:19, 17 July 2017 (UTC)
So, I think the best solution to avoid confusion, is to put the rtl text for the last second. --Mhhossein talk 14:53, 17 July 2017 (UTC)
I don't understand what you suggest. As mentioned, it's browser dependant. It happens because there are digits between right-to-left text and left-to-right text, and the browser tries to guess which text the digits belong to. I see '16' in the right place in Firefox 54.0.1 but only because of '}}' between the Farsi text and '16'. Without '}}' the '16' moves. Your browser (which you still haven't identified) apparently doesn't make that distinction. It could probably be "fixed" by placing non-rendered English text between the Farsi and the number, e.g. <nowiki/>, <!--Start of left-to-right text--> or &lrm;, but I don't actually support such insertions if they are only done to affect the source mode. Note that &lrm; is not rendered as a left-to-right mark in source mode so if it works then it's only because it happens to contain Latin letters. PrimeHunter (talk) 15:30, 17 July 2017 (UTC)
PrimeHunter: Thanks for the point. I'm using Chrome. I was suggesting to write the rtl text when all other parts are written. --Mhhossein talk 05:27, 18 July 2017 (UTC)

Trouble with Lua tables

I was playing around with a Lua at Module:Sandbox/Ahecht/sandbox, and I came across an interesting case. I wrote a script that puts the input arguments into a table called args, passes args to a local function which changes all the values to "X", iterates through args using for k, v in pairs(args), and displays the values by printing both v and args[k].

If call the script with {{#invoke:Sandbox/Ahecht/sandbox|main|a|b|c}} I would expect the output to be {1=X (args[1]=X), 2=X (args[2]=X), 3=X (args[3]=X)}, but instead I get {1=a (args[1]=X), 2=b (args[2]=X), 3=c (args[3]=X)}.

What is the difference between v and args[k]? --Ahecht (TALK
PAGE) 17:12, 18 July 2017 (UTC)

One is a value, and the other is a table of values. And in Lua, tables are passed by reference. So when you iterate over args using k and v, you are automatically copying values into k and v from args, so using v gives you a copied value, which after manipulation changes v, but not args[k]. Using args however, you directly modify the original values being referred to by args (args itself is not copied/duplicated). —TheDJ (talk • contribs) 18:09, 18 July 2017 (UTC)
@TheDJ: Thanks. What has me confused is that the manipulation happens before I copy values into k and v, and that the results I get are backwards from what you described -- the manipulation changes args[k] but not v. --Ahecht (TALK
PAGE) 18:29, 18 July 2017 (UTC)
@Ahecht: Oh sorry I didn't read that carefully enough. It has to do with this being the frame's args. They are actually a metatable and the argument values are requested from MediaWiki on demand. The args of frames don't have a setter function, so you cannot change them (they only have getters and the (i)pairs iterator). —TheDJ (talk • contribs) 18:54, 18 July 2017 (UTC)

Request for Chinese Seal script support on Wikipedia.

This is mostly a request to Sir Andrew West (Traditional Chinese: 魏安, although more accurately: 西強男) known here on Wikipedia as @BabelStone: to create UniCode support for Chinese Seal script, the reason I'm posting it here and not on his talk page is because if he’s not interested but other linguists are (that may exceed his capabilities, or knowledge on the subject) that they may refer to this post. My reason for asking this is that Seal script is because here on Wikipedia (and by extension on other Wiki-projects) it is only ever represented in images and thus may be harder to insert in articles where Seal script was used in a historical context, having a character set for Seal script might make inserting them more easier in relevant contexts.

Current existing precedent would be Chu Nom, Tangut script, Khitan script, Etc. which are all no longer used in this day and age but their UniCodes greatly serve both the Wikipedia and historian communities.

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.

P.S. (Post-Script)

In case someone is also interested in creating support for Semi-cursive script, Chinese cursive script (“Sloppy script”), Oracle bone script, and various other Chinese scripts this would greatly benefit not just Wikipedia, ABD/and the Wiktionary, but also the entire community of Chinese historians, the reason I name the different “fonts” of Chinese is because they often have unique characters from which modern Chinese and Japanese characters are developed.

--58.187.171.100 (talk) 04:00, 17 July 2017 (UTC)

I wonder if this would be (technologically) similar to supporting hieroglyphics. Whatamidoing (WMF) (talk) 07:04, 17 July 2017 (UTC)
@58.187.171.100: What does "create UniCode support for Chinese Seal script" imply exactly? Looking at Seal script#Computer encoding it sounds like this is out of scope for Wikimedia as long as the Unicode Consortium does not include it? --AKlapper (WMF) (talk) 12:44, 17 July 2017 (UTC)
Wikipedia supported Egyptian hieroglyphics for five years before they were added to Unicode, so that's presumably not an absolute blocker. Whatamidoing (WMF) (talk) 21:16, 18 July 2017 (UTC)

Is there a good starting point (link/doc) on the current Search Architecture?

I am a little lost as to where to begin. I am looking for a general overview of the search architecture and it's extensibility. Any link or documentation would be greatly appreciated. Thanks Pj quil (talk) 14:33, 18 July 2017 (UTC)

mw:Extension:CirrusSearch, a MediaWiki specific wrapper around Elasticsearch. Wikimedia config part 1 and part 2 and Wikimedia documentation about setup. —TheDJ (talk • contribs) 16:13, 18 July 2017 (UTC)
Everything TheDJ said. I'll add that a good link from the extension's main page is mw:Help:CirrusSearch, which is probably the best place to see the documented syntax of Cirrus/Elasticsearch. FACE WITH TEARS OF JOY [u+1F602] 21:46, 18 July 2017 (UTC)

Failure to collapse in mobile view

(Following Nthep's suggestion, I'm copying this here from Wikipedia talk:Teahouse # Failure to collapse in mobile view.)

In Template:Tone/doc § Templates that might be a better fit than this one, the mobile view includes this paragraph on a light blue background, followed by a very long list, the output of {{backlog status}}, that should be collapsed but isn't.

Wikipedia's tagged articles: backlog by template's category

Wikipedia:Backlog lists tasks that should be done to improve Wikipedia (assuming the cleanup templates were placed correctly). Helping reduce backlogs is an important issue, so please feel free to help out.

[Long list commented out]


generated by this wikicode: 

* [[Template:Unreferenced]] for articles with zero references (use {{tl|refimprove}} for articles with insufficient or weak references)

{{Wikipedia template messages|state=collapsed}}
{{divhide|Wikipedia's tagged articles: backlog by template's category}}<!-- Copied from: Wikipedia:Template messages/Cleanup#Open_tasks —Geekdiva, 2016 -->
[[Wikipedia:Backlog]] lists tasks that should be done to improve Wikipedia (assuming the [[WP:TC|cleanup templates]] were placed correctly). Helping reduce backlogs is an important issue, so please feel free to help out.
{{Backlog status}}
{{divhide|end}}

Please {{Ping}} me to discuss. --Thnidu (talk) 20:59, 17 July 2017 (UTC)

Indenting problem with original post

Hi, Thnidu. The weak references){{Wikipedia in the source page is affecting the margins on the left and subsequent posts, like below. May you please press the "Enter" key between "references" and "Wikipedia"? Therefore, the alignment is fixed. Thanks. --George Ho (talk) 23:34, 17 July 2017 (UTC)
I have fixed the indenting problem. – Jonesey95 (talk) 00:52, 18 July 2017 (UTC)
@Jonesey95 and George Ho: Thank you both, colleagues. I saw the indentation problem but had no idea what caused it or how to fix it. Remember, this is code that I didn't understand most of, but just copied and pasted with only a little editing. --Thnidu (talk) 04:46, 18 July 2017 (UTC)
You're welcome; you can use either "Show preview" and/or "Show changes" next time as they are more useful to (double-)check mistakes. --George Ho (talk) 04:50, 18 July 2017 (UTC)
Thanks, George Ho. I'm familiar with these methods. But please reread what I just wrote. The indentation problem had nothing to do with any code that I had written. It was caused by something in the code that I copied and pasted, which I did not understand the workings of. --Thnidu (talk) 05:17, 18 July 2017 (UTC)
@Thnidu: The problem that is still visible at Wikipedia talk:Teahouse#Failure to collapse in mobile view is the absence of a newline before the box-type templates, in particular before {{Wikipedia template messages}}. Such templates should be placed at the start of a line, and navboxes (such as {{Wikipedia template messages}}) always break if placed in lists - and the breakage extends to the rest of the page. --Redrose64 🌹 (talk) 09:32, 18 July 2017 (UTC)

Redrose64 Thanks for the info. As I said above, I don't know anything about this code. But at least I know now something about not quoting it. --Thnidu (talk) 00:38, 19 July 2017 (UTC)

Date formatting

When I use citation templates and click the "today's date" button for "date accessed" (for example), the template automatically inputs the date as "16 July 2017," but I have noticed that bots go around and constantly correct this to "July 16, 2017." If the latter is the preferred date format, why don't we just change the citation templates? Steevven1 (Talk) (Contribs) (Gallery) 03:29, 17 July 2017 (UTC)

You are probably referring to a particular tool or gadget rather than the template alone? The citation templates themselves permit various date formats. However, articles can by convention, for consistency, use a particular date format (see Help:CS1#Dates, {{Use dmy dates}} and {{Use mdy dates}} templates). I hope this helps, if not, feel free to provide more details. I also would be interested in seeing a diff of such a bot edit, in case something is unexpected. Thanks, —PaleoNeonate - 03:51, 17 July 2017 (UTC)
Also bear in mind that some articles don't use citation templates, in which case, follow the existing citation style, including the format of dates within citations. Jc3s5h (talk) 11:47, 17 July 2017 (UTC)
In the standard Wikipedia editing text box (like the one I'm typing in right now), I click "cite." Then, at the top-left, under bold/italics buttons, there is a dropdown which says "Templates." When I click this and choose "cite web" (for example), then click the autofill button next to "Access date," the date is filled in as "16 July 2017". Bots regularly correct this to "July 16, 2017".....Here is one such example: https://en.wikipedia.org/w/index.php?title=DatingAdvice.com&diff=787903818&oldid=787153074 Steevven1 (Talk) (Contribs) (Gallery) 19:43, 17 July 2017 (UTC)
@Steevven1: Tony1 is not a bot, though he is using semi-automated assistance to make an edit like that one. Each article is required to have only one date style per WP:DATEUNIFY (with a small exception here or there). I am aware of no strictly-automated processes ("bots" as Wikipedia uses the term) which will make a change like that one (due to WP:CONTEXTBOT). --Izno (talk) 20:13, 17 July 2017 (UTC)
The documentation for {{cite web}} says of the accessdate parameter: Full date when the content pointed to by url was last verified to support the text in the article; do not wikilink; requires url; use the same format as other access and archive dates in the citations. It does not say "use the same date format as all dates in the article" and it is common practice for these to be in a diffewrent format. MOS:DATEUNIFY says Access and archive dates in an article's citations should all use the same format, which may be: the format used for publication dates in the article; the format expected in the citation style adopted in the article (e.g. 20 Sep 2008); or yyyy-mm-dd. These edits by Tony1 and others seem at variance with these guidelines, and perhaps should stop. DES (talk)DESiegel Contribs 00:10, 19 July 2017 (UTC)
You appear to have ignored the final paragraph of the section "When a citation style does not expect differing date formats, it is permissible to normalize publication dates to the article body text date format, and/or access/archive dates to either, with date consistency being preferred." Keith D (talk) 00:54, 19 July 2017 (UTC)
  • I've pinged User:Ohconfucius, but he's very busy in RL. He's the go-to for the tech and style sides of these scripts. Tony (talk) 05:30, 19 July 2017 (UTC)
    • The script that Tony uses is my creation, and part of the utilisation hinges on interpreting to what extent an article given satisfies WP:MOSNUM. Whilst it's true that articles' access dates and publication dates are allowed to be different and are different, they need to be uniform within each category. More often than not this is not the case in practice, and it's for the script user to determine whether (s)he opts to transform all dates to dmy/mdy, or transform only accessdates and archivedates into yyyy-mm-dd, for example. The tool allows for that choice. -- Ohc ¡digame! 07:37, 19 July 2017 (UTC)

Structured Data on Commons Newsletter, July 19, 2017

Welcome to the newsletter for Structured Data on Wikimedia Commons! You can update your subscription to the newsletter. Do inform others who you think will want to be involved in the project!

Structured Data on Wikimedia Commons?

The millions of files on Wikimedia Commons are described with a lot of information or (meta)data. With the project Structured Data on Wikimedia Commons, this data is structured more, and is made machine-readable. This will make it easier to view, search (also multilingually), edit, organize and re-use the files on Commons.

In early 2017, the Sloan Foundation funded this project (see documentation). Development takes place in 2017–2020. It involves staff from the Wikimedia Foundation and Wikimedia Deutschland (WMDE) and many volunteers. To achieve this, Wikibase support is added to Wikimedia Commons. Wikibase is the technology that is also used for Wikidata.

Recent developments: groundwork

  • A new and crucial technical step (federation) now makes it possible to reference data from one Wikibase website in another. Because of this, it will be possible to use Wikidata's items and properties to describe media files on Commons.
  • Another important piece of groundwork is under development: so-called Multi-Content Revisions. This feature allows structured data to be stored alongside wiki text, so that one wiki page can contain several types of content.

Team updates

  • Amanda Bittaker was hired as Program Manager for Structured Data on Wikimedia Commons. Amanda will take care of the overall management of the project.
  • Sandra Fauconnier (known as Spinster in her volunteer capacity) is the new Community Liaison. She will support the collaboration between the communities (Commons, Wikidata, GLAM) and the product development teams at the Wikimedia Foundation and Wikimedia Deutschland.
  • We have open positions for a UX designer and a Product Manager!

Talking with communities and allies

  • Long-term feedback from GLAMs. Besides the Wikimedia community, many external cultural and knowledge institutions (GLAMs - Galleries, Libraries, Archives and Museums) are interested in Structured Data on Commons and are willing to provide feedback on the long-term plans for the project. Alex Stinson, GLAM strategist at the Wikimedia Foundation, is currently in contact with Europeana, DPLA, the Smithsonian and the National Archives of the United States. Alex is also looking for other GLAM institutions who might be able to advise on the long term. If you know of an institution or partner that may be appropriate for consultation, do get in touch with Alex.
  • Jonathan Morgan, design researcher, is starting to work on two projects:

What comes next?

  • The Structured Data on Commons team meets in the week after Wikimania to lay the groundwork for the next steps. This includes new backend development and design work, for better and more clear integration of the structured data in pages on Wikimedia Commons.
  • The project's information pages on Wikimedia Commons will receive a long overdue update in the upcoming months. The team will also work on more and better communication channels. Feedback, wishes and tips are welcome at the project's general talk page.

Get involved

Many greetings from SandraF (WMF) (talk), Community Liaison for this project! 13:55, 19 July 2017 (UTC)

Full page redirect?

Not... totally sure what happened, but someone more techy than me should probably look over this thread and this thread in case it turns out to be "a thing". Apparently someone somehow redirect an entire article to another website? TimothyJosephWood 13:28, 19 July 2017 (UTC)

It wasn't a redirect but just a full page external link made with template vandalism. It's not a new thing. The template has been protected and the user blocked. PrimeHunter (talk) 14:24, 19 July 2017 (UTC)
No worries. Just wanted to make sure someone who knows how to computer was aware. Seems quite a few people are judging by how many times the issue has popped up on my watchlist in the past couple of hours. TimothyJosephWood 14:40, 19 July 2017 (UTC)

Bots Newsletter, July 2017

Bots Newsletter, July 2017
 

Greetings!

Here is the 4th issue of the Bots Newsletter (formerly the BAG Newletter). You can subscribe/unsubscribe from future newsletters by adding/removing your name from this list.

Highlights for this newsletter include:

BAG

BU Rob13 and Cyberpower678 are now members of the BAG (see RfBAG/BU Rob13 and RfBAG/Cyberpower678 3). BU Rob13 and Cyberpower678 are both administrators; the former operates BU RoBOT which does a plethora of tasks, while the latter operates Cyberbot I (which replaces old bots), Cyberbot II (which does many different things), and InternetArchiveBot which combats link rot. Welcome to the BAG!

BRFAs

We currently have 12 open bot requests at Wikipedia:Bots/Requests for approval, and could use your help processing!

Discussions
New things
Upcoming
Wikimania

Wikimania 2017 is happening in Montreal, during 9–13 August. If you plan to attend, or give a talk, let us know!

Thank you! edited by: Headbomb 17:12, 19 July 2017 (UTC)

(You can subscribe or unsubscribe from future newsletters by adding or removing your name from this list.)

Search has gone crazy

Tracked in Phabricator
Task T171112

If I search for ~"universty" (intentionally misspelled so I can fix them), I get over a million articles, every page that has 'university'. This was not like this yesterday. Who changed what? Chris the speller yack 20:09, 19 July 2017 (UTC)

It's working fine for me. Are you getting this URL? Eman235/talk 20:24, 19 July 2017 (UTC)
@Chris the speller:, are you using the separate search page here and pressing "Enter" to start the search? I was able to reproduce the behavior, but only in the separate search page pressing "Enter" ("University" is auto-highlighted as first suggestion in the dropdown list and gets automatically selected regardless of the actual edit field value. When you press "Enter" --> wrong result). If you press the fancy blue "Search" button instead or use the small embedded search field in the upper right corner, the edit field value is used as it is supposed to, and you get the correct result (3 hits). This inconsistency seems to be a minor bug, and it may be new - I haven't noticed that odd behavior before. GermanJoe (talk) 21:26, 19 July 2017 (UTC)
Yes, I was pressing "Enter" on the separate search page. Maybe I had been using the "Search" button until today, so it looked like a new bug. I guess I can live with using the search button, but it's pretty natural to press the "Enter" key as soon as you finish typing instead of moving your hand to the mouse. Thanks for the help. Chris the speller yack 21:43, 19 July 2017 (UTC)
This is phab:T171112. PrimeHunter (talk) 22:19, 19 July 2017 (UTC)

Why doesn't the wiki software automatically remove double-spaces after periods/sentences?

I just encountered an article in which many sentences were followed by double-spaces.

As anyone reading this probably knows, double-spacing after a period/sentence is archaic behavior that was taught during the era of typewriters, because all typewriter fonts were monospaced. As such, double-spacing created a helpful, visual delineation between sentences. But the practice is wholly unnecessary in modern word processors using variable-width fonts (which is, of course, what the wiki software is and does).

I'm frankly surprised that the wiki software doesn't automatically remove double-spaces after periods (at least in normal paragraphs using variable-width fonts). Shouldn't it? — Preceding unsigned comment added by SyncopatorSyncopator (talk • contribs) 05:21, 19 July 2017 (UTC)

Because it would be ineffectual. Right from the very start of HTML, web browsers have compressed whitespace except where explicitly instructed not to (such as the &nbsp; character), so a long row of spaces like this is displayed as a single space. There's no point in doing something that we are certain is going to be done elsewhere, and probably more efficiently. --Redrose64 🌹 (talk) 09:27, 19 July 2017 (UTC)
Further to that, when you see double-spacing in articles it's often intentional on the part of the article's writers, as many editors find it makes navigating the edit window easier by providing a clear visual cue in the monospaced edit window. Removing it wouldn't just be ineffectual in terms of display output, but would be actively disruptive. ‑ Iridescent 09:32, 19 July 2017 (UTC)
And our MOS:DOUBLE SPACE explicitly allows double spaces. Automatic removal would require a lot of rules about when it's safe to remove it, and "safe" may only last until the next edit. Imagine for example a carefully spaced pre block where somebody accidentally disables pre, the software removes a lot of intentional spaces, and pre is then readded. PrimeHunter (talk) 09:45, 19 July 2017 (UTC)

Double-space could indicate break for machine translation

Although ending a sentence with two spaces was common with typewriters (and muscle memory for touch typists), I discovered it to be the "way of the future" to indicate end-of-sentence for clever auto-translation of text ending at an abbreviation, to avoid making a run-on sentence, such as:

"There are 50 states in the U.S.  Army and navy services are nationwide as Federal military." (where the extra space after U.S. avoids "U.S. Army").

Hence, where 2 spaces followed a dot, the computer translator would treat the subsequent text as the start of another sentence, without any meta-characters inserted to force end-sentence parsing. It is a phenomenal standard from typewriter technology, and the way of the future in machine translation. -Wikid77 (talk) 07:51, 20 July 2017 (UTC)

Automated detection of dead links

A reader contacted Wikimedia ticket:2017072010002077 stating they had developed a small program to easily detect dead or inaccessible links. My initial thought was that we must have a bot looking for these but I'm thinking that's not the case because I often find dead links while searching for something else. Should we have such a bot? And if so, with the code this person has developed be of use or are but developers perfectly capable of doing this themselves. I'll point the reader to this discussion but I thought I would get some preliminary feedback before encouraging them to join in the discussion.--S Philbrick(Talk) 14:55, 20 July 2017 (UTC)

User:InternetArchiveBot by @Cyberpower678: does do this as part of their job. Jo-Jo Eumerus (talk, contributions) 14:58, 20 July 2017 (UTC)

Linking Interwiki

Is there a direct way to link images in Interwiki without copying over the image into each language such as this one: [1]. Interwiki seems to work differently for text than for images and could someone link that image here or do a nowiki of the format which works here? JohnWickTwo (talk) 16:52, 20 July 2017 (UTC)

@JohnWickTwo: If you mean "use as an image", no, because most wikis with local upload also have non-free content policies which must be observed on that local wiki, while files which are freely-licensed should be hosted at Wikimedia Commons. If you mean, "link to the image on the other wiki as a wikilink", that's: ru:Файл:Плохие спят спокойно.jpg. --Izno (talk) 17:07, 20 July 2017 (UTC)
My attempt to do this gave me a link only to the Interwiki image file but not the image directly. Do I need to copy the Interwiki image into Wikicommons first before the image can be used, for example, in an Infobox on English Wikipedia? JohnWickTwo (talk) 17:34, 20 July 2017 (UTC)
If the image is freely-licensed, then it may go to Commons. If you would like to use it here and it is not free, you need to a) copy it here and b) assure other users that the WP:NFCC are met partially by filling in and placing a {{Non-free use rationale}} on the file page as well as that c) the use of the image in that article satisfies the WP:NFCC for that article. --Izno (talk) 18:09, 20 July 2017 (UTC)
Both WP:NFCI#1 (using a film poster for identification, as it carries implicit understanding of the film's marketing and branding), and {{Film poster rationale}} seem to justify the use of promotional unaltered film posters. This sounds redundant since Wikipedia consistently uses such poster art on hundreds of film articles, though it sounds like it is still required on a film-by-film basis anyway. JohnWickTwo (talk) 18:22, 20 July 2017 (UTC)

RFC re Character counter in edit notes window

withdrawn. To hell with it. Jytdog (talk) 18:45, 20 July 2017 (UTC)

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

The dev team has added a twitter-like "character counter" to the edit notes window as described here. Its initial implementation is buggy as discussed above.

Please !vote:

  • remove to get rid of this
  • keep to keep it as it is, where you cannot get rid of it
  • make opt-in to make it not a default, but available via preferences
  • Make opt-out to make it default but removable via preferences

-- Jytdog (talk) 15:24, 20 July 2017 (UTC)

!votes

  • remove immediately. Fix it offline and make it opt-in if people really want it. Jytdog (talk) 15:24, 20 July 2017 (UTC)
  • keep Funny, it seems like this feature has been around for a while, certainly a few weeks. So I am not convinced that the recent issues are necessarily the feature's fault. In my mind, an opt-in/opt-out provision needs a strong justification and I don't see it. Jo-Jo Eumerus (talk, contributions) 15:29, 20 July 2017 (UTC)
  • make opt-in — A gadget some people may find useful, but that should not be on by default. —PaleoNeonate - 15:58, 20 July 2017 (UTC)
  • Remove now, add as a gadget later What Jytdog says. Buggy features shouldn't be enabled and if it gets fixed, it should be up to the individual editor to decide. I have no preference whether opt-in or opt-out is a better approach though. Regards SoWhy 16:02, 20 July 2017 (UTC)
  • I see three aspects here, two of which Jytdog is conflating with this poorly-considered RFC, on which I will !vote individually. For the record, note this is being posted with my personal account. Now, time to go back from my lunch break. Anomie⚔ 16:35, 20 July 2017 (UTC)
    • Actual bugs: Temporarily revert/disable if phab:T169982 isn't already fixed. I see gerrit:366569 has already been submitted to disable it, while other patches have been submitted that may fix the issue. I note that in large part this sort of thing is WP:CONEXCEPT, although I support rolling back in the face of actual bugs if a fix isn't quickly forthcoming. Anomie⚔ 16:35, 20 July 2017 (UTC)
    • All the WP:IDONTLIKEIT: Speedy keep Some people have a very bad habit of loudly complaining every time someone moves their cheese. You're experienced editors who know how to use user scripts and gadgets to disable things you don't personally like. That's a much better option that forcing every newbie to find the options to enable things that they'll very likely find very helpful just because a few of the old guard loses their mind every time the slightest thing changes. Anomie⚔ 16:35, 20 July 2017 (UTC)
    • Also, I !vote to Trout Jytdog for submitting this RFC in the first place, per the second bullet. Anomie⚔ 16:35, 20 July 2017 (UTC)
  • Make opt-in; if that is not possible, remove. The counter interferes with my ability to actually see what I have typed in the bar. bd2412 T 18:44, 20 July 2017 (UTC)

Discussion

  • For me this adds no value. When I run out of room, I run out of room, and I don't need a counter. If other people think this is nice-to-have, well that's great. Let them have it. But don't add more clutter by default. Jytdog (talk) 15:27, 20 July 2017 (UTC)
    • Jo-Jo it is the counter. See phab:T169982 linked above. Jytdog (talk) 15:49, 20 July 2017 (UTC)
      Well, at least for me the counter has been displaying for far longer than these bug reports. A possibility is that the counter at first didn't break the edit summary box. Jo-Jo Eumerus (talk, contributions) 16:07, 20 July 2017 (UTC)
      Maybe if using the visual editor or wikied? It only appeared recently for me. —PaleoNeonate - 17:51, 20 July 2017 (UTC)
  • Jytdog, you should consider removing this RFC as not being pointful. The patch is temporarily remove this was submitted before you started this. It looks like the fix is almost done, but it takes about two weeks to get an OOjs UI change through the systems. Whatamidoing (WMF) (talk) 17:46, 20 July 2017 (UTC)
Your comment seems to be communicating that the "WMF contributor team" is uninterested in feedback from contributors on how the counter should be implemented with regard to default, opt-in, opt-out, or not all. Please correct me if that if I am mis-hearing you. Jytdog (talk) 17:57, 20 July 2017 (UTC)
That is good news. The main point of the RfC is about what happens after it is fixed. Jytdog (talk) 18:04, 20 July 2017 (UTC)
  • User:Anomie I don't use any gadgets: i don't know how to use them and don't want to take time to learn. What i want from the software is that it works and doesn't fight me. I am sorry you found the RfC difficult to understand.Jytdog (talk) 18:05, 20 July 2017 (UTC)
  • @Jytdog: please don't hold RfCs at VPT. Consider holding this at WP:VPR instead. --Redrose64 🌹 (talk) 18:39, 20 July 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Annoying new "Search for contributions" user interface

The latest MediaWiki software release has changed the "Search for contributions" means of selecting the date range:

 

Gone are the convenient drop-downs for choosing a year and month. In their place, are new "From date" and "To date" boxes with "No date selected" inside them. My initial reaction is that this is not an improvement, as it is tedious to select a date range now. Before it defaulted to the end of the month, now it forces you to select a specific date; there is no default. Adding a specific day-of-the-month drop-down would have been better. Would be interested in what others think of it. Can someone link to the phabricator or other project page where this change was discussed? I'd like to see the rationale for it. Thanks. wbm1058 (talk) 12:55, 12 July 2017 (UTC)

@Wbm1058: The relevant ticket would be phab:T120733. Was also announced in the Tech News. —TheDJ (talk • contribs) 13:03, 12 July 2017 (UTC)
Thanks. I see that this was one of the community wishlist winners. I support the need, but I'm not yet a fan of the DateInputWidget implementation. Maybe I'll get used to it. It did take me some time to figure out how to tweak URLs when I needed to specify a specific range. – wbm1058 (talk) 13:22, 12 July 2017 (UTC)
Maybe someone can write a more specific DateRangeInputWidget. Something like this. I'm sure there are UI improvements that can be made. There almost always are, it's just resourcing it which is often the difficult part. But do leave your suggestions. —TheDJ (talk • contribs) 14:23, 12 July 2017 (UTC)

Sounds like a classic workflow (https://xkcd.com/1172/) issue. Technically, there is already another date picker (making it two of them):

But that's not all, there seems to be yet another one coming up for recent changes that will result in 3 different date pickers (if either of them isn't assimilated first). It is likely that the incoming one will become the dominant one, or perhaps as a result of recent changes improvements the relevant team may help standardize and pick one before deploying them to all change list special pages.

Hopefully relevant teams will come to their senses and fix this inconsistency problem before it gets widely deployed.14:36, 12 July 2017 (UTC) — Preceding unsigned comment added by 197.218.91.42 (talk)

Any solution that allows me to independently select year, month and day, with a default in place (similar to how it worked before) would be appreciated. I don't usually feel the need to browse through calendars looking for a date, and rarely is it important to know whether an edit was made on a Sunday or on a Thursday. A common scenario in searching for an edit to "blame" is, having narrowed it down to a certain month, then needing to drill down to the specific day. On busy articles with hundreds of edits in a month, you want to do the equivalent of a binary search. That's when you would like to say, start from the 15th to see if it's in the first or second half of the month. Couldn't do that before. The one case I can think of where you want to specify a specific range is when you want to link to a subset of edits that were made as a set to for some common purpose. In that use case, not only do I want to specify a date, but also an hour and minute. That's where I learned to plug those directly into URLs. wbm1058 (talk) 22:46, 12 July 2017 (UTC)
Hmm... This doesn't look like a technical issue but rather a complaint about the update. Maybe this needs a proposal, wbm1058. Should we have the switch between the calendar update and the old "convenient drop-downs" proposed at WP:village pump (proposal) then? --George Ho (talk) 22:54, 12 July 2017 (UTC)
Please leave feedback in phabricator as well, possibly as a new ticket with suggestions. Not putting things in phabricator is the surest way to guarantee that it won't be improved :) —TheDJ (talk • contribs) 22:56, 12 July 2017 (UTC)
@Wbm1058: The best way to do a binary search of page history is to use the new "Browse history" feature in the diff interface (Extension:RevisionSlider). Kaldari (talk) 16:52, 13 July 2017 (UTC)
OK, fair enough. There's another learning curve in figuring out how to efficiently use that "widget". The change to Special:Contributions may motivate me more to try that solution, next time I need to search a page history for a particular edit. wbm1058 (talk) 17:14, 13 July 2017 (UTC)
I'm not really seeing the use case for "revision slider". This phab comment resonates with me: ?action=history is also better than RevisionSlider for history-diving, due to the information density: I can, at a glance, work through literal hundreds of changes in search of some nugget. RevisionSlider is painful on this point: click the paging widget, wait for RevisionSlider to load the next batch of diffs, move the newrev bubble to a new column, find nothing in the diffs (because they display no metadata like the associated edit summary save by hovering over each diff individually, which is a BIG piece of comprehending quickly what has changed), go back to grab the oldrev bubble to move to the current page, rinse and repeat. And RevisionSlider only loads, at-most, around 30 diffs. I can assess the potential relevance of each diff much better from ?action=history. wbm1058 (talk) 07:37, 21 July 2017 (UTC)
Tracked in Phabricator
Task T170502

I filed a Phabricator task to have an option added in the user preferences, so a switch between old and new interface will be possible. --George Ho (talk) 23:09, 12 July 2017 (UTC)

TheDJ, I was told that I was describing the "solution" there, not a "problem". What else can I do to address Wbm1058's concerns? --George Ho (talk) 15:09, 13 July 2017 (UTC)

Tracked in Phabricator
Task T91148

It has been pointed out above that there are at least 3 different "date pickers". The wishlist survey item and phab describe the problem: There is no good way to search a window of time in Special:Contributions. I don't see where any proposed solution was specified, or submitted to the community for comments and approval. Do we need three different versions of "DateRangeInputWidget". Where are the requirements specifications for the widget(s)? wbm1058 (talk) 15:19, 13 July 2017 (UTC)

Do we even need a "widget" at all to solve the problem? wbm1058 (talk) 15:29, 13 July 2017 (UTC)
Here you go, wbm1058: mw:Extension:Widgets. You may go to Phabricator to comment there if you wish. I'll tell them your opinions about this soon. --George Ho (talk) 16:20, 13 July 2017 (UTC)
There isn't any Widget: namespace implemented on English Wikipedia, so it doesn't seem that this is using the extension. I believe this was implemented with PHP or JavaScript added to the MediaWiki core. It seems that, on a meta level, excluding the community from discussions about solutions is just setting up for repeated cases of workflow conflicts. This isn't how WP:BRFA operates. There has to be a consensus to do anything with bots. – wbm1058 (talk) 16:57, 13 July 2017 (UTC)
I see the two different datepickers at Special:Contributions and Special:Newfiles, but I don't see the third mentioned datepicker at Special:RecentChanges. Is that maybe a gadget that I don't have enabled? FWIW, there is already a bug about consolidating the date pickers: T91148. Kaldari (talk) 17:24, 13 July 2017 (UTC)
Thanks, that link to the datepickers phab is very helpful. After seeing who is behind them, I bite my tongue with regard to further criticism. I'm optimistic that this will sort itself out satisfactorily. Having the ability to specify a specific time would be helpful, so hopefully the consolidated picker will be full-featured in that regard. wbm1058 (talk) 18:02, 13 July 2017 (UTC)
The third (undeployed) incoming date picker will be this (https://phabricator.wikimedia.org/T162784) . The question is whether this will be an extension of one of the others or yet another datetime widget. Also, although the other two datetime pickers look similar, only one of them allows time, and perhaps the "time" is only used in Special:Apisandbox. 21:12, 13 July 2017 (UTC) — Preceding unsigned comment added by 197.218.80.182 (talk)
...No, but there is WP:Widget... an essay. --George Ho (talk) 20:06, 13 July 2017 (UTC)
LOL. Should that be tagged with {{Humor}}? I suppose that's not necessary. wbm1058 (talk) 02:38, 14 July 2017 (UTC)

It just occurred to me that I was thinking more of &action=history when I made some of my comments above.  

Another drop-down for "From day (and earlier):" would be nice.

I think I might have a panic attack if that one gets "widgetized" ;) wbm1058 (talk) 02:38, 14 July 2017 (UTC)

Strictly speaking, those special pages don't use a date range picker. They use twin date pickers that largely operate independently. That's why for example, if someone enters a "start date" that is later than a "end date" it simply switches them around, and vice versa.

Based on the mockups in the related task, they seem to be designing a "true" date-time range picker. So this may replace the sets of date pickers in special:contributions and special:newfiles. Considering that the plan is to consolidate change list pages with consistent edit review tools, this likely to happen.

P.S. As far as the history page dropdowns are concerned, there is already a plan to replace them (https://phabricator.wikimedia.org/T56747). — Preceding unsigned comment added by 197.218.84.30 (talk) 22:01, 16 July 2017 (UTC)

A ticket is just a ticket, not a plan. —TheDJ (talk • contribs) 19:54, 17 July 2017 (UTC)
And link is just a link.
The goal or plan is to standardize the user interface (https://www.mediawiki.org/wiki/Wikimedia_Audiences/2017-18_Q1_Goals). Turning those awful dropdowns into a "standard" date picker is certainly one way of standardizing them, although there are many ways to skin a cat. Whether they do it or not is anyone's guess. 197.218.88.161 (talk) 20:56, 17 July 2017 (UTC)

Fixing a typo.....

(for the benefit of those reading this thread "after the fact", the file which is currently named "" (see image right) was named "File:Chandrasekhar's H-fucntion.pdf" when this thread was started)

The name of this file is a typographical error. I fixed it, not realizing it was the name of a file linked to by the article, and then the graphic did not appear. So I restored the typo. There is a danger that others may try to fix the typo. How can I change the name of the file? (There's no "move" button.) Michael Hardy (talk) 00:59, 21 July 2017 (UTC)

[[:]] is a "view" of the original file at Wikimedia Commons. It's the Commons file that needs to be renamed. I've submitted a request for that to occur. It should occur within the next couple of days. A bot will automatically update the local "view" and any articles which use it. DH85868993 (talk) 02:42, 21 July 2017 (UTC)
The file has been renamed. DH85868993 (talk) 03:11, 21 July 2017 (UTC)
@Michael Hardy: Files are renamed just like regular pages, using a "Move" tab - but the normal function of this tab is only available to those with the "filemover" right. It is normal to give some notice of a rename, so that others may share in the decision; so on Commons, although the "Move" tab is present on file description pages for everybody, if you don't have the filemover right it doesn't actually move the page - instead, it starts a Javascipt where you fill in a form explaining why you want it renamed. More at c:Help:RenameLink. --Redrose64 🌹 (talk) 09:53, 21 July 2017 (UTC)

Links starting with [[:: no longer valid?

DatGuy pointed out to me that the bot links at Wikipedia:Bots/Requests for approval#Approved requests aren't rendering properly. I looked into it, and the template, {{botlinks}}, has not changed in a while, but has always generated links that look like [[User:EarwigBot]] in the absence of a project argument. It looks like this is no longer valid; was there a software change? I can't find any indication of such. It looks like some other templates such as {{former admin}} are broken as well; see e.g. Wikipedia:Former administrators/alphabetical/A. This issue is probably in a few different places. Should we just change all the templates? — Earwig talk 01:28, 20 July 2017 (UTC)

@The Earwig: This is a very recent change. 10.000 Watts of Artificial Pleasures has an example which I found by scanning a database dump. The page looked correct until I purged the page to get it rebuilt by the latest software. There are ~130 examples of this kind in mainspace, not involving any templates. -- John of Reading (talk) 06:00, 20 July 2017 (UTC)
Similar problem reported at Template talk:Commons category multi#Broken links. --Redrose64 🌹 (talk) 08:26, 20 July 2017 (UTC)
Please file a phabricator report —TheDJ (talk • contribs) 09:41, 20 July 2017 (UTC)

It has always been undefined behavior. With wikitext, anything that works and isn't explicitly written down as an acceptable markup should be treated as undefined behaviour or a software issue (a bug) that can be killed at any time. Such a change is deliberate: gerrit:361597

Neither mw:Help:Links nor meta:Help:Wikitext_examples includes this "strange" markup. The former is the closest thing to an "official guide". P.S. The real wikitext "standard markup specification is the parser tests. 09:58, 20 July 2017 (UTC) — Preceding unsigned comment added by 197.218.91.11 (talk)

@The Earwig: The {{botlinks}} template has not always generated links that look like [[User:EarwigBot]] in the absence of a project argument - only since this edit five years ago. The first colon is necessary if |Project= is a language code, otherwise it is superfluous. --Redrose64 🌹 (talk) 11:22, 20 July 2017 (UTC)
I've changed both {{botlinks}} and {{former admin}} —TheDJ (talk • contribs) 11:31, 20 July 2017 (UTC)
I know there are other templates that can potentially produce links like that, as adding a "defensive" colon is an easy way to ensure that interwiki and interlanguage links work (I'll have to search through my contribution history, but I know I've made some out of laziness). I made a quick template {{Trimc}} that can be used in such templates once they're identified. Would some sort of detection or categorization of pages with these sorts of links be feasible? --Ahecht (TALK
PAGE) 15:32, 20 July 2017 (UTC)
I had to update Module:Pagelist, as several of its testcases were broken by this change. I'm still searching for the templates that I made with defensive colons, but I haven't found them yet. --Ahecht (TALK
PAGE) 22:12, 20 July 2017 (UTC)
@The Earwig, Redrose64, and John of Reading: Is there any way to search Wikipedia's HTML output for "[[:"? Wikipedia's search only searches wikitext, so it won't catch templates that output double colons, and Google ignores strings that are entirely punctuation. --Ahecht (TALK
PAGE) 22:32, 20 July 2017 (UTC)
@Ahecht: I guess you could take a database dump and run Parsoid over it and search for that string in the output. This depends on whether Parsoid does the same thing (I have no clue about that, or experience running Parsoid on database dumps, for that matter). Even if Google could search for the string, the change was recent and some pages need to be purged before the issue will appear. — Earwig talk 23:15, 20 July 2017 (UTC)

I've posted the results from my database scan at User:John of Reading/Sandbox. I've fixed all the examples of a literal [[:: in mainspace, except for Array slicing where it's inside <pre>...</pre> tags; I've also fixed about 30 examples in other namespaces. I have not fixed the hundreds of pages in the Wikipedia namespace where custom signatures are now broken (eg 1, 2, 3); my database dump doesn't include any talk pages, but there are doubtless hundreds more in those namespaces. I have not fixed hundreds of pages maintained by two bots, but have posted at relevant talk pages in case some code needs to change (COIBot, WP 1.0 bot). -- John of Reading (talk) 09:55, 21 July 2017 (UTC)

From/To field alignment in Special:Contributions

A recent MW upgrade brought us full date entry fields for "From date:" and "To date:". These two items are forced (via <br>) to be on separate lines. But they each use a single space to separate the field-name from the entry box itself. The field-names are different widths, which means the entry boxes are not aligned with each other. It would be more visually clear and less confusing if they were aligned (using a table for these two fields or putting them in a right-justified container <div>?) because their values relate to each other and are in the same format. DMacks (talk) 04:01, 17 July 2017 (UTC)

See a screenshot of the new "Search for contributions" user interface above. I agree with DMacks on field alignment if they are separate lines (which is unnecessary on wide screens). – wbm1058 (talk) 08:52, 21 July 2017 (UTC)

Hmm, this suggestion is like asking to fix one window in a house while leaving the rest of the windows broken. For one thing, using a table for layout often tends to be bad design (an html table is designed for tabular data), and tends to cause more problems than it fixes (e.g. infoboxes that often render badly on mobile). The right approach is probably to convert it all to OOUI, rather than the Frankenstein that it currently is. Special:newfiles for example is well aligned, and it is probably possible to make those date input boxes to appear in the same line as their labels.

Until that happens any knowledgeable admin can improve that and the rest of the form using a bit of CSS, for example using left padding on the date input box, and reasonable alignment / padding between other elements. 10:45, 21 July 2017 (UTC) — Preceding unsigned comment added by 197.218.82.59 (talk)

Tech News: 2017-29

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

Recent changes

  • "Wikimedia Labs" is now called "Cloud VPS". "Wikimedia Tool Labs" is now called "Wikimedia Toolforge". This is to help clarify the purpose of these services. [2]

Problems

  • On some pages, the Table of Contents is not being shown. It will normally appear if you edit the page again. Investigation is currently ongoing. [3]

Changes this week

  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 July. It will be on non-Wikipedia wikis and some Wikipedias from 19 July. It will be on all wikis from 20 July (calendar).

Meetings

  •   You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 18 July at 19:00 (UTC). See how to join.
  •   You can join the next meeting with the Architecture committee. The topic this week is: Migrate to HTML5 section ids. [4] The meeting will be on 19 July at 21:00 (UTC). See how to join.

Future changes

  • Page Previews, currently a Beta Feature, will be enabled for logged-out users for all remaining Wikipedias (with the exception of English and German) the week of 24 July. An A/B test will be run on English Wikipedia to collect data before approaching the community for further discussion. [5]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

22:59, 17 July 2017 (UTC)

It doesn't clarify. What is "VPS"? --Redrose64 🌹 (talk) 09:32, 18 July 2017 (UTC)
@Redrose64: Virtual Private Server, which in this context just means a virtual server   -- There'sNoTime (to explain) 09:36, 18 July 2017 (UTC)
@Redrose64: See User talk:Jimbo Wales/Archive 221 § Wikimedia Cloud for a recent discussion about this. While the weathermen continue to forecast clearing skies, they remain "cloudy" ;) wbm1058 (talk) 13:15, 21 July 2017 (UTC)

Improper formats for bullets when images are used

It seems that when an image is left justified in the Cast section of film articles, that the bullet format usually used to highlight individual actor names in lists do not reformat with the shift of text material to the right. The format bullets are over-layed on the image rather than being shifted to the right with the text. This happens on multiple film articles I have seen. See this example at The Idiot (1951 film). JohnWickTwo (talk) 15:07, 22 July 2017 (UTC)

@JohnWickTwo: We have {{flowlist}} for this problem. —TheDJ (talk • contribs) 15:29, 22 July 2017 (UTC)
Works exactly as advertised. JohnWickTwo (talk) 15:36, 22 July 2017 (UTC)

Why do some main space articles have the noindex meta tag?

I'm looking at the HTML source of some articles, and I'm noticing some have this tag:

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

...and some don't, but none of them have the {{NOINDEX}} tag.

Examples:

The only difference I see is that the articles without the noindex tag are recently created. If that's why the tag is there, how long does it take to expire? ~Anachronist (talk) 16:23, 22 July 2017 (UTC)

It takes 90 days on new articles unless they are reviewed. See Wikipedia:Controlling search engine indexing#Indexing of articles ("mainspace"). PrimeHunter (talk) 16:27, 22 July 2017 (UTC)

Revert dialog and Chrome

I have been having an issue with the revert function on Chrome for MacOS. When I click on "restore this version", the usual dialog box pops up with the prompt: "Please specify a reason for the revert:". If I change focus to another tab and then go back to the original tab, the revert is cancelled with a message: "Grabbing data of the earlier revision: Aborted by user."

Does anyone else experience this issue and does anyone know if there is a way to fix it?- MrX 16:01, 22 July 2017 (UTC)

This is a Twinkle feature on diff pages. It works for me in Firefox on Windows 10. In Microsoft Edge and Internet Explorer I cannot change tab while the dialogue box is open. PrimeHunter (talk) 16:22, 22 July 2017 (UTC)
Thanks PrimeHunter. I guess I will raise the issue with the developers, unless someone already has.- MrX 18:26, 22 July 2017 (UTC)

Non-free file rescaler

It seems like User:Legoktm/rescaled.js (@Legoktm:) does not remove the "orphaned non-free revisions" template anymore when used to deleted orphaned non-free revisions. Jo-Jo Eumerus (talk, contributions) 14:58, 20 July 2017 (UTC)

@Jo-Jo Eumerus: Please provide examples of where it didn't remove the template, where it should have. —TheDJ (talk • contribs) 15:47, 20 July 2017 (UTC)
My script that does the same and is based on Legoktm's started doing the same the other day. Checking it against Ronhjones version and I made this change to my script which seems to have resolved it. Nthep (talk) 16:00, 20 July 2017 (UTC)
@TheDJ: Here Jo-Jo Eumerus (talk, contributions) 16:09, 20 July 2017 (UTC)
@Jo-Jo Eumerus: I've gone through the script and retested the replace regex on the content of the page (at the time you deleted). It seems to work, so i'm not sure why it has not for you... Maybe your connection just was bad ? or you closed the page too fast ? —TheDJ (talk • contribs) 00:22, 23 July 2017 (UTC)

Verifying status and length of protection

I'm a little embarrassed to be asking this question as it seems like I should be able to answer it, but I'm trying to find an easy way of determining whether an article is protected and how long the production will last.

In many cases, there will be a padlock in the upper right corner of the article, but my understanding is that the active adding protection and the act of adding a padlock are two separate actions, and sometimes the first is done in the second is missed. (I have no idea why it should take two steps but that's a question for another time.) Even of if the padlock does exist, I thought it would be reasonable to click on it to find how long the protection will last but that doesn't tell me.

Yes, I'm aware that if I look on the history page and search carefully, I might find an edit indicating that the article has been protected and tell me how long. That's what I usually do, but at least once recently I was dealing with an article which was protected and I was unable to find that edit. There must be an easier way of identifying the status and length.

While my question is general it is prompted by someone asking why they cannot see the edit buttons on John Heard (actor). I believe that if an article is protected, those who do not have the right to edit it will no longer see the edit buttons, but I can see them, and I don't see a padlock, and I don't see an edit talking about protection, so I'd like to be able to make sure that it is or is not protected before I respond to the question.--S Philbrick(Talk) 18:32, 22 July 2017 (UTC)

Actually, if people watch a protected page and they don't have the permissions to edit it, the edit or edit source text is replaced by view source. Jo-Jo Eumerus (talk, contributions) 18:42, 22 July 2017 (UTC)
That's why I'm asking. John Heard died today, so it seems plausible it has been protected, explaining why they cannot see the edit buttons, but I cannot confirm it.--S Philbrick(Talk) 18:56, 22 July 2017 (UTC)
You can normally see what's going on when you click to edit the page - a big red banner will appear at the top showing the log when the page is edit-protected (ie not simply move-protected). -- zzuuzz (talk) 18:59, 22 July 2017 (UTC)
OK, I did find it in the history. And I looked in the logs but it seems like it ought to be easier. FYI @Connormah:, you added protection, but not the padlock.
Thanks @Zzuuzz:. It is fairly prominent when clicking on "edit source", not so obvious when using Visual Edit, but now I know where to look.--S Philbrick(Talk) 19:06, 22 July 2017 (UTC)
Sphilbrick, click on Page information to the left of the page. There is a Page protection section. StarryGrandma (talk) 19:26, 22 July 2017 (UTC)
Thanks. I have seen that page before, but not in a long time, so had forgotten about it. Very useful. It gives me exactly what I wanted.--S Philbrick(Talk) 01:42, 23 July 2017 (UTC)

Dead end analysis

Hmm...is there anything around which shows how far links through to articles go before going nowhere? Thanks, My name isnotdave (talk/contribs) 10:55, 23 July 2017 (UTC)

Removing arrow from link

Is there a way to remove the little arrows from these two links in this box? they shouldn't be there...◂ ‎épine talk♬ 15:50, 23 July 2017 (UTC)

{{Plain link}} uses this solution. Look at the wikicode of this comment. (((The Quixotic Potato))) (talk) 16:03, 23 July 2017 (UTC)
@The Quixotic Potato: LMAO, 👀 🌊 what you did there. Thanks!◂ ‎épine talk♬ 16:15, 23 July 2017 (UTC)

Watchlist not being updated properly

Recently, some of the buttons on my watchlist aren't coming up blue according to pages I've visited. Even in instances where mine was the last edit, the button sometimes remains green. Dhtwiki (talk) 22:49, 23 July 2017 (UTC)

By "buttons", I assume you mean "bullets" (round in Vector, square in MonoBook). Does it get fixed if you reload the page (F5 in Firefox & Opera)? --Redrose64 🌹 (talk) 22:59, 23 July 2017 (UTC)
Yes, bullets. Thank you. The watchlist just came up error-free, but it hasn't been working flawlessly. I'll follow up if there are further errors. Dhtwiki (talk) 23:53, 23 July 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_157&oldid=1146793971"