Wikipedia:Village pump (technical)

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

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

For a listing of ongoing discussions, see the dashboard.


Search results from sister projects...[edit]

Is there any way to disable or opt-out of the sister project search results? For instance, I put in "Talk:Orlando shooting" wanting to see how something was technically set-up on that page and found what I needed "Talk:2016 Orlando nightclub shooting" along with other Wikipedia articles listed on the left. I also got results from sister projects over on the right side which consisted of:
Talk:Keira Knightley
girls off-cam, and they were ready to kill me because I kissed Orlando Bloom! On shooting a scene in Pirates of the Caribbean. The fact that we haven't
Quotes from Wikiquote
Talk:As You Like It
As you Like it. Actus primus, Scæna prima. Enter Orlando and Adam. Orlando. As I remember Adam, it was vpon this fashion bequeathed me
From Wikisource

I'd really like to be able to opt-out if possible. Thanks, Shearonink (talk) 03:45, 17 June 2017 (UTC)

I'd like to opt out, too, and not via custom css, but a simple checkbox on the prefs page. BlackcurrantTea (talk) 07:27, 17 June 2017 (UTC)
Yep, I'd like to opt out as well. Lugnuts Fire Walk with Me 12:01, 17 June 2017 (UTC)

For those curious, see how search results from sister projects were discussed at WP:VPP. Such results went live as seen via mailing list. This isn't a technical problem but more of a complaint. BTW, I started a thread seen at Wikipedia:Village pump (miscellaneous)#Search results from selected sister projects now active. You can propose enabling/disabling search results from those projects at WP:village pump (proposal) if you can. George Ho (talk) 20:54, 17 June 2017 (UTC)

Also, see Wikipedia:Village pump (technical)/Archive 154#Sister projects search results. --George Ho (talk) 21:07, 17 June 2017 (UTC)

@George Ho: Not sure what your point is with the "...if you can" above there but ok. I went ahead and posted at proposal, probably worded it incorrectly or something but it would be nice to have an opt-out for this feature. That's all. Shearonink (talk) —Preceding undated comment added 06:00, 18 June 2017 (UTC)

Just write a gadget —TheDJ (talkcontribs) 08:41, 19 June 2017 (UTC)

If anyone is interested, here's the code for disabling the 'sister-site-search':

#mw-interwiki-results { display: none !important } or div#mw-interwiki-results { display: none !important }<-Post on your common.css page. This fix was kindly posted at Wikipedia:Village pump (proposals) by Nemo. (I still wish that this had been an opt-in checkmark-feature.) Shearonink (talk) 18:29, 19 June 2017 (UTC)
  • Here's a quick snippet you can add to your common.js to make it collapsible and collapsed by default:
    	if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ) {
    		$.when(
    			mw.loader.using( 'jquery.makeCollapsible' ),
    			$.ready
    		).done( function () {
    			var $mwInterwikiResults = $( '#mw-interwiki-results' );
    			
    			$mwInterwikiResults.addClass( 'mw-collapsible mw-collapsed' )
    				.find( '.iw-results' ).addClass( 'mw-collapsible-content' );
    			$mwInterwikiResults.makeCollapsible();
    		} );
    	}
    
    Murph9000 (talk) 19:15, 19 June 2017 (UTC)

Requesting suppression on search result from Wikibooks[edit]

Wikibooks was included, yet I slowly realized that there was no consensus per RfC discussion to include search results from Wikibooks in English Wikipedia. The developers included it without double-checking it. Therefore, I filed a task at Phabricator. --George Ho (talk) 00:54, 23 June 2017 (UTC)

Pinging TheDJ and Murph9000 about this. --George Ho (talk) 02:57, 23 June 2017 (UTC)

I support user choice in terms of being able to configure what is shown. There probably should be options added to preferences to control it. As long as there isn't a serious negative from it (I don't see one), and the presentation does not risk confusion about what is a local result vs. extended result (seems clear enough to me), I'm not significantly concerned about WMF using it to promote all projects (even when that does not align with the RfC closure). Murph9000 (talk) 08:15, 23 June 2017 (UTC)
Hi, when I wrote the follow-up to the RfC and the actions we'd be taking, I also explained why we decided to include Wikibooks in the sister project snippets display on enwiki in a comment to that posting. I've also replied on your phab ticket with the same information. Thanks, DTankersley (WMF) (talk) 14:26, 23 June 2017 (UTC)
Hey, Deb. I replied at Phabricator. BTW, I can quote what is said below from the RfC discussion:

Wikibooks--Strong consensus to oppose.Almost every work is seemingly incomplete.A garble of poorly thought out info at best!

--George Ho (talk) 14:45, 23 June 2017 (UTC)

Some sort of glitch in mobile view[edit]

Originally at WP:AN, but I moved it because it's more appropriate here. Nyttend (talk) 10:39, 17 June 2017 (UTC)

Hi,
The following are the screenshots of two pages. They are looking normal from desktop, but not from mobile devices (looked at it from iPad, and BlackBerry). Not sure where the problem is. I noticed this two days ago (almost 60 hours from now). Would somebody please take a look into that? Thanks a lot.

