Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Module:Infobox/i18n

This module apparently transcludes onto over 67k pages, including the June 28 TFA, but it does not actually exist. Should it exist, or if not, should it be protected from creation to prevent vandalism from transcluding onto all these? Home Lander (talk) 20:23, 26 June 2018 (UTC)

See Template talk:Infobox/Archive 14#Redlinked 'Module:Infobox/i18n', protection is probably a good idea for the reason you gave. Nthep (talk) 20:35, 26 June 2018 (UTC)

That mentions Module:Message box/i18n too. --Emir of Wikipedia (talk) 20:39, 26 June 2018 (UTC)

I added creation protection to this, any admin is welcome to override/modify as they deem appropriate without consultation. — xaosflux ^Talk 20:42, 26 June 2018 (UTC)

Thanks Xaosflux, can you close my request at RPP. Home Lander (talk) 20:47, 26 June 2018 (UTC)

 Done — xaosflux ^Talk 20:52, 26 June 2018 (UTC)

@Xaosflux: Can we also protect Module:Message box/i18n too? That is transcluded as well over 4000 times.--Emir of Wikipedia (talk) 20:55, 26 June 2018 (UTC)

@Emir of Wikipedia:  Done — xaosflux ^Talk 21:02, 26 June 2018 (UTC)

@Xaosflux, Nthep, and Johnuniq: Wouldn't it be easier to just revert the edit by Ans, instead of protecting lots of /i18n subpages which will never be needed? I find it unlikely that some random module is going to have an /i18n subpage which needs to supersede the i18n table of Module:Wikidata (which is apparently what the change is supposed to allow for). Jc86035 (talk) 21:38, 26 June 2018 (UTC)

I think that this function:

function p.loadI18nFrame(frame, i18n_arg)
	p.loadI18n(frame:getTitle().."/i18n", i18n_arg)
end

in Module:I18n is related. --Redrose64 🌹 (talk) 22:21, 26 June 2018 (UTC)

I won't have a chance to look at that for perhaps 24 hours but judging by my 2017 comment in the archived discussion linked above I thought the i18n code was not desirable. If no one beats me to it, I will unwind the code to remove that apparently unused feature. It is conceivable that it is used on other projects. If that is the case I would find a solution which does not cause the alarming red-links seen here. Johnuniq (talk) 23:18, 26 June 2018 (UTC)

Assuming anyone fixes the cause, any admin should feel free to revert the then uneeded create-protection. — xaosflux ^Talk 02:17, 27 June 2018 (UTC)

@Johnuniq and Xaosflux: There are apparently only three i18n subpages in non-sandbox modules on the English Wikipedia, one of which is blank, and one of which acts as a redirect. The other one is Module:Wd/i18n. I think it's safe for now to remove whichever function is causing the nonexistent pages to be called, particularly since the global template repository will not exist for some years. Jc86035 (talk) 03:19, 27 June 2018 (UTC)

Doing the same search on several other Wikipedias shows that this particular function is basically a completely useless feature right now since it hasn't caught on yet. There are a few dozen modules which use i18n tables, like Module:Routemap and Module:Video game reviews, but only one or two modules use subpages named /i18n. Jc86035 (talk) 03:26, 27 June 2018 (UTC)

@RexxS and Pppery: Are Module:Wikidata/i18n and Module:Wd/i18n actually useful? As far as I'm aware these are the only two modules which actually use an /i18n subpage, so much of the i18n subpage code in the main modules (the parts which handle the table merging and replacement) can probably be discarded to avoid massive amounts of redlinks being created. Jc86035 (talk) 22:44, 27 June 2018 (UTC)

@Jc86035: The sub-modules are not actually useful on enwiki. Their value would be in helping those who wish to use these sort of modules on foreign wikis. The intention was that the main module can be regularly updated by copy-paste from the master on enwiki while the English messages etc. will simply be overridden by a local internationalised /i18n sub-module in the local language where that exists. However, if it turns out that nobody is taking advantage of that, then it seems pointless to keep the framework here. --RexxS (talk) 23:39, 27 June 2018 (UTC)

@RexxS: Furthermore, was the calling of random i18n subpages like Infobox/i18n intended? If not then maybe the aforementioned edit by Ans should be reverted, and maybe the equivalent functionality (if any) should be removed from Module:Wd and from Module:I18n. Jc86035 (talk) 23:55, 27 June 2018 (UTC)

I'm not the right person to ask, because I don't believe in the value of any kind of modification of code to make it easier to copy to a different project at all, so of course think that Module:I18n and all forms of /i18n subpage are code bloat. {{3x|p}}ery (talk) 01:37, 28 June 2018 (UTC)

Like RexxS said, the value is maintainability across projects. To Module:Wd the /i18n submodule is only relevant to the parent module and I suppose that should be the case for any of these internationalisation submodules. Other modules should not worry or care about such submodules related only to the modules they include, since it should be self-contained. I'm not sure what's causing this to go wrong for the Infobox module, but it seems like this internationalisation concept was either misunderstood or interpreted differently by someone. Thayts ••• 11:06, 30 June 2018 (UTC)

I asked for some background at Module talk:Wd#Code for i18n. If anyone has information about those issues please mention them there (for example, does local arg = ... do anything useful in a module?). Johnuniq (talk) 03:39, 28 June 2018 (UTC)

Yes it does do something useful, see the talk page. But I'm not sure if ... by itself is part of the cause of the problem described here at all. Thayts ••• 11:06, 30 June 2018 (UTC)

Seeking intrepid technical volunteers for a mission

I'm thinking about what to say, and I keep thinking of this World War II-era comic strip. A junior officer stands up in front of his combat unit and says "I need a volunteer what don't owe me no money for a little routine patrol."

It's not that bad (honest!), but I do have a kind of odd request: I need some tech-savvy people who are willing to fix some templates and HTML markup in articles at non-English Wikipedias.

Situation: HTML5 is coming to the last ~100 wikis next Thursday (5 July). Most wikis, including this one, are mostly ready. A few are not. Some of them have more than 10K mainspace errors. Some of these errors are even very easy to fix:

• In many cases, the problem is in a template were originally copied from this wiki, and the changes have already been implemented here, so it's just a matter of copying the recent fixes over. An editor very kindly did this for train-related templates at the Chinese Wikipedia, and cleared up hundreds of errors on the spot.
• In some cases, it's super-simple fixes, like the literally thousands of articles that have <small>...<small> when they ought to say <small>...</small>. You don't have to be able to read the local script; just search for unclosed small tags and add the slash to close the last one (example).

The wikis that I'm most worried about are: ptwiki, zhwiki, srwiki, arwiki, viwiki, and plwiki. Here's the list of problems:

Error name (code)	Chinese	Portuguese	Serbian	Arabic	Vietnamese	Polish
deletable-table-tag (7)	1,454	2,305	2,374	915		793
pwrap-bug-workaround (9)	929	378	3,779	1,444
html5-misnesting (12)	9,863	10,654	839	1,737	2,811
tidy-font-bug (13)	18,991	2,668	2,062	2,683	2,781	538
multiple-unclosed-formatting-tags (14)	1,787	2,262	288	358		5,177

The links take you to a list of just articles (e.g., not talk pages) that are affected. At some wikis, these errors affect a non-trivial fraction of all articles.

What I'd like: If you have fixed these errors here, please check one of these wikis, and see if you can help. If you maintain a favorite template (or set of templates) here, please check out the matching templates at other wikis. It is generally not necessary to speak the local language to fix up the HTML. I've used the correct HTML (like "<small>...</small>") as an edit summary, and nobody's objected yet. Many hands make light work, and one gnome really could single-handedly solve some of these problems. Please help. If you need help figuring out where to start, then leave a note at WT:Linter or ping me. Whatamidoing (WMF) (talk) 21:35, 26 June 2018 (UTC)

I am not volunteering for this but just suggesting that someone considers looking into some automated like perhaps AWB to help with this. Personally I have used AWB on the English Wikipedia to to find and remove cases where "<small>" and "</small>" are used so I imagine it that it might be helpful with this. --Emir of Wikipedia (talk) 21:40, 26 June 2018 (UTC)

I posted a notice at WP:BOTN to bring bot coders to the party. Hopefully some will show up. Headbomb {t · c · p · b} 23:22, 26 June 2018 (UTC)

The lists of templates on pt.WP look especially ripe for improvement. If someone can figure out how to fix these templates, it will probably reduce the article count significantly. I found one obvious fix, which probably fixed a couple dozen articles, but I am stumped on the rest. My gut feeling is that Template:Navbox on pt.WP may be the root cause of many of the errors. – Jonesey95 (talk) 05:34, 27 June 2018 (UTC)

Just had User:Fluxbot (working just slightly off-task) empty w:pt:Especial:LintErrors/self-closed-tag; so there are 100 less high-priority ones. — xaosflux ^Talk 12:06, 27 June 2018 (UTC)

Thank you! You all are awesome.

I spent a while looking at a navbox (in my sandbox at ptwiki, if anyone wants to have a go at it – feel free to try out a few edits), and I've got no idea what's triggering the errors. Jonesey's gut feeling seems very plausible to me. Usually, the span tag problems are about the order that various elements are placed in (e.g., italics need to be on the outside of a language template), but I haven't figured these out. Whatamidoing (WMF) (talk) 06:53, 28 June 2018 (UTC)

See also pt:Predefinição Discussão:Nowrap begin. As this template is used on about 85 Wikipedias (not counting sister projects), this simple change might be needed at many more wikis. Whatamidoing (WMF) (talk) 17:49, 29 June 2018 (UTC)

FWIW, I have either personally fixed it or had others with rights fix them or left messages (like this one) on many 10s of wikis over the last 6 months. So, I think a majority of those 85 wikis should have been covered by this by now. SSastry (WMF) (talk) 09:21, 30 June 2018 (UTC)

Some of these multiple-unclosed-formatting-tags are really messed up! Nested <small>s with two missing </small> tags and I'm losing my mind.. - TNT ^💖 09:55, 30 June 2018 (UTC)

