Wikipedia:Village pump (technical)

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

« Older discussions, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Contents


Annoying new "Search for contributions" user interface[edit]

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

Screenshot of new "Search for contributions" user interface

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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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)

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)

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. Screenshot of "Search for revisions" user interface

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 (talkcontribs) 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)

Advanced search proposal at phab[edit]

Please see phab T101087, arising from geman WP, called to my attention by User:CKoerner (WMF) in this diff. Jytdog (talk) 21:17, 13 July 2017 (UTC)

Any chance that phab T159403 can piggyback onto this? That's actually a feature that used to be supported, long before the creation of the "Knowledge Engine" group.
See mw:Talk:Wikimedia Discovery#Search prefix: for background. – wbm1058 (talk) 00:46, 14 July 2017 (UTC)
Not very likely, one is MediaWiki frontend work on top of existing functionality, the other search engine backend work. Mixing that usually tends to create more complexity than desirable. —TheDJ (talkcontribs) 19:52, 17 July 2017 (UTC)
We hope to start updating query parsing (to possibly include phab T159403) in a couple quarters, starting in Jan 2018. We are currently working hard on machine 'learning to rank' and other high priority items in our annual plan (program 1) and we will also be helping with the Structured Data on Commons project. DTankersley (WMF) (talk) 23:47, 20 July 2017 (UTC)
Learning to rank seems difficult for laymen to understand. Except for "practical usage by search engines" which sounds like a "secret sauce" that makes PageRank work better. In other words, this is the core of the "Knowledge Engine" that was going to "compete with Google".
So what I hear you saying is that you can't take a minute to tie your left shoe lace, which I pointed out to you is untied, because you're too busy working on a new high-tech compound material for shoe soles, and that project will take several months, after which you will look into whether tying laces is possible. wbm1058 (talk) 08:24, 21 July 2017 (UTC)
No. That is not what Deb said. You asked if a not-insubstantial amount of work could "piggyback" on the work of the team. Both TheDJ and Deb, the product manager who defines and is responsive for the team's priorities, said no. Both explained some reasoning on why we can't just add more work to an already burdened team with established priorities. If you would like to discuss the methodologies that the foundation uses to prioritize and develop software that is welcome, but that is not the intent of this discussion. Also, mentioning a defunct proposal of staff long gone from the foundation as some sort of ongoing conspiracy does not encourage civil conversation. Many folks at the foundation who lived through that time are not keen on discussing it. It was a dark time for many. Empathy and understanding are appreciated. CKoerner (WMF) (talk) 15:27, 21 July 2017 (UTC)
OK. Empathize with the idea that I'm in the dark about why that time was so dark (and content to leave it at that). Your mission is to "build the anonymous path of discovery to a trusted and relevant source of knowledge". That seems about like what the mission has been all along; I don't understand what's defunct and what's not. "Program 1" is "Make knowledge more easily discoverable." Again, my understanding is that's been the program since the department was formed. Goal 1 of that program is to "Maintain our search systems and improve the relevance of search results." I believe my request is compatible with goal 1. Outcome 1 is "Through incremental Discovery improvements, readers are better able to discover and search for content." I believe my request is for an incremental improvement. Objective 1: is "Implement advanced methodologies such as “learning to rank” machine learning techniques and signals to improve search result relevance across language Wikipedias." Of course, this is subjective, but "advanced learning methodologies" strikes me as significantly more than an incremental improvement. Incremental improvements can usually be made in a matter of days, or weeks at most, while "groundbreaking advances" (sorry if I'm hinting at old hyperboles) take months or years of hard work. Part of my perception that you are working on a "groundbreaking advance" is the difficulty I have in understanding what you're doing. Is phab T101087 a component of this "objective 1" (aka “learning to rank” machine learning)? I honestly don't know. wbm1058 (talk) 23:06, 21 July 2017 (UTC)
I find it difficult to follow your train of thought. If you are in the dark about something, why mention it with such familiarity? Otherwise, don't. Questions are welcomed and I can help clarify. Perhaps there's a miscommunication between the task that was mentioned at the beginning of this conversation and the goals and objectives of the Discovery team? I am genuinely confused. I think the salient question I derive from your reply is if the Discovery department is working on improving the existing advanced search features (T101087). We are not, Wikimedia Deutschland is leading that development. We are aware and continue to support them where we can. CKoerner (WMF) (talk) 15:23, 24 July 2017 (UTC)

Date formatting[edit]

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)

From/To field alignment in Special:Contributions[edit]

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)

Rendering problems[edit]

I routinely clean out some error tracking categories and recently have seen strange problems that I have not encountered before. I think it must have been caused by some MediaWiki change a few weeks ago. This report is too vague for action, but I'm posting to see if others have noticed similar issues.

A problem can occur when a page is rendered (that is, when MediaWiki generates the HTML for display, from the wikitext). The problem goes away when the page is purged so it can be overlooked and issues are hard to pin down.

Two problems have been reported:

  • T168040 Table of contents (TOC) missing sporadically without apparent reason
  • T170039 Pages display Lua error in mw.wikibase.entity.lua

I saw a new problem at Fear, Love & War#External links 24 hours ago (it is still there, but will disappear when someone purges the page). An error can be seen just above the categories:

Lua error in mw.title.lua at line 59: attempt to index local 'ns' (a nil value).

List of Get Smart episodes#Season 5: 1969–70 currently shows the same message. I haven't investigated but my guess is that mw.title.lua would not be throwing that error unless something bad happened within Scribunto, similar to the mw.wikibase.entity.lua problem above.

Two hours ago I encountered another puzzle at Tornado outbreak of April 9–11, 2009#April 10 event. Just before "Brief tornado touchdown", a {{convert}} error is shown. The wikitext at that point is {{convert|1|mi|km}} but the error message is what would occur if the value (1) were omitted, or if {{convert}} (no parameters) were used. The article is in Category:Convert errors but it was not there 24 hours ago. The only edit since May was by InternetArchiveBot at 22:22, 16 July 2017—that edit did not affect the convert in question.

Ping JohnBlackburne because he has also noticed issues while clearing articles from Category:Pages with script errors. Normally (a month ago), articles with script errors would have been empty because problems that occur are fixed. However, the mw.wikibase.entity.lua problem above means that currently 97 articles are listed, and that is after fixing several wikitext problems. Johnuniq (talk) 10:49, 17 July 2017 (UTC)

I’ve just had a look at it. It seems unrelated to the Wikidata problem. In Fear, Love & War the problem seems to be here in Module:Navbar with the title 'Killarmy' (from {{Killarmy}}):
	local title = mw.title.new(mw.text.trim(titleText), 'Template');
	# ...
	local talkpage = title.talkPageTitle and title.talkPageTitle.fullText or '';
And the 'title' object is pretty unremarkable. I can only guess the 'title' got corrupted. when those scripts ran. It happening twice is odd, but I can’t see any reason why – a code change, a wikidata dependence, or other obvious trigger. It could be something happened on the server once that tripped up mw.title.lua for a short time.--JohnBlackburnewordsdeeds 13:24, 17 July 2017 (UTC)
That category always seems to need a null edit when I stop by to visit it. Changes to templates often add a bunch of pages that, when the template problem is reverted, need to be flushed from the error category. I wonder if we could ask a bot to null-edit all of the (non-sandbox, non-testpages) pages in that category once or twice a day. – Jonesey95 (talk) 14:17, 17 July 2017 (UTC)
My report about mw.title.lua has to be a bug in the underlying system. I haven't fully examined the situation, but it seems impossible to me that the red error could be generated by anything a template or module could do. It would be better to record any examples of weirdness that have been noticed, and later plan workarounds if the problem cannot be resolved. Purging the pages I mentioned just makes it hard for others to see the problem. Johnuniq (talk) 01:14, 18 July 2017 (UTC)

The heading of this thread is pretty ironic, considering that the designers of the Module:convert are deliberately abusing a parser function to cause "Rendering problems" and potentially triggering 3 different views (preview, cached rendering, preview with error) of the same page.