usernamekiran(talk) 22:43, 16 June 2017 (UTC)

  • Looks like you are getting the not-logged in banner from Wikipedia:PERM/Subpage, but it is not getting formatted well for mobile view. — xaosflux Talk 11:31, 17 June 2017 (UTC)
  • It's coming from Wikipedia:PERM/Subpage, which is transcluded into the other pages. It looks like the CSS classes (anonymous-show boilerplate metadata) are not having the intended effect in the mobile view. Desktop users can see this by visiting https://en.m.wikipedia.org/wiki/Wikipedia:PERM/Subpage, you don't need a mobile device to investigate the issue. It looks like MediaWiki:Group-user.css is not used or being overridden by the mobile skin (and obligatory "ugh!" at the use of !important in there…). It also needs a fix for the line wrapping (for cases where it should be shown). Murph9000 (talk) 01:21, 18 June 2017 (UTC)
    It looks like the following in MediaWiki:Mobile.css is responsible (both for overriding the hiding of it, and for breaking the expected display: block on a div element, with yet more horrible !important-ness:
    /* On en.wp .metadata is only hidden in article namespace... note :not must be qualified to body tag as otherwise it will match ANY tag that is not class ns-0 (T166451)*/
    :not(body.ns-0) .content .metadata {
    	display: initial !important;
    }
    
    Murph9000 (talk) 01:38, 18 June 2017 (UTC)
Yeah I recently unhid some of this previously hidden stuff, had not really considered about the user groups hiding stuff.... Either we need to hide everything again, remove the metadata class from that specific template, or fix the upstream mobile specification, to account for more en.wp variation... I'll look into it later tonight. —TheDJ (talkcontribs) 07:59, 19 June 2017 (UTC)
I've undone this change for now. Hopefully we can figure out something more sustainable at some point. —TheDJ (talkcontribs) 14:22, 20 June 2017 (UTC)

Help me, Obi-Wan Kenobi! You're my only hope!! (Referrers again)[edit]

At Wikipedia:Village pump (policy)#A solution that satisfies privacy and GLAM requirements? (which is a section of Wikipedia:Village pump (policy)#RfC: Wikimedia referrer policy I have an editor who claimed without evidence that a particular feature is supported only by the chrome browser. my research suggests that it is supported by all major browsers, but the ref I am basing that on is is to searchengineland, and I really am hoping to find a better source. I could really use some technical help here.

In particular, if Wikipedia puts the following in the head of the HTML...

<meta name="referrer" content="same-origin">

...thus sending no referrer information when a user clicks on a link to a non-Wikipedia page, and then Wikipedia adds the following to selected links...

<a href="http://example.com" referrerpolicy="always">

..to override the meta tag in the head, what browsers support this?

According to [ https://caniuse.com/#feat=referrer-policy ] Referrer Policy is supported by Firefox, Chrome, Safari, Opera, iOS Safari, Android Browser, and Chrome for Android and (maybe) Microsoft Edge. (It is not supported by Internet Explorer, but because Internet Explorer doesn't support the referrer meta tag or referrerpolicy on the link, IE will always have the default HTTP/HTTPS behavior no matter what we do with our meta tags and links.)

According to [ http://searchengineland.com/need-know-referrer-policy-276185 ], There are many ways you can deliver the referrer policy:

  • Via the Referrer-Policy HTTP header
  • Via a meta element with a name of referrer
  • Via a referrerpolicy content attribute on an a, area, img, iframe, or link element (emphasis added)
  • Via the noreferrer link relation (rel=) on an a, area, or link element
  • Implicitly, via inheritance

I have searched and searched and cannot find a shred of evidence that this is only supported by chrome, but I am also lacking good, strong evidence that it is supported by other browsers.

Help me, Obi-Wan Kenobi! You're my only hope!! :) --Guy Macon (talk) 13:35, 17 June 2017 (UTC)

We can crowdsource evidence: editors with the different browsers can use browser developer tools to look at what gets sent out when they click on a link with the attribute in question. If someone could create a suitable example page for everyone to use, it would help. (On a side note, my understanding of the cited "Can I Use" page is that it is explicitly talking about the meta element, and not an attribute on the link.) isaacl (talk) 00:16, 18 June 2017 (UTC)
I will not answer this question as I think i'm the "an editor" in question. —TheDJ (talkcontribs) 08:40, 19 June 2017 (UTC)
Let's review, shall we? First you refused to back up your claim[1] with any sort of citation or other evidence, then another editor[2] provided multiple sources that refute your claim, and your response was to... not answer the question?[3] And to strike your !vote?[4] Your attempt to withdraw from the dispute is admirable, but it would be a better strategy to do so without any final, snarky "parting shot" comments. --Guy Macon (talk) 11:00, 19 June 2017 (UTC)

Wikipedia:Village_pump_(technical)#Other_ways_to_set_a_referrer_policyTheDJ (talkcontribs) 11:18, 19 June 2017 (UTC)

Nothing in the link you just posted contains even a shred of evidence supporting your claim that "Only Chrome supports this attribute so far, and none of the other vendors have indicated they are going to be adding this any time soon."[Citation Needed]"
[ https://caniuse.com/#search=referrer ] says that all major browsers support rel="noreferrer" on links. While it doesn't specifically say whether the same browsers support referrerpolicy="always" on links, extraordinary claims require extraordinary evidence, and your claim that no major browsers other than chrome follow the spec at [ https://www.w3.org/TR/referrer-policy/ ] really sounds like something you just made up to win an argument.
The fact that you cannot provide a shred of evidence supporting your claim adds weight to my theory thhat you just made it up. That being said, I could be wrong. Post evidence supporting the specific claim you made and I will admit that I was wrong and apologize. --Guy Macon (talk) 13:56, 19 June 2017 (UTC)

Centering infobox titles[edit]

Why infobox titles in mobile view, e.g. for article YouTube (uses {{Infobox website}}, leads directly to {{Infobox}} i.e. Module:Infobox), display uncentered and not enlarged? --5.43.106.119 (talk) 21:34, 17 June 2017 (UTC)

A simplified example for the alignment with <table><caption>YouTube</caption><tr><td>Video hosting service</td></tr></table>:
YouTube
Video hosting service
The caption is centered in desktop but not in mobile. The same happens at hz:Special:ExpandTemplates versus https://hz.m.wikipedia.org/wiki/Special:ExpandTemplates in a wiki with no pages except the main page. The mobile skin has this by default:
.content table caption {
 display:block;
 text-align:left
}
The html default is centering. The mobile skin makes lots of changes from desktop. I don't know the reason for left-aligning captions but I guess somebody thinks it works better on small mobile screens. It could be changed in MediaWiki:Mobile.css. PrimeHunter (talk) 09:41, 18 June 2017 (UTC)
Is it known who or why? How would it "work better on small mobile screens" if it is aligned left? Only resizing can have effect (having smaller or resetting normal, 100% font size); I think that uncentering cannot save extra space or help by any means. --5.43.106.119 (talk) 21:13, 18 June 2017 (UTC)
Yes, it's known why. The mobile site prevents large tables from overflowing the entire viewport, and instead turns a table that is wider than the viewport into it scrollable box. If you center the caption or such a wide table that is made scrollabe, then this might result in the caption being partly or completely invisible (as it would overflow on the right side into the invisible area that is only reachable by scrolling). The caption is therefor left aligned, so that it is always visible and readable. There is also no CSS-only way to make something like the caption respond to the fact that the table is overflowing. It's not really an ideal solution, but large tables are incredibly problematic on smaller screens and dealing with that problem has the effect of left centering all captions. If better solutions are found, then these can be considered. —TheDJ (talkcontribs) 23:34, 19 June 2017 (UTC)
@TheDJ: OK, that's a reasonable explanation. Could solution be to exclude title from overflow div or other element, so that it is centered above the element (relative to its part-that-is-viewable width)? And where can this be achieved, in module Infobox or Mediawiki .css? --5.43.106.119 (talk) 09:25, 20 June 2017 (UTC)
Not as far as I am aware. captions are part of the table (even though rendered visually 'outside' of the table). Some things were tried with targeting just the table body in the past, but that was creating other problems. —TheDJ (talkcontribs) 10:14, 20 June 2017 (UTC)

Template:Periodic table borders[edit]

Why Periodic table legend displays improperly on mobile view (right border is not complete and box is not centered)? --5.43.106.119 (talk) 21:34, 17 June 2017 (UTC)

Which legend? I see several but no good match to your description. What is your browser? PrimeHunter (talk) 08:51, 18 June 2017 (UTC)
Here, next to the lanthanides and actinides there is a right border but is broken on vertical between Oganesson and Lutetium and below Lawrencium, all the way to the Unknown chemical properties in the legend where there is no *bottom border either (*down below Oganesson and right to the Unknown chemical properties cell).
The problem I described occurs in Chrome but not Firefox. In IE11 there are no borders at all, only 4 above and below three main legend rows and 1 extra border below legend (so there is double border below bottom row of the legend). All browsers are updated to latest versions (Chrome: 59.0.3071.104; Firefox: 54.0; IE: 11.0.9600.18665). --5.43.106.119 (talk) 09:33, 18 June 2017 (UTC)
There was an issue where a small minority of the table rows were 19 cells wide, and the remainder were 20. I've changed it so that they are all 20 cells wide; that's HTML table cells, nothing to do with the scientific column count just the web markup. Does that fix it for you? Murph9000 (talk) 09:50, 18 June 2017 (UTC)
Yes, now borders are complete in Chrome. With IE it's same, no borders, but it's not important as this browser is not used very often. --5.43.106.119 (talk) 21:13, 18 June 2017 (UTC)

Double spaces[edit]

Could someone globally replace two spaces between "Contents" and [show]/[hide] buttons at the top of the contents box as these are *only two spaces that are found by CTRL+F search on all article pages (*except for improper manual ways of creating bigger margins between words in transcluded templates or article itself)? Maybe this needs to be reported to phabricator in order to be resolved.

Also, there are two spaces used on several occasions as separator in script that generates bottom extra toolbar (before "Sign your posts on talk pages:", for example).

This can be solved by using proper margins instead of bigger spaces (so that selection is prevented). --5.43.106.119 (talk) 21:34, 17 June 2017 (UTC)

Why? So what if there's an extra space there? It's not breaking anything, there's no obvious negative impact from it. Murph9000 (talk) 21:54, 17 June 2017 (UTC)
Selection would be prevented and CTRL+F search would not start from article body but editing box when one wants to find double spaces inside code and clean it so that there are no double spaces. --5.43.106.119 (talk) 22:01, 17 June 2017 (UTC)
Use the code editor for CSS & JS, it has a search (and optional replace) feature which is independent of the browser's search-in-page. Inside article source, double spaces are not an error or something to be "fixed" in general (MOS allows traditional double space typography and states it should not be changed / cleaned). Murph9000 (talk) 22:06, 17 June 2017 (UTC)
Selection is still not prevented. --5.43.106.119 (talk) 21:13, 18 June 2017 (UTC)
Note that the double space is not treated differently from the single space when you look for a double space. When I do such a search in this section, I'm told that a double space appears in Why? So what if there's an extra space there? It's and also in lots of spots where single spaces are used. Nyttend (talk) 04:16, 19 June 2017 (UTC)
@Nyttend: In your example, there are double spaces in the code (if you do search in code editor, then it will find double spaces) but when previewed/saved – those spaces are displayed as one because that's how multiple &#32; whitespace characters are always rendered in HTML (so search will not find double spaces in this case). It's not true that they are not treated differently from single space; they are, because we have extra characters (bytes).
@Murph9000: If someone was eager to take care even of spacing apostrophe if it follows quote mark in citation templates (CS1 does not display "' or '" but adds space between), it would be fair to resolve this much more present and visible (when making text selection, and copying to Word for example – to print out article) 'problem'. When designing web page one should not use multiple spaces for creating invalid 'margins' (and have ugly selection) but use horizontal margin or padding property to achieve the desired output. --5.43.106.119 (talk) 09:42, 20 June 2017 (UTC)
No, I'm referring to viewing the page in the edit window and saying that inserting a double space into the "find" bar finds both the quoted text and a lot of non-quoted ordinary text in which only single spaces appear; my browser, the latest IE, only finds the first 100 instances of a phrase. It has trouble because there are so many instances of such a "phrase", but if I open a much shorter editing window and do the same search, it finds a higher percentage of the spaces. For example, if I open the next section and look for a double space, it finds nine instances in the string that one does catch me out from time to time. Nyttend (talk) 11:10, 20 June 2017 (UTC)

Odd cite error[edit]

Before an editor made this edit, the references displayed in the Notes okay, now they don't. Reflist 30em looks okay. Some hidden control characters lurking somewhere? CV9933 (talk) 19:18, 18 June 2017 (UTC)

A purge fixed it. PrimeHunter (talk) 20:21, 18 June 2017 (UTC)
Ah thanks - that one does catch me out from time to time. regards CV9933 (talk) 20:43, 18 June 2017 (UTC)

Search edit summaries?[edit]

Is there a way to search edit summaries (not the entire edit histories), not just for one article, but for all articles? Thanks. SharkD  Talk  14:35, 19 June 2017 (UTC)

You could use dumps or maybe labs DB replicas. But no, it's not in the actual search index. FACE WITH TEARS OF JOY [u+1F602] 20:13, 19 June 2017 (UTC)
Also see WP:RAQ. —PaleoNeonate - 21:27, 19 June 2017 (UTC)
@SharkD: At the bottom of your contribs, there's a link "Edit summary search". --Redrose64 🌹 (talk) 07:39, 20 June 2017 (UTC)

Regex "don't match string"[edit]

While it's fairly easy to match a string in regex, it's quite hard to not match it.

For instance, let's say <ABC> marks the start of a string and <XYZ>, and I want to match the first part in

<ABC>abc<def>[9-7];<t><XYZ>

How do I do that? My mind thinks <ABC>[^(<XYZ>)]+<XYZ> (e.g. match <ABC>, match NOT <XYZ>, match <XYZ>), but that's not valid regex. Headbomb {t · c · p · b} 15:31, 19 June 2017 (UTC)

The all-characters character . should work. If you want to grab all text up to the first instance of <XYZ>, use \<ABC\>.*?\<XYZ\>. If you want to grab all text up to the last instance of <XYZ> (including all intervening <XYZ>s), use \<ABC\>.*\<XYZ\>, without the ? from my first example. Of course, the best practice is, if possible, try to eliminate the use of . by enumerating all the potential characters. . can also be set to either include or exclude \r\n characters, depending on your application.   ~ Tom.Reding (talkdgaf)  15:50, 19 June 2017 (UTC)
Negative lookahead assertions — (?!pattern to not match) — can be used to ensure a specific pattern does not match, but they can be tricky to use as they do not consume any characters from the string being examined. Using a non-greedy wildcard as suggested by Tom.Reding will often be easier. isaacl (talk) 19:42, 19 June 2017 (UTC)
The negative lookahead might just be what is needed. I'll test that. Headbomb {t · c · p · b} 19:48, 19 June 2017 (UTC)
Doesn't seem to work. Trying "doi:(?!<\/ref>)" on doi:10.1324/12345<asdf;12-12>-asd[4]2;3245</ref> and I get no match. Trying "doi:.*(?!<\/ref>)" matches the whole thing, rather than just the doi:10.1324/12345<asdf;12-12>-asd[4]2;3245 part. Headbomb {t · c · p · b} 19:52, 19 June 2017 (UTC)
Got it, "doi:.*(?=<\/ref>)" works. Headbomb {t · c · p · b} 19:58, 19 June 2017 (UTC)
Your first pattern doesn't work because the lookahead assertion doesn't consume any characters, so it's only going to match the doi:. The second matches everything first and greedily, so the negative lookahead at the end doesn't matter. The third pattern matches greedily, which may or may not be what you want; you can use .*? for a non-greedy match.
To consume characters while checking for the negative lookahead assertion at each step, you need something like ((?!<\/ref>).)* . Warning: I didn't test that; just something off the top of my head. But checking for a trailing sentinel value (as you've done with the positive lookahead assertion, and Tom.Reding did with his example) is typically easier to understand. As long as there are no nesting issues it is often good enough combined with a non-greedy match. isaacl (talk) 20:41, 19 June 2017 (UTC)
Nesting issues exist. But I've managed something which seems to work by using multiple regex that kick off in a specific order. It might not be the most elegant solution, but it seems to work so far. Headbomb {t · c · p · b} 20:51, 19 June 2017 (UTC)

If you want to get a better insight into regex, I can highly advise https://regex101.com It's a great site to validate and debug various regex flavors. —TheDJ (talkcontribs) 23:22, 19 June 2017 (UTC)

I'm quite familiar with the regex tester, but it's rather unhelpful when your regex hopelessly fails to achieve anything to start with. The above gave me a good lead though, and I've hacked a solution. While it may not be the soundest of regex, it works. Headbomb {t · c · p · b} 23:39, 19 June 2017 (UTC)

Tech News: 2017-25[edit]

15:44, 19 June 2017 (UTC)

/æ/ tensing[edit]

When trying to link to the above article, I noticed that the link does not point to the article, but instead points to the page you're currently viewing, plus "/æ/ tensing", resulting in a red link. The above link, for example, loads "Wikipedia:Village pump (technical)/æ/ tensing". The only way to properly load the correct page is to copy the text and paste it into the search bar. Is this a known issue with pages that start with a "/"? Home Lander (talk) 01:43, 20 June 2017 (UTC)

I first noticed it here (see the bottom edit summary) when Huggle spawned a red link. Home Lander (talk) 01:54, 20 June 2017 (UTC)
(edit conflict) Yes, although it doesn't occur in mainspace. You can work around this with a colon at the beginning, producing /æ/ tensing. Pppery 01:55, 20 June 2017 (UTC)
Ah, thanks. Looks like Huggle therefore has a tiny bug in the edit summary programming. Home Lander (talk) 01:59, 20 June 2017 (UTC)
A wikilink starting with a slash links to a subpage of the current page per Help:Link#Subpage links. This is deliberate to allow links like /Archive 155. The subpage feature is disabled in mainspace so if the link is written in mainspace then it just goes to a page starting with a slash. Most mainspace names starting with a slash are redirects. There are 20 articles: [8]. Maybe they should be moved and use {{correct title}} to reduce confusion. They are currently allowed by WP:NC-SLASH. The above link here shows wrong edit summary links by both Twinkle and Huggle. PrimeHunter (talk) 09:26, 20 June 2017 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I observed that as well and left messages at both the Huggle and Twinkle talk pages. Home Lander (talk) 15:01, 20 June 2017 (UTC)

It won't let me log in[edit]

I can't log in with Firefox anymore.

The WP login window keeps giving me this message:

"There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

I followed those instructions, but I keep getting the same message.

So I loaded chromium, and was able to log in fine with that.

But I still can't log in with my Firefox browser.

Please help! The Transhumanist 03:50, 20 June 2017 (UTC)

So good news, your account is fine. In firefox, delete your cache and cookies and try again. See their help article. — xaosflux Talk 03:53, 20 June 2017 (UTC)
Good point about the account, that was a relief. Thanks for the link. I'll let you know if I can fix it. The Transhumanist 04:00, 20 June 2017 (UTC)
Cookies were disabled. It's fixed now. *Sigh* The Transhumanist 04:22, 20 June 2017 (UTC)

Proposal for new requirement for AWB bots[edit]

I opened a discussion in Wikipedia_talk:Bot_policy#Should_bots_perform_multiple_edits_in_a_page.3F to raise the problem of multiple bots editing a single page and how we could optimise that using AWB bots to perform many tasks. -- Magioladitis (talk) 07:59, 20 June 2017 (UTC)

For clarity, since the linked discussion is something of a mess: The current bot policy is to allow AWB bots to include "general fixes" as long as they are approved to do so via WP:BRFA and as long as they do not make edits that violate WP:COSMETICBOT. Magioladitis proposes requiring that all bots (or possibly just all AWB bots) perform "general fixes" even if the operator does not wish to do so. Anomie 12:37, 20 June 2017 (UTC)
Magioladitis has also proposed removing WP:COSMETICBOT entirely in an earlier section on that talk page, and has generally been agitating against WP:COSMETICBOT since it became an issue in his recent ArbCom case. Anomie 12:37, 20 June 2017 (UTC)

Also note that WP:COSMETICBOT changed after the linked ArbCom case whose decision was based on the old definition. Also there is now an open discussion of the correct term of low volum edits. ArbCom suggested that the community has to re-examine these things. During the discussions it was made clear that an inbalance is created since in many cases BAG members would allow secondary edits or minor tasks only in combination of a different task. Note that even the title "COSMETICBOT" is subjct to change after many comments that show that dos not reflect correctly what does this policy tries to express.-- Magioladitis (talk) 12:53, 20 June 2017 (UTC)

Again for clarity: ArbCom considered that the then-ongoing discussion to revise WP:COSMETICBOT (that resulted in the change Magioladitis refers to) satisfied their recommendation that the community re-examine that part of policy. Anomie 13:26, 20 June 2017 (UTC)
I'm not aware of any discussion about "the correct term of low volum [sic] edits", a link would be helpful. Anomie 13:26, 20 June 2017 (UTC)
Anomie For clarity everyone is free to read the ArbCom and see what was actually proposed and what was the conclusion of the discussion. -- Magioladitis (talk) 16:36, 20 June 2017 (UTC)
I'll point out to this old VPR thread" which concluded with pretty much the status quo. At the policy level, genfixes may be allowed, but they are not required. I don't understand what's so hard to get about this. This is getting to a pretty high level of WP:DEADHORSE/WP:IDIDNTHEARTHAT, and right now I'm wondering if a topic ban isn't required.Headbomb {t · c · p · b} 13:50, 20 June 2017 (UTC)

Headbomb you just reported the current status. I claim that this is not enough because this does not constitute a solution. How can I make clearer this for you? We have the following:

  • We want low volume fixes to happen as a general concept
  • We don't want.

Then we have the follow options:

  • Allow bots to make low volume edits
  • Disallow them.
  • Allow them only under circumstances.

Then we have the following problems:

  • People claiming that a if a bot arrives too often to a page it clogs the watchlist
  • People claiming that if a bot arrives only once and does everything the edit is difficult to check.

The last two things are contradicting each other. Second threat that I will get a topic ban for opening the discussion and this is before a start the RfC for the concept and this is before the Bot issue in general reaches the Wikipedia Startegy for the next 15 years. Why is that? Wikipedia has over 5,000,000 pages and how the bots will work in such a big site is a general issue. The current changes in a policy page show that.

-- Magioladitis (talk) 15:45, 20 June 2017 (UTC)

Headbomb This discussion is not a repeat of a question I did some onths ago. Because we can for instance create a superbot to do all in once. Not just "secondary" edits. We could find a way to meerge all major bots and major tools. This was th direction I am working many years now. ow it's time to start the discusion in the community for creating the superbot. But this requires more steps to convience people and the commmunity about it. -- Magioladitis (talk) 15:48, 20 June 2017 (UTC)

Do you have tangible, concrete evidence to back that any of these supposed problems are actually problems? You'll also have to define some of your terms here, because they're certainly not terms I've seen before on Wikipedia. What is a "low volume" fix or "edit"? How do BRFAs somehow fail to make it clear what bot are and are not allowed to do, and under which circumstances they can be done? And yes the last two things contradict each other. Sometimes it can be too warm, sometimes it can be too cold. This doesn't mean I need to choose between a house where I'm cranking up the heat when it's 30°C outside to make sure it's not too cold, or bringing out liquid nitrogen to cool my house when it's –30°C outside to make sure it's not too hot. There is a spectrum of possibilities, and where on the spectrum of "does as much as it can" to "only does one specific thing" a bot's ideal location is depends greatly on the bot's task. Also, I have no idea what that supposed "Wikipedia Strategy for the Next 15 Years" is, but it's certainly nothing I've seen proposed on Wikipedia.
And concerning a "superbot", it again depends on which tasks you want it to do. If you're thinking about making a general fix bot, or a general checkwiki bot, I can see those being supported by the community, provided they abide by WP:BOTPOL and WP:COSMETICBOT/WP:BOTCOMM in particular. This might mean taking on T161467 and T138977, Wikipedia talk:WikiProject Check Wikipedia#Identifying cosmetic fixes, and conducting a similar review for AWB genfixes. Headbomb {t · c · p · b} 15:56, 20 June 2017 (UTC)
I prefer the term "low volume" than "cosmetic" which is also not defined. I am also still waiting evidence that bot edits hide vandalism. The ArbCom case endd and still nobody brought any statistics. -- Magioladitis (talk) 16:11, 20 June 2017 (UTC)
Two things. 1) Don't be surprised if no one can understand you. Cosmetic has a definition and is a term the Wikipedia community has used for ages, "low-volume" is something you made up. 2) no one cares if you are personally convinced this is an issue, and even if the watchlist bug is fixed, it does not invalidate the general idea behind the prohibition of cosmetic edits, since the hiding vandalism concern is only part of the rationale behind the prohibition, not the entire rationale for it. Vandalism isn't even mentioned in WP:COSMETICBOT. Headbomb {t · c · p · b} 16:18, 20 June 2017 (UTC)
"Cosmetic" as definition limits itself to bots as far as I understand since it is only mentioned in the Bots' policy page. -- Magioladitis (talk) 16:34, 20 June 2017 (UTC)
Th same problem of "understanding" holds for others and not only for me since here is a page for general discussion and your comment is far too technical I think. -- Magioladitis (talk) 16:35, 20 June 2017 (UTC)
RexxS, this "Wikipedia Startegy for the next 15 years", is that what we were talking about in the pub on 21 May 2017? --Redrose64 🌹 (talk) 22:49, 20 June 2017 (UTC)
@Redrose64: Yes: meta:Strategy/Wikimedia movement/2017 and the associated pages. --RexxS (talk) 23:01, 20 June 2017 (UTC)
  • This is an obvious non-starter, we don't do "requirements" (as far as forcing people to make certain types of edits), and forcing AWB bot operators (who generally fall on the less experienced side) to add tasks outside their expertise is going to cause more problems than it solves. –xenotalk 17:44, 20 June 2017 (UTC)
  • Comment: I am probably one of the most prolific AWB users on Wikipedia - at least half a million of my edits were made using this tool. I have used AWB for everything from simple typo correction to creating entire series of new articles, but the primary use to which I have put it is disambiguation link fixing. When so doing, it is important to be able to clearly and concisely see, as the editor, all fixes being made with each edit. When a substantial number of cosmetic fixes are included in such a fix, the disambiguation fix can be obscured. This is particularly the case where the cosmetic changes causes a paragraph to shift up, and the entire paragraph is highlighted as changed, obscuring changes within its text. I would note, however, that this can be fixed by improvements to AWB that highlight the noncosmetic changes in some manner that is different from the cosmetic changes. bd2412 T 19:12, 20 June 2017 (UTC)

These comments are really good because they show that clarity of edits is more important than watchlists. -- Magioladitis (talk) 20:03, 20 June 2017 (UTC)

The clarity of edits is ONE aspect, to be balanced against other aspects. Headbomb {t · c · p · b} 20:45, 20 June 2017 (UTC)
Yes, it is important to balance all effects. If watchlist load is a concern, then we must also consider the effect of having to edit the same article multiple times to correct an error that was missed because it was obscured by the volume of automated changes being made to a page. bd2412 T 21:05, 20 June 2017 (UTC)
  • Oppose per my comments at the original discussion from just this week as well as shake my head a bit at the forum shopping. ~ Rob13Talk 00:45, 21 June 2017 (UTC)
What do you oppose exactly? I did not make any concrete proposal yet. I started a discussion before coming with a proposal based on opinions. As you see I presented the various pathways the community could take. Please stop jumping into conclusions and discouraging people from participicating in Wikipedia. -- Magioladitis (talk) 07:40, 21 June 2017 (UTC)
Your thread here is titled "proposal...", and you have stated in the linked discussion " I ask to require bot owners to do more in a signle edit the same way it is required(?) for some valid edits to be done only in addition to other edits."[9]. This seems concrete enough and rather clear about "which" pathway you want the community to take. It is rather disingenious to now state that you have not made a proposal... Fram (talk) 08:02, 21 June 2017 (UTC)
The proposal is not here about the bot. It is about the policy. First we have to examine the policy and then create the bot. So in this page we are now I made no proposal. -- Magioladitis (talk) 08:11, 21 June 2017 (UTC)
I have no idea what you are replying to here. Of course your proposal is about the policy, and all comments and opposes are about your propsal to change the policy. "Create the bot" is not even on the table. It is very hard discussing things with you when what you mean is often completely different to what most other people read in your comments. Fram (talk) 08:25, 21 June 2017 (UTC)
Fram I aam not in favour or against any pathway. I am OK either way as long as ALL the edits are done. If the community for clearness needs the bot to visit the page multiple times I 'll go this direction. -- Magioladitis (talk) 08:14, 21 June 2017 (UTC)
The community seems quite happy with how most bots and operators work, and with the frequency of bot updates to most pages. Some tasks can easily be combined, some tasks should be kept separate for clarity. Bot requests usually deal with this kind of thing, and discussion with bot owners if things get messy or complicated. Only one editor seems to have a real problem with this. So perhaps you should first have a discussion to see if people really see the same problem as you do, and only then try to find solutions? Fram (talk) 08:25, 21 June 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Maybe we should think about this idea from a different perspective for a moment.

I think that, overall, the core community tolerates AWB and bot editors, but does not love them. They're useful, but we're also annoyed by them sometimes, even when we agree that the specific changes are ideal. For example, everyone loves having refs properly filled in, but nobody really loves reading the resulting lengthy diff, especially if these fixes are mixed with a dozen content and/or vandalism edits.

But here's a question: Since these edits are already annoying us, are there any advantages to getting all of the annoyance over with all at once? Or at least getting some slightly more important genfixes (not all of which are cosmetic) over with at the same time? Think of it as sort of a "tax" on using AWB: if you're using AWB to change <ref>Example</ref>. to .<ref>Example</ref>, then maybe you should also have to let AWB remove pointless <ref /> tags at the same time. This is a good edit, even if the diff is long, but what makes me happiest about it is that it fixed two kinds of problems in the same edit – the reference formatting plus a genfix. This means that (a) the page is better now than it was before, especially from the POV of any readers who had previously seen "800" at the end of the line and "mg/day" at the start of the next line, and (b) nobody's going to have to make those genfixes later, which means one fewer diff for the rest of us to look through.

I don't want all of the genfixes done in every edit, but is there any good reason against having all AWB automatically always do a few of them? We'd have to talk about which ones, but why not pick a few that have low potential for problems (here, I am thinking of BD2412's comments about being able to read the diffs, but we would also want to consider the probability of a particular genfix not being wanted in any given edit) and are relatively important for editors and readers (e.g., adding non-breaking spaces)? WhatamIdoing (talk) 21:34, 22 June 2017 (UTC)

WhatamIdoing Yes, this is avery good idea. We should find the golden ratio between readbility of diffs and not making a lot of edits in a single page. Very nice comment. Really appreciated. -- Magioladitis (talk) 21:38, 22 June 2017 (UTC)

@WhatamIdoing: The negative is that I (and many others) who don't like running someone else's buggy code will just stop using AWB and developing bots with it. There are currently zero requirements to do anything on Wikipedia. Editors help out how and where they'd like to. If a requirement is added here, AWB will just see lower use. ~ Rob13Talk 21:47, 22 June 2017 (UTC)
BU Rob13 No need to run the "buggy(???) parts". You can stick in the OK parts of choose which oart you can understand to run. It can even be a combination of two useful tasks you do. -- Magioladitis (talk) 21:55, 22 June 2017 (UTC)
Me, Bgwhite and other we wer co-writing code and we had no problem running "someone else's buggy code" because we were reporting bugs and ficing them in regular basis. We were removing tasks that were controversial and adding new tasks that were useful. -- Magioladitis (talk) 22:00, 22 June 2017 (UTC)
There is some confusion here. Is the proposal to require operators to do something, or to let them choose what they want (which is the current situation)? If it is required, it can't be chosen. If it can be chosen, then it isn't required. So what is the precise proposal - to require something, or not? — Carl (CBM · talk) 21:58, 22 June 2017 (UTC)
Rob, is all the code for genfixes buggy? Or is only some of it buggy, and we could pick only a fraction of the non-buggy parts? WhatamIdoing (talk) 23:54, 22 June 2017 (UTC)
@WhatamIdoing: My concern isn't about specific bugs, although I've seen many and often been met with little urgency when they've been pointed out. The problem is that I don't want to be responsible for someone else's code that I cannot change or fix. When I make any edit on Wikipedia (manual, semi-auto, auto), I take responsibility for that edit. I can be sanctioned based on its contents if it violates policy, such as WP:COSMETICBOT, which has been a major issue with genfixes for quite a while. If AWB screws up and makes a genfixes-only edit when it shouldn't (this is an actual bug that existed in the past, don't know if it was fixed), that's a violation I'm responsible for, even though I have no control over that code. Do you see how that seriously puts off editors from using AWB? Further, it makes it much harder for me to test a bot task or semi-auto task because I have to wade through horrendous diffs with multiple fixes. I don't want to do that nor do I have the time to do that when I'm reviewing a 1,000 edit trial, either as a bot operator or as a BAG member, so I just wouldn't. ~ Rob13Talk 14:15, 23 June 2017 (UTC)

CBM if you read carefully the entire discussion I am exploring the various alternatives we have based on comments like yours and others. I try to initiate a discussion that at the end of the day we will all be happy. I am not coming with ready answers and I don't claim the ultimate truth. I proposed various perspectives and possibilities. Maybe my title is not the best one but it was suppose to only link to a different place at the beginning. -- Magioladitis (talk) 22:03, 22 June 2017 (UTC)

Btw, this is a very good edit. Minor issues fixed in a single edit. -- Magioladitis (talk) 22:05, 22 June 2017 (UTC)
I did read the entire discussion - the title is Proposal for new requirement for AWB bots. What is the requirement you are proposing? Whenever someone asks what the requirement, you seem to indicate there is no requirement. As for my edit, it was not done by a bot, nor by AWB, which removes two significant issues. — Carl (CBM · talk) 22:10, 22 June 2017 (UTC)
"Required" on Wikipedia is more of a continuum than a binary state, for anything except the spam blacklist (which is enforced in software). I expect that if we "required" AWB users to do some fixes, then the rule would change from something like "this huge set of genfixes strictly optional, and you have to get permission in advance via BRFA to use it" to "this small subset of genfixes is strongly encouraged, so if you don't want to do it, then your BRFA application should explain why you don't want to". I don't think that we would actually prohibit people from using AWB if they had a halfway-plausible reason for kicking that can down the road (to the next bot or AWB user). WhatamIdoing (talk) 23:54, 22 June 2017 (UTC)
And if they just silently disable to genfixes in AWB without mentioning it? Your proposal was for "AWB automatically always" to do them, which sounds different from what you just wrote. I think it will be better to leave this discussion for a while until a concrete recommendation is actually made, and the goalposts stop moving with each comment. — Carl (CBM · talk) 00:52, 23 June 2017 (UTC)
I think it's important to try out all the different sizes, shapes, and locations of goalposts in a discussion like this, so that we can find the best arrangement.
If you explicitly agreed (i.e., at BRFA) that you would do an AWB task with Genfixes #392b (or whatever) turned on, and someone noticed that you didn't (and cared enough to mention it), then I think that we'd probably talk about why you did that. Is the script buggy? Did you have problems with it? I imagine that deliberate dishonesty (e.g., "Sure, I said I'd do that, but I never actually intended to do it. I just thought I'd be more likely to get approval if I agreed to help with this") would result in loss of authorization. But I really doubt that would happen. It's been my experience that editors here are very honest. WhatamIdoing (talk) 02:32, 23 June 2017 (UTC)
@WhatamIdoing: To be clear, there is currently zero functionality in AWB to run some genfixes but not others. There exists a module that you can install and manually edit to run only some of the genfixes, but that's not a function in the software (it requires external code), and it's not something I would expect most AWB operators to know how to edit/run. ~ Rob13Talk 14:18, 23 June 2017 (UTC)
Sure, genfixes is a package deal at the moment, but (a) some people have already figured out how to run only some of them, and (b) if this were a desirable direction, then presumably that could be changed. Perhaps AWB users would be given an option in the software that would allow them to choose between "run all the genfixes" or "run only the five genfixes that AWB users have determined are the most important and the least likely to make messy diffs". At the moment, there's no point in creating that code, but if it were wanted, then I think it would be possible to do it. WhatamIdoing (talk) 20:03, 23 June 2017 (UTC)

Is there any way of adding a reference to every paragraph in an article automajically?[edit]

Hi all

I'm working with a new editor who has created a lot of new articles but has unfortunatley forgotten to add inline citations. Is there a way (maybe using AWB?) to quickly add a reference to the end of every paragraph of an article? It would be a different reference for every article.

Thanks

--John Cummings (talk) 15:06, 20 June 2017 (UTC)

No. How would AWB (or any other tool) know which references you want to append? Headbomb {t · c · p · b} 19:35, 20 June 2017 (UTC)
I guess in essence what I want to do is the create a reference, reuse it and then repeat that reuse at the end of every paragraph. Can AWB recognise the end of a paragraph? --John Cummings (talk) 20:10, 20 June 2017 (UTC)
John Cummings How many paragraphs are you talking about? It only takes a couple of seconds to reuse a citation — I would think using AWB would be overkill unless there are dozens of paragraphs not worth the time.--S Philbrick(Talk) 20:32, 20 June 2017 (UTC)

You can just use named references for that.

Paragraph 1.<ref name=REF1>Reference 1</ref>

Paragraph 2.<ref name=REF1/>

Paragraph 3.<ref name=REF1/>

will give

Paragraph 1.[1]

Paragraph 2.[1]

Paragraph 3.[1]

  1. ^ a b c Reference 1

Headbomb {t · c · p · b} 20:52, 20 June 2017 (UTC)

Downloading extract of Infobox data[edit]

Is there an easy way to download in CSV format (or similar format) the names of people and corporations in English Wikipedia? In other words, has someone already extracted the data from the Infobox records? I don't see a way to do this except to download the whole Wikipedia and parse all articles (even articles not about people or corporations).

Minimally the file should have the entity's name or entity type (person or corporation). It would also help to have the birth place because names differ by region.

If such an extract does not already exist, which tools would make this process the easiest?

My reason for asking: the open source probablepeople project parses the names of people and corporations, but it struggles with less popular names. Using Wikipedia data would help test the probablepeople software, and it would train it to better parse names.

I was preferred to WP:VPT from the Help Desk.

AndrewHZ (talk) 17:43, 20 June 2017 (UTC)

You can look at Wikidata:. Ruslik_Zero 20:02, 20 June 2017 (UTC)
Pigsonthewing, one for you I think. --Redrose64 🌹 (talk) 22:56, 20 June 2017 (UTC)
Thank you. Wikidata is certainly the best place to obtain data to solve User:AndrewHZ's need, but if he /must/ have what is in Infoboxes, he can parse one of the Wikipedia:Database downloads. On an article-by-article basis, he can also extract some data using microformats. To disambiguate people with similar names requires more than just birth places; for that, see {{Authority control}} template (and equivalent properties in Wikidata). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 21 June 2017 (UTC)

Archival borked at AHCA[edit]

Can someone fix this ClueBotIII archival error?

Talk:American Health Care Act of 2017/Archives/ 1 should be located at Talk:American Health Care Act of 2017/Archive 1

And whatever error in the autoarchival request template would need to be corrected to account for that

-- 65.94.169.56 (talk) 21:25, 20 June 2017 (UTC)

 Done — Maile (talk) 21:40, 20 June 2017 (UTC)

Nihongo cite template always co-printing with unusual typeset question mark[edit]

When using the Nihongo template for Japanese character typesetting, the text is always co-printed with a unusual question mark always superimposed in the article. See for example Tokyo Story. The infobox and especially the cast section are all co-printed with this unneeded question mark for Japanese characters that appear to be perfectly fine for the entire cast section. This occurs in nearly all Japanese films and does not appear sensible or useful. Can these superimposed question marks be dropped. JohnWickTwo (talk) 12:27, 21 June 2017 (UTC)

The small question mark after Japanese text marked with {{Nihongo}} like in "Shūkichi Hirayama (平山 周吉, Hirayama Shukichi)" is a piped link to Help:Installing Japanese character sets. Some users will see placeholder symbols instead of the Japapanse text. The page cannot determine what users see and only display it to those who don't see the intended Japanese text. Use {{Nihongo4}} to omit it.[10] This is mentioned at Template:Nihongo#See also. PrimeHunter (talk) 13:13, 21 June 2017 (UTC)
That worked well. The Nihongo4 should be the default for the Nihongo family of templates since this affects the dozens and dozens of Cast sections for Japanese films that use this template. JohnWickTwo (talk) 14:47, 21 June 2017 (UTC)
{{Nihongo}} is used in 80330 pages so "dozens and dozens" don't amount to much. Most of the pages probably don't have a list of uses in the same section like a cast list. It seems sensible that the default is to include the link. PrimeHunter (talk) 15:08, 21 June 2017 (UTC)
Seems to me there should be some sort of css/lua magic we could do so only the first instance of the help link on a given page displayed. —Cryptic 18:03, 21 June 2017 (UTC)
I have serious questions about whether that question mark still makes any sense to begin with. Japanese and Simplified Chinese are probably the best supported 'non-standard' scripts out there. This was intended for the days of Windows XP and explorer 6, but you can't even connect to Wikipedia with that anymore, so maybe it's time to shelve those question marks ? —TheDJ (talkcontribs) 08:36, 22 June 2017 (UTC)
Which reminded me that there was actually a discussion on that going on: Template_talk:Nihongo#Remove_the_question_mark.3FTheDJ (talkcontribs) 08:46, 22 June 2017 (UTC)
@TheDJ: That link you just included is really at what appears to be full consensus to remove the question mark as now superfluous. The talk there became stalled in May when the editors went their own ways likely thinking that someone on the discussion team would have done this. There appears to be full consensus there, I am adding my own support for removing it, and perhaps someone like Prime could install it. JohnWickTwo (talk) 13:10, 22 June 2017 (UTC)

Special:LinkSearch[edit]

I have noticed that Special:LinkSearch requires two searches, one with a prefix http:// and one with https://, in order to find all external links to one website. The template {{LinkSummaryLive}} has recently been updated to provide two links to do these two searches. Is there currently a way of finding both http and https links with just one search? If not, is it technically possible to modify Special:LinkSearch to accommodate this? Deli nk (talk) 14:38, 21 June 2017 (UTC)

@Deli nk: It is not currently possible to search for both at once. phab:T14810 is the relevant request to modify Special:LinkSearch. — JJMC89(T·C) 19:22, 21 June 2017 (UTC)
A bit earlier this week there was a similar question at WP:ELN#LinkSearch and https. --Izno (talk) 19:39, 21 June 2017 (UTC)

Parameters in Wikilinks[edit]

I often want to add parameters to wikilinks. The most common use case is for permalinks, eg. Daniel Berrigan?oldid=785863491. Also, occasionally I want to use other parameters such as Daniel Berrigan?action=watch. However, even though both of these links work fine, they are marked as redlinks as if they are for creating new pages. To workaround this issue, some Wikipedia pages end up using full URLs, eg. the links on Wikipedia:Article alerts/Report page footer. However, these are then decorated as if they are external links, even though they are not.

I suppose this is a feature request, but I wonder if there is some way to do this with existing wiki formatting that I don't know about. Sondra.kinsey (talk) 15:00, 21 June 2017 (UTC)

A wikilink to a page name cannot have parameters. Some things can be done with wikilinks to special pages. See Help:Permanent link and Help:Diff#Linking to a diff. We also have many link-producing templates but they don't work in edit summaries or other wikis without the templates. fullurl and friends at mw:Help:Magic words#URL data work in all wikis and accept a query_string but may be difficult to use and also don't work in edit summaries. PrimeHunter (talk) 15:19, 21 June 2017 (UTC)
Many of the url-producing templates in Category:Internal link templates use the method at Wikipedia:Plainlink to avoid the external link icon. PrimeHunter (talk) 15:23, 21 June 2017 (UTC)

Text wrap on right of an mbox[edit]

Hi there. I'm trying to fix the layout at Oakbrook Terrace, Illinois, particularly the two population templates lost way down at the bottom right. You can see my fix at User:Magnolia677/sandbox. Unfortunately, in my fix the demographics section looks wonky because of all the white space at the top. Is there a way to get text to wrap on the right, around a left-aligned mbox? Thanks! Magnolia677 (talk) 22:16, 21 June 2017 (UTC)

I added "float:left" to the mbox style in your sandbox, and I think it gets you what you want. What do you think? – Jonesey95 (talk) 03:31, 22 June 2017 (UTC)
@Jonesey95: I actually poked around first looking for a style guide for this template, but couldn't find anything specific. Thanks for your help! Magnolia677 (talk) 09:22, 22 June 2017 (UTC)
@Magnolia677: Assuming you mean {{mbox}}, the lack of a style guide would be because it's not really intended to be used for content like that. I'll stop short of asserting that the usage is invalid or inappropriate, and just say that it's unusual and not the intended use of the mbox-small-left CSS class (as far as I'm aware). Murph9000 (talk) 11:20, 22 June 2017 (UTC)

Fractions[edit]

Can some people please indicate how they see the following two ways to write down fractions:

  • {{frac|2|1|2}}: 2 12
  • 2{{frac|1|2}}: 212

To me (most recent Firefox on Windows), the first one looks like (2 to the first power) / 2, with the three numbers of roughly equal small size. The second looks like a standard 2 and then a small 1/2. MOS:FRAC prescribes {{frac|2|1|2}}, but (for me) this is much less clear, much harder to interpret when reading an article. Of course, if I am the only one with this problem (or if others get the same result but don't see it as a problem), nothing needs to change. Otherwise, either the frac template or the prescription at MOS:FRAC should be corrected. Fram (talk) 13:48, 22 June 2017 (UTC)

Various displays
@Fram: see image screenshots to the right, the biggest difference I'm seeing is the spacing between the whole number and the fraction component - in all versions. — xaosflux Talk 14:09, 22 June 2017 (UTC)
I think I agree using chrome on win7.
<span class="nowrap">&#8202;</span><span class="frac nowrap">2<span class="visualhide">&nbsp;</span><sup>1</sup>&frasl;<sub>2</sub></span>
2<span class="nowrap">&#8202;</span><span class="frac nowrap"><sup>1</sup>&frasl;<sub>2</sub></span>
It seems to me that the integer is misplaced in the first example and that it should be within the first span tag preceding the hairspace character; like this perhaps:
<span class="nowrap">2&#8202;</span><span class="frac nowrap"><span class="visualhide">&nbsp;</span><sup>1</sup>&frasl;<sub>2</sub></span>
2  12
Trappist the monk (talk) 14:11, 22 June 2017 (UTC)
what Fram sees

Thanks, both of you. I have added a screenshot of what I see as well, so you may get a better idea of why I discuss this. Fram (talk) 14:22, 22 June 2017 (UTC)

Oh, and I use Vector, no css or other fancy scripts, and show math as " MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools)" I have the gadget " Vector classic typography (use only sans-serif in Vector skin)" enabled. I think these are the only ones that might affect this. Fram (talk) 14:26, 22 June 2017 (UTC)

But neither the math setting nor the Vector classic typography one have any effect on this apparently... I'm confused on what might cause this now. Fram (talk) 14:29, 22 June 2017 (UTC)

That top display on yours is defiantly bad - we should try to focus on where that is coming from as it could be reader-impacting. — xaosflux Talk 14:34, 22 June 2017 (UTC)
Clearly part of the problem is that there isn't any space between the integer and the fraction which is why I suggested that the template output is wrong in how it positions the integer. Perhaps the correct output should be this:
<span class="frac nowrap">2&#8202;<span class="visualhide">&nbsp;</span><sup>1</sup>&frasl;<sub>2</sub></span>
2  12
I'm not clear on the purpose of this tag:
<span class="visualhide">&nbsp;</span>
Removing it doesn't seem to change the rendered output for me on chrome:
<span class="frac nowrap">2&#8202;<sup>1</sup>&frasl;<sub>2</sub></span>
2 12
Trappist the monk (talk) 14:44, 22 June 2017 (UTC)
That gives for me the correct result (with a larger 2), so this may be all that needs to be done. But I'll wait for some further reactions to see whether others have the same problem or even better solutions. Fram (talk) 14:54, 22 June 2017 (UTC)
@trappist: Regarding the visualHide tag. It's to force screenreaders to add a 'space' between the two characters. I don't see how the position should influence it. Its just seems correct to me.. Maybe a gadget or something is interfering ? or a browser gadget ? —TheDJ (talkcontribs) 15:10, 22 June 2017 (UTC)
I'm all for accessibility so keeping the visualhide is proper. I don't think that I understand you comment about position. I was not talking about the position of the visualhide tag but was talking about the position of the integer portion of the fraction. In Fram's first example there is no hairspace between the integer and the numerator portion of the fraction. I think that there should be.
Trappist the monk (talk) 15:18, 22 June 2017 (UTC)
@Fram: Does it look the same in this link ? [11] ? How about in a different browser ? —TheDJ (talkcontribs) 15:10, 22 June 2017 (UTC)
@TheDJ: Thanks! In safemode, I get (for the problematic version) now a large 2, then a space, and then the fraction. So you seem to be on the right track here :-) Fram (talk) 07:45, 23 June 2017 (UTC)
@Fram: Then it's either a userscripts/style (which you don't seem to have), a gadget (most likely) or a piece of site wide styling. —TheDJ (talkcontribs) 08:40, 23 June 2017 (UTC)
Ok, thanks. It would be great if someone else had the same problem, that would make it easier to really pinpoint the issue, but until then I seem to be the only one affected so I'll have to live with it (I'm not going to test all combinations of gadgets for something I encounter only sprodaically anyway). Fram (talk) 09:42, 23 June 2017 (UTC)
Some more: I don't get the issue in Chrome (logged in or logged out), but I do get it in Firefox even when I'm logged out. So this would seem to suggest that it is not a gadget, but some Firefox setting / combination with OS or other add-ons on my part. I have very few add-ons installed though, nothing fancy. Anyway, thanks for your time, but unless others have the same problem I thnk it is not useful to spend too long on this. Fram (talk) 09:48, 23 June 2017 (UTC)
  • Why is this not being discussed at Template talk:Frac? There have been several changes over the years concerning spacing and character size, some of them were aimed at improving accessibility (Graham87, are you awake yet?), so let's not compromise the hard work that various people have done in the past. For instance, the visualhide class has been there since this edit three and a half years ago, by Edokter (talk · contribs); WT:Manual of Style/Dates and numbers/Archive 143#Spacing of mixed numbers was contemporary. --Redrose64 🌹 (talk) 20:26, 22 June 2017 (UTC)
    • @Redrose64: Thanks for the ping, but all I've done for the frac template is make the slash usable with screen readers in {{sfrac}}. I'm not sure I can help out any further. Graham87 07:44, 23 June 2017 (UTC)
    • Because a) I wasn't sure the problem was with the template and not some other issue, and b) in my experience you get much better results discussing something like this at VPT than at a template talk page. Fram (talk) 07:46, 23 June 2017 (UTC)