My theory is this: people know that the '' markup both starts and ends some italic text, similarly with ''' for bold. They have the firm idea that these work like toggles, to switch between the ordinary and the modified. They then hear of <small> and assume that it is also a toggle, and that they should use <small> a second time to switch off small text. They may never have heard of end tags. --Redrose64 🌹 (talk) 10:34, 30 June 2018 (UTC)

Agreed - I'm not blaming anyone! {{small}} goes some way to make the tag easier to use, as most experienced editors are aware of how templates work, but I'm not sure how many projects have that template.. - TNT ^💖 11:08, 30 June 2018 (UTC)

I've cleared a few of the code 13 errors. -- WOSlinker (talk) 23:31, 30 June 2018 (UTC)

Error name (code)	Chinese	Portuguese	Serbian	Arabic	Vietnamese	Polish
tidy-font-bug (13)	18,991 -> 1498	2,668 -> 454	2,062 -> 7	2,683	2,781	538 -> 17

Just for the record, clearing more than 22,000 errors is not "a few". I really appreciate your generosity and kindness in pitching in with this. I'm practically "Face with Tears of Joy" today. Whatamidoing (WMF) (talk) 02:00, 2 July 2018 (UTC)

@Whatamidoing (WMF): I've added the wikis you mentioned to my lint count tool - click 'Linter errors by namespace' to get a dropdown list of them all. Might help people focus their efforts. Counts updated every ~30 minutes. ƒirefly ( t · c · who? ) 12:27, 1 July 2018 (UTC)

Thank you, ƒirefly. Whatamidoing (WMF) (talk) 02:00, 2 July 2018 (UTC)

Most of the problems at fywiki involve a single template. If you have above-average wikitext-table-fu, then please see m:User talk:Ieneach fan_'e Esk#Fywiki. Whatamidoing (WMF) (talk) 18:43, 2 July 2018 (UTC)

Lua module editors might be able to tackle this one on cewiki which is probably straightforward. SSastry (WMF) (talk) 13:40, 5 July 2018 (UTC)

Putting a stand-alone list in two columns?

I'm not sure if we are allowed, or if it is technically feasible, to do this. MOS:LIST#Tables is the only place on that page "columns" is mentioned, and it says tables are discouraged except for cases like, for example, where three or more columns are warranted; but what if I only want two columns? Specifically, I think the page List of Man'yōshū poets would benefit from this, as much of the page only uses the left half of the screen. I was torn between asking this question on WT:MOS (with an emphasis on whether it was recommended) and here, but really I'm more interested in whether it is possible, so here. Hijiri 88 (聖やや) 09:57, 27 June 2018 (UTC)

There are a number of templates such as Template:Div col that can do this.--Racklever (talk) 11:20, 27 June 2018 (UTC)

Listing a specific number of columns is generally deprecated (on Wikipedia) because it is not very responsive. You can set a colwidth with a template like the one that Racklever linked and that will flex depending on how wide the reader's screen is. --Izno (talk) 12:40, 27 June 2018 (UTC)

Annoyingly, the default for {{div col}} without any parameters is to produce two fixed columns. That really ought to be fixed. --RexxS (talk) 00:06, 28 June 2018 (UTC)

Yes, I noticed this. Of the 144k articles transcluding the template, only 10k have no parameters, which is fairly few. I'll take a look... --Izno (talk) 02:32, 28 June 2018 (UTC)

It looks like there were some discussions in the March timeframe, and there are edits queued in the sandbox for the default behavior to change, but it is not obvious to me that anyone is working Jonesey's recommended path (which is, not to implement the sandbox until the remaining 10k articles or so are cleaned). I don't think I agree with that path, but I don't feel like chasing the talk page about it. Feel free to drop by there and see if there is large resistance to moving implementation forward. --Izno (talk) 02:52, 28 June 2018 (UTC)

TheSandDoctor began running a bot task (DeprecatedFixerBot, see Wikipedia:Bots/Requests for approval/DeprecatedFixerBot 2) to remove the deprecated parameters, then halted the bot while a lively discussion ensued on the operator's talk page. As of 7 June, TheSandDoctor intended to restart the bot, and then got caught up in becoming an administrator and hasn't had a spare moment, what with all of the mopping. Once the bot finishes its work, the template can be updated based on the sandbox code, or something close to it. – Jonesey95 (talk) 05:01, 28 June 2018 (UTC)

That is correct Jonesey95 and thanks for the prod. I have now resumed the bot with a one thousand page run. Of course, it isn't going to be able to handle every page (so won't touch ones that don't match specific conditions), that is just the "sample size" of the run. --TheSandDoctor ^Talk 05:43, 28 June 2018 (UTC)

@RexxS: I hope you don't mind, but I've undone your change to the article linked at the top of this thread. I don't exactly understand why (if I did I wouldn't have needed to come here for technical advice), but on every screen I have access to at the moment the list with the "colwidth" parameter added looks identical to the list without the div col template in place at all; even if it's deprecated, this really seems like an IAR situation because the page looks a lot better (at least on my laptop, tablet and phone) with the columns, and without them the "List" heading I added here is meaningless (I actually used the preview button a few times to figure out how best to work it, and only included the heading to keep the right-hand column from running parallel to the table of contents). Hijiri 88 (聖やや) 00:53, 30 June 2018 (UTC)

@Hijiri88: It doesn't matter whether I mind or not: having two fixed columns is bad for readers who have very narrow screens or very wide ones. If {{div col|30em}} gives you one column on every screen you have, then you don't have a screen wider than about 1000px, but lots of other readers do. It's not fair to make an article look good on just a narrow range of screen sizes without taking into account other readers. I've tried again with colwidth set to 30em in the hope you find that acceptable. If not, you really ought to be trying 25em or 20em for yourself - you can do it in preview - rather than reverting to two fixed columns.

@Jonesey95: You finished your cleanup in March. Isn't it about time that we updated this template to remove support for fixed widthsnumber of columns? --RexxS (talk) 01:48, 30 June 2018 (UTC)

Maybe so, but the article definitely looked worse on my laptop screen (which apparently has more pixels than my phone or tablet, unsurprisingly) under your initial edit than under your new, revised edit that actually fixed the problem. I came here and politely asked a technical question for which I should not be expected to know the answer, and you responded by effectively undoing my edit (at least for all readers whose screens are the same size as my laptop's). You have my thanks for now having resolved the issue (honestly I still think the two columns looked better on my iPad than the one that shows up now, but I guess that's a matter of opinion), but in future please just explain up-front why 20em, 25em or 30em would be better than two fixed columns (40em is definitely worse than two fixed columns on every screen I have access to at the moment) rather than implementing an edit that moots the whole point of the question without offering an explanation on the original thread. I don't even know what an "em" is, and I'm pretty this page is supposed to allow folks like me to ask for assistance with these problems (this is actually unclear, though -- both the page header and Wikipedia:Village pump (technical)/Before posting variously imply that the page is only for one or the other of asking questions or reporting bugs and other issues). Hijiri 88 (聖やや) 02:02, 30 June 2018 (UTC)

Yes, I did some work in March, but we have been waiting for the bot job to finish (i.e. for the deprecated parameter category to be cleared out) before completely removing the deprecated parameters. This is just normal template conversion work; sometimes it takes time, especially when there are thousands of articles involved. The bot has been quite active in the past few days, reducing the categories from about 8,000 pages to just under 4,000 pages. Once the bot is done, humans will need to clean up the cases that were not fixable by the bot. Patience, grasshopper.

Also, just to be clear, we are not removing support for fixed widths. We are removing support for a fixed number of columns. It may be better to continue this discussion at Template Talk:Div col. – Jonesey95 (talk) 05:12, 30 June 2018 (UTC)

@Hijiri88: You need to compare my amendment with your revert on a wider screen sometime to get the full picture and understand why a fixed number of columns is a bad idea.

@Jonesey95: I have little patience with poor template implementations. Why should readers have to wait years for an obvious fix to materialise? Reflist was fixed in fraction of the time once we worked on it. Screen resolutions are diverging continually and responsive layouts are essential to catering for as wide a range of readers' screens as possible. The 'fixed widths' was obviously a typo on my part, and I've corrected that. --RexxS (talk) 09:52, 30 June 2018 (UTC)

The template implementation was not poor when it was developed, since responsive design was either nonexistent or in its infancy. Software migrations take human effort to perform in ways that don't leave readers looking at bad formatting in articles. If you're out of patience, you're welcome to clean out the deprecated parameter categories. Take a look at the BRFA for details on the fixes that should be applied to {{div col}} and {{columns-list}}. I manually fixed at least 99% of templates that are affected. There are only about 3,000 pages in article space left. I've been chipping away at them slowly over the past week or so. – Jonesey95 (talk) 20:05, 30 June 2018 (UTC)

List items containing sublists

Is there any way, a template or anything, to allow a single * list item to span multiple lines and continue after sublists? Is something like the following possible with syntactically correct wikimarkup? (I’m using numbered lists here to better illustrate what’s happening.)

1. Some stuff.
2. Some other stuff, including:
   1. things
   2. other things
   and stuff like that.
3. Yet more stuff.

This is easily doable in HTML, as I did here: just keep typing after closing the sublist. In wikimarkup, a purely visual effect is possible by using : after the sublist, but that’s syntactically very wrong.

Expand me if you’re not sure why that’s wrong.

This list should be identical to the above, but the final item changes from 3 to 1 because there’s something in between. Markup Renders as *Some stuff. *Some other stuff, including: **things **other things :and stuff like that. *Yet more stuff. Some stuff. Some other stuff, including: things other things and stuff like that. Yet more stuff. The problem being, the use of a colon results in a type of MOS:LISTGAP situation: it terminates the original list, creates a new description list of one, then creates a third list containing what was supposed to be the rest of the first. We don’t want three lists of different types. Just one continuous list that isn’t syntactically awful and doesn’t cause accessibility issues.

Is there any workaround besides laying out the entire thing in HTML (or rewriting)? Maybe a templated implementation of lists? Thanks. —67.14.236.193 (talk) 03:56, 28 June 2018 (UTC)

I just found {{bulleted list}}, which seems to be partly exactly what I just asked for.

markup
Markup Renders as {{bulleted list |Some stuff. |Some other stuff, including: *things *other things and stuff like that. |Yet more stuff.}} Some stuff. Some other stuff, including: things other things and stuff like that. Yet more stuff.

The HTML source of that is about identical to my first example above. I don’t think it would work in every scenario, but it definitely helps. —67.14.236.193 (talk) 04:19, 28 June 2018 (UTC)

Nope, {{bulleted list}} is no good. If there’s nothing on a line after a sublist (for instance, if the line “and stuff like that” were removed above), that sublist never ends, and the entire rest of the list gets indented. So, back to square one. Help? —67.14.236.193 (talk) 05:39, 28 June 2018 (UTC)

markup
Markup Renders as {{bulleted list |Some stuff. |Some other stuff, including: *things *other things   |Yet more stuff.}} Some stuff. Some other stuff, including: things other things   Yet more stuff.

Is this the kind of nothing you want on the next line? There's an nbsp on the "blank" line. – Jonesey95 (talk) 05:53, 28 June 2018 (UTC)

@Jonesey95: I’ve taken the liberty of collapsing all the markup (they’re kinda bulky), but I actually meant within the param, after the sublist:

markup
Markup Renders as {{bulleted list |Some stuff. |Some other stuff, including: *things *other things |Yet more stuff.}} Some stuff. Some other stuff, including: things other things Yet more stuff.

That’s a problem. And probably not what this template is meant for, anyway. BUT! This works:

markup
Markup Renders as {{bulleted list |Some stuff. |Some other stuff, including: {{bulleted list |things |other things }} and stuff like that. |Yet more stuff.}} Some stuff. Some other stuff, including: things other things and stuff like that. Yet more stuff.

So we can’t (or shouldn’t) mix wiki lists and template lists, but we can nest the template in itself. So… is there anything more editor-friendly that kinda does the same thing? —67.14.236.193 (talk) 06:56, 28 June 2018 (UTC)

See Help:List#Continuing a list item after a sub-item for our current recommendations. Not sure they're good solutions (for various meanings of "good"), but if you have any thoughts about how to improve or other solutions, feel free to contribute there or discuss on its talkpage. DMacks (talk) 11:30, 30 June 2018 (UTC)

@DMacks: Thanks, I missed that section. But it seems to be recommending what I concluded here, so I guess that’s as simple as it’s gonna get. —67.14.236.193 (talk) 15:49, 30 June 2018 (UTC)

User compare report at SPI cannot handle Thai characters

At Wikipedia:Sockpuppet investigations/รุตม์, it appears that the user compare report cannot handle Thai characters. I had seen this when I tried the report when I filed the SPI, but after the blocking admin made a comment about it, I decided to bring it up here to see if it can be fixed. Dr. K. 17:19, 28 June 2018 (UTC)

The way to get the error is to type this command. Python says "<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 99-103: ordinal not in range(128)". The user compare may be one of the tools in https://tools.wmflabs.org/betacommand-dev/. EdJohnston (talk) 17:29, 28 June 2018 (UTC)

Side note: the above link shows a Python snippet

40   try:
41       main()
42   finally:
43       pass

...which is quite an eyesore. The pass statement should go (either line 44 and following are on the same level of indentation as line 43 and do something, then nuke line 43, or they are not, then nuke lines 42-43). This reeks of vestigial code. Tigraan^{Click here to contact me} 16:24, 29 June 2018 (UTC)

Thank you Tigraan. Your solution, to be implemented, must be done at the WMF Labs. Should a bug report be opened? Dr. K. 18:45, 29 June 2018 (UTC)

Huh, Dr.K., what I propose is not a solution to the problem you reported (hence the side note); it is a purely cosmetic change to the code and should not affect how it runs. (I doubt it's worth a bug report.) Tigraan^{Click here to contact me} 09:06, 2 July 2018 (UTC)

Thursday's software release issues, 28 June (1.32.0-wmf.10)

I just made WP:ITSTHURSDAY to explain this recurring issue. Summary: It's probably not you. --Izno (talk) 13:50, 29 June 2018 (UTC)

crazy watchlist

Tracked in Phabricator
Task T198440

Something has happened with the watchlist. There seems to be a line break after each bullet point, so the diff and hist links, and the pagename and all the rest appear on the next row instead of the same row, and as a result, the watchlist is twice as long. HandsomeFella (talk) 21:10, 28 June 2018 (UTC)

• Same problem here. I use Monobook, on Edge, on Win10. DuncanHill (talk) 21:43, 28 June 2018 (UTC)

I see it in Edge but not in Firefox. I see it both in Vector and Monobook, both here and at Commons, and also with safemode=1. I see it for two seconds at Special:RecentChanges while it's permanent at Special:Watchlist. If I enable "Hide the improved version of Recent Changes" at Special:Preferences#mw-prefsection-rc then it's also permanent at Recent Changes. We got mw:MediaWiki 1.32/wmf.10 today so I guess it's something there. PrimeHunter (talk) 23:38, 28 June 2018 (UTC)

Same for me, in Edge but not Chrome. Black Kite (talk) 08:10, 29 June 2018 (UTC)

• Seeing the same in IE 11. Gandalf61 (talk) 08:17, 29 June 2018 (UTC)

Same here. What's just changed? Was fine an hour ago. Martinevans123 (talk) 08:34, 29 June 2018 (UTC)

• I'm also seeing this in IE11. Double sharp (talk) 12:26, 29 June 2018 (UTC):
• Same problem in Win10/MS Edge. Works fine in Chrome. --Hobbes Goodyear (talk) 23:17, 29 June 2018 (UTC)
• Ditto here. Use Edge in latest edition of Windows 10. SMP0328. (talk) 23:50, 29 June 2018 (UTC)

OK... everybody saying "yes, me too" seems to be using a Microsoft browser (Internet Explorer or Edge). Is anybody having this problem but not using a Microsoft browser? Is anybody using a Microsoft browser and not having this problem? --Redrose64 🌹 (talk) 08:35, 30 June 2018 (UTC)

I don't mean to be cheeky, but if you have deployed something, and it doesn't work, why don't you just back the change out, and try to find what's wrong in a test environment? I work in IT (though not on this platform), that's what I'd do if something similar happened to me. Also, is there a time plan? HandsomeFella (talk) 22:01, 1 July 2018 (UTC)

Anyone know where we can request that failed updates be backed out, and get an ETA? Or, if WMF has decided the MS products are to be unsupported or under-supported, where we can request that they explicitly recommend that MS users switch to Google products? --Hobbes Goodyear (talk) 22:12, 1 July 2018 (UTC)

That happens sometimes, depending on the severity of the issue. This issue doesn't seem to rise to that level of severity.

The fix has been merged, and absent a backport should be deployed here with the next deployment, which would be 1.32.0-wmf.12 scheduled for Thursday 2018-07-10 (there are no deployments this week due to the US holiday on Wednesday). Anyone can propose a backport, see wikitech:SWAT for details of the process. Anomie⚔ 22:19, 1 July 2018 (UTC)

Thanks. --Hobbes Goodyear (talk) 22:25, 1 July 2018 (UTC)

Looks back to normal for me now. DuncanHill (talk) 00:59, 3 July 2018 (UTC)

Yep, the watchlist displays properly now. Thanks. HandsomeFella (talk) 11:33, 3 July 2018 (UTC)

Watchlist bullets

Tracked in Phabricator
Task T198445

I'm not sure this is the same problem, although it seems likely to be related, but as of sometime late yesterday, my Watchlist no longer has bullet points for either seen or unseen changes, under Chrome (version 67.0.3396.62). They appear, very briefly, and within ~1 second vanish, never to return. With IE11, the extra line break also occurs while the bullet points are visible, but vanishes (along with the bullets) within 1-2 seconds. Squeamish Ossifrage (talk) 13:51, 29 June 2018 (UTC)

I'm using Firefox 60 and experience the same issue regarding watchlist bullets. I'm using the enhanced watchlist. Are you? --Izno (talk) 14:01, 29 June 2018 (UTC)

Do you see this at other wikis (i.e., the ones that don't also have the English Wikipedia's green-dot script)? Whatamidoing (WMF) (talk) 16:46, 29 June 2018 (UTC)

It did occur to me that it might be those. No, I haven't tested it yet because I wasn't sure how much effort I wanted to put into testing it. When I get a chance ~ --Izno (talk) 18:48, 29 June 2018 (UTC)

I'm also using Chrome (version 67 on Windows 10) and I also have this problem. Specifically whenever I look at my watchlist on my laptop, I don't see any dark bullets, only hollow ones, even if the "mark all changes as seen" message is still on the top, meaning that there are some changes I haven't seen. Everymorning talk to me 14:46, 30 June 2018 (UTC)

Do you all have "Group changes by page in recent changes and watchlist" checked under "Advanced options" at Special:Preferences#mw-prefsection-rc? Whatamidoing (WMF) (talk) 02:33, 2 July 2018 (UTC)

I was having various watchlist bullet problems regardless of the status of that toggle. However, as of today, things seem back to normal? Squeamish Ossifrage (talk) 13:36, 2 July 2018 (UTC)

We just deployed a patch, so you should see this fix in your Special:Watchlist and on Special:RecentChanges soon. Thank you for letting us know about the issue, and for your patience while the fix was pending deployment. KHarlan (WMF) (talk) 13:40, 2 July 2018 (UTC)

Issue with auto-patrol?

Tracked in Phabricator
Task T198497
Resolved

Hi. I've had the auto-patrol user right for some time now, but new articles I've created today have gone through page curation (example). Obviously this creates an extra backlog on page curation, where there wasn't one before. Thanks. Lugnuts ^{Fire Walk with Me} 13:18, 29 June 2018 (UTC)

@Lugnuts: "patrolled" and "reviewed" are not the same thing (though many of the "review" activities ALSO mark a page patrolled). — xaosflux ^Talk 13:26, 29 June 2018 (UTC)

OK, I'm getting the terms mixed up, but whatever the right is that allowed me to create new articles without them going to the new page patrol list has changed. It's not just me with this issue. Thanks. Lugnuts ^{Fire Walk with Me} 13:28, 29 June 2018 (UTC)

• - Yes, there does seem to be snafu. Not only did I come across one from Lugnuts, but also Magicpiano, and The Drover's Wife, both of which I believe have autopatrolled rights. The good news is, I checked about 20 of the other new creations from all 3 editors, and all were autopatrolled. Onel5969 ^{TT me} 13:29, 29 June 2018 (UTC)

  So it sounds like there may be a feed/filter issue? Are you using Special:NewPagesFeed and expecting "patrolled" pages to be able to be filtered out (like how "reviewed" pages can be filtered out)? — xaosflux ^Talk 13:31, 29 June 2018 (UTC)

  Yes, I'm using the NewPagesFeed, which has always filtered out the reviewed and patrolled pages before. Onel5969 ^{TT me} 13:59, 29 June 2018 (UTC)

  @Xaosflux: It's not an issue with the feed or mixed up terminology. Pages created by admins or users with the autopatrolled right are supposed to be marked as reviewed (in the Page curation log) automatically on creation. That appears to have been broken. For example, compare the page curation logs for this page I created a few days ago (empty because I'm an admin) and this page Victuallers created today (had to be manually marked as reviewed even though he's an admin). – Joe (talk) 14:08, 29 June 2018 (UTC)

There is some bug, see phab:T198476. Stryn (talk) 13:30, 29 June 2018 (UTC)

Thank you. Lugnuts ^{Fire Walk with Me} 13:33, 29 June 2018 (UTC)

That's different. I think we're getting patrolled and reviewed mixed up here. This is an issue with sysops/autopatrolled users having articles not marked as patrolled automatically, which sends them to the NPP queue. Natureium (talk) 14:05, 29 June 2018 (UTC)

@Joe Roe: so the summary of the problem is "Page creations by editors with autopatrolled access are no longer also be marked as reviewed" (and they WERE previously)? It doesn't look like the phabricator ticket @Stryn: referenced is for this specific case. Did someone already open one? — xaosflux ^Talk 14:34, 29 June 2018 (UTC)

The issue is specifically about page curation. I have created T198497 for this bug. GeoffreyT2000 (talk) 16:01, 29 June 2018 (UTC)

Thanks Geoffrey. Lugnuts ^{Fire Walk with Me} 16:46, 29 June 2018 (UTC)

Hi all -- I'm Marshall Miller; I'm a product manager at WMF working with the Community Tech team. Thanks for filing this bug. We've realized that this problem was accidentally caused by Community Tech's work on improvements to the New Pages Feed, and we're working on a fix now. I'm sorry about this -- it's definitely frustrating that extra pages are showing up in the feed unnecessarily. We definitely don't want to rush and potentially cause any other issues, so the team is currently writing some additional tests for the fix and will be doing code review. Because of that, it's looking like the fix can be deployed on Monday. I'll give another update here in a few hours. -- MMiller (WMF) (talk) 18:57, 29 June 2018 (UTC)

Thanks, Marshall, for the heads up. Schwede66 19:19, 29 June 2018 (UTC)

Hi all -- the team has developed a fix for the bug, and it has been code reviewed. They also wrote additional tests into the code to help ensure that the fix does its job, doesn't break other things, and will be harder to break in the future. The next step is to test the fix in a testing wiki before deploying, which we expect to do on Monday. Thank you for your patience, and please let me know if you have any questions or concerns. -- MMiller (WMF) (talk) 23:46, 29 June 2018 (UTC)

@MMiller (WMF): Thanks for the quick response to this. The timing is awkward, as we were very close to eliminating a two-year-old backlog before the sudden uptick in pages to review! But otherwise it's a relatively harmless bug. Will the fix on Monday retrospectively mark pages as patrolled that should have been? Or will it just fix autopatrolled from that point on? – Joe (talk) 12:16, 30 June 2018 (UTC)

I am seeing the same issue. Hopefully the fix will remove new articles from autoconfirmed users from the queue. My concern was about the queue size as well.–CaroleHenson (talk) 16:55, 30 June 2018 (UTC)

It will not but I can write a quick script to do this. I'll look into this Sunday. — MusikAnimal ^talk 17:33, 30 June 2018 (UTC)

Excellent, thanks, MusikAnimal!–CaroleHenson (talk) 18:44, 30 June 2018 (UTC)

Thanks for that question, Joe Roe, and thank you for thinking about this MusikAnimal. I'll update the Phabricator task. -- MMiller (WMF) (talk) 21:05, 30 June 2018 (UTC)

Defo a bug. I am WP:APAT, and in the last 24 hours two editors have wasted time and effort reviewing and approving two {{R to disambiguation page}} creations of mine. Narky Blert (talk) 21:23, 30 June 2018 (UTC)

@MusikAnimal: That would be very helpful, thanks. – Joe (talk) 21:02, 1 July 2018 (UTC)

Hi all -- the bug fix was deployed by MusikAnimal a few minutes ago, so we expect that new pages created by autopatrolled users are no longer going into the queue for review. Additionally, a script was run to mass review the 1,867 pages that were created by autopatrolled users during the time that the bug was in the software. So at this time, we're expecting that everything is back in order, with existing pages in the right places, and new pages going to the right places. Please post here if you're still seeing anything different! Thank you for your patience with this as we put the fix in place. -- MMiller (WMF) (talk) 18:50, 2 July 2018 (UTC)

Yeah, I too have been getting notices that things like redirects I create (and I do a lot of that kind of gnoming) have been "reviewed". This means the reviewing system is being flooded by stuff it doesn't need to see from me and other affected parties, and I'm getting spammed with "reviewed" notices. This isn't even new; it's been happening to me for some time, though intermittently.  — SMcCandlish ☏ ¢ 😼  00:59, 5 July 2018 (UTC)

WikiMarkup color-shading is missing from a text editor using Chromium

After spending 10 minutes trying to figure out if it was a change I made, I'm convinced that something was altered in the text editor that removed all the colored formatting which specified the different markup in articles. These helpful colors are now all gone in edit mode. I suppose the one question I'm left with asks whether anyone agrees with me that there is a certain inefficiency to taking settings I've set for my own use, turning them off, and then leaving me for 10 minutes with the unshakable feeling that the entire problem was of my own making. So is this really a problem of my own making, or have I become completely delusional. My fish is ready to self-trout if the latter is the case.  spintendo  13:29, 29 June 2018 (UTC)

Spintendo, in case you didn't see Izno's reply to you before I moved it: it is at the top of the section, directly under the Thursday's software release issues (1.32.0-wmf.10) heading. I carelessly moved it to there without noticing it was a reply specifically to what you wrote. (Izno approved the move, but I thought I should tell you if you missed it.) --Pipetricker (talk) 21:44, 29 June 2018 (UTC)

Spintendo, syntax highlighting has a toggle in the toolbar. Look for a highlighter pen (not a pencil) and click it. Whatamidoing (WMF) (talk) 16:53, 29 June 2018 (UTC)

I thought it might be that too, but after re-configuring my settings half a dozen times trying every kind of combination I could think of, and ones I've never tried before, I still cant get the editor back to looking the way it did before whatever it was that happened, happened. Alas, in following the Kübler-Ross stages of grief, I've left behind the levels of denial, bargaining and blame. I'm transitioning now into level 5 - acceptance that I'll probably never see those editor settings and their beautiful colors again. Maybe if I was more of a yellow-appreciative person I'd get along better with the beta wikitext editor - but that color dominates that editor. Oh well, thank you everyone for your help!  spintendo  10:00, 1 July 2018 (UTC)

Problems with the edit window when there is WikiMarkup color-shading

I wanted to report this but didn't have time. My problem is that all these colors and fonts in the edit window are distracting. Furthermore, when I was trying to edit using Microsoft Edge while signed in, the edit would end up in the wrong place and I'd have to fix it. Usually I would be copying and pasting information and it would end up at the start of the edit window rather than where I intended it to go.— Vchimpanzee • talk • contributions • 16:39, 29 June 2018 (UTC)

And I don't know what explains this diff. I blame the software but don't know what I did to get that result. Seeing as how I didn't make another edit to the article I have no way of knowing what I intended there. On the other hand, I might have used the edit window to move some text I wanted to be plain text, which whatever email address I was using would make a complete mess of.— Vchimpanzee • talk • contributions • 16:42, 29 June 2018 (UTC)

That's usually seen when there's a "loss of focus" (the cursor forgets where it's supposed to be) when you start typing. It's a known occasional problem in the 2017WTE, but it's not so common with other editing environments. What's your mw:editor? Whatamidoing (WMF) (talk) 16:53, 29 June 2018 (UTC)

By the way, using Microsoft Edge at home I'm not having problems. I don't usually use it for Wikipedia but it wouldn't allow me into two email addresses, so I used Chrome for those. Since I couldn't easily copy information that I was moving to those email addresses using the edit windows with Microsoft Edge, and since the site kept freezing, I eventually used Wikipedia, but not signed in, on Chrome and had no problems, or colors.— Vchimpanzee • talk • contributions • 16:58, 29 June 2018 (UTC)

Whatamidoing (WMF) I never had the problem of the cursor forgetting where it was supposed to be. I also had some trouble with copying and pasting but don't know how to describe that. I am having a new problem at home. The text is jumping up and down as I type, like there's an earthquake.— Vchimpanzee • talk • contributions • 16:58, 29 June 2018 (UTC)

Wait. Copying and pasting is misbehaving now. The gray area disappears before I finish, but apparently what I copied was copied.— Vchimpanzee • talk • contributions • 17:01, 29 June 2018 (UTC)

Vchimpanzee, what's your mw:editor? There are about a dozen of them, and bugs are tracked separately for each. Whatamidoing (WMF) (talk) 20:47, 29 June 2018 (UTC)

Sorry, I didn't know what that was and forgot to ask. I clicked on that link and couldn't really tell. At a library yesterday, where I was having the focus problem, I was on a desktop, though I think the software is the same as what I use at home. I explained why I wasn't using Chrome. And when I did and wasn't signed in, everything looked normal. I've never used Visual Editor and I am on a desktop at home.— Vchimpanzee • talk • contributions • 20:50, 29 June 2018 (UTC)

If the editing toolbar looks the same when you're logged in vs logged out, then you're using the 2010 WikiEditor. It looks something like https://upload.wikimedia.org/wikipedia/commons/5/5f/VectorEditorBasic-en.png (although the icons were changed a little while ago).

Do you happen to have "GoogleTrans: open a translation popup for the selected text or the word under the cursor when pushing the shift button" enabled in Special:Preferences#mw-prefsection-gadgets? It caused one of the behaviors you're describing, but not the others (and I thought that it had been fixed since then).

Also, do the problems go away if you add &safemode=1 to the end of the URL? (Like this: https://en.wikipedia.org/wiki/User:Whatamidoing_(WMF)/sandbox?action=edit&safemode=1 – feel free to edit that page.) Whatamidoing (WMF) (talk) 21:24, 29 June 2018 (UTC)

Until I go to the library, I won't know. I'm not aware any of what you said is true there. At home, while signed in, I see what look like photos above the edit window. With private browsing, which I was told to use for reading newspapers, there are fewer of those and they look simpler, and there are words on the right, and everything in the edit window is black. The earthquake is still ... wait, it stopped while I was typing.— Vchimpanzee • talk • contributions • 21:29, 29 June 2018 (UTC)

At this library there is Windows 10 and I am using Internet Explorer 11. I'll check to see if it is happening with Chrome too. When I click the left mouse button if the cursor is inside the edit window, I always go to th top of the window, regardless of where I told the cursor I wanted to go. Using the arrow keys is just too frustrating.— Vchimpanzee • talk • contributions • 16:45, 2 July 2018 (UTC)

Okay, it's not happening with Chrome. And things look somewhat different here too.— Vchimpanzee • talk • contributions • 16:46, 2 July 2018 (UTC)

I couldn't get a clear answer for why I don't have the same problems at home with Edge that I do at that one library. I'm going to that library Thursday. One problem i did notice was that if I try to copy and paste and then move the cursor within the edit window at the same time, I get sent to the top of the edit window.— Vchimpanzee • talk • contributions • 16:43, 3 July 2018 (UTC)

I'm going to start a new section.— Vchimpanzee • talk • contributions • 18:28, 5 July 2018 (UTC)

Persistently demonstrating template rendering without using subst

This may be my poor memory and decent imagination, but I remember there used to be a way to persistently render a template in a way that will not change even when the template changes, which does not involve subst. The reason I am asking is that we are discussion changes in {{Single chart}} and substing it adds 85k to the talk page, as I did here, which is obviously not going to work. I vaguely remember a few years back there was a way to fixate templates without subst. --Muhandes (talk) 16:06, 29 June 2018 (UTC)

This is not possible. Your options include: Link a version in the page history, make a screenshot, copy a version of the template to another page and transclude that, use subst (which usually only substitutes the outermost template call), use Special:ExpandTemplates (which substitutes everything recursively) and copy the resulting code. PrimeHunter (talk) 16:28, 29 June 2018 (UTC)

Oh well, thanks. --Muhandes (talk) 16:32, 29 June 2018 (UTC)

Templates with misnested tags

• Template:Fooian European Commissioners is causing lint errors: Misnested tag with different rendering in HTML5 and HTML4. See the discussion at Template talk:Fooian European Commissioners#Misnested tags.
• Template:Members of the European Parliament for Foo is causing lint errors: Misnested tag with different rendering in HTML5 and HTML4. See the discussion at Template talk:Members of the European Parliament for Foo#Misnested tags.

The two templates probably have the same issue. —Anomalocaris (talk) 23:07, 29 June 2018 (UTC)

Oh, comeon Anomalocaris, these were easy ones that you should have been able to fix with experience from many moons ago. ;) --Izno (talk) 01:43, 30 June 2018 (UTC)

Why are page movers told to fix double redirects when the bot can do it?

I always assumed this was because asking editors to fix technical issues themselves was quicker and less disruptive than waiting for the bots, but I just moved a page and deliberately didn't fix the double redirects (I was performing a page split, and all of the double redirects were better targeted at the new article I was creating) and EmausBot (talk · contribs) got to the redirects and "fixed" them before I could even pop out the placeholder stub, only taking three minutes.[1][2][3]

I had always assumed the bots were slower on these things (they seem to take days to migrate interwiki links to wikidata), and thought for a moment that my edit conflict was with someone undoing my page move. Obviously I'm not complaining about EmausBot doing its job effectively, but if it's that effective wouldn't changing Please clean up after your move: [...] Check what links here to see whether the move has created any double redirects, and fix the most serious ones. A bot will fix the rest later on. to, say, taking this out of the bulleted list and adding an extra note You may also wish to fix the double redirects [with a link to the list], but you do not have to as a bot will fix them shortly.

Hijiri 88 (聖やや) 02:13, 30 June 2018 (UTC)

The bots don't always get to them at all. DuncanHill (talk) 02:16, 30 June 2018 (UTC)

Well, would you agree that setting them to wait at least ten minutes would be a good idea, if we are telling page movers that they have to check the redirects and fix the "serious ones" and that the bots will fix them "later"? Hijiri 88 (聖やや) 02:19, 30 June 2018 (UTC)

Can someone explain what a "serious" double redirect is? Natureium (talk) 02:22, 30 June 2018 (UTC)

Presumably one that is linked to from a lot of articles, thus creating a whole bunch of broken wikilinks. I would have thought that if the bots get some double redirects and miss others, it would be the "serious" ones that they are most likely to get, and get the fastest, so they would be the ones that don't need to be manually fixed immediately. Hijiri 88 (聖やや) 02:25, 30 June 2018 (UTC)

From a bot perspective, e.g. how the bots are coded, an serious double redirect would be when the final redirect target is unclear. One of the most known examples of this would be the redirect loop, where Redirect A links to Redirect B, Redirect B links to Redirect C, which links back to Redirect A, thus creating a loop. The bots are capable of marking serious redirects for deletion, but whether the bot operator has configured it to do that, I do not know.--Snaevar (talk) 11:23, 30 June 2018 (UTC)

Another example would be self-loops, where a redirect redirects to itself (basically the same thing as an A->B->C->A loop except without the B and C involved. Side effect of WP:SWAP moves when the pages to be swapped are an article and its redirect, which is probably the most common type of SWAP-move. AddWittyNameHere (talk) 11:29, 1 July 2018 (UTC)

(edit conflict) Snaevar I don't think those are double (as opposed to triple, quadruple, etc.) redirects, though, and they can't be created by an individual page move. In fact I don't think the "loop" scenario can result from page moves at all, unless someone actively created a double redirect at some point and then the article was moved to a title that none of them redirected to, which seems like a somewhat unlikely scenario, and writing instructions that only need to be followed in very specific, rare circumstances doesn't seem like a good idea. Hijiri 88 (聖やや) 11:31, 1 July 2018 (UTC)

Redirect loops can result from page moves, examine the recent history of Template talk:Random quotation. I'm unable to work out what the motivation of Wpgbrown (talk · contribs) was for that strange sequence. --Redrose64 🌹 (talk) 18:03, 1 July 2018 (UTC)

Oh, and bots don't always get it right either. --Redrose64 🌹 (talk) 18:05, 1 July 2018 (UTC)

Redrose64 (talk · contribs) I was trying to fix a problem with the template in that it did not keep the same random number, I had thought that moving the page to a subpage and then calling it with a random number would work, alas, this did not work. I then moved it back to the original place.

I had thought that the change would be permanent and to keep edit histories properly in place, I moved the page (however, I now realise without ensuring that my idea would work). I reverted my mistakes and used the |same=yes parameter instead to achive my goal. I usually test using the sandbox, but this has just reaffirmed the need for testing first. Dreamy Jazz ^{talk | contribs} 18:12, 1 July 2018 (UTC)

This bot has actually been failing (or running so slowly that it amounts to a failure). E.g., Wikipedia:Manual of Style/Biographies was RMed to Wikipedia:Manual of Style/Biography last week, and days later all the shortcuts and other redirs had not updated, so I had to do them all manually. Similarly, it used to be that if I moved a page (I'm a page-mover, and do a lot of that, including round-robins), it was often the case that the bot would fix double redirs before I even got around to it, and that was handy. Now, I have to do them all by hand.  — SMcCandlish ☏ ¢ 😼  01:02, 5 July 2018 (UTC)

Deleted page message not displaying in British English

Recently I've noticed that the successful page deletion message (MediaWiki:Deletedtext/enGB since I use British English) doesn't display when I delete a page, and just gives me a single one-line message instead. The page hasn't changed - it simple transcludes the default language message. If I change my language settings to the default (American) English, it displays correctly. Can anyone explain/fix this? Optimist on the run (talk) 14:10, 30 June 2018 (UTC)

Yes, this goes for many of these locally customized messages. You fix it by not using british or canadian english. —TheDJ (talk • contribs) 14:21, 30 June 2018 (UTC)

MediaWiki:Deletedtext/enGB isn't used. The correct name is MediaWiki:Deletedtext/en-gb which hasn't been customized. There are hundreds of interface languages and hundreds of customized messages, giving a huge number of combinations. A few messages have been customized for en-gb but there are no plans to systematically customize messages for users who change away from the default language "en - English". PrimeHunter (talk) 15:21, 30 June 2018 (UTC)

Part of the constant debate about fall backs too (e.g. phab:T55789. IMHO, if en-gb is null, we should fall back to en, not to mediawiki default. — xaosflux ^Talk 17:24, 30 June 2018 (UTC)

Thanks - I've created MediaWiki:Deletedtext/en-gb and it seems to work. This doesn't explain why it worked until recently though. Strange... Optimist on the run (talk) 18:19, 30 June 2018 (UTC)

The value of the parameters $1 and $2 are not passed from MediaWiki:Deletedtext/en-gb to MediaWiki:Deletedtext, and it's not possible to pass them without recoding MediaWiki:Deletedtext to receive and use them. As far as I know there is nothing which can be saved in MediaWiki:Deletedtext/en-gb to make it always behave like MediaWiki:Deletedtext, and it's the same with all customized messages with parameters. See Wikipedia:Village pump (technical)/Archive 158#Odd looking block message for my attempts. I advice all users against selecting en-gb or en-ca as interface language, and especially admins. They should generally see the same interface as the users they interact with (at least the users who haven't changed language). Here is a possibly complete summary of differences between en and en-gb in 2014: uncategorized/uncategorised, "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/Licence. There may be a couple more today but for a few British spellings and different quotation marks, you lose hundreds of customized messages, often with links to relevant tools, help pages, processes, guidelines and policies at the English Wikipedia. en-gb is basically a trap we lead unsuspecting users into. We only give them a vague message with MediaWiki:Preferences-summary/en-gb displayed at top of preferences. It causes a lot of wasted time for users who don't see our customized messages, and for other users who have confused discussions with them. But some British users object whenever it's suggested we should advice against selecting en-gb as interface language. They may say we should change the software instead but that's easier said than done, and instead we keep a poor system indefinitely. PrimeHunter (talk) 21:09, 30 June 2018 (UTC)

I've nominated MediaWiki:Deletedtext/enGB for deletion at MfD, though I can't add the deletion notice to the page. Jc86035 (talk) 21:18, 30 June 2018 (UTC)

@PrimeHunter: - you're right, my attempt didn't work (I'd forgotten to change my preferences back to en-gb before testing) so I've deleted it. I've left my preference for en for the time being, though this still doesn't explain why it'd worked for me in the past. Optimist on the run (talk) 21:43, 30 June 2018 (UTC)

Adding a navbox to a category adds a random selection of articles to which the navbox links to the category?

This has me stumped. I did a bit of work on Template:Japanese princesses yesterday, which apparently brought its attention to someone who added it to a navbox category. This seems reasonable enough, but when I clicked on the category itself and noticed that a bunch of the princesses in question were mysteriously listed in the category now. None of the subcategories seem to have this problem, and I can't for the life of me figure out what happened; I considered just reverting the change as doing more harm than good, pending someone figuring it out, but I figured asking here would be better. Hijiri 88 (聖やや) 00:51, 1 July 2018 (UTC)

Categories should go into a "noinclude" section of the template. See the source at Template:Hiroshige. StarryGrandma (talk) 01:49, 1 July 2018 (UTC)

Thank you User:StarryGrandma for the advice, which (I think?) I botched on implementation, and thank you User:PrimeHunter for (I think?) fixing my botching. I still don't quite understand why including a navbox in a category without noinclude will automatically add several (but not apparently all?) of the linked articles in the navbox, and so don't know why my edit didn't initially work or whether PH's amendment was what finally fixed it, but I guess it's done now. :-) Hijiri 88 (聖やや) 11:20, 1 July 2018 (UTC)

All pages transcluding the navbox would be added to the category but the job queue may not have updated all link tables when you examined it. Your edit [4] fixed the category issue. My removal of a newline [5] didn't affect categorisation but just prevented some articles from displaying whitespace after the navbox. A noinclude part should nearly always start at the end of the last line and not on a new line. PrimeHunter (talk) 13:56, 1 July 2018 (UTC)

Possible double edits?

Sometimes, when I push the public changes button, to implement an edit, I get an 'edit conflict' notice. GoodDay (talk) 18:01, 1 July 2018 (UTC)

It happens sometimes when I accidentally push the button the second time (a short time after the first push) before the page reloads. Ruslik_Zero 20:44, 1 July 2018 (UTC)

I haven't been doing that, though. GoodDay (talk) 22:32, 1 July 2018 (UTC)

@GoodDay: Edit conflicts occur when two people are editing a page a the same time. (See Help:Edit conflict.) —Eli355 (talk) 19:44, 4 July 2018 (UTC)

That wasn't it. But, I think I found the problem. It's in my mouse. I'm editing against myself. It's a glitch. GoodDay (talk) 20:19, 4 July 2018 (UTC)

@GoodDay: Your mouse is probably suffering from switch bounce. I have one that started doing this a couple of months ago, so I found that I was double-clicking when not intending to. Mice can be repaired, temporarily - but the bounce will return after a period, and it's much easier to just buy another. The one that I'm using at the moment cost GBP 1.00 --Redrose64 🌹 (talk) 09:15, 5 July 2018 (UTC)

Category:Infobox importer templates

I created this category for importers (or is it better call them converters?) of infoboxes. Are there only that little such importers? If not, how can I find and add others? Wikisaurus (talk) 19:34, 1 July 2018 (UTC)

I have added six results from a search of "translated" in infobox documentation.[6]. PrimeHunter (talk) 21:28, 1 July 2018 (UTC)

Firefox snafu

Just updated to Firefox 61.0 32-bit, still with Windows 10, Modern skin. Tab viewing. Firefox did some funky stuff when it updated, and reset some of my non-Wikipedia settings. But everything otherwise looked normal on Wikipedia. Now my edit window is missing the toolbar, and looks like I'm typing on a plain sheet of paper, instead of the different colored diffs that are usually there. Access to my user space pages in Firefox is gone. I can click my main User page and User talk, but there is no tab to let me access my user space pages. Preferences, instead of being tabbed, is one long straight page. In Chrome, I see that my common.js script is still intact. But I can't access any of my user space pages on Firefox. What happened? — Maile (talk) 21:14, 1 July 2018 (UTC)

My admin tools are all gone, also on Firefox, but remain intact on Chrome. — Maile (talk) 21:24, 1 July 2018 (UTC)

I'll be darned. It was the latest version of NoScript, which listed Wikipedia.org as an untrusted site. Problem solved. — Maile (talk) 21:30, 1 July 2018 (UTC)

That'll teach you not to trust anything on Wikipedia. --Redrose64 🌹 (talk) 21:50, 1 July 2018 (UTC)

thumbnail image is getting sporadically cropped

When I open the article atan2 in the wikipedia beta android app, the image at the top (i.e. File:Atan2definition.svg) is cropped a bit, halfway through the letter "x" on the right. Also, someone told me they saw the exact same crop problem in a browser, albeit sporadically (depending on zoom level, whether they were viewing the main article or a history comparison, etc.). I can't reproduce it in a browser, but anyway that hints to me that it's something about the picture or article, not just a specific bug in the android app.

Before I file a bug report, am I doing something stupid? (Current version is [7], image is invoked as [[File:Atan2definition.svg|thumb|(caption text)]]). Thank you very much in advance!! --Steve (talk) 00:23, 2 July 2018 (UTC)

I wouldn't say the image is cropped. It just doesn't have room for all the text in some cases. SVG images can store text as characters instead of images. SVG software then displays the text as part of an image. Our software converts SVG to PNG images. The conversion is done independently for each size and the result can vary. The spacing (kerning) in the text varies in your example so some sizes cannot fit the whole text within the margin. Try to make a version where the text isn't so close to the margin. PrimeHunter (talk) 00:59, 2 July 2018 (UTC)

How I see the current version
100px, ends in middle x 150px, large margin 200px, ends after x 250px, small margin 300px, ends in right part of x

The description in the captions is what I see at 100% zoom in Firefox. srcset is actually used to give the browser a choice between PNG versions at different sizes. If you zoom then you may see another version with another spacing and resulting cutoff. For example, the html for |100 px says: <img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/100px-Atan2definition.svg.png" width="100" height="86" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/150px-Atan2definition.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/200px-Atan2definition.svg.png 2x" data-file-width="815" data-file-height="698" />. So for |100 px you may see a MediaWiki-generated PNG image with size 100px, 150px or 200px, scaled to some other size by your own browser. PrimeHunter (talk) 01:32, 2 July 2018 (UTC)

PrimeHunter, thank you for helping me understand! I also see that I was using a generic font that "may cause alignment and positioning issues". --Steve (talk) 03:02, 3 July 2018 (UTC)

PNG transparency issues with new images

Tracked in Phabricator
Task T198370

I've uploaded two images this week to update images into articles; the first was a logo on WKAQ-TV for the 'NBC Puerto Rico' subchannel (File:WKAQ-DT3 Logo.png), the second a new logo for WLPR-FM (File:WLPR-FM Logo.png). In my browser (Chrome 68), the article page doesn't show either image within their infoboxes as transparent (white background instead), though it's fine on the actual image page and showing transparent there (I have reproduced the same result in Edge, Firefox and Safari iOS with white backgrounds on article pages, transparent on image pages). Am I doing something wrong, is this local to my systems or reproducible outside it, or is there a bug that needs to be traced down? I've used Paint.NET for years to create PNGs and never had any issues with it until now, so any insight is appreciated. Nate • (chatter) 07:18, 2 July 2018 (UTC)

Something is wrong with image resizing on Wikipedia. https://upload.wikimedia.org/wikipedia/en/4/44/WKAQ-DT3_Logo.png is transparent but https://upload.wikimedia.org/wikipedia/en/thumb/4/44/WKAQ-DT3_Logo.png/120px-WKAQ-DT3_Logo.png isn't. See T198370, where it has also been reported on Commons, but no developers have responded yet. --Ahecht (TALK
PAGE) 21:20, 2 July 2018 (UTC)

Glad to see there's a report on it and others are having issues on other wikis; hopefully this helped with this bug report. Thanks! Nate • (chatter) 08:37, 3 July 2018 (UTC)

Problems with the DS template documentation

Resolved

I noticed that the documentation for several templates related to discretionary sanctions, such as Template:Ds/talk notice and Template:Ds/alert, shows the wrong code for the templates (such as "subst:alert" instead of "subst:Ds/alert" or "subst:Ds" instead of "Ds/talk notice"). I cannot figure out how the code for the documentation works though. Can someone with more skills take a look? Regards SoWhy 09:32, 2 July 2018 (UTC)

{{Alert}} redirects to {{Ds/alert}}. The redirect works and is easier to write so I see no need to change the documentation. I think Template:Ds/talk notice and other subpages of Template:Ds are fixed by [8]. Say if you see problems. PrimeHunter (talk) 11:10, 2 July 2018 (UTC)

@PrimeHunter: Your edit fixed part of the problem. However, {{Ds/talk notice}} and {{Ds/editnotice}} should not be substed but their documentation still says {{subst:Ds/talk notice}} / {{subst:Ds/editnotice}}. Could you fix this as well? Regards SoWhy 10:04, 3 July 2018 (UTC)

Fixed by [9]. PrimeHunter (talk) 10:55, 3 July 2018 (UTC)

Thanks PrimeHunter! Regards SoWhy 15:18, 3 July 2018 (UTC)

Tidy to RemexHtml

The Parsing team will be replacing Tidy with RemexHtml at this wiki on 5 July 2018.

Some pages at this wiki use outdated HTML. This change may change the appearance of those pages. Special:LintErrors has a complete list of affected pages.

Read this e-mail message for more information. Read the instructions at mw:Help:Extension:Linter. You can ask questions at mw:Talk:Parsing/Replacing Tidy. Thank you for helping fix these problems.

m:User:Elitre (WMF) 14:38, 2 July 2018 (UTC)

FYI, i'm not available too much, but after the remex introduction, someone needs to remove the .mw-parsermigration-right part from a style line in MediaWiki:Common.css dealing with {{tree list}}. —TheDJ (talk • contribs) 09:41, 5 July 2018 (UTC)

I recommend keeping the parser migration extension and preview functional for a month or so in case it helps editors fixing pages to see how it looked it before the switch. SSastry (WMF) (talk) 13:54, 5 July 2018 (UTC)

PS I also expect quite a few people coming in with broken user pages or stuff like that, as these were mostly skipped (in favor of fixing articles) when people were doing the cleanup. —TheDJ (talk • contribs) 09:46, 5 July 2018 (UTC)

I expect the same. --Izno (talk) 13:10, 5 July 2018 (UTC)

The switch has been deployed about 30 mins back. FYI. SSastry (WMF) (talk) 13:53, 5 July 2018 (UTC)

Proposal to make discretionary sanctions actually work, by auto-delivering the required DS "awareness" notices

FYI

 – Pointer to relevant discussion elsewhere.

Please see: WP:Bot requests#Bot to deliver Template:Ds/alert
 — SMcCandlish ☏ ¢ 😼  18:03, 2 July 2018 (UTC)

Error in template code

The template {{Mamrot}} has an error caused either by the absence of {{Type}} or some other problem. I'm not sure how to fix this.--Auric talk 19:37, 2 July 2018 (UTC)

Try it now Auric.--John Cline (talk) 20:26, 2 July 2018 (UTC)

Thanks. I was hoping it might be something like that.--Auric talk 20:29, 2 July 2018 (UTC)

Tech News: 2018-27

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

Recent changes

• The database for tags will be changed. This will happen on 2 July on French Wikipedia and 9 July on all other wikis. Please report if recent changes get slower or you can't save edits. This could especially affect editors who use the database on ToolForge. [10]

Problems

• Last week's MediaWiki update was rolled back. This was because of a database problem. [11]

Changes later this week

• There is no new MediaWiki version this week.

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 3 July at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 4 July at 15:00 (UTC). See how to join.

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

00:46, 3 July 2018 (UTC)

A |link parameter has been added to Template:Tag

(Section heading changed to remove template calls, see the comment in the wikitext. --Pipetricker (talk) 14:33, 4 July 2018 (UTC))

It seemed weird and annoying that after all this time, the {{tag}} template (for HTML tags) did not support a means to link to the meaning of the element in question, the way {{xtag}} does for MediaWiki elements (e.g. {{xtag|ref}} → <ref>) so I fixed it.

Example:

     {{tag|del|link=yes}} (or |link=y or whatever)

now produces:

     <del>...</del>

 — SMcCandlish ☏ ¢ 😼  19:26, 3 July 2018 (UTC)

Pinging over 50

If you attempt to {{ping}} more than 50 users in one post, you receive a system-generated message reading: "You tried to mention more than 50 users. All mentions above that limit were not sent." This implies that the first 50 were sent. However, this does not appear to have happened here—although information is incomplete, all indications are that none were sent. Thus the system-generated message is highly misleading, and in this case resulted in a potentially harmful 3-day delay in notification of previous participants.

The software needs to be changed to send the pings up to the limit as per the message, or to correct the message. My preference is the former. Equally important, the limit should be increased to something that accommodates reasonable legitimate usage, such as 100.

Can someone see if there are existing phab ticket(s) for both issues, or create same?

Finally, the doc for ping (Template:Reply to) is unclear as to whether the limit applies to a single use of the template or to the entire post. I thought it was the former, so I split the 56 users into two templates. Since I received the system-generated message, it appears it's the latter. That needs to be clarified, but that's something we can handle ourselves; I mention it only as a related issue in case anyone has comments. ―Mandruss ☎ 22:25, 3 July 2018 (UTC)

50 is a MediaWiki limit for the whole edit no matter how the users are mentioned. It's controlled by $wgEchoMaxMentionsCount which is 50 for Wikimedia wikis. phab:T144614 ("Inform Flow users when they hit the flow mention limit") lead to gerrit:350887 where MediaWiki:Notification-header-mention-failure-too-many was changed. Before it said: "{{GENDER:$2|Your}} mentions were not sent because they exceeded the limit of $3." Now it says: "{{{GENDER:$2|You}} tried to mention more than $3 {{PLURAL:$3|user|users}}. All mentions above that limit were not sent." According to phab:T144614 the change was made because Flow (an alternative discussion software) does send the mentions below the limit. But it appears the same message is used without Flow where the mentions are not sent, leading to confusion. Flow has been uninstalled at the English Wikipedia so we could create a customized MediaWiki:Notification-header-mention-failure-too-many which ignores Flow and copies the original message. Flow might return at some time and other wikis are affected so somebody should probably file a Phabricator ticket about the issue.

I oppose raising the limit to 100 or sending the first 50 mentions. Users sometimes make huge accidental mentions by transcluding or archiving a page with many linked users, e.g. from old signatures. Mentions are only sent for signed edits but such edits are sometimes signed. The limit helps against meaningless mass mentions. There is rarely a good reason to ping more than 50. Make multiple edits in those cases. PrimeHunter (talk) 23:22, 3 July 2018 (UTC)

Oppose, that is too many mentions. @Mandruss: what are the important use cases you are thinking about? — xaosflux ^Talk 23:31, 3 July 2018 (UTC)

Well the one I linked above, for one. But fine, I'll be happy if (1) the message is corrected to reflect what actually happened, so editors know what action to take when they see it, and (2) the doc is made crystal clear that the limit applies to the entire post (it is not even close to that now). ―Mandruss ☎ 23:41, 3 July 2018 (UTC)

Please note mentions have been known to be unreliable, and some editors opt out. If you really have an "important" message to get to many editors a MassMessage may be the better route as its delivery can be better confirmed. — xaosflux ^Talk 00:00, 4 July 2018 (UTC)

Requires a special user right, apparently, and more work than simple pings. According to Wikipedia:Mass message senders, there are 53 non-admin users who have the right. Clearly pings have a lot more community acceptance/uptake than mass messages, and anybody who opts out is choosing to be left out of mass notifications like the one I linked. ―Mandruss ☎ 01:14, 4 July 2018 (UTC)

Template:Reply to/doc does currently say "Warning: If the total number of detected to-be-pinged users in an edit exceeds 50, no notifications will be delivered." I will add a sentence to clarify that "in an edit" means even spread among multiple templates. --Ahecht (TALK
PAGE) 00:01, 4 July 2018 (UTC)

My mistake. Comment corrected by strikethrough. ―Mandruss ☎ 03:22, 4 July 2018 (UTC)

Pinging Sbisson (WMF) who worked on phab:T144614. PrimeHunter (talk) 10:39, 4 July 2018 (UTC)

Unable to delete an article

I closed Wikipedia:Articles for deletion/List of superhuman features and abilities in fiction as delete - however, I am unable to delete the target page List of superhuman features and abilities in fiction as it has too many revisions. I've redirected it as a protected redirect to Superhuman for the time being - but what should be done? I've never come across this issue before. Black Kite (talk) 22:58, 3 July 2018 (UTC)

@Black Kite: if it really needs deleting, you have to ask a steward to do it for you. I think the redirection is sufficient though. — xaosflux ^Talk 23:01, 3 July 2018 (UTC)

According to the error page, you should ask the stewards. עוד מישהו Od Mishehu 23:03, 3 July 2018 (UTC)

Apparently communities can request this access be assigned, (ckbwiki has it on adminbots for example), but enwiki is a bit riskier since we have some pages with huge histories that a bigdelete could cause problems for. This one "only" has 8,230 revisions though so it should go ok if a steward does it. — xaosflux ^Talk 23:05, 3 July 2018 (UTC)

OK, thanks. I'm about to turn in for the night now but I'll get onto it tomorrow. Black Kite (talk) 23:13, 3 July 2018 (UTC)

I deleted it after four unsuccessful attempts (write duration exceeding limit). Ruslik_Zero 20:12, 4 July 2018 (UTC)

Spanish Wikipedia not functioning

Does anyone know why whenever I go to Spanish Wikipedia, I get a message stating "Defendamos una Red abierta", and it will not allow me to access that Wikipedia? Please {{ping}} me when you respond. --Jax 0677 (talk) 08:13, 4 July 2018 (UTC)

Jax 0677 It is a protest banner against a recent EU copyright law proposal, there is some discussion on Wikipedia:Village pump (proposals) about it. Jo-Jo Eumerus (talk, contributions) 08:22, 4 July 2018 (UTC)

@Jax 0677: if you disable javascript you will be able to read eswiki still. — xaosflux ^Talk 18:25, 4 July 2018 (UTC)

And/or add ?safemode=1 to your requests (e.g. https://es.wikipedia.org/wiki/Wikipedia:Portada?safemode=1) — xaosflux ^Talk 18:32, 4 July 2018 (UTC)

What just got implemented?

Okay, the membership box at Wikipedia:WikiProject Women in Red just got wonky, with no edits anywhere. And one of the members reports she has lost rollback, and her new articles are being patrolled (I think she has auto reviewed rights normally). So is there something new we should know about? NotARabbit (talk)18:04, 4 July 2018 (UTC)

@NotARabbit: thats a lot going on, lets break it down:

1. Wikipedia:WikiProject_Women_in_Red/Members is this the list you are referring to, it looks OK to me? — xaosflux ^Talk 18:20, 4 July 2018 (UTC)
2. Who "lost rollback", need a username to check on that. — xaosflux ^Talk 18:20, 4 July 2018 (UTC)
3. There is/was a bug in autopatrol, see Wikipedia:Village_pump_(technical)#Issue_with_auto-patrol? above. — xaosflux ^Talk 18:20, 4 July 2018 (UTC)

It looks like {{WPX member box}} is broken on multiple pages where it is used: Wikipedia:WikiProject Hampshire County, West Virginia, Wikipedia:WikiProject Women's Health, Wikipedia:WikiProject Women in Technology, Wikipedia:WikiProject Cannabis, and more. I'm guessing this is some sort of Linter error that is now live. – Jonesey95 (talk) 18:22, 4 July 2018 (UTC)

Doubtful. Remex is tomorrow, and even if it weren't, the template in question looks well-formed. NAR's reported issues are certainly unrelated to each other. The template looks fine on its own page, so I would guess there's something wrong with the participants lists. The autopatrolled issue is probably the one Xaos linked. As for rollback, that's likely Javascript not loading fully for the user (or the user having some legacy Javascript lying around). --Izno (talk) 18:38, 4 July 2018 (UTC)

No, the template does not look fine on its own page. There are definite cosmetic issues, though I’d be hard put to describe exactly what. I’ve asked some of the other editors to come here. NotARabbit (talk) 18:41, 4 July 2018 (UTC)

Also pinging @Harej: as the creator of the templates. NotARabbit (talk) 18:46, 4 July 2018 (UTC)

I lost the ability to rollback. [12] and my new articles are still being patrolled (most recent notification was 5 hours ago). I don't have the technical know how to explain the membership sign up issues. Thank you NotARabbit for trying to help. As a non-tech-oriented editor, trying to explain what happens typically is out of my league. SusunW (talk) 18:51, 4 July 2018 (UTC)

I fixed {{WikiProjectCard}}, which has fixed the formatting of the member box. Someone added an extra closing /div tag, which broke transclusions. – Jonesey95 (talk) 19:10, 4 July 2018 (UTC)

Jonesey95, thank you so much! NotARabbit (talk) 23:01, 4 July 2018 (UTC)

Grasping at straws here, but maybe one of the scripts you import from User:SusunW/common.js / User:SusunW/monobook.js / User:SusunW/vector.js is breaking? (Which skin do you use: monobook, vector, or something else?) Do you see the rollback links and nothing happens when you click on them, or do they not appear at all? Any improvement in safemode, e.g. https://en.wikipedia.org/w/index.php?title=User:SusunW/sandbox&action=history&safemode=1 ? —Cryptic 19:15, 4 July 2018 (UTC)

Cryptic sorry, I do not understand any of those questions about skin, importing scripts, or breakage, nor have any idea how to answer them. I do not see an option to rollback at all, only undo. I don't know what safemode is. SusunW (talk) 19:18, 4 July 2018 (UTC)

You can activate safemode (for one pageview only) by clicking on the link to your sandbox that I made above (and here); that'll temporarily disable the custom javascript you've installed in those three .js pages. You can see which skin you're using at Special:Preferences#mw-prefsection-rendering; that'll tell us whether User:SusunW/monobook.js, User:SusunW/vector.js, or neither is active. —Cryptic 19:26, 4 July 2018 (UTC)

Cryptic I am really sorry, I have no idea what I am supposed to look for when I go to my sandbox, that preference page or those pages that end in .js, or even what to do, once I go to those pages. The very reason I don't post on pages such as this, trying to communicate is overwhelming to me on technical problems. I am a writer and a researcher, I have zero and I do mean zero skill with technology other than type, preview, save. I truly do not understand what it is that I am supposed to be looking for, nor what it is supposed to be telling me. Under skin on the preference page a "*" appears before Vector (default | Preview | Custom CSS | Custom JavaScript) does that mean something? It should be quite clear that I did not install anything, nor make changes to it, as I honestly would have no idea how to do that. If we must work together to solve this, you are going to need to explain items in great detail and step by step—go here, find X, press Y, etc. SusunW (talk) 19:49, 4 July 2018 (UTC)

@SusunW: step one, go to this page: Special:Preferences#mw-prefsection-rendering. Let us know which item in "Skin" has the dot filled in. — xaosflux ^Talk 20:05, 4 July 2018 (UTC)

Xaosflux I think it must be Vector as I noted above? SusunW (talk) 20:08, 4 July 2018 (UTC)

@SusunW: OK, I tried to load your scripts and couldn't break rollback on my test account. Next, try to go to this page: https://en.wikipedia.org/w/index.php?title=User:Xaosflux/Sandbox2&action=history on the first line of the history does it end with (test) (rollback: 9 edits | undo) or something else? — xaosflux ^Talk 20:20, 4 July 2018 (UTC)

Special:Diff/848854254 suggests your rollback access is working, can you explain in more detail what you used to see, and how it is different now? — xaosflux ^Talk 20:26, 4 July 2018 (UTC)

Xaosflux I could rollback on your sandbox, but on Vera Gedroits the article where all this started from, I only have an option to undo. You will see I manually had to undo a whole bunch of changes because there was no way to rollback the lot of them. I now have a work around, Opening the last clean version and saving, but why I cannot just rollback the lot of them is not understandable to me. Usually I have an option to rollback or undo, on Gedroits, only undo appears. SusunW (talk) 20:28, 4 July 2018 (UTC)

@SusunW: the rollback link will only work if the "right side" version is the latest version. If you are comparing any other versions rollback is not an option. Can you go to the page you think rollback should work on, then copy the entire url from your address bar to here so we can see exactly what you are looking at? — xaosflux ^Talk 20:31, 4 July 2018 (UTC)

xaosflux I do not understand what you mean by right side version. I am not comparing any version, I am looking at the revision history, not the article. I linked above to the revision history so that you could see that there is no option to rollback. Or at least there isn't for me. What do you mean by the entire url? That isn't what I gave you above? SusunW (talk) 20:37, 4 July 2018 (UTC)

Here is what xaosflux sees. — xaosflux ^Talk 20:43, 4 July 2018 (UTC)

@SusunW: I posted a screen capture of what I see, at the end of Kencf0618's line what do you see? — xaosflux ^Talk 20:43, 4 July 2018 (UTC)

On that one line I see rollback on the 20 or so edits that appeared on 29 June, there was no option to rollback anything. I manually had to undo each one. I finally got frustrated trying to figure out which ones I had undone and which ones I hadn't and pulled up the last clean version and just manually corrected all the introduced errors by manually comparing the two versions. It took over an hour to fix what should have been the press of a button. I have now spent more than an hour trying to explain the problem to you, which I find very, very stressful. Our service is to provide articles for users to read. The technology piece should not be something that readers or writers struggle with. I am truly sorry that I cannot explain why this is important or why whatever happened should be evaluated. What caused it, if it will happen again, if it is fixed I do not know. What I do know is that I will not finish my article today. What I know is that I do not have the skill to explain it better than I have and I apologize for wasting your time, as you could have helped so many other people. SusunW (talk) 20:56, 4 July 2018 (UTC)

@SusunW: manually undo each edit? You could have simply reverted to a version without the issues. E.g. go to this version [13], click "edit this page" and then save it with whatever edit summary is appropriate. The reason you could not rollback is that SunnyBoi edited after the IP, and you can only rollback the most recent editor. Headbomb {t · c · p · b} 21:00, 4 July 2018 (UTC)

Headbomb I know that now, but I did not know that then, so I went one at a time undoing each edit. Until Gerda told me to just open the last clean version and save it, it never occurred to me to do that. By that time, I had already manually undone them all retyping what was originally there. SusunW (talk) 21:06, 4 July 2018 (UTC)

Headbomb, however, thank you for identifying the problem. A slew of editors introduced errors to a GA. Rather than being able to quickly fix the problem rolling back all the errors introduced, the programming was such that only one user (the most recent) could be easily rectified. This seems to me to be a disconnect, there ought to be a way to eliminate multiple blocks of erroneous text. But it doesn't matter. I have a work around. Again, I am sorry for taking up so much time. I thank you all for your efforts to try to help. SusunW (talk) 21:22, 4 July 2018 (UTC)

If a series of the most recent edits are in error and you want to revert them to a previous version, go to the article history, click the left radio button next to the good version you want to go back to, click the right radio button next to the most recent version, then click "Compare selected revisions". Once you get the comparison screen, click the "undo" link next to the time stamp for the latest revision. Add an edit summary and save. – Jonesey95 (talk) 22:11, 4 July 2018 (UTC)

Viewing, editing and saving an old version in the page history is only three clicks. You have to know about it (or know another method) but I would oppose one-click rollback links at all versions to revert to them without giving an edit summary. There would be many misuses and accidental clicks. PrimeHunter (talk) 23:06, 4 July 2018 (UTC)

One difference between editing an old version and clicking "undo" on a diff is that the editors who made the edits you are undoing will be notified only in the latter case. One may view this notification as desirable or undesirable, depending on the circumstances. – Jonesey95 (talk) 23:25, 4 July 2018 (UTC)

WP:TWINKLE facilitates this to an extent. It works in the diff view, not on in the edit history (see [14]). Only admins have access to that functionality, for some reason. Presumably concerns about edit wars and the like. Headbomb {t · c · p · b} 23:28, 4 July 2018 (UTC)

At a point in the article, templates stop transcluding

There's an issue with Australia women's national field hockey team results (2010–19), which I don't know how to resolve.

In the 2018 "Tri-Nations Hockey Tournament" section, the first four calls of {{footballbox collapsible}} are behaving correctly — but for some reason, the final one instead turns into a text link to the template instead of a transclusion of the template, and then this problem carries through the entire rest of the page, so that even {{reflist}} links out instead of displaying any of the footnotes. And in addition, the page was uncategorized — but even the {{Uncategorized}} template was also linking out instead of displaying the maintenance template, thus forcing me to add the first semi-appropriate category I could think of to actually make it drop from the uncategorized pages list even though I don't really know what the most correct category for this page would really be.

I've looked thoroughly at the page, however, and cannot find any obvious indication of a coding error, such as a misplaced nowiki tag, that would cause this to happen.

Could somebody take a look at the page and figure out how to fix this? Thanks. Bearcat (talk) 22:49, 4 July 2018 (UTC)

Hidden category: Pages where template include size is exceeded. --Pipetricker (talk) 23:05, 4 July 2018 (UTC)

Users often ask about this. Previewing the whole page shows a red warning: MediaWiki:Post-expand-template-inclusion-warning. It is currently the MediaWiki default. I suggest we make a customized version where "Template include size is too large" is a piped link to Wikipedia:Template limits#Post-expand include size. PrimeHunter (talk) 00:26, 5 July 2018 (UTC)

@Bearcat:  Fixed I split the page into Australia women's national field hockey team results (2010–14) and Australia women's national field hockey team results (2015–19), which has resolved the issue. As PrimeHunter said, the page hit the limit of how much code it can include from templates. --Ahecht (TALK
PAGE) 14:32, 5 July 2018 (UTC)

Much thanks. I didn't even know that there was a limit, so I guess now I'll know if I ever see a situation like this again. Bearcat (talk) 14:51, 5 July 2018 (UTC)

• Support suggestion to link "Template include size is too large" to Wikipedia:Template limits#Post-expand include size. --Pipetricker (talk) 15:53, 5 July 2018 (UTC)

Do we have a pretty link template for OpenStreetMap wiki like we do for Wiktionary?

I posted this question first at Wikipedia:Help desk/Archives/2018 June 27#Template:OSMwiki?, and User:Vchimpanzee asked both for clarification and suggested I post here.

The Wiktionary template I mentioned is here: Template:Wiktionary. What it does is give some visual distinctiveness, attractiveness, and separateness to a link to an equivalent or strongly related Wiktionary article. A visitor will easily be able to see it, be more likely to expect it will be useful to them in that moment to click on it, and understand that the link is more related than usual to other links between Wikipedia/Wiktionary/wiki articles or the web generally. I think having the same thing between Wikipedia and OpenStreetMap wiki would be useful given that there are some articles of a geographical bent that cover the same ground on both wikis.

If this template already exists, I would like to learn about it so I can use it. If it does not exist, I will ask at Wikipedia:Requested_templates/Places_and_things (I am willing to learn how to craft templates and put the work in but I will need help, and if anyone here wants to assist, that would be great). Thanks!

Arlo James Barnes 23:57, 4 July 2018 (UTC)

Category:OpenStreetMap templates has some templates like {{OSM relation}} which can be used to make a normal line in an External links section. Templates displaying more prominent boxes like Template:Wiktionary are generally only used for Wikimedia sister projects. I don't know whether there are exceptions. PrimeHunter (talk) 00:43, 5 July 2018 (UTC)

Just to clarify, I was letting Arlo Barnes know the question wasn't answered and was suggesting another way to ask.— Vchimpanzee • talk • contributions • 14:57, 5 July 2018 (UTC)

@Vchimpanzee: Did not mean to misrepresent your role! But thanks again for pointing me here. @PrimeHunter: I did see the relation et al templates, thanks for letting me know about the wider category, however. The reason I see no problem with extending it beyond sister projects is that it is not an endorsement of a whole project, just a recommendation for a reader that they may find some additional or recontextualised information on (in this case) the linked OSMwiki page useful given that they are already reading about the topic. So it can even be evaluated on a case-by-case basis as needed to further the encyclopedic goal of WP. Also, OSM and Wikimedia do collaborate quite a bit already, given that both focus on community involvement (wiki-nature) and verifiability. Arlo James Barnes 18:45, 5 July 2018 (UTC)

Category:External link templates has a huge number of templates to make a normal external link with no box. If there are no existing websites outside Wikimedia wikis which have gained consensus for external link boxes then I think you would have to seek consensus at a central place, e.g. Wikipedia:Village pump (proposals). PrimeHunter (talk) 20:58, 5 July 2018 (UTC)

Query help

Resolved

I need a little help developing an SQL query on Quarry.

I need to get something like this: [15]

but also listing reviewers who have done zero reviews (i.e. containing the full list of reviewers listed in this query)

Any advice on this? — Insertcleverphrasehere ^{(or here)} 05:13, 5 July 2018 (UTC)

If I could also get the Query to output the date that the NPR user right ('patroller') was granted, as well as the date of the last patrol completed, that would be ideal. — Insertcleverphrasehere ^{(or here)} 05:43, 5 July 2018 (UTC)

quarry:query/28019, for the first two parts. It's... not elegant. And getting the date patroller was granted isn't going to be feasible by any method I can imagine: it's only stored in the enormous logging table, and which groups were added or removed are stored in its hard-to-parse log_params column. —Cryptic 06:55, 5 July 2018 (UTC)

@Cryptic: thanks very much. The other stuff was wishlist, so we can make due with this query, thanks. — Insertcleverphrasehere ^{(or here)} 07:07, 5 July 2018 (UTC)

References numbers

Numbered list for references when viewed desktop on a mobile device are partially hidden because of margin/padding settings malfunction. Only ones are visible completely, tens are half-visible, and hundreds etc. are below left content so are not visible (may be different for different devices but problem exists for sure). --Obsuser (talk) 05:42, 5 July 2018 (UTC)

@Obsuser: It'd help much to understand what you're experiencing if you can add screenshot and device/browser you're using. –Ammarpad (talk) 08:38, 5 July 2018 (UTC)

I'm on mobile so cannot cope with screenshots. It is obvious that reference number i.e. 137 should be displayed as such and not as 37 or 7 (this glitch happens especially for numbers in right column[s] when references are displayed in two or more cols). Browser is Samsung internet and device Galaxy J3 2016. Obsuser (talk) 09:38, 5 July 2018 (UTC)

Samsung Internet is probably the issue (it's garbage), and I think the only reasonable way to fix this issue is to change your browser. --Izno (talk) 12:07, 5 July 2018 (UTC)

Mystery user script

User:Dr Brains/ListPages.js: What does this do, and how does it work?

(I installed it, and I didn't notice anything different).    — The Transhumanist   18:29, 5 July 2018 (UTC)

That script appears to have been written for the French wikipedia, so it may not work here. --Ahecht (TALK
PAGE) 19:09, 5 July 2018 (UTC)

It's never a good idea to install scripts that you know nothing about. You never know what it might do - good or bad. --Redrose64 🌹 (talk) 19:19, 5 July 2018 (UTC)

The answer seems to be, as far as I can tell from reading the code, nothing other than producing a broken link on category pages due to the script being massively out of date. {{3x|p}}ery (talk) 02:30, 6 July 2018 (UTC)

Userpage artificially transcluded into inappropriate category

User:Derkommander0916 is being filed in Category:Templates for railway lines of Malaysia, by virtue of transcluding a Malaysian railway line template on the page. As always, userpages are not supposed to be categorized alongside content in mainspace categories, so this has to be removed — but I can't even find that category declaration in the template, but rather even there it seems to also be an artificial transclusion generated by yet another nested subtemplate I can't identify. Can somebody figure out where this category is coming from so that the userpage can be removed from it? Thanks. Bearcat (talk) 19:12, 5 July 2018 (UTC)

@Bearcat: It's the {{railway-routemap|MYS}} near the bottom. --Redrose64 🌹 (talk) 19:17, 5 July 2018 (UTC)

Okay, but I can't fix that — it seems to always autogenerate "Templates for railway lines of (Country)" for every country whose railway lines use a "railway-routemap"-calling template at all, so I can't remove it for Malaysia without completely blowing up the entire forest. Is there any other way to get the user page evicted? Bearcat (talk) 19:25, 5 July 2018 (UTC)

@Bearcat: I modified {{railway-routemap}} so that it only adds categories in mainspace. --Ahecht (TALK
PAGE) 19:29, 5 July 2018 (UTC)

It needs to be templatespace, not main, because the categories are meant to hold templates — you depopulated the categories in the process, exactly as I feared I'd be doing. Bearcat (talk) 19:31, 5 July 2018 (UTC)

This should do it. --Redrose64 🌹 (talk) 19:50, 5 July 2018 (UTC)

You could have used {{suppress categories}} on the user page. PrimeHunter (talk) 19:59, 5 July 2018 (UTC)

I've tried to do exactly that on four other similar userpages I've come across that are being transcluded into Category:Templates for railway lines of the United States by the {{US-railway-routemap}} template — User:Abramius/sandbox, User:Geoffrie/Template:NorthstarHiawathaCentral, User:Mliu92/sandbox/Template:Dumbarton Rail Corridor, User:Useddenim/CN Freeport and User:Aalox/sandbox1 — but either I'm misunderstanding the template documentation or it doesn't work in situations like this at all, because I'm doing exactly what I'm told but it's not suppressing the undesired category at all. Bearcat (talk) 20:12, 5 July 2018 (UTC)

You have no such edits to the linked pages so I cannot say what went wrong. The first example worked for me.[16] Did you wrap {{suppress categories}} around the template which adds a category? PrimeHunter (talk) 20:37, 5 July 2018 (UTC)

@Bearcat: Yup, my mistake. Thanks to RedRose64 for correcting it. --Ahecht (TALK
PAGE) 18:29, 6 July 2018 (UTC)

Kludginess in displaying pages and in the wikitext editor

Something weird is going on since the new parser was implemented, both when viewing pages and when editing in the wikitext editor. The window will often hang, and then the contents will shift a little (like it is being rejiggered on the backend or something) then settle, and then it does this again. This is extremely frustrating when it happens in the editing window. I use the most recent version of chrome on a mac desktop and use the default skin with no javascripts or anything. I tried it with the most recent version of Firefox and it replicated there. This is very frustrating. Jytdog (talk) 20:11, 5 July 2018 (UTC)

Probably unrelated to the new parser since the parser is not used for page views. There might be another change in the deployment today which is causing FOUC (or not-quite-styled content). (WP:ITSTHURSDAY) --Izno (talk) 20:29, 5 July 2018 (UTC)

Thanks for replying but I have been swearing at my computer over this for few days now. Jytdog (talk) 20:42, 5 July 2018 (UTC)

Jytdog, does it happen on every page, or every time on a particular page? If so, please change the URL to add safemode=1 to the end, like this: https://en.wikipedia.org/wiki/User:Whatamidoing_(WMF)/sandbox?safemode=1 and see if that improves anything. Whatamidoing (WMF) (talk) 02:16, 6 July 2018 (UTC)

Remex: My page is recently broken and I can't figure out why

A new parsing tool called Remex is now cleaning up the HTML output for a webpage. It may cause some pages to display in undesirable ways. Be patient while we work out the kinks, and feel free to report problems in a new subsection here:

Visible bullets in infobox

FYI

 – Pointer to discussion elsewhere

See Template talk:Infobox musical artist#Visible bullets at Limp Bizkit. --Redrose64 🌹 (talk) 20:58, 5 July 2018 (UTC)

Post-Tidy fix may be needed at Template:Infobox NFL team

This link currently shows me different rendering of the bullets under "Playoff appearances (10)" and "Home fields" in {{Infobox NFL team}}. The Tidy version on the left renders normally, with bullets inside the infobox and aligned with the bulleted lists above these bottom sections. The post-Tidy version, which is currently live, shows the bullets for these two sections sitting just outside the box that outlines the infobox. I don't see an obvious cause of this problem. – Jonesey95 (talk) 03:04, 6 July 2018 (UTC)

I hacked the {{Infobox NFL team/sandbox}} with div tags wrapping the problematic list items. Is that terrible? It seems to work. If I put /sandbox into the edit above and preview it, everything looks fine. I wonder if a similar fix would work for Infobox musical artist, or if there is a more general fix that is needed. It seems like it would be a challenge to do something like this to every infobox field that might have bullets in it.

And it doesn't explain why the "Team nicknames" section renders just fine. Is it because the header and data use different numbers in the broken sections? I don't know enough about how infoboxen work to know what effect that numbering has. – Jonesey95 (talk) 03:18, 6 July 2018 (UTC)

Jonesey95: See my response at Template_talk:Infobox_musical_artist#Visible_bullets_at_Limp_Bizkit. The same reasoning applies to this infobox. Presumably, fixing that module would fix this too. SSastry (WMF) (talk) 09:13, 6 July 2018 (UTC)

image widths that respond to page width

Is there a way to format a wide image that fits the image as a percentage of the page width or box width, so that it responds to screen width without overflowing or cropping the display?

Please ping with reply, Thanks, · · · Peter (Southwood) ^(talk): 08:00, 6 July 2018 (UTC)

Try Upright, see here WP:EIS - X201 (talk) 08:23, 6 July 2018 (UTC)

@Pbsouthwood: forgot to ping - X201 (talk) 08:23, 6 July 2018 (UTC)

X201, Upright scales the image as a proportion of default thumbnail size. I am looking for a way to scale as a proportion of page width or box width. Cheers, · · · Peter (Southwood) ^(talk): 09:41, 6 July 2018 (UTC)

Although this is possible in HTML with a little CSS, as in:

<img src="Example.svg" style="width:50%;" />

the MediaWiki software does not allow this. The main reason is that image scaling is done server-side, and our servers have no way of knowing how wide your device is. --Redrose64 🌹 (talk) 10:54, 6 July 2018 (UTC)

The software can find the viewport width of the device with CSS media queries, and respond accordingly. This functionality just isn't exposed to editors. TemplateStyles will change that though, and it's due to be enabled soon (phab:T197603), since this wiki was just switched from Tidy to RemexHTML. — AfroThundr ^{(u · t · c)} 12:08, 6 July 2018 (UTC)

WikEd now inserts div tags all over

Hi, WikEd is still giving trouble, but of a different kind from a week or two ago. Then, it was inserting numerous blank lines, creating havoc with list formatting. Now, it closes things up but too vigorously; if one tries to insert blank lines, the result is often paired <div></div> tags instead. This diff illustrates the thing that I mean. It is a new effect not seen until recently. Hope it can be fixed soon. All the best, Chiswick Chap (talk) 14:26, 16 June 2018 (UTC)

This is very annoying indeed. Headbomb {t · c · p · b} 14:39, 16 June 2018 (UTC)

I can't seem to replicate this - does it happen when inserting blank lines under any circumstances? ƒirefly ( t · c · who? ) 22:27, 16 June 2018 (UTC)

What browsers, browser version, operating systems, and skins are ya'll using? --Izno (talk) 12:53, 17 June 2018 (UTC)

Firefox (most recent version), Win10 64 bit, Monobook. Problem seems to be related to find/replaces with WikiEd, but that could be a coincidence. Headbomb {t · c · p · b} 01:16, 18 June 2018 (UTC)

This is still going on. The empty lines still happen, and the div tag seem to be inserted whenever you to a whitespace-related regex. This seems to be caused particularly when copy/pasting new lines. Possible an issue with end-of-line encoding. Headbomb {t · c · p · b} 13:25, 6 July 2018 (UTC)

It's Firefox. Hawkeye7 (discuss) 13:33, 6 July 2018 (UTC)

Only when WikiEd is enabled. So it's in WikiEd somewhere. Headbomb {t · c · p · b} 17:23, 6 July 2018 (UTC)

These kinds of issues aren't always an either-or situation; it's possible that it's a bad interaction between WikEd and Firefox, rather than just being one of them to blame. Personally, I'd recommend not using WikEd at all, because it seems to be poorly maintained. --Deskana (talk) 14:43, 7 July 2018 (UTC)

Wikimedia Maps problem

I've reported this on Phabricator (T198235), but since Kartographer is now basically unmaintained because Community Tech have moved onto something else, does anyone know why highway shields in the map in Kartographer and at https://maps.wikimedia.org consisting of numbers only are incorrectly sized? (Images are in the task description.) I'm noting this here because it should be relatively easy to fix for someone who can read and can edit the map stylesheets. Thanks, Jc86035 (talk) 15:44, 6 July 2018 (UTC)

I've got consensus to merge two pages - now what do I do?

Back in December 2017 I put in a merge request using Copy and Paste easy merge templates. Consensus to merge was established 2 June 2018 see: Requests answered in June 2018 and discussion but I don't know how to do mergers (please don't point me to the instructions). Is there a place I can go to request a "volunteer merger editor" to actually carry it out, or do I simply wait? I thought there would just be a "done" or "not done" reply, I hadn't bargained on a "working - you may now proceed" answer! --The Vintage Feminist (talk) 17:19, 6 July 2018 (UTC)

@The Vintage Feminist: there is nothing magic or automatic about the merge process, see Wikipedia:Merging#How_to_merge - I know you asked not to see the instructions but they are there for a reason. The major next step is editorial, not technical: what actual content from the FROM article to you want to show in the TO article? You need to put that content in to the article by editing. — xaosflux ^Talk 17:26, 6 July 2018 (UTC)

(edit conflict)You can request so at Requests for merge assistance and feedback, although that place is perpetually backlogged due to cumbersome nature of merging. Moreover, after you list it, it will be helpful for you to be bold and learn how to merge pages yourself. There's a chance, you'll learn the merger process and even merge the pages before the volunteer from heaven attended to your request. –Ammarpad (talk) 17:40, 6 July 2018 (UTC)

The Vintage Feminist, It really is not difficult. Just follow the instructions step by step and the actual merge will be done after very few steps, none difficult. It looks more complicated than it is, and you can't break anything irreversibly. As an extra suggestion. put an {{in use}} template into each before you start to reduce the chance that someone or a bot will edit while you are busy. Give it a go and ping me if you have any trouble. (I am in UTC+2 time zone, and often not available between 10pm and 7am, due to a habit of sleeping at night). The cleanup after the merge usually takes longer. · · · Peter (Southwood) ^(talk): 18:59, 6 July 2018 (UTC)

Structured Data on Commons Newsletter - Summer 2018

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

Community updates

• Our dedicated IRC channel: wikimedia-commons-sd ^webchat
• Since our last newsletter, the Structured Data team has moved into designing and building prototypes for various features. The use of multilingual captions in the UploadWizard and on the file page has been researched, designed, discussed, and built out for use. Behind the scenes, back-end work on search is taking place and designs are being drawn up for the front-end. There will soon be specifications published for the use of the first Wikidata property on Commons, "Depicts," and a prototype is to be released to go along with that.

Things to do / input and feedback requests

• A workshop on what Wikidata properties Commons will need. This workshop will be open for the entire month of July 2018 at minimum.

• Join the community focus group!
• Do you want to help out translating messages about Structured Data on Commons from English to your own language? Sign up on the translators page.
• Contribute to the next newsletter.

Discussions held

• In late February there was a discussion around how Commons generally sees data being modeled.

• The first discussion on copyright and licensing with Commons was held in March. This was a "high level" discussion, there will be a consultation later this summer about the deeper mapping of copyright and licensing in a structured way.
• In April there was an exercise for GLAM partners in metadata and ontology mapping.
• A discussion about the design for Multilingual Captions on the file page took place in May. You can still review the designs and leave feedback.
• There was an IRC office hour in June to discuss progress so far and future plans.

Wikimania 2018

• Three sessions about Structured Commons are officially scheduled for Wikimania 2018 - Cape Town, South Africa - July 2018.
  • Wikimedia Commons and GLAM needs around the world (Friday 20 July, 10:30 local time)
  • Structured Data on Wikimedia Commons and knowledge equity (Friday 20 July, 14:00 local time)
  • Design challenge workshop: How can multilingual structured metadata bring knowledge equity to Commons? (Friday 20 July, 14:30 local time)
• Structured Data on Commons is also a focus area during the Wikimania 2018 Hackathon. We will, among other things, do 'live' modelling of Wikidata properties for Commons - an offline spin-off of the community consultation taking place on wiki.

Partners and allies

• We are still welcoming (more) staff from GLAMs (Galleries, Libraries, Archives and Museums) to become part of our long-term focus group (phabricator task T174134). You will be kept in the loop of the project, and receive regular small surveys and requests for feedback. Get in touch with Sandra if you're interested - your input in helping to shape this project is highly valued!
• Structured Data on Commons was presented to GLAM audiences during EuropeanaTech 2018 in Rotterdam (15 May 2018) and at the Deutsche Digitale Bibliothek Forum in Berlin (4 June 2018).

Research

Two research projects about Wikimedia Commons are currently ongoing, or in the process of being finished:

1. m:Research:Curation workflows on Wikimedia Commons—a project that seeks to understand the current workflows of Commons contributors who curate media (categorize it, delete it, link to it from other projects, etc.).
2. m:Research:Technical needs of external re-users of Commons media—soliciting feedback from individuals and organizations that re-use Commons content outside of Wikimedia projects, in order to understand their current painpoints and unmet needs.

Development

• Prototypes will be available for Depicts soon.

Stay up to date!

• Follow the Structured Data on Commons project on Phabricator: https://phabricator.wikimedia.org/project/profile/34/
• Subscribe to this newsletter to receive it on a talk page of your own choice.
• Join the next IRC office hour and ask questions to the team! The date for next quarter will be announced soon.

-- Keegan (WMF) (talk)

Message sent by MediaWiki message delivery - 21:07, 6 July 2018 (UTC)

Structured Data Newsletter - Research link fix

errata

Greetings, The newsletter omitted two interwiki prefixes, breaking the links on non-meta wikis as you might see above. Here are the correct links: m:Research:Curation workflows on Wikimedia Commons—a project that seeks to understand the current workflows of Commons contributors who curate media (categorize it, delete it, link to it from other projects, etc.). m:Research:Technical needs of external re-users of Commons media—soliciting feedback from individuals and organizations that re-use Commons content outside of Wikimedia projects, in order to understand their current painpoints and unmet needs. My apologies, I hope you find the corrected links helpful. - Keegan (WMF) (talk) 21:21, 6 July 2018 (UTC)

 Fixed in the post above. --Pipetricker (talk) 21:55, 6 July 2018 (UTC)

Ghost edits

When I paused during an operation to expand the sections of Template:British legislation lists, I noticed this peculiar diff. What makes it odd, at least to me, is that it shows that I erased a space following the {{very long|date=December 2013}} template; however, I did not erase that space. All I did was add the |delegated parameter to the other template. How is it that the space was erased? and who or what erased it?  Paine Ellsworth  ^put'r there  07:40, 7 July 2018 (UTC)
PS. That also happened during this edit. What the heck is going on?  Paine Ellsworth  ^put'r there  08:07, 7 July 2018 (UTC)

You might have a user script installed, or maybe you're using a gadget that you forgot about, like wikEd. NinjaRobotPirate (talk) 08:24, 7 July 2018 (UTC)

Whitespace at the end of an edit can be automatically removed on save. I don't know the details but the space was left there in a full page edit so it wasn't removed at the time. PrimeHunter (talk) 10:31, 7 July 2018 (UTC)

To editors PrimeHunter and NinjaRobotPirate: thank you for your help! No, I don't have a script that does that, and this is the first time I've ever seen this happen. If the software is automatically making edits while I edit a page, it makes me wonder what else it's doing. It's a bit unsettling to see a diff where there was an edit there that I didn't make. When I look at a diff made by another editor, I've always taken for granted that all the edits in that diff were made by that editor. Now I wonder! (???)  Paine Ellsworth  ^put'r there  14:25, 7 July 2018 (UTC)

I created a testcase and couldn't replicate it. Assuming it's not caused by a user-script or copy-paste, it must be something in the MW software, intentional or bug, but anyway benign. -- GreenC 14:41, 7 July 2018 (UTC)

@Paine Ellsworth and NinjaRobotPirate: - PrimeHunter is on the right lines here. When you edit a section, trailing whitespace is removed from the last line. This is an oversimplification: in more detail, what happens is that when the edit box is first loaded, trailing whitespace (spaces, tabs and newlines) is removed from the last line of text or other markup and replaced with a single newline. You then get the chance to start editing in that edit box. When you use the Publish changes button, trailing whitespace is again removed from the last line and replaced with a single newline (if it is the last section on the page) or with two newlines (if it is not). This has been normal behaviour for as long as I've been around (nine years and counting), evidence from 4 years ago. --Redrose64 🌹 (talk) 14:49, 7 July 2018 (UTC)

There you go. Easy. --Redrose64 🌹 (talk) 14:53, 7 July 2018 (UTC)

All right Redrose64! It has been awhile, and yet once again you come through. It amazes me that I never noticed those subtle extra edits before. Thank you! and also PrimeHunter, NinjaRobotPirate and GreenC for your inputs!  Paine Ellsworth  ^put'r there  15:27, 7 July 2018 (UTC)

Thank you! I tried too and couldn't get it to happen. It does though, judging by Redrose64's sandbox case above. Maybe the software doesn't do it in userspace?  Paine Ellsworth  ^put'r there  15:34, 7 July 2018 (UTC)

This behaviour is most obvious when you edit a section. It also happens when you edit a whole page, but it's rarely visible since trailing whitespace almost never occurs on the last line of a page. The only instances that I know of are from six or so years ago when somebody used a bot to create a number of redirects which ended with two newlines instead of one. The next edit to the redirect naturally removed the extra newline. --Redrose64 🌹 (talk) 16:22, 7 July 2018 (UTC)

As I said, "Whitespace at the end of an edit can be automatically removed on save". I should apparently have clarified that "the end" really did mean the end and not before section heading code in a full page edit. If you want to see the effect at the current version of User:GreenC/testcases/test then edit the lead section only with [17] and click "Show changes". The diff shows a space at the end of the edit will be removed. Don't save. Others may want to see it. I know four situations where save will not save what is actually in the edit area. 1) Whitespace removal at the end of the whole edit. 2) Signature conversion of three, four or five tildes. 3) Substitution with subst:. 4) The pipe trick on [[...|]]. I haven't tried to save a page above 2 MB but cutting that off may be a fifth case, and there may be more cases I don't know. PrimeHunter (talk) 16:48, 7 July 2018 (UTC)

JavaScript page in error tracking category

Why do some js pages end up in an error tracking category such as Category:ParserFunction errors? An example is here. I asked the user about the issue here and mentioned that the js page seems to get parsed as if it were wikitext. That generates errors due to three comments which mention a template, for example {{Aired episodes}}. Viewing the HTML source for the js page shows the error: "Lua error in Module:Template_parameter_value at line 27: attempt to index a nil value" since the template has no parameters. Having the fake error in the tracking category is an irritation to someone who obsesses about cleaning errors but my question is how this happens. Why would template syntax in a js page get parsed with a resulting error category? I don't think this happens in a module. Johnuniq (talk) 09:31, 7 July 2018 (UTC)

js (and css) pages are parsed like wikitext when categories and link tables are made. The result is just ignored when the page is rendered since it automatically gets the page content model "JavaScript". It's deliberate and we use the link tables in some features. For example, speedy deletion nominations of js and css pages place the pages in the right admin-monitored categories even though the nomination box is not shown on the page. User:Anomie/linkclassifier.js asks to install with:

importScript('User:Anomie/linkclassifier.js'); // Linkback: [[User:Anomie/linkclassifier.js]]

This means uses can be found with Special:WhatLinksHere/User:Anomie/linkclassifier.js. Many scripts do the same. The wikitext processing can be avoided in a js page by starting with a line saying // /* and ending with a line saying // */. Everything inside /* ... */ is a wikitext comment which is ignored in wikitext parsing. Lines starting with // are js comments so the lines but not the lines between them are ignored in JavaScript parsing. PrimeHunter (talk) 10:21, 7 July 2018 (UTC)

Amazing, thanks for the detail. Johnuniq (talk) 10:33, 7 July 2018 (UTC)

Hmm, regarding "Lines starting with // are...ignored", that might not be correct. I just created User:Johnuniq/sandbox.js containing a single // comment. Yet the page is in Category:Pages with script errors and Category:ParserFunction errors. I will remove the errors in a day or two to clear the categories—here is the permalink. Johnuniq (talk) 10:46, 7 July 2018 (UTC)

I mean // lines are ignored when the JavaScript runs in the account. // is not a wikitext comment so you have to use /* ... */ for that. But /* ... */ is also a JavaScript comment so you cannot place /* ... */ around the whole page. That would prevent the JavaScript from running. But if you start the page with // /* and end it with // */ as I said then the combination works (assuming there are no other /* ... */ in the page). Wikitext processing ignores // and the whole page is commented out. JavaScript running ignores everything after // on a line so // /* ... is a single-line comment and ignores that /* alone would have started a multi-line comment in JavaScript. PrimeHunter (talk) 11:38, 7 July 2018 (UTC)

Another way is to put // <nowiki> at the top and // </nowiki> at the bottom. Everything between the tags won't be processed as wikitext. This is probably more useful for actual scripts rather than for user's common.js or skin-specific js pages, where linkbacks are useful for finding who has installed a script. - Evad37 [talk] 11:54, 7 July 2018 (UTC)

I don't think that /* ... */ will work to suppress the parsing of templates and links; I'm pretty sure it needs to be the HTML comment tags <!-- ... -->. --Redrose64 🌹 (talk) 15:19, 7 July 2018 (UTC)

Right. I confused the comment tags. It's // <!-- on the first line of a js page and // --> on the last line if you don't want the page to be processed as wikitext when link tables are made. <!-- and --> are invalid JavaScript but that doesn't matter when they are in a JavaScript comment line. <nowiki>...</nowiki> also works. PrimeHunter (talk) 16:22, 7 July 2018 (UTC)