As far as scribunto libraries are concerned. mw.title and mw.html are some of the worst of the crop. They don't careful protect themselves from errors caused by calling modules by catching the invalid use and outputting better errors. The same applies to module:convert which should catch that error and prevent it from ever reaching a page, and output a much better error.Apart from the wikibase problem which is certainly a software issue, it is quite easy to replicate the "mw.title" error noted above :

local ns = mw.site.namespaces[buu]
mw.log(ns.buu)

Module:convert uses a lot of related modules, so any one of them could at some point have facilitated the error above. Generally speaking, mediawiki needs a better error reporting tool that doesn't rely on crazy hacks like dumping errors to pages or using categories, perhaps Extension:Pickle or a related extension could one day facilitate this.

It won't however, fix bad programming practices. — Preceding unsigned comment added by 197.218.82.137 (talk) 18:00, 21 July 2017 (UTC)

If you have positive suggestions for error reporting (rather than just complaining that existing methods are "crazy hacks"), feel free to suggest them in Phabricator. I suspect the title error described above (as opposed to your GIGO complaint) may be due to T166348, which is in the process of being fixed. The missing TOC error described above is also in the process of being fixed. Anomie 12:23, 22 July 2017 (UTC)
By the way, searching for "Lua error in mw.title.lua at line 59" in Special:Search or Google finds plenty of examples, and the Google cache shows them. Wang Maolin (last edited on 18 March 2017) is showing the error. Johnuniq (talk) 01:28, 23 July 2017 (UTC)
It seems that the error caused by the code above is intermittent and seems to show up whenever an unrelated uncaught script error occurs. It would probably happen with other unguarded related code even if that line didn't trigger it.
Improvement for the current error reporting seems to be already captured in phabricator. One approach might be to get rid of tracking categories, and red errors everywhere, and instead surface them using a centralized Linter like mechanism in mediawiki core.
In fact, it is already demonstrably superior to the tracking category, compare Special:LintErrors/self-closed-tag vs Category:Pages_using_invalid_self-closed_HTML_tags , and see T163430. At the time of this writing the former shows more errors, has a namespace selector, seems to be faster to update, can facilitate the collation of errors, identification of the template causing many errors, and unlike mediawiki core has a specific API for it.
There are also many related tasks that address a proper warning system phab:T141970, phab:T160102#3213366. Temporarily logging past errors is also way more useful than randomly popping them up in various pages. That is also partly discussed in mw:Help:Pickle/Test_log, and perhaps addressed by the pickle extension as a whole as far as lua is concerned. There are also plenty of phabricator tasks for pickle itself.
On wiki, wrapping the offending line in a xpcall would probably mitigate this problem until it is fixed server side. Such defensive programming is generally a good practice for data retrieved from a separate database. For specific scenarios like these intermittent errors, a targeted approach would be more useful than senselessly playing wack a mole, as some editors seem to be doing exactly because of the legacy error reporting system. 197.218.89.125 (talk) 07:58, 23 July 2017 (UTC)
The error cannot be caught by a Lua module. Johnuniq (talk) 09:54, 23 July 2017 (UTC)
Scribunto !== Lua . You may also be confusing templates with a genuine programming language (LUA). It is fact that wrapping the entry point of the module (and/ or all functions within all modules) should still catch it, and if that doesn't work, then that truly merits a separate bug report. Looking at this error throughout various wikis, all of them seemed to make an unguarded call. In a worse case scenario the module could simply do string matching before outputting anything similar to the {{#iferror parser function. Someone mentioned a similar thing years ago (and was ignored) related to the tester (Module_talk:UnitTests#Add_a_value_to_nowiki_to_show_the_wikitext_only_if_the_actual_result_does_not_contain_a_script_error). If even that can't be done, then it is a pretty serious software issue.
Lua can even report the exact runtime variables at the point it errored, which would certainly help in tracking that and other errors without guessing. That's a fact, and something used in several other non-mediawiki platforms. However, scribunto developers deliberately neutered those powerful error reporting tools for security reasons, or due to lack of interest / resources to provide wrappers for it. 197.218.89.125 (talk) 11:16, 23 July 2017 (UTC)

Apparently a new type of error started showing up (with a new deployment), "Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead.". It also seems to be intermittent, and probably as easily caught as the mw.title one, e.g. testwiki:module_talk:Errorcatch.15:59, 24 July 2017 (UTC)

Tech News: 2017-29[edit]

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 Face-smile.svg -- 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)

Save changes buttons - accessibility[edit]

At some point between 23:23 and 23:34, 18 July 2017 (UTC), the edit interface has changed. Is it Thursday already? I notice that the buttons at the bottom (Save changes, etc.) have changed, are bigger and less readable: there's a contrast problem. Accessibility is something to be careful of. --Redrose64 🌹 (talk) 23:57, 18 July 2017 (UTC)