Wikipedia:Administrators'_noticeboard#Proposal_to_topic_ban_Magioladitis_from_COSMETICBOT-related_discussions[edit]

Please comment there. Headbomb {t · c · p · b} 17:59, 22 June 2017 (UTC)

Canmt S&R edit any more[edit]

Right now, I can not edit by "search and replace" any more. -DePiep (talk) 01:05, 23 June 2017 (UTC)

It works for me. Which feature is it about? I use "Enhanced editing toolbar with wizards" at "Help:Edit toolbar", click "Advanced" and then the icon Vector toolbar search-replace button.png at the right. What is your skin and browser? What goes wrong? PrimeHunter (talk) 09:05, 23 June 2017 (UTC)

User:Qwertyytrewqqwerty/DisamAssist.js[edit]

I have the above script installed, but can't seem to access its functions. Nothing changes as far as I can tell on any of the interfaces I use - I also use WP:POPUPS but nothing seems to change there either. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 10:15, 23 June 2017 (UTC)

Zeke, did it ever work for you? When did it stop working? Do you see any warnings or errors in your JS console (ignore various CSS warnings which are most likely from hacks to support badly implemented Microsoft code in old versions of IE)? Murph9000 (talk) 10:20, 23 June 2017 (UTC)
It has never worked for me that I can tell. I certainly have never been able to use it. Using my console's search feature I can find no reference to this script. It has loads upon loads of warnings, though, all for "deprecated" parts of webpages or something and displaying CSS warnings has been disabled. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 10:28, 23 June 2017 (UTC)
Zeke, it looks like User:Qwertyytrewqqwerty "left the building" in February 2014. So, I'd guess the script just isn't compatible with changes made to MW or WP since then. The script on ES-WP has not been updated since then. I suggest removing it from your config, and using a more current tool. Murph9000 (talk) 11:13, 23 June 2017 (UTC)
Might as well. I'm also going to put a note at Wikipedia:User scripts/List next to this one if that's okay. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 11:14, 23 June 2017 (UTC)