+1 I am not entirely sure what was wrong with the old version either, and it is certainly not yet Thursday. ^_^ Double sharp (talk) 00:00, 19 July 2017 (UTC)
They've been dutifully warning us of the buttons' fuglification for weeks, including that there's no practical way to repair them with user css. I'd have complained earlier, but of course it would've done no good. —Cryptic 00:07, 19 July 2017 (UTC)
Redrose, accessibility for people with low vision is one of the main points. The contrast has been dutifully checked (several times by now, at least for Vector) and easily clears all of the standards.
Note that this is more than an aesthetic change, so a few old editing scripts may also break. See mw:Contributors/Projects/Accessible editing buttons for information on how to fix anything that's broken.
(P.S. It's a config change, which means it can descend on you on any day of the week. ;-) So far, it's only reached the Wikipedias and Meta. Other wikis will happen in a couple of weeks.) Whatamidoing (WMF) (talk) 01:20, 19 July 2017 (UTC)
They look perfectly fine to me. I don't see where any potential readability issues would come from even for those with eyesight issues. They're compliant. Amaury (talk | contribs) 01:27, 19 July 2017 (UTC)
Whatamidoing (WMF), could you please explain how making various interface elements exceedingly disproportional (like buttons being about 4 times bigger than hyperlinks) improves accessibility? If you care so much about these people (by the way, what is their fraction among the editors?), then maybe it would be better to make a special "accessible" style for them, with everything large and contrast? I can tell about my own experience with "accessibility": when I need to use a website with small fonts, I just press Ctrl++, and my browser magnifies everything proportionally. If I would do that with the current WP design, these ugly buttons will take half of the screen, actually decreasing the usability. And I also wonder very much: how artificially limiting the summary line to 80% of the width is supposed to help people with low vision? — Mikhail Ryazanov (talk) 09:46, 19 July 2017 (UTC)
The intention, at least as stated in prior posts here, was to improve accessibility for readers using the desktop version on mobile devices. Never mind that this affects editors, not readers, and significantly degrades the desktop version on the desktop. —Cryptic 16:50, 19 July 2017 (UTC)
Not just mobile devices. Touch devices. This includes things like Windows Surface laptops for instance. —TheDJ (talkcontribs) 18:49, 19 July 2017 (UTC)
I thought that all modern OSs have user preferences for sizes and colors, such that any interface built from standard elements will have a comfortable look and feel. Am I wrong? I do not have much experience with touch devices (believing that text editing on a keyboardless device is a bad idea), but how can it be that these users can tap hyperlinks, but cannot tap standard buttons (which are usually about twice bigger)? And again, how reducing the summary width to 80% helps them? Especially considering the problems (discussed below) with its wrong alignment and an overlapping counter. — Mikhail Ryazanov (talk) 22:57, 19 July 2017 (UTC)
Web pages cannot access OS user preferences (it would be a leak of privacy if they could), nor directly use the user interface elements provided by the OS (they use the user interface elements provided by the web browser, which may or may not resemble those natively provided by the OS). isaacl (talk) 23:54, 19 July 2017 (UTC)
Web pages do not need to access OS user preferences because the browser itself should. In any case, browsers have user preferences for default colors, fonts, and overall magnification. — Mikhail Ryazanov (talk) 04:42, 20 July 2017 (UTC)
Sure, the browser could retrieve and expose this data to web servers, but I don't believe there's currently a mechanism for web servers to retrieve this info from web browsers, and it would still be a potential privacy issue. There are defaults for colours and fonts, but not size information for user interface elements. Most users, though, appreciate greater variety in the web sites they visit, and would not want all of them to use only the default background and text colour. Even just considering the implications on a single site, visual elements such as side bars would blend into the main text flow without a distinguishing background colour. isaacl (talk) 18:31, 21 July 2017 (UTC)
Browser do not need to expose these preferences to web servers, they use them locally for rendering pages. If you have no idea how it works, please see [5], [6], [7], [8].
A variety in the web sites is fine, but kind of interferes with the accessibility, which was the declared reason for the changes we discuss here. And I still assert that neglecting user's setting actually does not "improve accessibility". — Mikhail Ryazanov (talk) 10:02, 24 July 2017 (UTC)
Thanks; I am familiar with how the default settings work. I was only responding to your original post regarding using the OS user preferences. Sure, it's possible to go back to the late 1990s look, with the web site using only defaults, and a single flow of content such as seen on many sites that are designed with mobile devices in mind as the primary viewing experience. But it's unlikely for any highly popular site such as Wikipedia to drop all styling, and in particular judicious use of background and foreground colours. For better or worse, most readers today expect both accessibility features to be respected and an engaging site design. Specifically regarding buttons: the key problem is that browsers don't offer good customization options to tailor their accessibility, and there is uneven support in adjusting their appearance via CSS. Accordingly sites will substitute their own button elements for the default ones. It's not a perfect solution, but it's what we have available. isaacl (talk) 16:29, 24 July 2017 (UTC)
Mikhail, the use of 80% width on the edit summary box has nothing to do with this change. It's been like that for years (possibly since the creation of the MonoBook skin). However, the team can change it, and if people don't like the result, then they can complain. Whatamidoing (WMF) (talk) 17:37, 24 July 2017 (UTC)
Yes, they have tried their best to impede user's CSS. I have added to my common.js some code to remove the offending classes:
// remove ugly styles from buttons:
$(".oo-ui-buttonInputWidget").removeClass("oo-ui-buttonInputWidget")
$(".oo-ui-buttonElement-button").removeClass("oo-ui-buttonElement-button")
// and checkboxes:
$(".oo-ui-checkboxInputWidget").removeClass("oo-ui-checkboxInputWidget")
// remove inflated field margins:
$(".oo-ui-fieldLayout-header").removeClass("oo-ui-fieldLayout-header")
This seems to help against the most evil stuff, at least so far... — Mikhail Ryazanov (talk) 09:31, 19 July 2017 (UTC)
What a relief! The awful new buttons couldn't be styled by CSS (by me at any rate), but this returns them to a usable legible state. And fixes my widgets too. Lithopsian (talk) 14:02, 19 July 2017 (UTC)
I regret that I have but one thanks button to click for this edit. A css solution would be better - removing the classes in javascript still shows the irritatingly immense buttons briefly until the page finishes loading - but this is still a huge improvement. —Cryptic 16:50, 19 July 2017 (UTC)
@Cryptic: Since they are classes, you can redefine them using user CSS. For example, I have changed the color. If you want to have boring grey buttons again, you can use
.oo-ui-buttonElement-button {
border: 1px solid black !important; 
background-image: linear-gradient(to bottom,#eee,#eee 100%) !important;
border-radius: 0 !important;
padding: 0.5rem !important;
transition: none !important;
}
for example. Regards SoWhy 12:29, 20 July 2017 (UTC)
Is there a CSS style that is just "look like a button, like all the other buttons - eg 'Go' and 'Search' in Monobook"? Mitch Ames (talk) 11:28, 24 July 2017 (UTC)
I just took a screenshot at File:Save_dialog_Wiki.jpg (FF 52.0.2, Windows desktop, Vector skin). Maybe that helps a bit to find remaining problems and script incompatibilites (obviously the buttons need fixing, and the "edit summary" field is cut by 1-2 pixels on the left side). GermanJoe (talk) 02:45, 19 July 2017 (UTC)
wikEd is making it's own style modifications. It will need an update. —TheDJ (talkcontribs) 07:17, 19 July 2017 (UTC)
I think they're awful – unattractive and huge, but I am more concerned with the fact that I no longer have any ability to leave an edit summary. Gone. The field is not even presented to me. I do/did have my interface tweaked to get rid of the gallons of material at the bottom of the page, and order it better. I'm assuming that is the issue. Can anyone advise if there's any way to tweak my customization or can identify the issue between my common.js and my my common.css?--Fuhghettaboutit (talk) 12:03, 19 July 2017 (UTC)
@Fuhghettaboutit: Eh, yeah you are doing some very uncommon manipulations there with both JS and CSS on your editOptions. If you want to hide something, you should always target as narrow as possible, not go high level and then selectively move things out of it with JS... —TheDJ (talkcontribs) 15:37, 19 July 2017 (UTC)
  • Any chance we have a preference like with VE ?, My main dislike is the huge blue button as well as the rather big tick (image) - Wouldn't be so bad if it was smaller, ofcourse I realise it's been designed for people with eyesight issues however without being disrespectful we're not all blind so surely there should've been common ground in terms of the design ?,
It pleases those with eyesight issues (which is absolutely great) but it pisses those off that don't have eyesight issues (FWIW I am short sighted and do wear glasses however the previous design was never an issue),
If we could have a preference option like with VE that'd be great - I know we can't please everyone I understand that but atleast to me the big blue button/tick is rather extreme... –Davey2010Talk 16:41, 19 July 2017 (UTC)
Davey, I know it seems like a pretty big visual change, but my bet is that if you wait a couple of weeks, you won't notice it as much any longer. Most people adapt to visual changes pretty quickly. Also, since most of us here are experienced editors, most of us don't really look at the buttons much anyway: It's just Tab ↹ to the edit summary box, type the edit summary, and Return to save the page. The buttons don't even need to be above the scroll.
We made this change at half a dozen big wikis two weeks ago. There were a few comments about the size and color there on the first couple of days, but I've seen nothing about it since then. Whatamidoing (WMF) (talk) 20:04, 19 July 2017 (UTC)
Ah see I don't do that - I usually hit any part of the scrollbar thus making it "ping" to any place - I then type whatever or use the arrow keys for autofil and then hit return,
Ofcourse I mean changes happen everywhere and not all are liked but we live with it but usually if something changes to my dislike I'll "dislike it but live with it" but here and I hate to be a little drama-queen but I actually hate it, The button is "too in your face" if that makes sense, I love the colour Blue always have so I love the colour choice here no problem but the button and tick are too big,
It would've been better to have it the same size as the previous and perhaps have implemented a tool where it could be made bigger in preferences or something, But I suppose it all goes back to "you can't please everyone",
Ah well it's changed and I guess there's nothing I can do except look in anger! Face-tongue.svg, –Davey2010Talk 20:37, 19 July 2017 (UTC)
Is this why the button is green?— Vchimpanzee • talk • contributions • 20:52, 20 July 2017 (UTC)

Show changes clicks Editing help on Android[edit]

On Google Android phone (Google Chrome) browser, the new oversize "Show changes" (button 3) clicks into "Editing help" (cheatsheet link) which is very bizarre because no "Cheat" buttons onscreen, and "Show changes" really should show changes on mobile phone edits (which are hard enough already). This glitch shows the horrors of user-hinterface experiments which can hinder simple processing, as the inverse consequence of wanting a modest improvement in user interfaces. "Kids don't do this: never move the brake pedal, gas petal or steering wheel while a car is being driven". We need an essay, "wp:Computer Screwups 101" to remind people to use alpha/beta testing steps on crucial user-interfaces, where experimental glitches can have horrific impacts (over 20,000 mobile phone edits per month). -Wikid77 (talk) 08:32, 20 July 2017 (UTC)

This report misses critical information. which page, which editor, which skin, which android device, which version of google chrome, did you test with disabling all your gadgets and userscripts ? How to report bugs effectivelyTheDJ (talkcontribs) 07:05, 21 July 2017 (UTC)
It happens on any page (wikitext editor) in Vector skin (Monobook skin ok) while suppressing License blurb, but when logged out then "Show changes" clicks Show preview, on Android phone LG Escape2, version 5.1.1. To avoid preview horrors, the Monobook skin can be used (which shows avocado " Save_changes " rather than Vector blue  Save changes ). -Wikid77 (talk) 06:08, 24 July 2017 (UTC)

New Edit summary window[edit]

The redesigned Edit summary window has the text left-anchored, with the result that most of the time you can't see what you're typing because it's off the right-hand end of the window (on an ordinary 13" laptop). Can that really be what the designers wanted to achieve? The remaining-character count is good, though. Justlettersandnumbers (talk) 08:27, 19 July 2017 (UTC)

@Justlettersandnumbers: It is supposed to right align. If it is not for you, then that might be a browser specific bug. Please report what browser and version of it you are using. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
Safari Version 5.1.10, TheDJ. Justlettersandnumbers (talk) 09:14, 19 July 2017 (UTC)
Ah, that browser is not really supported anymore, so I guess it's not too surprising. I've been saying that we should disable JS support for Safari 5, but so far it seems it's still included. —TheDJ (talkcontribs) 09:51, 19 July 2017 (UTC)
Similar but not identical problem in Chrome Version 49.0.2623.112; Firefox 48.0.2 is OK, though. Justlettersandnumbers (talk) 09:20, 19 July 2017 (UTC)
I use Chrome 36 (after I abandoned Firefox because v. 51 got waaay too slow - five minutes to load a Wikipedia diff, and ten mins to click "back" from that? Ridiculous) and I find that it's right aligned, but the last two or three characters are hidden by the bytes-remaining counter. Pressing End reveals them though. Perhaps that counter could be put outside the box? --Redrose64 🌹 (talk) 10:06, 19 July 2017 (UTC)
Counter, what counter? Using the latest version of Chrome with Vector. Doug Weller talk 10:58, 19 July 2017 (UTC)
Are you using wikEd? That makes its own edit summary box with no counter. PrimeHunter (talk) 12:38, 19 July 2017 (UTC)
@Doug Weller: I suspect this might be interfering. And indeed so will wikEd. —TheDJ (talkcontribs) 12:57, 19 July 2017 (UTC)
@PrimeHunter and TheDJ: I got rid of the CSS but I want to keep WikiED, I'm ok without the counter, just nice to know why I can't see it. Doug Weller talk 15:40, 19 July 2017 (UTC)
@Doug Weller: I'm not going to fix wikEd though, you will need to contact it's maintainer. —TheDJ (talkcontribs) 15:50, 19 July 2017 (UTC)
@TheDJ: Of course not, why should you? As I said, I'm not bothered, I want to keep WikiED. Doug Weller talk 19:09, 19 July 2017 (UTC)
@Doug Weller: By "that counter", I mean the one described at Help:Edit summary#The 250-character limit (the bit about the figure 143). --Redrose64 🌹 (talk) 20:02, 19 July 2017 (UTC)
I have the same problem on Firefox 52.2.1. Deli nk (talk) 12:43, 19 July 2017 (UTC)
I have the same problem with latest version of Chrome for Windows. When I undo a change, I find myself removing most of the default stuff in the box so I can see what I'm doing. Annoying. Any way to go back until they fix it?--Bbb23 (talk) 14:04, 19 July 2017 (UTC)
  • Please roll back the change to the edit window. This makes it harder to write edit notes. It is cute to have the little twitter character counter but it actually gets in the way many, many characters from the end. This must go'. Jytdog (talk) 22:19, 19 July 2017 (UTC)

Edit summary field hidden[edit]

Not sure if this is related, but I came here wondering about why I was not able to see any edit summary field at all. I'm editing on a Kindle fire at the moment with the vector skin. olderwiser 08:57, 19 July 2017 (UTC)
You have #wpSummaryLabel hidden in your vector.css (as did I). Just remove the line.[9] -- zzuuzz (talk) 09:06, 19 July 2017 (UTC)
Hmm, that seems like an oversight in one of the IDs.. Please file a bugreport. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
(edit conflict) The id wpSummaryLabel ended before the box in an old version I compared to. You can currently place the below in your CSS to hide the heading but not the box. PrimeHunter (talk) 09:32, 19 July 2017 (UTC)
#wpSummaryLabel .oo-ui-labelElement-label {display:none;}
@Bkonrad and Zzuuzz: You can increase the specificity of the selector, like this. --Redrose64 🌹 (talk) 09:31, 19 July 2017 (UTC)
Thanks @Redrose64 and PrimeHunter:. Both your suggestions work, though I noticed PrimeHunter's suggestion also hides the count of remaining characters (something I had not seen before and is nice touch). olderwiser 10:02, 19 July 2017 (UTC)

What is this number?[edit]

When I'm in the edit window in Firefox 54.0.1, logged in, there is an odd 3-digit number outside and to the right of the Edit Summary box. That same number appears no matter what article I open up. So, I opened Microsoft Edge without logging in. That same number appears no matter what article, except it's inside the Edit Summary. Are you tracking us? What is this number, and why is it the same number no matter what article, no matter if I'm logged in or not? — Maile (talk) 11:54, 19 July 2017 (UTC)

@Maile66: Type some letters into the edit summary box and you will see what it means! See also the first point at Help:Edit summary#Edit summary properties and features. — This, that and the other (talk) 11:57, 19 July 2017 (UTC)
Ahhhhh ... it counts the characters in our edit summary and tells us when we've reached the limit. Thanks. — Maile (talk) 12:00, 19 July 2017 (UTC)
@Maile66: Specifically, it counts bytes rather than characters; if you type in non-Latin characters like "카나다", "Канада", or "קאנאדע" you'll see it drop more quickly. My colleagues in the MediaWiki team are working on making it possible to write more than the current limit of 250 bytes, which was a highly-rated Community Tech wishlist item recently. Jdforrester (WMF) (talk) 15:56, 19 July 2017 (UTC)
Seems pretty pointless TBH. Another good reason why I ditched using edit summaries years ago. Lugnuts Fire Walk with Me 13:04, 19 July 2017 (UTC)
Actually, it counts the bytes, not the characters. This distinction is what makes it particularly useful for people who aren't typing in English. Whatamidoing (WMF) (talk) 15:34, 19 July 2017 (UTC)
@Maile66 and This, that and the other: A better link is Help:Edit summary#The 250-character limit, in particular the bit about the figure 143. @Jdforrester (WMF): 255 bytes, not 250. Same link. --Redrose64 🌹 (talk) 20:00, 19 July 2017 (UTC)
The counter is cool but should be outside the text field. The rest of the changes are just ugly. RivertorchFIREWATER 23:28, 19 July 2017 (UTC)

Last characters in summary are hidden[edit]

I came here to ask a related question, and saw this thread. How do I turn off the count box? I couldn't find anything in preferences. Is there a .css or setting that will kill it? On Google Chrome (with MonoBook skin), the box hides the last couple characters typed in the Edit Summary box - as a result, it just gets in the way. To verify I didn't leave off anything I need to back arrow then forward arrow to trick the UI to show me all the typed characters. If I type again at that point, they are again hiddent and I need to use the stupid back arrow/forward arrow thing again to view all my typed characters. --- Barek (talkcontribs) - 17:06, 19 July 2017 (UTC)
Put
.oo-ui-textInputWidget > .oo-ui-labelElement-label { display:none !important; }
in your common.css. —Cryptic 17:13, 19 July 2017 (UTC)
Doesn't work—the countdown is still there. I'm sure this was implemented with the best of intentions but please, disable it until you can get it working properly—not being able to see what you're typing is remarkably irritating. We survived for 15 years without it, I'm sure we can survive another week while you work the bugs out. ‑ Iridescent 17:18, 19 July 2017 (UTC)
You're right - I was able to change the positioning and opacity with that selector, but display doesn't stick. I've added an "!important" to the above, which does work. (At least for me, in cologneblue, in preview.) Try that? —Cryptic 17:24, 19 July 2017 (UTC)
Even if CSS allowed to hide it, note that this will not prevent the extra scripts from loading and running (every typed character will still be processed by them). —PaleoNeonate - 17:21, 19 July 2017 (UTC)
Works here. It is an element and so it can be easily hidden. The selector is correct, make sure you copied it exactly and placed it in the correct file. Not to say it won't change tomorrow though. Also the count doesn't hide anything for me, so might be a browser-specific issue. Or just that skin? Either way, might work one day! Lithopsian (talk) 17:25, 19 July 2017 (UTC)
Sorry, my mistake, I was using a different selector:
#wpSummaryWidget > .oo-ui-labelElement-label
Lithopsian (talk) 17:28, 19 July 2017 (UTC)
Since "that browser" is Chrome and "that skin" is Vector, this is the most frequently occurring combination among Wikipedia editors by an order of magnitude—we're talking a major issue, not some obscure glitch that only affects a few users using archaic systems. ‑ Iridescent 17:30, 19 July 2017 (UTC)
I figured out why this is occurring. Let's hope someone can find a fix for it soon. —TheDJ (talkcontribs) 18:31, 19 July 2017 (UTC)
I also experience a strange bug where sometimes characters become hidden under the counter when typing using FF, after typing enough it resets and I can see the new characters again. I would really like if most of those new features systematically came with corresponding disable/enable preferences (large buttons, interwiki search, this counter are examples of recent features which lacked systematic toggling options. There's now a gadget to disable the search aspect (and it could be hidden by CSS), but that was still introduced afterward and does not prevent unnecessarily loading extra scripts (and all the interdomain pages, as can be seen in inspectors or security control addons); I also noticed that page loading time increased in the last months, scripts often lagging behind the actual page. I commonly click on the watchlist star before all scripts are loaded, causing the page to reload with the "add/remove" question like if JS was disabled. Another common occurence is for the page to load and jump at the proper anchor with scripts lagging, which when loaded cause sudden scrolling/jump, where I have to select the address bar and press enter again to scroll to the anchor. It's unfortunate for this bloat to become obvious for features I don't need, even on a fast system and fast connection... —PaleoNeonate - 22:50, 19 July 2017 (UTC)
  • Yes please turn this "counter" off. It is a bug, not a feature. Jytdog (talk) 22:23, 19 July 2017 (UTC)

Character counts on subject/edit summaries?[edit]

I'm seeing character counts on the Subject and Edit summary boxes now, which I wasn't before a few days ago. However, for long edits (such as after a revert) the cursor and last few characters are hidden.

Is this on for everyone, or is my Javascript (currently only OneClickArchiver) somehow causing this? Power~enwiki (talk) 21:37, 19 July 2017 (UTC)

see #What is this number? above, sounds like the same. Nthep (talk) 21:46, 19 July 2017 (UTC)
yup, same thing. Closing. Power~enwiki (talk) 23:44, 19 July 2017 (UTC)

Process[edit]

What is the process through which this "Improvement" was implemented? Jytdog (talk) 22:24, 19 July 2017 (UTC)

God only knows. At the very least, there should have been a banner warning users of it. When I first saw it yesterday, I wondered for a moment if I'd somehow wound up on a spoofed site. RivertorchFIREWATER 23:26, 19 July 2017 (UTC)
Obviously someone at WMF who never uses this site thought it would be a great thing to implement. Hats off to them! Lugnuts Fire Walk with Me 12:11, 20 July 2017 (UTC)
It was pointed out to me here that this was done via phab:T36984. That in turn was related to phab:T165856. It ~appears~ to me that User:Jdforrester (WMF) was the person who implemented the request? I don't understand how the process of changing code works or how decisions are made to actually implement things. I suppose somebody thought this was a trivial tweak. I have no idea.
There is a Tech news thing where the devs communicate what they are doing, but I looked through the current issue and one previous issue and don't see this mentioned. Jytdog (talk) 12:31, 20 July 2017 (UTC)
Obviously someone at WMF who never uses this site is wrong per Jytdog's phabricator link (which I dug up). The original feature had implementations on other wikis in gadget form (especially the non-Latin alphabetic wikis) and has anyway existed in VisualEditor for 5 years (without seeming complaint anywhere on phabricator, besides a handful of breakages). --Izno (talk) 12:37, 20 July 2017 (UTC)
User:Izno - I have appreciated your providing information but the implementation in the WikiEditor was crappy and broke things. Period. Whether it worked somewhere else is entirely irrelevant. People get angry when their tools get broken - irrelevant argument pours oil on the fire. Jytdog (talk) 13:10, 20 July 2017 (UTC)
Indeed. So I guess we all need to start using VisualEditor so that we'll be forewarned about interface "improvements". It never ceases to amaze me: there are so many areas of the editing experience that could be improved, and WMF developers have repeatedly shown themselves capable of coming up with brilliant solutions, but they keep fixing things that aren't broken. And failing to give fair warning. RivertorchFIREWATER 13:57, 20 July 2017 (UTC)
It is rather amusing to see that almost everything now on my common.js and common.css pages exists solely to reverse various changes WMF developers made. And I certainly cannot thank enough everyone who has contributed here with wonderful solutions, with a special shout-out going to Mikhail Ryazanov and Cryptic! ^_^ Double sharp (talk) 14:36, 20 July 2017 (UTC)
@Rivertorch: Not having an indicator of how much information I could pack into an edit summary was more-or-less broken behavior and I'm personally surprised this change wasn't made earlier. "No-one got around to it because it would have been a pain before the train got rolling on the big blue Publish button" seems to be the indication from the phabricator task for the "why" of that. --Izno (talk) 15:11, 20 July 2017 (UTC)
@Izno: As I indicated elsewhere in this ever-growing section, the counter isn't a bad thing; the implementation of it is. The implementation is half-baked and was rolled out without proper notification. (It certainly wasn't urgently needed; one becomes rather adept over the years at estimating summary length and trimming as needed.) RivertorchFIREWATER 18:19, 20 July 2017 (UTC)
@Rivertorch: Agreed, generally. --Izno (talk) 18:31, 20 July 2017 (UTC)
@Jytdog: Having feelings about an (un)expected change is understandable. Communicating that in a non-collegial manner (that is, dripping sarcasm and obvious lack of research) is not. I am perturbed that you did not state an issue with his behavior but instead targeted my response, but sure, I'll move along. --Izno (talk) 15:11, 20 July 2017 (UTC)
User:Izno this was not feelings about an unexpected change - it is frustration with a change that broke something I rely on for every edit I make, that adds a "feature" that provides no value for me. Your initial responses were helpful and provided information. These last responses have not been helpful but are causing "feelings" that are decidedly not good. Jytdog (talk) 05:12, 22 July 2017 (UTC)

Make it stop[edit]

Please kill this counter. It is turning my edit notes into garble. This is so unbelievably stupid. TURN THE COUNTER OFF.Jytdog (talk) 03:00, 20 July 2017 (UTC)

This issue is being worked on. —TheDJ (talkcontribs) 09:32, 20 July 2017 (UTC)
The counter should be removed and made an option for people who want to see how much space they have left. I do not want this clutter. Removing it should be simple and fast, no? Whatever it takes to fix it can be worked out at leisure then, and It can be re-implemented as an option. Jytdog (talk) 13:13, 20 July 2017 (UTC)
The counter gets in the way of editing on a mobile / tablet and makes it impossible to leave a meaningful edit summary when reverting an edit using the web interface on an iPhone. For example: Undid revision 12345689 by Example (talk) consensus on the talk page is that this information violates the biographies of living persons policy and should not be used. Ritchie333 (talk) (cont) 09:43, 21 July 2017 (UTC)
  • It stopped!! Thank you devs, very much. Such a relief not to have to fight with the software to leave an edit note. We take simple things that work for granted, so I wanted to be sure to say thanks. I would prefer not to have the counter re-implemented but if it must be, please keep it out of the way. Jytdog (talk) 21:42, 21 July 2017 (UTC)

Cancel button no longer a button[edit]

Why is the Cancel button no longer a button, just a bolded red text link?

What on earth is that about? --BrownHairedGirl (talk) • (contribs) 09:20, 20 July 2017 (UTC)

The link has changed colour and size, but it wasn't a button before: 2014 screenshot -- John of Reading (talk) 09:29, 20 July 2017 (UTC)
The word "Citations", also without button, is floating just above the line between "Show changes" and "Cancel". (Monobook, desktop, current Firefox): Noyster (talk), 12:32, 20 July 2017 (UTC)
That sounds like you have a user script or gadget that needs updating. Anomie 12:45, 20 July 2017 (UTC)
The color change was not a good idea, because now it looks like a redlink, instead of just an editing page option. kennethaw88talk 00:00, 22 July 2017 (UTC)

Shortened edit summary[edit]

Nobody else seems to have mentioned it, so I will: Since the implementation of the accessible save buttons, the length of the edit summary seems to have been cut in half. I usually edit on a Windows 7 machine using 64-bit Firefox 54.0.1, using WikEd and these scripts; here is my CSS. Any suggestions? If I undo an edit, the automatically generated portion of the edit summary (the diff number and the links to the editor's contribs and talk page) take up more than half the length of the (shortened) edit summary. Thank you. — Malik Shabazz Talk/Stalk 02:47, 21 July 2017 (UTC)

I was wondering about that, but I think it's unchanged. There is a bug in that when scripting is disabled in the browser, there is no visible cursor in the edit summary box once the cursor hits the end of the box (129 characters in my browser window at the moment—that depends on how wide the window is). I can continue typing (with no visible cursor) until 200 bytes have been entered. I think that is the same as it used to be, although 255 bytes are available when scripting is enabled. Johnuniq (talk) 01:40, 23 July 2017 (UTC)
The 200-byte limit was lifted for everybody with the release of MediaWiki 1.17 back in February 2011; making this gadget somewhat redundant (it's no longer listed at Preferences → Gadgets). --Redrose64 🌹 (talk) 08:42, 23 July 2017 (UTC)
OK, but I tested before posting my comment above, and 200 bytes is all I can put in an edit summary box with scripting off, and 255 with it on. Johnuniq (talk) 09:57, 23 July 2017 (UTC)
I think it is just wikEd racing the oojs ui. If wikEd is first, it gets 200 limit (because that is the fallback if OOjs UI has not finished enhancing the view). —TheDJ (talkcontribs) 15:06, 24 July 2017 (UTC)

No preview of edit summary[edit]

I'd like to also express my disapproval of the new bigger "Save changes" etc buttons. More importantly though, I no longer get a the preview of edit summary that I used to get when I clicked "Show preview" or "Show changes". I use the MonoBook skin, but the same problem occurs when I switch to Vector. The preview of the edit summary itself is quite useful because I frequently include wiki-links in my edit summaries - most often to the relevant MOS guideline shortcut (eg MOS:BOLD) when editing pages to meet those guidelines. The summary preview showed me a clickable link (red if I've mistyped it) which I can ctrl-click (open in new tab/page) to check. Can we have the summary preview put back please. Mitch Ames (talk) 09:52, 24 July 2017 (UTC)

When I try it, in both Monobook and Vector, the preview shows up just under the edit summary input. I don't think it has even moved due to this change. Anomie 12:11, 24 July 2017 (UTC)
If I try in in a "private browsing" window, so I'm effectively not logged in, the preview appears, so perhaps there's something in the new style that conflicts with one or more of the settings in my preferences. I could reset them all to defaults and work through them all, but that will be tedious. Does anyone have any suggestions as to specific settings to try? Mitch Ames (talk) 13:34, 24 July 2017 (UTC)
Mitch Ames, if you are using the Live Preview option of your preferences, then there is currently a bug where the preview of the summary doesn't work. This is ticket phab:T171156. —TheDJ (talkcontribs) 14:59, 24 July 2017 (UTC)

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

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 (talkcontribs) 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[edit]

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)

Full page redirect?[edit]

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)