Expanding edit box[edit]

This might be the wrong place, but I can't find where else to ask, does anyone how to expand the edit box? It used to be as simple as going into Preferences -> Editing, but it's not there anymore, any help would be appreciated. YellowStahh (talk) 11:33, 23 June 2017 (UTC)

@YellowStahh: You can expand it by dragging the box larger. The drag control may vary depending on your OS & browser, but try dragging the bottom-right corner out. Absolutely no warranty on this next bit, use at your own risk. It could cause you problems if it's ever set too large for the device you are using at the time. If you are not comfortable playing around with CSS stuff, it may not be for you. Try adding something like the following to your common.css, to set the default height:
body.action-edit #wpTextbox1 {
	height: 666px;
}
Murph9000 (talk) 11:48, 23 June 2017 (UTC)
Wikipedia:Village pump (technical)/Archive 153#Edit box size. --Redrose64 🌹 (talk) 11:52, 23 June 2017 (UTC)
Awesome, that's great it looks so much better to view now, thanks very much. YellowStahh (talk) 11:55, 23 June 2017 (UTC)

Another Recent Changes edit filter problem[edit]

I have "Mostly good edits" in green, "May be bad edits" in yellow, "Likely bad edits" in orange, and "Very likely bad edits" in red as my filter setup (I call it "Patrollers' choice" since I like to patrol the recent changes), but it doesn't highlight any of the edits (but it does highlight experienced users' edits in blue, and I didn't tick on either three of them) unless at least any one of the eight checkboxes are ticked. (yes, I'm talking about my setup for both Contribution quality and User intent prediction filters) If the problem is already being discussed at wherever my last discussion about a now-fixed bug was being talked about, you may feel free to move this discussion there too. -- MrHumanPersonGuy (talk) 12:26, 23 June 2017 (UTC)