Structured Data on Commons Newsletter, July 19, 2017[edit]

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?[edit]

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[edit]

  • 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[edit]

  • 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[edit]

  • 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?[edit]

  • 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[edit]

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

Bots Newsletter, July 2017[edit]

Bots Newsletter, July 2017
BAG laurier.svg

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[edit]

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)

Links starting with [[:: no longer valid?[edit]

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 (talkcontribs) 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 (talkcontribs) 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)

Automated detection of dead links[edit]

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)

Non-free file rescaler[edit]

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 (talkcontribs) 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 (talkcontribs) 00:22, 23 July 2017 (UTC)

RFC re Character counter in edit notes window[edit]

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[edit]

  • 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[edit]

  • 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.

Linking Interwiki[edit]

Is there a direct way to link images in Interwiki without copying over the image into each language such as this one: [10]. 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)

New look in edit window on Delete Page[edit]

I'm fine with the big blue buttons in the regular edit windows. I am also an admin, and now when I delete a page, the big button that says "Delete Page" has a red background. For people with vision problems, the editors I think you want to accommodate, red is not a good choice. Especially in older people, or anyone dealing with macular problems. Red is one of the first colors that becomes harder to see. — Maile (talk) 00:14, 21 July 2017 (UTC)

Agree that color is horrible - this whole scheme wasn't thought through very well before release. — xaosflux Talk 00:33, 21 July 2017 (UTC)
Those colors are more for those who don't have those problems (it's a cognitive speed-up for most of us). But for the accessibility of those with visual impairments, there are basically two types of buttons: 'primary' (colored) and neutral/secondary (non-colored). For accessibility it matters if you can read the text (achieved by contrast between background vs text), and if can distinguish the primary choice from the other choices. The red color indicates the action is 'destructive', but the text is required to ALWAYS use wording that also implies 'destructiveness' (so that this is not solely communicated via color, which would be bad for screenreader users as well). —TheDJ (talkcontribs) 06:44, 21 July 2017 (UTC)
Yes, but ... the delete button is white text with red background. If a visually-challenged person doesn't see the red, then they just have a field of white with no distinct lettering. Or, depending on their individual case, maybe that red fades and blurs until they see some kind of background, but the text is not distinct. Maybe other colors too. But I'm just saying that visually-challenged people have difficulty with colors. And if the button is white letters with any color background, what a visually-challenged person sees is just a block of nothing. — Maile (talk) 11:09, 21 July 2017 (UTC)
@Maile66: I don't know much about all forms of visual impairments, but I do know that the color sheet is at least AA and strives to be AAA as much as possible. The style has been tested for most color deficiencies. But macular degeneration is a rather problematic issue and depending on how far it has progressed, it will indeed significantly affect your ability to read anything that doesn't have the highest contrast ratios (black vs white). We have had a long standing wish to integrate some aggressive accessibility settings (font size, contrast, aliasing/smoothing) to tackle the last of these problems, but as most users have these tools as part of their OS as well, it hasn't had top priority unfortunately (there have been some experiments at hackathons though).—TheDJ (talkcontribs) 12:30, 21 July 2017 (UTC)
Okey dokey. — Maile (talk) 12:38, 21 July 2017 (UTC)
Thanks for the link, The DJ. The bottom line is that red is, for almost all Western cultures, associated with high risk/emergency/problems....and that is not the association that should be made with where the colour red is being used here. I've also done a little poking at the WCAG guidelines and haven't been finding statistically valid testing to back many of the assertions and principles of the project, but that's neither here nor there. End of the day, red is a much harder colour for MOST people to see when it is in skinny font - almost regardless of background - and it's not being used effectively in these interfaces. I'd much rather they skipped the red completely or, if used at all, always have it presented properly as a button with bold, fat fonts. The editing population is aging a lot, and neither the WCAG standards nor the WMF colour palette take this factor into consideration. It has nothing to do with macular degeneration. It has more to do with changes over time in the way people perceive colours. Risker (talk) 00:08, 24 July 2017 (UTC)
I suspect they chose red for "destructive" actions such as deleting a page specifically because of that association. I'll leave debate over whether WCAG took "aging" vision into account for others. I see TheDJ already created T171458 to determine whether the Monobook styling actually follows WCAG's guidelines (it wouldn't terribly surprise me if it turns out they had only looked at Vector before). Anomie 12:15, 24 July 2017 (UTC)
I'll back out a little from my prior comment "the whole scheme" is a bit vague - I'm really only referring to the red "Cancel" and "Delete" buttons links - perhaps just adding some font weight to them would be enough. — xaosflux Talk 15:45, 21 July 2017 (UTC)
  • Noting in passing that today I found the delete button to be white with red lettering. Now, I've got pretty good eyesight, and I could barely make out what the letters were because they were too faint. They need to be bolded, bigger - and NOT RED. Red is almost never a good colour for an interface, unless the intention is for it to be considered the "Emergency" button. I also can barely read the "Cancel" link in the editing window below - also red, thin font. How about making the "CANCEL" an actual button rather than just a word?Can it at least be CAPITALIZED? It should be considered an equal partner to the other buttons. Current FF, Windows 10, Monobook. Risker (talk) 23:53, 23 July 2017 (UTC)
    • I share some concern with you about the accessibility of the Apex (as it is called) oojs-ui style that monobook users receive. I have created T171458 to start with an assessment and documentation of the color combinations. —TheDJ (talkcontribs) 10:07, 24 July 2017 (UTC)

Drop Down Box[edit]

Too much whitespace example
  • The other problem is that scroll-down list of reasons has too much white space and is harder to scan. Also, the font seems lighter and harder to read (for me) on the white background. SarahSV (talk) 22:14, 21 July 2017 (UTC)
    100% agree here, way to much line spacing here - how can we get these adjusted back? — xaosflux Talk 02:20, 22 July 2017 (UTC)
    • You write a style gadget that changes it. —TheDJ (talkcontribs) 12:48, 22 July 2017 (UTC)
TheDJ Don't exactly understand what you're saying, unless you're saying we should write a style gadget. But the issue with the drop down box spacing (at least on mine) is that every line is double spaced between the lines (LOTS of white space between the lines), larger type than before, and while the categories are in bold, the individual selections are grayish. I'm guessing ... but this seems to be what is about to happen to everything, including blocking, protecting pages, etc. etc. I know this was done in good faith, but it seems like it's being rolled out for a given editor demographic (whatever that is). — Maile (talk) 21:21, 22 July 2017 (UTC)
Maile66 Maybe we're not seeing the same things. Screenshots can be uploaded here. —TheDJ (talkcontribs) 00:01, 23 July 2017 (UTC)
This is more trouble than it's worth. I'm not doing a screenshot. Sorry. I know you mean well. Editing on Wikipedia shouldn't require all this. I find the changes happening counter-productive to what I do on Firefox. That's it. And it isn't just this edit window. If I send you a screen shot on this latest, tomorrow it will be something else. And another. And another. And another. Little things started going whack-a-doo for me about a month ago, when everybody else started complaining about things like the missing toolbar or other stupid stuff in the edit window. And every time another change comes, something else looks whacked, and not everything going on behind the scenes works for everybody. Bah. Humbug. What's happening now is total junk.— Maile (talk) 00:35, 23 July 2017 (UTC)
Also, I know you are very dedicated and are very diligent at trying to help editors. I don't mean to sound rude towards you, The DJ, but whatever they're doing is just too much. Sometimes I open an edit window, and everything looks normal. Sometimes it takes a refresh, or a preview, or any guess on a jiggle here or there to get things to load right in the edit window. And it's not consistent. And it's not a virus or malware. It's the re-programming that's happening. Unbelievable. — Maile (talk) 00:56, 23 July 2017 (UTC)
@TheDJ: see screen shot on the right, that double spacing is unwanted. — xaosflux Talk 23:23, 23 July 2017 (UTC)
Thank you Xaosflux. That does look a bit weird indeed. I have filed T171455 to double check if this is correct. —TheDJ (talkcontribs) 09:55, 24 July 2017 (UTC)

Maile66: Here's some medicine for you:

Big CSS snippet
/* Remove some whitespace */
.oo-ui-panelLayout-padded {
	padding: 0;
}

.oo-ui-fieldsetLayout.oo-ui-labelElement > .oo-ui-fieldsetLayout-header > .oo-ui-labelElement-label {
	margin-bottom: 0;
}

.oo-ui-panelLayout-padded.oo-ui-panelLayout-framed {
	margin: 0;
}

.oo-ui-fieldLayout.oo-ui-labelElement,
.oo-ui-fieldLayout.oo-ui-fieldLayout-align-inline {
	margin-top: 0;
}

.oo-ui-fieldLayout.oo-ui-labelElement > .oo-ui-fieldLayout-body > .oo-ui-fieldLayout-header {
	padding-bottom: 0;
}

.oo-ui-fieldLayout {
	margin-top: 0;
}

.oo-ui-dropdownInputWidget select:not( [no-ie] ) {
	height: 1.5em;
}

.oo-ui-textInputWidget input,
.oo-ui-textInputWidget textarea {
	padding: 0;
}

/* Make destructive buttons black */
.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button {
	color: white;
	background-color: black;
	border-color: black;
}

.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button:hover {
	background-color: black;
	border-color: black;
}

You can put that in Special:MyPage/common.css. You can pick and choose the snippets you want or copy it wholesale. If you think it's too squeezed up, you can just replace 0 with 3px or whatever values you want. Nirmos (talk) 12:02, 23 July 2017 (UTC)

Thank you. It has no effect on the white spacing. But one thing it does, is change that red button to black. And what a great improvement the black is. So, thank you for providing this to me. Just for the record, I have previously tried deleting all my scripts, and that didn't work. I've tried changing my skin to Vector, and that didn't work. I unchecked just about everything in Preferences/Gadgets, to no effect. The phenomenons I'm experiencing in English Wikipedia do not happen on Commons or Wikisource, both of which look remarkably like they always did. — Maile (talk) 12:12, 23 July 2017 (UTC)
Maile66: I've updated the code above to also remove the whitespace for the drop down menus and the text inputs. Nirmos (talk) 12:31, 23 July 2017 (UTC)
Nope, nothing. But I have a question. There is something in my .css that I put there in 2013. I can't remember why I put it there, or what it's for. Could it be part of the cause? — Maile (talk) 12:43, 23 July 2017 (UTC)
Maile66: You are indirectly loading MediaWiki:Gadget-navpop.css, but I don't think that's the problem. What skin are you using, exactly? Nirmos (talk) 12:56, 23 July 2017 (UTC)
Nirmos I have no idea what that Gadget-navpop does, so I must have been reading some noticeboard when I did that. I'm using Modern skin. I clear my cache. Tried Vector skin with the changes you gave me. I am on Windows 10 , Firefox 54.0.1. — Maile (talk) 13:12, 23 July 2017 (UTC)
Maile66: I can't see that you have tried my revision in Special:Diff/791941470. Nirmos (talk) 13:18, 23 July 2017 (UTC)
I misunderstood. Now I have tried the revision, both in Modern and Vector skins. What that does, is narrow the drop down box and the "Other additional reason" blank. But within the drop-down list itself, it's still double spaced between the drop-down reasons, and that's the original issue. Also, your changes not only narrowed the box on the Delete template, but as I'm typing this, I see it narrowed the Edit Summary box below this window. In case I was not clear, I can live with a wide Edit Summary box/drop down box. It's the lines between the drop-down reasons that are the issue for me. — Maile (talk) 13:37, 23 July 2017 (UTC)
Maile66: How much space there is between option elements varies by browser. Firefox simply has more space in between than, say, Chrome. Nirmos (talk) 14:49, 23 July 2017 (UTC)
Bingo! You just solved it. I don't normally use anything but Firefox. And the only other browser I have available to me it Edge, which does not show the extra spaces inbetween. It's Firefox. Sorry I wasted everybody's time on this. — Maile (talk) 15:49, 23 July 2017 (UTC)
@Maile66: I don't think you've wasted anyone's time. And if the "fix" that you got is the same as everyone else needs we may need to put it site wide. — xaosflux Talk 00:33, 24 July 2017 (UTC)
Xaosflux There's another piece to this puzzle regarding Firefox 54.0.1 (which I've just learned to live with) - that version of Firefox became available almost at the exact same time that Wikipedia started rolling out its changes. And there's more than just the double spacing issue. Opening an edit window in Firefox is funky, and I don't know if it's Firefox or the Wikipedia changes. And the issue with the Firefox edit window opening is that not everything loads (toolbar, and on opening things like AIV/RFPP listings, the "Show" link to drop down the templates) The solution to getting everything to drop down is to reload the page, or do a Preview, or whatever works at that time. And then again ... sometimes everything in the edit window opens up the first time. I haven't checked the Edge browser on anything but the double spacing, so I don't know if these issues are inherent in the current version of Firefox, or if all of these issues are a conflict with any Firefox version. — Maile (talk) 00:50, 24 July 2017 (UTC)
The "doublespace" problem does appear to be limited to Firefox (at least in FF v54.0.1) - verified with a separate account on testwiki - using chrome there is no doublespacing, with FF there is (with the new UI). — xaosflux Talk 01:32, 24 July 2017 (UTC)
@Maile66: If you mean the line
@import url('https://en.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=User:Lupin/navpopdev.css');
that, in essence, means "take the whole of the page User:Lupin/navpopdev.css and copy it here". So any CSS on that page will affect your experience as a user, and any changes there will be outside your control. --Redrose64 🌹 (talk) 18:52, 23 July 2017 (UTC)
Side note: The OOjs UI change (aka "Big Blue Button") has only been deployed to the Wikipedias so far. It will reach most sister projects on Tuesday, August 1st, and Commons sometime later. The reason I split this up is because it can affect some editing scripts, and there are only a handful of volunteers who really know how to fix some of them. I didn't want to overload them with all the wikis on the same week. The main downside is that you can't test a script this week at, say, Wikisource, to determine whether it's working under OOsj UI. Instructions for testing (including how to turn it off here for a single edit, by hand-editing the URL to include &ooui=0, so that you can see whether a problem you're encountering is actually related to this) are still at mw:Contributors/Projects/Accessible editing buttons. Whatamidoing (WMF) (talk) 18:09, 24 July 2017 (UTC)

Fixing a typo.....[edit]

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

Chandrasekhar's H-function for different albedo

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)

File:Chandrasekhar's H-function.pdf 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)

#iferror does not work correctly with template:convert for me[edit]

I try to use {{#iferror:}} in a template which uses template:convert so that when the convert template gets invalid input, no "invalid number" error is returned. See User:Spike/Sandbox/Template:NFL predraft 2 for a simple example. But it does not work for me. When I use my new template User:Spike/Sandbox/Template:NFL predraft 2 on a page, see e.g. User:Spike/sandbox, I still see an "invalid number" error. The strange thing is that when I edit a page which transcludes this template, everything looks fine in the preview window: as I expected from the code, the error is simply replaced by the non-converted value. Try it out: Open User:Spike/sandbox for editing and click "Show preview" without changing anything. No error visible, #iferror replacement works perfectly. Only when I save the page does the error show up. Can someone tell me what I'm doing wrong? I have also tried another template which uses the same method, template:Ridership, and it seems that it has the same problem.

Until now I only have tried all of this in my own sandbox. Maybe it is a problem which only comes up in the sandbox and not in the proper Wiki. But I have not yet had the courage to do a change in the main namespace to try it out. Spike (talk) 14:47, 21 July 2017 (UTC)

{{#iferror:}} checks for class="error". {{Convert}} uses ispreview() in Module:Convert to only add that class in preview where a prominent red error message is displayed. On saving it adds the blue link seen in User:Spike/sandbox without class="error". {{convert|2{{frac|3|8}}|in}} produces:
[convert: invalid number]
Compare the above in save and preview. PrimeHunter (talk) 16:24, 21 July 2017 (UTC)
Seriously? This is why stuff like "ispreview()" is a bad idea and should be avoided. Anomie 16:38, 21 July 2017 (UTC)
As I understand it, "ispreview()" is not the issue here but the fact that {{Convert}} does not save "class=error". With such a saving, "#iferror" will work. (see also Template talk:Convert, looks good). Objections to "ispreview()", I'll encounter in other places then. -DePiep (talk) 20:19, 22 July 2017 (UTC)
My issue here is that the output of the template when previewed is wildly different from the output of the template when saved, which misbehavior "ispreview()" enables. Anomie 13:06, 23 July 2017 (UTC)
Convert works like that because people requested it. The idea is that if an editor uses a convert with a bad parameter, the editor should be given a chance to see the problem with an in-your-face error message, but readers should not stumble over the defacement if the page is saved with the error. At least one other widely used template does the same. Editors often adjust convert parameters in a big wiki-gnoming edit, and sometimes they mess it up but do not notice the problem in the middle of a big article. There is not much point in having an ugly message visible, and the tracking category means the problem is fixed with a couple of days. What is the actual problem with ispreview? Johnuniq (talk) 22:39, 23 July 2017 (UTC)
The actual problem here was that the output of the template differed so that {{#iferror:}} worked in preview but not when the page was saved. In general, I'd say the point of previewing is that it should as much as possible show what the page is going to look like when saved, not something gratuitously different no matter how much some people might want it to be gratuitously different for their specific use case. Anomie 12:28, 24 July 2017 (UTC)
@Spike and PrimeHunter: I proposed a change to Module:Convert/text at Template talk:Convert#Add <span_class="error"><span/> to cvt_format and cvt_format2 that would add an empty span with class "error" to the blue link error messages to allow them to be detected by {{#iferror:}}. --Ahecht (TALK
PAGE
) 17:22, 21 July 2017 (UTC)

Improper formats for bullets when images are used[edit]

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 (talkcontribs) 15:29, 22 July 2017 (UTC)
Works exactly as advertised. JohnWickTwo (talk) 15:36, 22 July 2017 (UTC)

Revert dialog and Chrome[edit]

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)

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

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)

Verifying status and length of protection[edit]

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[edit]

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[edit]

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[edit]

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)

Varieties of criticism[edit]

Can someone explain why no table of contents appears in varieties of criticism? This is generally sub-optimal behavior (per WP:Accessibility) and a Ctrl+F for "notoc" doesn't appear to identify the offending wikicode. --Izno (talk) 23:45, 23 July 2017 (UTC)

@Izno:  Works for me (see image right).
Works for me
. — xaosflux Talk 00:36, 24 July 2017 (UTC)
@Xaosflux: I'm not seeing it in Vector (works for me is probably not the best response for a non-default skin :D). --Izno (talk) 00:44, 24 July 2017 (UTC)
@Xaosflux: re-sign and ping. --Izno (talk) 00:45, 24 July 2017 (UTC)
The TOC was missing for me but appeared when I purged the page. PrimeHunter (talk) 00:56, 24 July 2017 (UTC)
@Izno: I don't recall ever actually "changing" my skin, so monobook is my default ;) — xaosflux Talk 01:26, 24 July 2017 (UTC)
Xaosflux was created in 2005, when MonoBook was the default. Vector did not become available until 2010; initially it was opt-in for all users, later it became the default for new users but existing users were left with their existing skin setting. --Redrose64 🌹 (talk) 08:53, 24 July 2017 (UTC)

See also #Rendering problems higher up on the page. This is ticket phab:T168040. —TheDJ (talkcontribs) 07:25, 24 July 2017 (UTC)

Exceedingly frustrating mobile view[edit]

I am stuck owing to internet access reasons accessing Wikipedia via the mobile site. This is a substandard and very frustrating experience. As some of the key features are missing, including on talk pages the "add topic" button, tables of contents on talk pages, I can't access my sandbox, nor full settings. I can't even seem to escape t his experience as I am automatically redirected here. Any ideas how to fix this?? Frustrated, Tom (LT) (talk) 12:34, 24 July 2017 (UTC)

@Tom (LT): If you scroll to the bottom of any Wikipedia page on the mobile site, there is a link that says "desktop". Click it, and your device should redirect to the desktop version of Wikipedia. --Ahecht (TALK
PAGE
) 14:24, 24 July 2017 (UTC)

Jobqeue[edit]

Resolved

How long should it take for a change in a small template to update all articles. Special:WhatLinksHere/Tabarz does not reflect the change at Template:Cities and towns in Gotha (district) six days ago. Agathoclea (talk) 06:21, 24 July 2017 (UTC)

Not even an edit of an article makes a difference. Agathoclea (talk) 08:38, 24 July 2017 (UTC)
Try fixing {{Imagemap Germany district GTH}}, which also links there. עוד מישהו Od Mishehu 08:46, 24 July 2017 (UTC)
Thanks that was the hickup. Agathoclea (talk) 09:03, 24 July 2017 (UTC)

Tech News: 2017-30[edit]

15:57, 24 July 2017 (UTC)