Edit: I just went back to the Recent Changes thing, and the filter has [sic] highlit edits green, yellow, orange and red (with all eight boxes unchecked) again. -- MrHumanPersonGuy (talk) 20:16, 23 June 2017 (UTC)

Edittools[edit]

I requested a change at MediaWiki talk:Edittools#Protected edit request on 13 June 2017 to reflect recent changes at Help:IPA for English. However, each letter of ɑːr, ɔːr, ɔər, ɜːr has become a separate button as opposed to four buttons as intended. Anyone know how to fix this? Nardog (talk) 12:53, 23 June 2017 (UTC)

Redirection correction software[edit]

Hello everybody,
I'm trying to correct some articles for redirection... So, when I see a link to a redirected article, I try to replace it with the final article (the one leading the redirect), so people know if they opened a page or not (for example, if A person wants to compare several different elements). The question is: Is there a WikiLabs application to allow this or another thing?
--Anas1712 (talk) 16:36, 23 June 2017 (UTC)

(Translated by Google Traduction)

@Anas1712: It's not entirely clear to me exactly what you want to do, or where you want to do it. Please do not indiscriminately "correct" any redirects on English Wikipedia, per WP:NOTBROKEN. They should only be changed if the link via a redirect goes to the wrong target, or there is actually some other error being corrected. If it's on some other wiki where that policy does not apply (and local policies prefer to change them), it could probably be done using pywikibot. Murph9000 (talk) 16:45, 23 June 2017 (UTC)
@Murph9000: What I would do is the modifications that I did this morning and that you undo... It's possible that in other wikis, it's done (personnaly, I edit most in French wiki but there are more infos to read in English wiki). Thank you for saying me that it isn't correct.--Anas1712 (talk) 17:06, 23 June 2017 (UTC) (edit conflict)
P.S.: Is it here the right section to ask the question? Because English Pump is so difficult compare to French Bistrot.
@Anas1712: Other wikis often copy English Wikipedia's policies and guidelines, but each community determines their own policies and their local interpretation of any that they take from us. So, you'll need to check with the local community on each wiki to find out what they prefer. Note that operating a bot to make large scale changes would usually require a proposal, discussion, consensus, and approval (that is required on English WP). Yes, "Village pump (technical)" is usually a reasonable place to ask about tools, or one of the other VP pages if it's not technical / tools. I believe it's roughly equivalent to the French WP's Bistro pages. Murph9000 (talk) 17:19, 23 June 2017 (UTC)
@Murph9000: Oh, on French Wikipedia, you ask to the main page of the bistro and after you get redirected, maybe it's that stupid french "habitude" of being lazy... (I'm Belgian). Here you must choose one section and after you post your message. That's why I don't go so much on the Pump --Anas1712 (talk) 17:28, 23 June 2017 (UTC)