Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 04:06, 3 July 2019

Table of contents
First discussion
End of page
New post

Shortcuts

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.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

RfC: Alteration of Account Creation Limits/Account Creator Rights

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Currently, one of the most backlogged processes is Request an Account (ACC) , which exists mainly (though not entirely) for helping with 3 purposes: Those having trouble completing CAPTCHA; enabling the choosing of a username that is too similar to an existing username under certain circumstances & creating an account for those hindered by a rangeblock.

The current backlog on pending requests is 4 months.

In the last couple of months multiple editors have signed up to be ACC tool users, Tool users are signed up to the confidentiality agreement and meet various other criteria.

Currently here are limits, however, on both their ability to create accounts. Two options could ease their work.

Raise the local account creation rate limit from 4 to 10. The new limit only to extended-confirmed users to prevent any abusive behaviour from IPs.
Automatically grant account creator permission, on request, to new ACC tool users. This would allow them both to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.

Pinging all participants in the local chat discussion: @Ajraddatz, FlightTime, Xaosflux, TheSandDoctor, AfroThundr, QEDK, and Oshwah: Nosebagbear (talk) 13:11, 14 June 2019 (UTC) [reply]

NOTE: Option 2 is broader than Option 1, however they do not completely overlap. Option 1 would allow any EC-confirmed editor to create up to 10 accounts per IP address, option 2 is specifically targeted at ACC-users. Thus participants can !vote for either/both/none of the options.

Survey: Account creator rights

Support for option 1 only. Speaking as an ACC administrator, I believe that automatically granting all new ACC tool users the account creator user right (option 2) would open the door for new tool users to potentially handle requests incorrectly and without limitations before it's caught and identified - which would not be a good thing at all. We need to have a limit for how many accounts that new tool users can create per day by default. When a tool user shows proficiency with handling requests correctly, they can apply for and (after approval by an ACC admin via a comment made to the request) be granted the account creator flag in order to remove those limits. Option 2 would remove the need for an ACC tool administrator to give their approval before an admin can grant the user rights to the requesting user. This approval is still necessary and absolutely needed. Raising the current limit of 4 creations per day to 10 creations per day would loosen the restrictions so that users can help take care of the current backlog of requests at ACC, while still being on a set limit during the time that they're learning and demonstrating their knowledge and proficiency with ACC tool user interface. This option is the best way to resolve the concerns expressed. :-) ~Oshwah~^{(talk) (contribs)} 13:25, 14 June 2019 (UTC)[reply]
Support for option 1; encourage ACC admins to quickly work with new ACC volunteers to get them trained and empowered with additional flags as soon as feasible. — xaosflux ^Talk 13:43, 14 June 2019 (UTC)[reply]
Support option 1 Per above. Also, as all rights on Wikipedia are, it is granted on the basis of need for the right, inherent oppose for point 2. --qedk (t 桜 c) 13:59, 14 June 2019 (UTC)[reply]
Support option 1 as per my comment in the previous discussion. I also agree with Oshwah on automatically granting new users the ACC bit. The current method of granting the right after a couple weeks of activity allows the team to gauge the user's performance and whether or not they have learned the policies and procedures properly. Lowering the barrier further could lead to a problematic user potentially causing a lot more damage (no rate-limit, anti-spoof override, username title blacklist override) than they otherwise could if we had to manually grant those rights. On the other hand, when all is in order, granting them the right is usually quick and painless anyway. — AfroThundr ^{(u · t · c)} 14:04, 14 June 2019 (UTC)[reply]
Support alternate option where an group named Account creation helper is formed, which would contain only the noratelimit right.--Snaevar (talk) 14:38, 14 June 2019 (UTC)[reply]

I appreciate the idea, but I just don't see how this implementation would be useful here, or how it would resolve any issues that the account creator flag wouldn't already resolve. If an ACC admin user can trust an ACC tool user enough to have no account creation limit, that admin user should also trust the tool user enough to be able to correctly and properly handle requests that tripped the antispoof extension and require a flagged user to override (and vice versa). ~Oshwah~^{(talk) (contribs)} 14:45, 14 June 2019 (UTC)[reply]

Support 1. After thinking about this a bit more, I'm not sure if tying the rate limit to extendedconfirmed would be possible. If not, I still think we should raise the limit, but maybe to 6 like it was before instead. The limit was lowered mainly for projects without 300 active local sysops who couldn't instantly respond to mass account creation. -- Ajraddatz (talk) 15:16, 14 June 2019 (UTC)[reply]
Rights like PMR have increased limits for certain flags (in that case, page moves), this would just mean adding a flag like that to EC right holders. --qedk (t 桜 c) 15:23, 14 June 2019 (UTC)[reply]
Yes, most ratelimits are determined on a per-account basis (or per IP for anonymous users). But I seem to remember account creations being different, and being specifically tied to the IP. I assume/hope that a defined higher ratelimit for extendedconfirmed would override that. And no need to tie it to a specific permission; it can be done for the group itself. -- Ajraddatz (talk) 22:58, 14 June 2019 (UTC)[reply]
Yep, but that's a non-issue as far as devs are concerned. Delving into the issue of newer technical changes, from my experience talking to people on SRE/Deployment (and Anomie, TheDJ), technically unfeasible things are pretty rare and I have not seen requests getting turned down (rarely, if ever) with "MediaWiki does not support this", if it's a feature change, or some irreproducible bug, it's a different thing but for example, during the RfC for Template editor rights, a lot of people were worried about the tecnical changes but eventually it was done, with no big deal at all. That's how it is for most new things (and TE rights had a new protection level as well), so I would say a change would be technically feasible until a dev says exactly otherwise. --qedk (t 桜 c) 07:50, 16 June 2019 (UTC)[reply]
With dev time almost anything is possible; my concern would be if the current software doesn't support the change, then we should be looking at easier options like raising the max number to 6 / IP as it used to be. Adding a new protection level is easy to do through the software. Fundamentally changing the account creation throttle might be more difficult. But agreed that we should ask rather than muse about things we know little about :-) -- Ajraddatz (talk) 01:03, 18 June 2019 (UTC)[reply]
(ACC admin comment) I'm pretty sure option 1 isn't possible without development, i.e. it is not a simple configuration change. AFAICT, IP account creation limits can only be set as a count per interval with the noratelimit right being the only way for a user to bypass that limit. (mw:Manual:$wgAccountCreationThrottle) Oppose option 2 for the reasons outlined by Oshwah. Support returning the daily IP limit to 6 unless the Security Team provides a good reason that it needs to remain at 4. — JJMC89 (T·C) 05:50, 15 June 2019 (UTC)[reply]
The Security Team doesn't have a problem with bumping the IP limit from 4 to 6 or even 10, as originally proposed. SBassett (WMF) (talk) 21:32, 21 June 2019 (UTC)[reply]
@SBassett (WMF): thanks for the note, is this really something we need to worry about at a per-project level then? — xaosflux ^Talk 21:52, 21 June 2019 (UTC)[reply]
@Xaosflux: - see my response to JJMC89 starting here: https://phabricator.wikimedia.org/T212667#5274787. SBassett (WMF) (talk) 12:39, 22 June 2019 (UTC)[reply]

@JJMC89:, @Xaosflux: - just following up here, the account creation throttle revert was deployed today. SBassett (WMF) (talk) 21:47, 24 June 2019 (UTC)[reply]
Comment. My preference would be to at least be granted access to the tool. I've waited for a week or so now. :/ –MJL ‐Talk‐^☖ 16:04, 18 June 2019 (UTC)[reply]
Oppose I think 6 is the highest we should go with general limits on account creation per IP. Given that changing IP is rather trivial, the higher we go the greater the risk of abuse. If we raised the limit from 4 to 10, and a bad actor switches from their laptop to their cellular data network when they hit a limit, that is an additional 12 accounts they would be able to create. I think 4 was fine, 6 is okay, but anything higher I am not in favor of. I am not in support of option 2 for the reasons above. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 19:05, 29 June 2019 (UTC)[reply]

Discussion: Account creator rights

@Nosebagbear: regarding your proposed options, and since this is VPT, can you explain the specific technical changes you are proposing - or is this more of a "let some developer figure it out" type of request? Is the "automatic" granting you are asking some sort of technical change you are proposing, or is it a procedural/policy change? — xaosflux ^Talk 13:24, 14 June 2019 (UTC)[reply]
Xaosflux - If option 1 were to reach consensus, it would be corrected by filing a phab ticket to have this done. See phab:T212667. ~Oshwah~^{(talk) (contribs)} 13:27, 14 June 2019 (UTC)[reply]
Thanks. — xaosflux ^Talk 13:29, 14 June 2019 (UTC)[reply]

(edit conflict) @Xaosflux: - changing the rate limit is obviously possible. Whether it can be changed "in bands" to different protection levels is, I'm afraid, I query for those more technically savvy than me. If they say that's impossible (or akin), then this would need to be rethought. Nosebagbear (talk) 13:29, 14 June 2019 (UTC)[reply]
For the problem that is trying to be solved - is overriding anti-spoof the normal resolution, or is getting them to pick a new username? — xaosflux ^Talk 13:25, 14 June 2019 (UTC)[reply]
Xaosflux - For instances where similar usernames exist and are caught by anti-spoof, it depends. See this section of the ACC guide for the policy on when ACC tool users with the account creator flag can override the antispoof flag and proceed with creation. ~Oshwah~^{(talk) (contribs)} 13:30, 14 June 2019 (UTC)[reply]
@Oshwah: thanks, option 1 above won't fix the antispoof ones, is that a significant part of the backlog? Just asking so we don't spend time getting something done that won't help. — xaosflux ^Talk 13:33, 14 June 2019 (UTC)[reply]
Xaosflux - No. Requests that have tripped the anti-spoof extension make approximately 3.5% of all total requests at this time. Of those, users without the account creator flag can still see if the similar accounts are active, and decline the request if any of them are. The only time that a request requires a user with the account creator flag is when a request trips the antispoof extension and the similar accounts are all inactive. This means that the antispoof needs to be overridden, the request approved, and the account created. ~Oshwah~^{(talk) (contribs)} 13:37, 14 June 2019 (UTC)[reply]
Why not grant Wikipedia:Event coordinator to new members of ACC? EVC will give them ability to bypass 4 account limit and it also doesn't allow overriding antispoof/title ban restrictions. ‐‐1997kB (talk) 16:36, 14 June 2019 (UTC)[reply]
1997kB - Not a bad thought, but event coordinators can set new accounts as 'confirmed' using Special:UserRights, which is an ability that they don't need. Essentially, we'd be trading apples and oranges here if the concern is over access to some user rights they shouldn't have. As I said above, I believe that if an ACC admin can trust an ACC user to create accounts with no limit, they should also trust them to properly handle requests that tripped the antispoof extension and require a user with the account creator permissions to override and create (and vice versa). :-) ~Oshwah~^{(talk) (contribs)} 16:42, 14 June 2019 (UTC)[reply]
@Oshwah: - I realise I agree with you, but to run with the Event-Coordinator compromise theory a bit further, it would be clearer cut - the damage possible is pretty tiny. Even if they made every account they created confirmed, it wouldn't cause a great uptick in carnage. Nosebagbear (talk) 22:36, 14 June 2019 (UTC)[reply]
Fair point. ~Oshwah~^{(talk) (contribs)} 02:31, 15 June 2019 (UTC)[reply]

@Oshwah: what is the expected amount of accounts to be created by "new" ACC volunteers per period? (i.e. would 6 or 8 be enough?) since the "rights they don't need" here to ECC users is expected to be way more than is needed by the relatively minuscule ACC team. — xaosflux ^Talk 16:59, 14 June 2019 (UTC)[reply]
Xaosflux - Honestly, any increase from 4 would be beneficial. Even if the increase is just by a few... :-) ~Oshwah~^{(talk) (contribs)} 17:41, 14 June 2019 (UTC)[reply]

New bot

I think we should have a bot or some kind of tool check for accounts which are hitting the account creation limit but do not hold the rights event coordinator, account creator and are also not ACC tool users. The account creation limit was lowered for a reason and increasing it without keeping a check in place would be a gross violation of WP:BEANS imo. Thoughts, @Nosebagbear, JJMC89, Xaosflux, and Oshwah:? --qedk (t 桜 c) 14:19, 14 June 2019 (UTC)[reply]

A recurring database report may be able to solve this for you. — xaosflux ^Talk 14:27, 14 June 2019 (UTC)[reply]

If this is a major issue, the report would have to be run quite frequently, and viewed frequently by patrolling users. Otherwise, this method might not be effective enough at stopping abuse and quickly enough... ~Oshwah~^{(talk) (contribs)} 14:30, 14 June 2019 (UTC)[reply]

(edit conflict) QEDK - Doesn't sound like a bad idea to me. How would this new bot alert others that an account is hitting a limit and isn't within one of those groups? Who would this bot alert? Where? This is something that we should figure out if we're going to consider an idea like this... :-) ~Oshwah~^{(talk) (contribs)} 14:29, 14 June 2019 (UTC)[reply]

It can function the same way AnomieBot handles WP:TPERTABLE, there's no annoying notifications involved and interested people can simply watch the page and report when they find anyone suspect. --qedk (t 桜 c) 14:33, 14 June 2019 (UTC)[reply]

QEDK - Nice... I like it. :-) ~Oshwah~^{(talk) (contribs)} 14:36, 14 June 2019 (UTC)[reply]

Functionally, a bot wouldn't be able to work "that way". Also, bot's wont be able to see "that you got denied by the limit" , but a bot could periodically generate a report of "accounts created per user over some time period" and could either filter out members of certain groups or just report the groups as well. — xaosflux ^Talk 14:38, 14 June 2019 (UTC)[reply]

Why not? The logic is pretty simple, you would need to check creation logs iterating a certain period (maybe an hour) and track accounts which create another account for 24 hours at minimum and more if they somehow meet the limit each day (hence, suspect). Wikipedia accounts which do not have a similarly authorized account in ACC (or the other account creation rights as well) have demonstrably no reason to carry out actions like this, hence red-flagging them almost immediately. --qedk (t 桜 c) 14:49, 14 June 2019 (UTC)[reply]

A bot could create a report, technically it won't be able to tell if you actually got stopped by the limit, just that you hit it or approached it. It wouldn't work "the way" of the protected edit requests in that those don't mine logs, they make use of what links here/category memberships. But the output could still be made. Have a bot periodically (say hourly) ingest the user account creation log and make a report. I think it may even be helpful to have it report on everyone, or everyone with say 3+ creations - and also to identify accounts made by coordinators, etc - so they can be coached as needed. — xaosflux ^Talk 14:54, 14 June 2019 (UTC)[reply]

Yeah, I mean, technically not. But I'm saying it like the logic is clear that an account cannot make more than 10, so an account which makes 10 accounts can be construed to have hit the limit, what's important is identifying if anyone is trying to make a large number of accounts in a short period of time, hitting the actual limit is more of a formality. --qedk (t 桜 c) 15:06, 14 June 2019 (UTC)[reply]

Something like quarry:query/36938? It can't tell if they're an ACC tool user, obviously. If this query is correct, there's not a whole lot of ACC activity going on. — MusikAnimal ^talk 19:46, 14 June 2019 (UTC)[reply]

@MusikAnimal: thanks for the query, even including everyone with 3+ creations over the last whole 10 days (quarry:query/36941). I haven't checked their groups, but the impact here seems to be very small. — xaosflux ^Talk 20:07, 14 June 2019 (UTC)[reply]

Almost all ACC users in that 10+ range, minus the one event coordinator. Unfortunately I won't be appearing in that query anytime soon due to a certain rangeblock with "account creation disabled" set. Really puts a damper on ACC work... — AfroThundr ^{(u · t · c)} 01:51, 15 June 2019 (UTC)[reply]

@AfroThundr3007730: - I thought individual accounts could be exempted from rangeblocks? If so then ACC tool users would be a priority Nosebagbear (talk) 14:32, 15 June 2019 (UTC)[reply]

@AfroThundr3007730: this is a known issue, even effects admins: phab:T189362. — xaosflux ^Talk 15:16, 15 June 2019 (UTC)[reply]

@Nosebagbear: Besides IPBE, I'm not aware of any (current) facility to exempt an individual user from the effects of a rangeblock, at least not the account creation part.

@Xaosflux: - thanks, suspect it was one of those merging of facts I got while swinging around the policy pages. Clearly, I'd made a terrible nerd Nosebagbear (talk)

@Xaosflux: Yep, definitely tracking that one, and if they do get around to implementing it, I would be first in line to request IPBE so I can get back to helping in ACC. — AfroThundr ^{(u · t · c)} 18:37, 15 June 2019 (UTC)[reply]

Could use an abusefilter for this - something along the lines of Special:AbuseFilter/527. Galobtter (pingó mió) 15:33, 15 June 2019 (UTC)[reply]

Event Coordinator Rights

The idea of granting (permanent) Event Co-ordinator rights to any ACC tool user who didn't possess Account Creator rights was mooted as a compromise. The right waives the account creation limit, and also allows accounts to be made confirmed. Obviously the latter isn't needed, but as I noted above, even if a tool-user went rogue, the maximum potential damage is significantly smaller (than the additional rights of Account Creator). It makes a good halfway house between nothing and Account Creator, and if Option 1 turns out to be inviable, then it might be the only way to significantly help with their task. Nosebagbear (talk) 18:46, 17 June 2019 (UTC)[reply]

Oppose The event co-ordinator right will allow the ACC team to grant confirmed right to new users. And the new users will start to create articles in the mainspace, which will cause more damage. Masum Reza^📞 10:20, 29 June 2019 (UTC)[reply]
Oppose We (ACC tool admins) want new ACCers to be rate limited, so that we can easily monitor adherence to the ACC Guide. — JJMC89 (T·C) 17:29, 29 June 2019 (UTC)[reply]

Back to 6 per day

So, the prior "temporary" reduction has been lifted and the setting is back to 6 accounts per day for all projects; that being said is anything really needed now? I think that it is reasonable for volunteers working with the ACC team to get account creator access after a short warm-up/training period - and having the team communicate the plan to new members and getting those swiftly processed (say within a fortnight of actively working with ACC) is a good thing. — xaosflux ^Talk 13:16, 25 June 2019 (UTC)[reply]

I haven't personally noticed any issues with ACC members requesting and getting the bit granted — after they have demonstrated continuous good judgment for a few weeks, that is. I still think it might make sense to raise the limit to 10 for enwiki, being the largest userbase, and with that query and edit filter from above, we can continue to monitor non-ACC users with high creation rates. — AfroThundr ^{(u · t · c)} 15:49, 25 June 2019 (UTC)[reply]

Comments: I am new to this, support account creation, and was appalled at the backlog. A note that 2-3 days may be needed, may take weeks or even months, and a backlog of 4 months seems to point to a possible loss of good editors at worse, those legitimately seeking an account to lose interest or maybe just not actively seeking an account. Maybe I am looking at this wrong but a backlog of 4 months seems to indicate "is anything really needed now?" a strange question. I understand the need to limit account creation abuse and possible vandalism, but if what is in place seems to be a horrible failure then why not an increase to maybe the 10 suggested instead of back to the statue-quo? I haven't looked at this, just read over some of the above, but has there been a problem with "trusted user" abuse to cause the decrease in the first place? Otr500 (talk) 08:55, 29 June 2019 (UTC)[reply]
The backlog doesn't have anything to do with the rate limit. Almost everyone working at ACC has noratelimit (from accountcreator or sysop), so the limit doesn't apply to them. The backlog is from a shortage of volunteers willing to devote time to working at ACC. — JJMC89 (T·C) 17:28, 29 June 2019 (UTC)[reply]
If it's back up to 6, then I don't think further changes are needed. New volunteers can get the accountcreator bit once they have a bit of experience. The biggest issue is number of volunteers. -- Ajraddatz (talk) 01:11, 1 July 2019 (UTC)[reply]

Is Wikiblame broken?

I'm trying to track down changes to Anna Pavlova and am getting no hits at all. Has one of the software changes broken the "find additions and removals" tool? Yngvadottir (talk) 04:19, 19 June 2019 (UTC)[reply]

Yep, seems to be broken. I just tried several searches on a completely different article and they all came up "0 versions found" even though the words are in the article. Softlavender (talk) 06:08, 19 June 2019 (UTC)[reply]

Yep. Tried it just a few minutes ago. We really need it fixed, among other things it let's us find out when copyvio was added. Doug Weller talk 14:55, 19 June 2019 (UTC)[reply]

Have you tried the RevisionSlider feature as an alternative? --Redrose64 🌹 (talk) 19:59, 19 June 2019 (UTC)[reply]

I find that incomprehensible I'm afraid, and it sounds like an exercise in dexterity? I wanted to know when "little toe" entered the article, surely a search function? Yngvadottir (talk) 20:04, 19 June 2019 (UTC)[reply]

It's been reported to the author here: de:Benutzer Diskussion:Flominator/WikiBlame#WIkiblame down? --AntiCompositeNumber (talk) 20:12, 19 June 2019 (UTC)[reply]

Oh good, I couldn't figure out who to report it to. I see my guess was right as to the cause. Yngvadottir (talk) 04:15, 20 June 2019 (UTC)[reply]

It's fixed! About to thank Flominator, although the test revealed a weakness in articles with this much history - it returned the 2010 restoration of the vandal string rather than the 2008 insertion (I searched manually from the start of the history). Yngvadottir (talk) 21:15, 20 June 2019 (UTC)[reply]

@Yngvadottir, AntiCompositeNumber, and Softlavender: it's still not working. Doug Weller talk 05:41, 26 June 2019 (UTC)[reply]

Blast. I needed it again today, got an error message this time, and reckoned it was just temporarily down. See the talk page (discussion is in English), where the maintainer is saying his ISP is giving him grief. Yngvadottir (talk) 05:45, 26 June 2019 (UTC)[reply]

@Yngvadottir, Softlavender, AntiCompositeNumber, and Doug Weller: It's still beta-ish, but XTools now features a Blame tool. See for example [1]. This new tool uses the fantastic WikiWho algorithm, which should be more accurate and much faster than the old blame tool. Feedback appreciated. Best, — MusikAnimal ^talk 20:46, 26 June 2019 (UTC)[reply]

MusikAnimal, Great! Do you think it is stable/reliable enough to switch the links on article history pages? --AntiCompositeNumber (talk) 20:53, 26 June 2019 (UTC)[reply]

@AntiCompositeNumber: Yes I believe so. It's possible there are bugs, but from my testing everything seems to work. It's certainly better than nothing, I hope :) — MusikAnimal ^talk 21:15, 26 June 2019 (UTC)[reply]

Requested: MediaWiki talk:Histlegend#Wikiblame replacement. Nardog (talk) 09:31, 27 June 2019 (UTC)[reply]

I liked the old tool; it was relatively clear what was going on, and I didn't find it slow. I hope we can eventually have both. Yngvadottir (talk) 21:11, 26 June 2019 (UTC)[reply]

@Yngvadottir: I would be curious to know what we can do to improve the XTools version. Are the diff views overkill? Someone else mentioned how the old one would tell you what revisions it was scanning; the thing is the new Blame tool doesn't work in the same way. It does not scan any revisions. The speed should be directly relational only to the size of the article, not how many revisions there are. The algorithm is where it shines most, with reportedly 95% accuracy (of course the XTools may be parsing its results wrong, but I have yet to a find an example where it didn't work). It will also find all relevant diffs, I don't recall if the old one did this. Anyway, not a competition :)

You may also be interested in WhoColor. This allows you to do a "blame" while viewing an article directly within the Wikipedia interface. It does this through a web browser extension. It's a little difficult to set up (though Community Tech has plans to improve this). The other issue is you can't search by wikitext, which is why the XTools Blame tool was created.

Regards, — MusikAnimal ^talk 21:24, 26 June 2019 (UTC)[reply]

I should also mention the WikiWho service only has data on mainspace pages. For this reason XTools' Blame could not be a replacement, but hopefully still a nice compliment to the older tool. — MusikAnimal ^talk 21:32, 26 June 2019 (UTC)[reply]

@MusikAnimal: Thanks, a good blame tool would be wonderful. I tried clicking your example link ([2]) twice. The first time my browser said there was a timeout and nothing was displayed. The second time it showed "Error querying Wikiwho API: Unknown" + "Executed in 30.129 seconds. Taken 2.95 megabytes of memory to execute." Then I tried searching a user page to test what happens if it is not the main namespace and got "500: Internal Server Error" + "cURL error 35: Unknown SSL protocol error in connection to en.wikipedia.org:443 (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)". Questions: If it only searches articles, the starting screen should say that? In a 20,000-foot view, what is going on behind the scenes? If I enter a query, is XTools sending my search to f-squared.org/wikiwho/? Is the user identified? Even if not, isn't there a potential for a privacy breach? Johnuniq (talk) 00:54, 27 June 2019 (UTC)[reply]

@Johnuniq: There are networking issues going on right now with all WMF servers, which would explain the errors you got. You may have noticed the wiki itself being slow to load pages -- this is for the same reason. Check back later and that example link should load in 3-5 seconds, 10 at the most.

XTools sends WikiWho only the page title, and WikiWho sends back the attribution data, and finally XTools performs your search on that. IPs are completely scrubbed for all tools on Cloud Services, but regardless the requests to WikiWho are made server-side so your IP and user agent (by default) wouldn't be forwarded anyway. — MusikAnimal ^talk 01:34, 27 June 2019 (UTC)[reply]

OK, thanks. An article with a lot of history would have a giant amount of attribution data. Very interesting system. Johnuniq (talk) 01:39, 27 June 2019 (UTC)[reply]

The length of the history doesn't actually matter in this case. WikiWho has precomputed attribution data for each "token" of the article (basically each word), and XTools merely loops through that until it matches your search query. This should usually make it very fast, but for very long articles the response payload from WikiWho will be larger and hence take longer to transfer. WikiWho server performance of course is also a factor. This precomputed tokenized system is what separates it from other options (not a claim a superiority, just a different system), and is what makes its content persistence measurements so accurate; e.g. you write a sentence that matches my search query, then someone reverts it, and it gets reverted back again by someone other than you. You'd end up with two diffs that match the query, but WikiWho in theory should attribute it to the original editor who added it. — MusikAnimal ^talk 02:23, 27 June 2019 (UTC)[reply]

Administrator note following an edit request at MediaWiki_talk:Histlegend#Wikiblame_replacement, the xtools version has replaced the broken tool on this history legend. If resolved or if any new issues are caused feel free to revert. — xaosflux ^Talk 20:31, 27 June 2019 (UTC)[reply]
Sigh, I tried it on the Pavlova article and got no results, repeatedly (for "toe", "big toe", "little toes". The vandalism edit replaced "big toes" with "little toes", among many other changes). My experience of Xtools from looking at the contributions pages for editors is that it's down more than it's up. Although I can hardly blame the maintainers when the database is lagged (recently by 7 hours!) I don't find the downtime inspiring. Looks like one tool that worked for me but has now quit working has been replaced with another that may or may not be as useful but has now quit working. Let's have both linked from the history, please, as we do with the two geolocate links on IP contribution pages, so we can at least try the other when whichever we prefer isn't working ... Yngvadottir (talk) 20:51, 27 June 2019 (UTC)[reply]

(Although maybe I should blame the WMF in this instance, since the servers just told me twice that they'd failed to save that last edit.) Yngvadottir (talk) 20:54, 27 June 2019 (UTC)[reply]
@Yngvadottir: Yes, there are all sorts of network issues going on across all of the WMF infrastructure, which would include XTools. I can't speak for the issue with the Pavlova article (I don't see the word "toes" anywhere), but if you give me more information I might can help.

I don't know about the downtime you speak of, either. XTools has had close to 99.9% uptime since the new version launched in 2017. Queries may time out, but this has nothing to do with stability, just that the user or page has too many edits to feasibly get results in a timely fashion.

At any rate, right now is not the time to evaluate the performance or stability of any tool on Cloud Services. Both the WMF networking infrastructure and replica databases are either experiencing severe lag or under maintenance, so you're going to see issues/slowness everywhere. Hopefully everything will be back in working order soon. — MusikAnimal ^talk 22:15, 27 June 2019 (UTC)[reply]
Ah, you meant Anna Pavlova, sorry. I see results for "big toes". I think one issue is you must use complete words as they exist in the article. That is something I can fix and will get to ASAP.

"Little toes" doesn't exist anywhere, but I think you were trying to find the edit that added this, even though it has since been reverted. I think WikiBlame did this because it scans each revision, so it is indeed truly a "Find addition/removal". XTools Blame is just that -- a "blame" tool (tantamount to git blame, where the name comes from). If you want to blame an older version of the article, you need to tell XTools that using the "As of" option at https://xtools.wmflabs.org/blame/en.wikipedia.org. I just went to revision history and found a version that contained "little toes", and here are the results.

I realize now how the XTools Blame tool might be a little confusing, considering people are used to how the old tool worked. "Find addition/removal" isn't really the right name for the link at MediaWiki:Histlegend. "Blame" is accurate, but many people probably don't know what that means. — MusikAnimal ^talk 22:29, 27 June 2019 (UTC)[reply]
Thanks for that sample output. I did find it confusing. In theory it's nice to be able to see both the insertion and the reinsertion, but instead of the vandal edit substituting "little toes" for "big toes" among several other changes, and the subsequent edit reinstating that whole vandalized block of text after someone had removed it (the latter is what the older tool found and stopped at), the XTools tool appears to have given the original insertion of the paragrah with the correct "big toes", followed by the vandalism diff., and omitted the reinsertion of the vandalized paragraph. That is a bit misleading, since the first of the two diffs provided doesn't have the search string in it. (Or if it does I can't see where.) And aside from the reappearance of a 7-hour lag (!), if I understand your point about many revisions/edits, XTools is of fairly little use if it's going to balk at my contributions (what do I have, 35,000? Several editors have hundreds of thousands) and pages like Anna Pavlova with revisions since 2003 or so. Yngvadottir (talk) 04:46, 28 June 2019 (UTC)[reply]

Incorrect Edit Conflicts

I have had a *large* number (almost half my edits) of incorrect "Edit Conflicts" over the last week or so. In these cases, often no one has edited the article in months, but my edit comes up as an edit conflict between the current version and my change. I wasn't seeing this prior to last week. I'm running Google Chrome, though I'm not sure that affects things.Naraht (talk) 15:12, 19 June 2019 (UTC)[reply]

+1 --qedk (t 桜 c) 16:39, 19 June 2019 (UTC)[reply]

Is it possible that you double-clicked the "Publish changes" button, thus sending the save request twice and so edit-conflicting with yourself? One of my old mice was faulty, the left button developed a bounce which caused a number of unwanted double-clicks. --Redrose64 🌹 (talk) 20:02, 19 June 2019 (UTC)[reply]

Naraht, I've seem some, one a minute ago to my own subpage User:Sphilbrick/Fram. Definitely not a conflict. I don't think I double-clicked, but will pay close attention next time S Philbrick (Talk) 12:47, 20 June 2019 (UTC)[reply]

Naraht, And I got another one, while fixing a typo in my past reply. S Philbrick (Talk) 12:49, 20 June 2019 (UTC)[reply]

Happens with me too, occassionally. Some undeniably because of double presses, but I am immediately aware when I do that and this issue occurs even with just one click. Sometimes, just my own diff is shown in the edit conflict resolver. --qedk (t 桜 c) 14:36, 20 June 2019 (UTC)[reply]

Occasionally doesn't surprise me, and getting them <5% of the time it would be reasonable. Getting them *half* the time, OTOH is a bit odder.Naraht (talk) 15:56, 20 June 2019 (UTC)[reply]

Naraht, I'm not sure why <5% would be reasonable. I'm getting them often, not half the time, but probably half a dozen times in the last 24 hours. S Philbrick (Talk) 17:55, 23 June 2019 (UTC)[reply]

Naraht, three more in last couple hours , which is under 50% but well over 5%. Using Google Chrome. S Philbrick (Talk) 20:28, 23 June 2019 (UTC)[reply]

@Naraht, Redrose64, Sphilbrick, and Nyttend: I am still having apparent self-conflicts on edits. I didn't see this so posted below at Wikipedia:Village pump (technical)##Posting issues and see that others also have a possible related issues, See: Wikipedia:Village pump (technical)#Block conflict. I have been hitting edit conflicts and it may happen two or three times in a row or may skip one or two, then happen again. I use Chrome so would like to find a solution if it is involved. I suppose there could be a problem of a somehow contagious finger twitch syndrome but it seems unlikely as I have rarely had false edit conflicts before. A result is that I have to open another tab to check the posting to see if it was in fact a conflict or not. In my case the post will have happened and an attempt to correct it resulted in a double post. Otr500 (talk) 12:57, 29 June 2019 (UTC)[reply]

Note: It showed an edit conflict when posting this but it still posted even showing the conflict. Otr500 (talk) 13:00, 29 June 2019 (UTC)[reply]

Searching for old vandalization in a file

I'd like to know if there is any bot or tool that can help me finding old vandalizing editions in a WP file history. Thanks. --Jotamar (talk) 23:56, 19 June 2019 (UTC)[reply]

When I said WP files, I meant WP pages. Can someone at least tell me, where should I ask my question? --Jotamar (talk) 19:01, 26 June 2019 (UTC)[reply]

Yes, Jotamar, probably WP:BOTREQ, how many edits are you looking for? There will be many millions. Fist step might be to look for edits preceding those with an edit summary of "rvv". Another good place to look is the edits prior to User:ClueBot's edits.

All the best: Rich Farmbrough, 10:49, 28 June 2019 (UTC).[reply]

If you already know specific vandalized text in an article and want the edit which added it then click "Find addition/removal" at the top of the page history. It used WikiBlame until recently but the tool has problems and another is currently used. It's discussed at MediaWiki talk:Histlegend#Wikiblame replacement. PrimeHunter (talk) 11:09, 28 June 2019 (UTC)[reply]

What I have in mind is some sort of heuristic tool, capable of finding a short list of possible vandalazing editions that have not been reverted, in a group of pages, for instance, the pages under one category. In less popular, poorly maintained pages, it's not uncommon that such an edition can be easily reverted even after months or years, but first you have to find them, and that takes up a lot of time. --Jotamar (talk) 13:48, 1 July 2019 (UTC)[reply]

Pending changes

I would like to use this script when reviewing pending changes. However, when I see the pending changes, it only shows the diff, not the article with the changes implemented. Can an editor edit the my script so that it shows both the diff and article with the changes implemented? I don't know how to do it myself so I am asking for help. Interstellarity T 🌟 10:08, 21 June 2019 (UTC)[reply]

Not me, but DannyS712 can.

--qedk (t 桜 c) 19:42, 21 June 2019 (UTC)[reply]

QEDK, Can you find someone else that can do it if DannyS712 can't do it? Interstellarity T 🌟 20:09, 24 June 2019 (UTC)[reply]

Interstellarity, Hi there i have fixed that issue. ___CAPTAIN MEDUSAtalk 13:14, 30 June 2019 (UTC)[reply]

Userscripts Comment

Hi! I've been trying to fiddle with userscripts for a while, but getting nowhere fast. I've tried to edit User:ohconfucius/script/flagcruft to change links to {{ENG}} etc to {{flagicon|ENG}}, or {{flagathlete|[[Person]]|ENG}}. However, I've come to the conclusion my coding is not up to scratch. Is there a good way to do this as a script I can just run in WP? My attempts are at User:Lee Vilenski/script/testing.js. Any help would be appreciated. Best Wishes, Lee Vilenski ^{(talk • contribs)} 17:20, 23 June 2019 (UTC)[reply]

(in theory, not tested) The first replacement (ENG -> flagicon|ENG) should be the easiest (replaces all uppercase 3-letter templates):

regex(/\{\{(\u\u\u\)}\}/g, '{{flagicon|$1}}');

where \u (or equivalent [A-Z]) is a class of uppercase letters.

I may be wrong, but that script (flagcruft) doesn't work - there are no such functions as regex or setreason (checked in console under F12, without installing the script). MarMi wiki (talk) 19:54, 24 June 2019 (UTC)[reply]

JavaScript/Guide/Regular_Expressions MarMi wiki (talk) 20:10, 24 June 2019 (UTC)[reply]

regex is in User:Ohconfucius/test/formatgeneral.js/core.js (User_talk:Ohconfucius/script#regex_is_not_defined). MarMi wiki (talk) 14:21, 25 June 2019 (UTC)[reply]

Why can I edit another user's common.css file?

See User talk:Writ Keeper/Scripts/logoutConfirm.js for background.

I'm able to edit User:Khajidha/common.css, even when logged out (see the two IP edits in that page's history). I thought js and css pages were automatically protected so only the user (or admins) could edit them, per WP:REDLOCK. For example, I can't edit User:RoySmith/common.css when logged out; I get a "View source" tab instead of the "Edit" tab. What's going on here? -- RoySmith (talk) 02:46, 24 June 2019 (UTC)[reply]

I believe the reason for that is that Khajidha created the page as User:Khajidha/common.ccs with the extension spelled wrong and then moved it to the correct place, which meant that the system failed to recognize it as a CSS page (also note that it renders as Wikitext instead of CSS). To fix the problem, an interface admin needs to change to content model of the page. * Pppery * _{it has begun...} 02:49, 24 June 2019 (UTC)[reply]

@Pppery and RoySmith: yes, that is exactly the problem (I wanted to be sure) - the code to protect user css from others is in PermissionManager.php, and it only applies when the page is a isUserCssConfigPage, which is restricted by Title.php to only pages that hasContentModel( CONTENT_MODEL_CSS ) (are actually CSS pages) --DannyS712 (talk) 02:53, 24 June 2019 (UTC)[reply]

Fixed by summoning Oshwah — JJMC89 (T·C) 03:03, 24 June 2019 (UTC)[reply]

Pppery is correct. Upon creating a new page, the MediaWiki software looks at the namespace and the title of the page (in this example, for the '.css' characters at the end) when deciding what content model the page should be set to - and hence what permanent / system protection should be applied as a result. Because Khajidha had initially created the page with the misspelled title User:Khajidha/common.ccs, the MediaWiki software just applied the plain text content model. Moving the page from User:Khajidha/common.ccs to User:Khajidha/common.css does not resolve the issue; the content model must be changed over by an administrator in order to fix it. Another solution to this would've been to just create the page with the correct spelling (User:Khajidha/common.css), then just tag User:Khajidha/common.ccs for U1. Two things obviously come to mind when writing this response:

Does simply changing the content model on any page to be "sanitized CSS", "JavaScript", or "JSON" automatically apply the system protection to the page as if it were a .js, .css, or .json? Or does the MediaWiki software look at the namespace and title's ending before it does so?
The fact that page moves don't automatically go through this check and update the content model if the move changes the title to be a .js, .css, or .json is definitely something that we need to open a new phab ticket about and report / request. If someone in the not-too-distant-future creates a script that becomes highly used by many users, and they accidentally did so by misspelling the title (just like what happened here), and they fix it by moving the page and without making sure that the content model is manually fixed - this is a security hole that's significant and very dangerous. While this should definitely become a phab ticket, we should also verify that the possibility or potential for abuse of the project using this change is low or non-existent (for example, an LTA or vandal renaming a bunch of pages to "VandalismTitle1.js", "VandalismTitle2.js", etc). Okay, after some testing, we found that you cannot call .js files or import scripts using importScript() if the target .js page is set to the "wikitext" content model, which is what happens on all pages that are created that are not code files. This is not an issue. ~Oshwah~^{(talk) (contribs)} 12:21, 29 June 2019 (UTC)[reply]

Additional comments and input would be appreciated here. ~Oshwah~^{(talk) (contribs)} 01:25, 29 June 2019 (UTC)[reply]

@Oshwah: if you try to import a page (e.g. User:Xaosflux/common2.js) that is in the wrong content model (such as that page) it won't work. So that it isn't having protection enforced isn't a major security problem. Let's follow up at WP:IANB if there are other use cases that you want to test out? — xaosflux ^Talk 02:09, 29 June 2019 (UTC)[reply]

Hi Xaosflux! Thank you for looking into this and for responding here. When you mean "import a page", are you referring to attempting to use Special:Import? Or are you referring to something else? I didn't know if you were trying to replicate what I believe might be a major issue, or were simply trying to test something else... let me know. :-) ~Oshwah~^{(talk) (contribs)} 03:59, 29 June 2019 (UTC) I'm an idiot... ~Oshwah~^{(talk) (contribs)} 04:05, 29 June 2019 (UTC)[reply]

@Oshwah: I was just testing this as Xaosflux was responding. See User:Suffusion of Yellow alt 5/common.js, which tried to load the "fake JS" page User:Suffusion of Yellow alt 5/foo.js (before I moved it) in four different ways. All I got were four HTTP 403 responses, and no alert()s. When I moved it to User:Suffusion of Yellow alt 5/monobook.js, it didn't load at all, even though I was using the monobook skin. Suffusion of Yellow (talk) 02:22, 29 June 2019 (UTC)[reply]

Suffusion of Yellow - Ah, okay. So attempting to call that .js file is 403'ing on you? I'm looking at the page logs for foo.js (which is now redirecting to monobook.js due to moving it) and I don't see where the content model has been modified, yet the current content model of your common.js, foo.js, and monobook.js pages are all set to "sanitized CSS" - did someone change that for you? How did you create foo.js? Did you try creating it as "foo something else" (no .js or other ending like that), then moving the page to be "foo.js"? I'm just trying to figure out what you did exactly so that I can follow... Thanks for testing this and for responding with your input and comments. It means a lot. :-) ~Oshwah~^{(talk) (contribs)} 04:05, 29 June 2019 (UTC)[reply]

SoY's monobook.js is not in SCSS, it is in JS as seen here. — xaosflux ^Talk 04:09, 29 June 2019 (UTC)[reply]

@Oshwah: I created it as User:Suffusion of Yellow alt 5/foo.notjs, then moved it twice. The content model shows as wikitext for me. I don't know where you see "sanitized CSS". Suffusion of Yellow (talk) 04:28, 29 June 2019 (UTC)[reply]

Suffusion of Yellow - Oh interesting. What page are you referring to exactly that's currently set to "wikitext"? I might be missing something... lol ~Oshwah~^{(talk) (contribs)} 04:34, 29 June 2019 (UTC) Okkkkkayyy... I just realized that I was using Special:ChangeContentModel to view what the current content model of each page was. That doesn't work... you have to use the "Page information" link to see it. Special:ChangeContentModel's drop-down field option is labeled "New content model", meaning that the drop-down list isn't set to the current model by default, it's just set to the item on the top of the list (which is "Sanitized CSS").... I'm a fool..... ~Oshwah~^{(talk) (contribs)} 04:39, 29 June 2019 (UTC)[reply]

@Oshwah: At [3], under "Page content model", I see "wikitext". Suffusion of Yellow (talk) 04:38, 29 June 2019 (UTC)[reply]

Suffusion of Yellow - I'm a moron. See above. ~Oshwah~^{(talk) (contribs)} 04:41, 29 June 2019 (UTC)[reply]

@Oshwah: perhaps phab:T226914 may help! — xaosflux ^Talk 01:58, 30 June 2019 (UTC)[reply]

Xaosflux - Thank you for creating that enhancement request. :-) ~Oshwah~^{(talk) (contribs)} 07:55, 30 June 2019 (UTC)[reply]

Following up on my talk if you have some experiments you'd like to see. — xaosflux ^Talk 04:08, 29 June 2019 (UTC)[reply]

Posting issues

I have just recently been having an issue: When I hit the preview button to check my edits then hit the publish button I get an edit conflict. When this first happened I treated it as such and it posted twice. After that I have reloaded and see it is already posted by only hitting the preview button. I have never had this issue, that was not a legitimate edit conflict, so am at a lose. Otr500 (talk) 16:09, 24 June 2019 (UTC)[reply]

Note: This has happened 4 times but when I previewed this edit then hit "publish changes" it worked fine. Otr500 (talk) 16:12, 24 June 2019 (UTC)[reply]

Apparently this is an issue only I am having but it is still ongoing. Otr500 (talk) 18:09, 28 June 2019 (UTC)[reply]

Wikipedia:Village_pump_(technical)#Incorrect_Edit_Conflicts related? Galobtter (pingó mió) 18:24, 28 June 2019 (UTC)[reply]

Very possible. Also whatever the issue is (I will have to look) it might be related to Wikipedia:Village pump (technical)#Block conflict that may just be another area where the edit conflict is occurring. Otr500 (talk) 12:19, 29 June 2019 (UTC)[reply]

I'm getting inexplicable edit conflicts today. Doug Weller talk 19:55, 30 June 2019 (UTC)[reply]

And again when I tried to post the above. Doug Weller talk 19:56, 30 June 2019 (UTC)[reply]

Again! Is it groundhog day? When this happens again I own't bother to mention it here. Doug Weller talk 19:57, 30 June 2019 (UTC)[reply]

AVG and Johannes Kepler artilce

Hi all, I had someone approach me off wiki and inform me that AVG is registering the Johannes Kepler article as possible malware. I ran several checks with other anti-virus software and haven't been able to see an issue. AVG said a link on the article registered positive for PDF:UrlMal-inf[Trj]. If anyone technically minded could take a look to see if this is a false positive I'd appreciate it. --Cameron₁₁₅₉₈ ^(Talk) 16:23, 24 June 2019 (UTC)[reply]

Cameron11598, it's even more complicated. The article links to PDFs, and the PDFs contain links towards websites that have been flagged as serving up 'a' virus. Lots of links to check manually with a virus checker... —TheDJ (talk • contribs) 09:14, 25 June 2019 (UTC)[reply]

@TheDJ: Is there a tool or anyway to run a check on those PDFs? --Cameron₁₁₅₉₈ ^(Talk) 15:22, 25 June 2019 (UTC)[reply]

Cameron11598, not that i'm aware of —TheDJ (talk • contribs) 12:44, 27 June 2019 (UTC)[reply]

Which gadget colors redirects green?

I have it enabled, I like it, but I cannot find it in gadgets/etc. as I wanted to recommend it to other editors? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:05, 25 June 2019 (UTC)[reply]

I have it too, set directly in my common.css with a note that I took it from Help:Link color. DMacks (talk) 04:11, 25 June 2019 (UTC)[reply]

@DMacks: I don't think I even have a User:Piotrus/common.css. I have a User:Piotrus/vector.css but I don't think it was doing anything (I just blanked it and I don't see any diff, my redirect links are still green). Nothing in User:Piotrus/vector.js seems related to redirects or colors. Ditto for User:Piotrus/common.js. I thought there was a gadget for it but I can't find it? (I did find and enable the one to "Display links to disambiguation pages in orange", why not). PS. I finally found it, I guess it's this code: meta:User:Piotrus/global.css. Hmmm. Someone should just make a proper tickable gadget for this like with the orange disambigs. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:27, 25 June 2019 (UTC)[reply]

@Piotrus: See User:DannyS712/Gadget-RedirectLinks.css - if you want to propose this as a gadget, I'd support --DannyS712 (talk) 04:31, 25 June 2019 (UTC)[reply]

And, just my 2¢, I use Anomie's script for this and more. Eman 235/talk 05:24, 25 June 2019 (UTC)[reply]

Anomie's script is the one to go with IMO. Headbomb {t · c · p · b} 05:34, 25 June 2019 (UTC)[reply]

WMFLabs 500 error

I am well aware this technically isnt the correct place, however WMFLabs is not working a all - coming up with a code 500 internal error. Thanks Nightfury 11:45, 25 June 2019 (UTC)[reply]

Nightfury, which page(s)? I tried the edit counter and Earwig's copyvio detector just now and both were reachable/functioning. BlackcurrantTea (talk) 12:27, 25 June 2019 (UTC)[reply]

AfD vote stat counter was not working. I'm guessing the issue may have been fixed if it is now working. Nightfury 15:10, 25 June 2019 (UTC)[reply]

Not that it's relevant now but every WMFLabs page (links on ORCP) wouldn't work for me yesterday either, Only lasted 10-20 minutes tho. –Davey2010^Talk 21:25, 26 June 2019 (UTC)[reply]

Issues with alerts, June 2019

Missing notification icons in MonoBook

Tracked in Phabricator
Task T226503

I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)[reply]

I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets:

.oo-ui-icon-bell, .mw-ui-icon-bell:before {
    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook);
    background-image: linear-gradient(transparent,transparent),url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E");
}
.oo-ui-icon-tray, .mw-ui-icon-tray:before {
    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook);
    background-image: linear-gradient(transparent,transparent),url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E");
}

Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word "monobook" becomes "vector" in the first and third url(...) value. --Redrose64 🌹 (talk) 20:21, 25 June 2019 (UTC)[reply]

Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content. Killiondude (talk) 23:42, 25 June 2019 (UTC)[reply]

@Killiondude: Yes, I see the same thing. (Firefox 67, Linux) Suffusion of Yellow (talk) 23:45, 25 June 2019 (UTC)[reply]

Ditto here, IE 11 in Windows. They were missing for a while, but now they've reappeared. I think they're blurrier than before, however. Could someone ping me and thank me for this edit, so I can see whether the number notifications look any different. Nyttend (talk) 23:53, 25 June 2019 (UTC)[reply]

@Nyttend: (ping) Suffusion of Yellow (talk) 00:06, 26 June 2019 (UTC)[reply]

Thank you. Things are somewhat different; the numbers looked normal, but when I clicked each one, it was momentarily surrounded by a little dark box. The same is true if I want to review past notifications and click either of the icons when I have nothing new. Nyttend (talk) 10:51, 26 June 2019 (UTC)[reply]

@Nyttend: You might be right about the extra blurriness, I'm not sure (I took some screenshots a few years ago: c:File:Vpt redrose64 alerts.PNG, c:File:Vpt redrose64 alerts2.PNG, c:File:Vpt redrose64 alerts3.PNG back when the car door was still in place, now replaced by the TV set icon). You're certainly right about the little dark box, it's blue and there are two for each icon, one enclosing the number and the other enclosing the icon.

@Killiondude: The super-wide scroll space was present for me on all pages until about an hour ago, it's now stopped appearing. --Redrose64 🌹 (talk) 13:06, 26 June 2019 (UTC)[reply]

You guys aren't getting the icons? I'm getting only the icons — not the actual pings. On the upside, I get all thanks twice. See below. (Using Monobook.) Bishonen | talk 21:38, 27 June 2019 (UTC).[reply]

@Bishonen: That's because this problem was fixed and the "fix" caused another problem. Try putting my "fix"-to-the-fix from the other thread in your monobook.css, and see if the links work as expected. Suffusion of Yellow (talk) 21:48, 27 June 2019 (UTC)[reply]

I'm sorry, Suffusion of Yellow, I don't see a fix-to-the fix in the other thread (you mean "Someone has broken Thanks", right?), and altogether, you're speaking a foreign language. Could you tell me what to do as if explaining to your mother? Bishonen | talk 21:59, 27 June 2019 (UTC).[reply]

@Bishonen: Sorry, there are too many threads about this right now. Try adding:

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

to your monobook.css. Works for me, at least. Suffusion of Yellow (talk) 22:07, 27 June 2019 (UTC)[reply]

And it worked for me. Thank you very much, Suffusion of Yellow.

Re-pinging Suffusion of Yellow. Bishonen | talk 08:10, 28 June 2019 (UTC).[reply]

Suffusion of Yellow, I've just realized that my problem persists on Meta. Somebody pinged me, to test, and all I got was a three-year-old thanks. Can I put your magic code somewhere to fix that? (And hopefully Commons, Swedish Wikipedia, etc etc — I assume it's everywhere.) Bishonen | talk 19:30, 29 June 2019 (UTC).[reply]

@Bishonen: the problem on meta-wiki, (and most all other projects) should get cleaned up with the next release train. If it doesn't I'll put the hack on meta-wiki. If you need it urgently, you can hack your own monobook.css there (or just click a bit further to the left). — xaosflux ^Talk 19:38, 29 June 2019 (UTC)[reply]

@Bishonen: You can also put ~~the same code~~ in your meta:Special:MyPage/global.css. In theory this could cause display problems if you view some wikis in non-monobook skins, but I just tried in Vector and Timeless and I didn't see any problems. Suffusion of Yellow (talk) 19:42, 29 June 2019 (UTC)[reply]

@Bishonen: Wait, just realized that it's possible to have the fix only apply to monobook. Give me a few minutes to work it out. Suffusion of Yellow (talk) 19:45, 29 June 2019 (UTC)[reply]

@Bishonen: Ok, try putting:

.skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

in your meta:Special:MyPage/global.css. Suffusion of Yellow (talk) 19:54, 29 June 2019 (UTC)[reply]

Suffusion of Yellow, now you're talking my language. It seems to work. Thank you. Bishonen | talk 20:20, 29 June 2019 (UTC).[reply]

Excessive width on monobook

Tracked in Phabricator
Task T226594

So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux ^Talk 03:14, 26 June 2019 (UTC)[reply]

Merged to phab:T226594. — xaosflux ^Talk 03:41, 26 June 2019 (UTC)[reply]

Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on! Lugnuts ^{Fire Walk with Me} 06:54, 26 June 2019 (UTC)[reply]

Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix. —RainFall 07:13, 26 June 2019 (UTC)[reply]

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-indent: 0px !important;
}

Yesterday, when I responded to the thread above ("please ping and thank me"), I looked for this and it wasn't the case, but now it is. Nyttend (talk) 10:53, 26 June 2019 (UTC)[reply]

I've added RainFall's fix temporarily to MediaWiki:Monobook.css after testing locally, revert if any new issues are caused (I tested with both notification types as well). — xaosflux ^Talk 11:58, 26 June 2019 (UTC)[reply]

Does the temporary fix actually work? I've still got the excessive width. DuncanHill (talk) 12:00, 26 June 2019 (UTC)[reply]

@DuncanHill: it took a min to update the central css, try force refreshing a page. — xaosflux ^Talk 12:01, 26 June 2019 (UTC)[reply]

@Xaosflux: Now working, thank you. DuncanHill (talk) 12:05, 26 June 2019 (UTC)[reply]

@Xaosflux: Now, when I click on the "talk" link to the right of the notifications, I get the Special:Notifications popup instead. It looks like the screen-reader text, hidden by color:transparent, is overlapping with the talk link. Suffusion of Yellow (talk) 21:24, 26 June 2019 (UTC)[reply]

@Suffusion of Yellow, DuncanHill, Nyttend, Lugnuts, and RainFall: OK, I reverted the .css in monobook.css, give it a few and see if it fixes that problem (resulting in the original problem) - seems like I'm having to argue with the dev team to get them to understand that the change they made is making the final page worse than before :( — xaosflux ^Talk 21:37, 26 June 2019 (UTC)[reply]

OK Talk is back, but so is super-wide-mode :( — xaosflux ^Talk 21:38, 26 June 2019 (UTC)[reply]

@Xaosflux: Argue with the The Knights Who Say "OOUI!"? Good luck! Suffusion of Yellow (talk) 21:52, 26 June 2019 (UTC) [reply]

I'd like to laugh, but it's so annoying that breaking changes are just rolled out. If WMF want's to deprecate monobook they need to just say it - else stop breaking it.... — xaosflux ^Talk 22:31, 26 June 2019 (UTC)[reply]

"Quick - we need a distraction from Framgate, BREAK THINGS!" DuncanHill (talk) 22:32, 26 June 2019 (UTC)[reply]

please please please, don't feed to conspiracy theorists ... — xaosflux ^Talk 22:41, 26 June 2019 (UTC)[reply]

deprecate monobook: WP:BEANS! Suffusion of Yellow (talk) 22:33, 26 June 2019 (UTC) [reply]

"Deprecate" would be too strong a word, but the end of official support for MonoBook was announced about half a dozen years ago.[4] Whatamidoing (WMF) (talk) 06:31, 27 June 2019 (UTC)[reply]

I suppose I can put that code in my own css file, but I'd prefer that talk page link not to work over the wide screen space. I use trackpad shortcuts to move backward and forward through browser tab history a lot on Wikipedia. Having all the space to the right pretty much disallows moving forward in the history via that shortcut. Killiondude (talk) 22:35, 26 June 2019 (UTC)[reply]

If someone can come up with another hack for it that doesn't break things I'll happily force it back out there. — xaosflux ^Talk 22:42, 26 June 2019 (UTC)[reply]

If somehow this breaks the fundraising banner Seddon (WMF) is working on I bet it will get immediate attention...ijs... — xaosflux ^Talk 22:43, 26 June 2019 (UTC)[reply]

For any of my over-the-top complaining on this, some of it is frustration - but I really would like to thank Catrope for their continuing efforts to resolve this. Last update, the width problem is fixed, but now there is an alignment issue with the areas to click (you have to click a little further to the left then you used to right now) - this is already reported to phab. — xaosflux ^Talk 03:46, 27 June 2019 (UTC)[reply]

Ah, I was wondering about that. I was trying to get to my userpage from the link at the top, and kept getting info about notifications... Risker (talk) 04:16, 27 June 2019 (UTC)[reply]

Related xkcd. The initial "fix" that caused this seems to be very problematic. Can we not revert back and make a proper, tested patch instead of applying these small hacks repeatedly? —RainFall 05:15, 27 June 2019 (UTC)[reply]

Hi all. I don't know if this is related, but I can't click on the link to my talkpage from the very top bar, it always goes to my notifications. This is in Firefox. Lugnuts ^{Fire Walk with Me} 06:29, 27 June 2019 (UTC)[reply]

@Lugnuts: the 'talk link' problem should be fixed now (at least in monobook). If you are still seeing it in monobook can you gather some more details: hover over "log out" and look at what the link would be, then slowly move your mouse to the left (over contribus/wl/pref/ etc..) and see if you get sandbox, then your talk link. If it is out of alignment let us know? The link to the "user page" is somewhat overlapping with notifications (See above) but should work if you approach it from its left edge. — xaosflux ^Talk 14:27, 27 June 2019 (UTC)[reply]

Thanks Xaosflux, that seems to be OK now. Lugnuts ^{Fire Walk with Me} 14:29, 27 June 2019 (UTC)[reply]

I've just noticed that "Notices" now fills up most of the space between "DuncanHill" and "Talk", and "Alerts" partially overlaps "DuncanHill". I don't generally notice them unless I actually have an alert or a notice, as I use the blackscreen gadget and the words "Notices" and "Alerts" helpfully display in black text on a black background. Since these recent changes they have started shewing up in orange (like the other links at the top) but only when I point my mouse at them. DuncanHill (talk) 15:08, 27 June 2019 (UTC)[reply]

@Xaosflux: This fixes all the overlap issues for me, in FF67/Linux:

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

I don't know why; I was just trying things at random. Might be worth trying in some other browsers. Suffusion of Yellow (talk) 21:33, 27 June 2019 (UTC)[reply]

This code fixes all the things for me. :) Before inserting this, I couldn't access "alerts" (the bell) only "notifications" (the inbox icon). Killiondude (talk) 22:00, 27 June 2019 (UTC)[reply]

I noted it at phab:T226594 to see if there will be an upstream fix before we start band-aiding again. — xaosflux ^Talk 22:18, 27 June 2019 (UTC)[reply]

@Suffusion of Yellow: That stops the overlap, but the text stays black when I point at it. Could someone thank and/or/ping me so I can see what it looks like then? Thanks, DuncanHill (talk) 22:24, 27 June 2019 (UTC)[reply]

User:DuncanHill, you annoy.---Sluzzelin talk 22:26, 27 June 2019 (UTC)[reply]

Thanks both, thanks and pings seem to shew up well and be clickable. Someday I'll get around to mentioning the incompatibility with the blackscreen gadget. I have to highlight the notification to read who it's from. But that's been like that for ever. DuncanHill (talk) 22:28, 27 June 2019 (UTC)[reply]

@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference. Suffusion of Yellow (talk) 22:34, 27 June 2019 (UTC)[reply]

Thanks again, have moved it over. Seems to be much the same effect. DuncanHill (talk) 22:40, 27 June 2019 (UTC)[reply]

Message & notification icons in Modern skin

Tracked in Phabricator
Task T226684

The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)[reply]

@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on. — xaosflux ^Talk 14:57, 27 June 2019 (UTC)[reply]

Thanks. Nthep (talk) 15:10, 27 June 2019 (UTC)[reply]

@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me. -— Isarra ༆ 15:55, 1 July 2019 (UTC)[reply]

Someone has broken Thanks

Now when I thank someone, instead of it happening all in the history page, it takes me to another page to ask me if I want to thank them, then to yet another page saying I have thanked them, and leaves me there and not where I was to start with and with no apparent way back. I expect it's an "improvement", but it makes life harder. DuncanHill (talk) 20:53, 27 June 2019 (UTC)[reply]

@DuncanHill: Works normally for me. What you are describing is the expected behavior if you have JavaScript disabled. It is possible that the JS for the "thanks" feature didn't load properly. Try WP:BYPASS, and see if it works again. Suffusion of Yellow (talk) 20:58, 27 June 2019 (UTC)[reply]

Works for me - but the servers were just also having some hiccups, can you try again? — xaosflux ^Talk 20:59, 27 June 2019 (UTC)[reply]

I've been having intermittent weirdness of another type. On "Show preview", I've been getting a message that the servers are busy. If I refresh, it works fine. But the error has repeated numerous times today. I've been wondering if it's the new version of MediaWiki that Tech News mentioned would be on all wikis as of today. — Maile (talk) 21:00, 27 June 2019 (UTC)[reply]

(ec)I went back and in the page history it did not shew me as having thanked the person I had thanked. I tried again, nothing happened, then tried again and it behaved normally. I think there's a log somewhere where I can see if it went through, but can't remember where. DuncanHill (talk) 21:03, 27 June 2019 (UTC)[reply]

Hah! I found the thanks log, it's shewing me as having made the first thanks before I posted here, but not the second when I tried again. DuncanHill (talk) 21:06, 27 June 2019 (UTC)[reply]

This is not about thanks (I think), but I got first one, then two notifications today for apparently nothing. I mean, there's a little red "2" in the usual place, but when I look there's nothing new there. I think the second one may have been for AGK's mention of me here, since it turned up right as I was reading his motion, but I've no idea what the first one is. Anybody know what's going on? If an arb offers a motion to examine my conduct, and has as far as he knows pinged me about it, it would be nice to get that ping. Can I go somewhere to find it? Bishonen | talk 21:20, 27 June 2019 (UTC).[reply]

There's a Thanks log at this link. I don't think there's a ping log. People shouldn't rely on pings as 1) they don't always work at the best of times, 2) it's very rarely the best of times, and 3) I think you can turn notifications off. DuncanHill (talk) 21:26, 27 June 2019 (UTC)[reply]

There was a recent problem with notification (at least in Monobook) see here (look above), but I don't know whether there's a connection. I will henceforth thank and revert and ping users profusely and see how they react. ---Sluzzelin talk 21:27, 27 June 2019 (UTC)[reply]

Duncan, you better stop thanking me, or I will report you to ... ---Sluzzelin talk 21:31, 27 June 2019 (UTC)[reply]

(edit conflict) (edit conflict) (edit conflict) I use Monobook, Sluzzelin, I'm old school. You know what? I just realized that the little notifications digit — the red one — shows the thanks I've got, just like the blue digit does. So, I get thanks twice, and notifications never. Bishonen | talk 21:32, 27 June 2019 (UTC).[reply]

You can get a complete list of current and past notifications at Special:Notifications (which, frustratingly, works much better with javascript disabled). Doesn't help you realize there's new ones there if the main notice is broken, though. —Cryptic 21:57, 27 June 2019 (UTC)[reply]

@Sluzzelin: Wilco! DuncanHill (talk) 21:34, 27 June 2019 (UTC)[reply]

Bishonen, this happened to me (also a Monobook user) when someone replied to me in a topic which was archived in the time between their reply and when I saw the notification. Ever since then, whenever I go to a wiki project for the first time, there's a red number for notifications, even when there are none (because the default preference is to show cross-wiki notifications). On the bright side, I can always tell if it's my first visit to a project. BlackcurrantTea (talk) 07:48, 28 June 2019 (UTC)[reply]

@BlackcurrantTea:, my problem was solved by a kindly techy type in a thread above. I don't know if the same magic would help you, but it's probably worth trying. Bishonen | talk 08:06, 28 June 2019 (UTC)[reply]

Bishonen, thanks for the tip. That doesn't make a difference in my case, but it's not really a problem. BlackcurrantTea (talk) 08:36, 28 June 2019 (UTC)[reply]

Stuck alert/notification

At the top of every Wikipedia page I open are my control tabs: Username, Alerts, Notifications, Talk, Sandbox, Preferences, Beta, Watchlist, Contributions, Log out.

There is a red number over my Alerts tab, and the tab isn't working. When I click on it, it shows all the Notifications, as does the Notifications tab.

I can't get rid of that red number. It has worked fine until today. Help! -- BullRangifer (talk) 03:19, 28 June 2019 (UTC)[reply]

@BullRangifer: do you use Monobook for your skin? If so, see #Excessive width on monobook and specifically the last bit of code given that you can put into your css file to fix what the devs broke in the skin. Killiondude (talk) 03:23, 28 June 2019 (UTC)[reply]

Still a problem. -- BullRangifer (talk) 06:53, 28 June 2019 (UTC)[reply]

@BullRangifer: The problem is that although the bell and TV set icons are still links, their hotspots have shifted to the left by about their own width plus a bit more. So the TV set's hotspot is now where the bell is displayed. Therefore, to activate the bell, you click a little to its left - just over the letters "fer" should do it. --Redrose64 🌹 (talk) 11:05, 28 June 2019 (UTC)[reply]

Several patches for this were worked on and hopefully it will be fixed very soon! — xaosflux ^Talk 11:07, 28 June 2019 (UTC)[reply]

@Redrose64:, you're right! That's exactly what's happened. When will this be fixed? -- BullRangifer (talk) 14:18, 28 June 2019 (UTC)[reply]

@BullRangifer: My "fix" (developed using the tried-and-true XKCD method) should work, but you need to put it in your monobook.css, not your monobook.js. Isarra has submitted a patch which should fix this on all wikis, but it hasn't been reviewed yet and I don't know how long it will take to be merged. Suffusion of Yellow (talk) 17:45, 28 June 2019 (UTC)[reply]

I don't have that subpage, but I'll create it and give it a try there. Thanks. -- BullRangifer (talk) 20:11, 28 June 2019 (UTC)[reply]

That worked instantly! -- BullRangifer (talk) 20:14, 28 June 2019 (UTC)[reply]

I've worked out why the hotspots are overwide and overlapping. Whilst looking at DuncanHill's (unrelated) Blackskin problem with that gadget enabled, I happened to hover over the alerts icons - and behold! the text links "Alerts (1)" or "Notices (1)" become visible. It is those textual items that are invisibly appearing in front of the desired links. So to get the bell's link, you need to be to the left of the "N" of "Notices (1)". --Redrose64 🌹 (talk) 19:12, 28 June 2019 (UTC)[reply]

It'll be actually fixed here by the end of the week, or next week. Probably. Patch is merged; this is just the last place to get fixes when people aren't wildly swatting everything like lemurs. Mmm, lemurs. -— Isarra ༆ 15:50, 1 July 2019 (UTC)[reply]

@Suffusion of Yellow: I'm trying your css hack at testwiki:MainPage, it should be live in a few mins - just as another stopgap until the phab ticket is resolved - feel free to go look for bugs there before it gets promoted locally here. — xaosflux ^Talk 20:19, 28 June 2019 (UTC)[reply]

I'm being over-notified.

Somebody rid me of those dang notifications, which won't go away. GoodDay (talk) 20:49, 28 June 2019 (UTC)[reply]

@GoodDay: Are you using the MonoBook skin? If so, please visit the test wiki, WP:BYPASS your cache, and see if everything works as expected over there. Suffusion of Yellow (talk) 21:08, 28 June 2019 (UTC)[reply]

I went to my All notifications & 'unread' them. It seems to have worked. GoodDay (talk) 22:05, 28 June 2019 (UTC)[reply]

Hack added to monobook.css

I'm adding Suffusion of Yellow's hack to MediaWiki:monobook.css for now - revert if it causes trouble. — xaosflux ^Talk 22:33, 28 June 2019 (UTC)[reply]

Working for me, at least. Suffusion of Yellow (talk) 22:46, 28 June 2019 (UTC)[reply]

Deployment update

Thanks to User:Isarra's efforts on Friday, we now have full fixes for the notification badge issues in the Monobook and Modern skins. About 15 minutes ago (at 23:36 UTC) I deployed the fixes for Monobook, these are now live on all wikis. I didn't deploy the fixes for Modern because those are a little more complicated and that skin isn't used as much as Monobook is. If I get a chance, I may be able to deploy those 24 hours from now, and otherwise they'll come with next week's regular weekly deployment train on Thursday July 11 (there is no train this week due to the July 4th holiday). Thanks to User:Isarra for writing proper fixes for these bugs, and to User:Xaosflux for putting interim fixes in MediaWiki:Monobook.css in the meantime. And, again, my apologies for this disruption; I was the reviewer on the change that broke this, and I should have caught the fact that it changed the badge structure and the main badge CSS but did not update the Monobook CSS to match. --Roan Kattouw (WMF) (talk) 00:02, 3 July 2019 (UTC)[reply]

"Education Program:" and "Education Program talk:" namespaces restored?

Back in 2018, the "Education Program:" and "Education Program talk:" namespaces were removed from the English Wikipedia. However, today, I discovered that they were activated again. I'm trying to figure out if anyone here knows how this happened (or who did it) since it would require technical implementation to accomplish. Steel1943 (talk) 20:25, 25 June 2019 (UTC)[reply]

Because on various wikis there were pages that became unaccessible. So the namespaces (only) were re-enabled (not long after) for wikis to clean them up. Reedy (talk) 20:30, 25 June 2019 (UTC)[reply]

@Steel1943: the talk namespace was restored so that archives could be accessed; there shouldn't be any pages left in the education program namespace (the last one was a cross-namespace redirect that I tagged for deletion a couple months ago) --DannyS712 (talk) 20:30, 25 June 2019 (UTC)[reply]

Correction: The Education Program extension was implemented such that upon its installation all traces of education program pages ceased to exist (even as deleted history). * Pppery * _{it has begun...} 20:33, 25 June 2019 (UTC)[reply]

It's mentioned at Wikipedia:Namespace#Currently unused. PrimeHunter (talk) 20:34, 25 June 2019 (UTC)[reply]

...Thanks all. Yep, turns out the grandeur was on the namespace info page. I guess I got hit with a bit of a shock since I thought its decommissioning was on the permanent. Steel1943 (talk) 20:39, 25 June 2019 (UTC)[reply]

Any objections to adding these namespaces to the titleblack list for creations, as their only new use would be an admin restoring some history? — xaosflux ^Talk 22:12, 25 June 2019 (UTC)[reply]

Added in Special:Diff/903493438 - let me know if any trouble. — xaosflux ^Talk 01:29, 26 June 2019 (UTC)[reply]

Thanks for doing that. I think it's a safe move. Killiondude (talk) 03:39, 26 June 2019 (UTC)[reply]

Note: This was found out through a self-promotional editor creating Education Program:Usamatahir786 (now deleted). Geolodus (talk) 08:41, 26 June 2019 (UTC)[reply]

Block conflict

Yesterday I got into a block conflict with myself at Special:Block/Nemaco. How is this possible? I clicked the block button just once (I'm using mouse buttons on a touchpad and would have heard the button go again if I'd clicked it twice), and there's no indication that anyone else was involved. Nyttend (talk) 21:58, 25 June 2019 (UTC)[reply]

Technical Problem

I am the creator of the page Erich Brauer, but when any onlooker checks the edit history and goes back to the earliest date, the article is listed as being created by User:Mag2k. The reason for this discrepancy is because, before I created the article, User:Mag2k had already made a "Redirect" for a different article, entitled Arik Brauer, and he used the name "Erich" for his redirect. How can I alleviate this problem, and have the article "Erich Brauer" shown in my own list of articles created? The same can be said about the article Beit Shearim, which I created, but because of an earlier re-direct in that name to the article Beit She'arim National Park, the article that I created is listed under the articles created by User:Ynhockey. What can be done to correct this problem?Davidbena (talk) 23:34, 25 June 2019 (UTC)[reply]

I suspect you're not going to love this answer, but this is not worth worrying about. One of the major tenets of wikipedia is that nobody owns articles. Despite the sense of pride you may feel at creating the article, it belongs to all of us. The history is what the history is. Don't sweat it. -- RoySmith (talk) 01:00, 26 June 2019 (UTC)[reply]

You're absolutely right. I'm fine with that. What is in the public domain is in the public domain.Davidbena (talk) 01:11, 26 June 2019 (UTC)[reply]

Agree. Since this is VPT, I can say that yes - there do exist a few very annoying methods to "split" the history of a page using administrator or other tools, but it is both challenging and can make things worse so they would only be done for very special technical or exceptional reasons, and your use case does not rise to that level. — xaosflux ^Talk 01:15, 26 June 2019 (UTC)[reply]

Newline not rendered as space on mobile

I noticed a mobile web editor removed a newline, with the edit summary "Spacing". The newline presumably was to aid readability when editing. The spacing appears as it should on desktop (see previous revision here) but does not appear on mobile (see here). When testing this in my sandbox I also noticed that the spacing for {{hlist}} does not appear on mobile, see 1 and 2. What is causing this? Hrodvarsson (talk) 02:42, 26 June 2019 (UTC)[reply]

From Wikipedia:Manual of Style/Accessibility#Text: Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors. --Redrose64 🌹 (talk) 13:13, 26 June 2019 (UTC)[reply]

I was not referring to the second newline, as it does not create an issue with spacing. For whatever reason the first newline is not rendered as a space on mobile. Hrodvarsson (talk) 02:19, 28 June 2019 (UTC)[reply]

Fundraising Tests

Hey all,

I just want to give you all a heads up that we are getting into that time of year of Fundraising testing in preparation for the end of year fundraiser on the English Wikipedia. These tests will initially be once a week, typically on a Wednesday for a few hours. Later in the year, as we get closer to the fundraiser this might increase to twice a week.

If you have specific ideas to share, please feel invited to add them to our fundraising ideas page.
If you need to report a bug or technical issue, please create a phabricator ticket.
If you see a donor on a talk page, OTRS or social media having difficulties in donating, please refer them to donate@wikimedia.org.

Many thanks Seddon (WMF) (talk) 13:17, 26 June 2019 (UTC)[reply]

Reset the order of a sortable table

Tracked in Phabricator
Task T226697

I've forever found it frustrating that once you've clicked a header on a sortable table, there's no way to bring back the default order other than to reload the page. I wish clicking on a column header for the third time reset the sorting instead of just toggling between ascending and descending. Has this feature been requested? Nardog (talk) 15:39, 26 June 2019 (UTC)[reply]

@Nardog: I don't see it requested in this list; I think what you would want to ask for is to enable "sortReset" in "jquery-tablesorter". — xaosflux ^Talk 16:03, 26 June 2019 (UTC)[reply]

Thanks. So are you saying the option exists, but it's not enabled on MediaWiki (or on this wiki or Wikimedia wikis) as a whole? Nardog (talk) 16:18, 26 June 2019 (UTC)[reply]

@Nardog: a very quick search indicates that it could exist, but is not enabled. I don't think it would be a good idea to try to get it to work for only enwiki, and rolling the function in the main mediawiki core could be the best. I think this is a good demonstration of what you are talking about. — xaosflux ^Talk 16:25, 26 June 2019 (UTC)[reply]

@Xaosflux: Task filed. This is my first time using Phabricator, so please tell me if I did anything wrong. Nardog (talk) 09:06, 27 June 2019 (UTC)[reply]

I would also like a way to reset the sorting. Reload works but many users may not think of that. There was no support at Wikipedia:Village pump (proposals)/Archive 112#Restoring sortable tables initial order. Somebody wrote somewhere else that there is no good way to place a reset button. I think it's too confusing if a third click on a column stops sorting by that column. PrimeHunter (talk) 08:51, 27 June 2019 (UTC)[reply]

Other wikis' icons no longer shown when logging out

Tracked in Phabricator
Task T226736

Screenshot showing the Special:UserLogout screen without interwiki icons.

Previously, logging out of one wiki shows the icons for other wikis that one is also being logged out of. But now the icons have disappeared. Why did they temporarily disappear, and will they re-appear in the near-future? GeoffreyT2000 (talk) 16:39, 26 June 2019 (UTC)[reply]

@GeoffreyT2000: can you be a bit more descriptive? Are you referring to clicking on Special:UserLogout? Logging out should invalidate your global logon session. You could be "logged in" to 100's of wiki's at once - what were you expecting to display? — xaosflux ^Talk 16:44, 26 June 2019 (UTC)[reply]

I have just attempted to reproduce this issue and did not experience it. Is this an issue you are having repeatedly? Have you hard refreshed the page to verify that the images are being downloaded to the page in full? --Izno (talk) 20:13, 26 June 2019 (UTC)[reply]

An image has been uploaded showing the problem. The problem is that I no longer see "Logging you out from other wikis of the Wikimedia Foundation:" or the wiki icons below it. Also, even if I was already logged out, when I visit "Special:UserLogout", the problem still occurs. GeoffreyT2000 (talk) 21:28, 26 June 2019 (UTC)[reply]

@GeoffreyT2000: are you using monobook by chance (you can easily tell if you have a horizontal scroll bar to nowhere right now). — xaosflux ^Talk 22:29, 26 June 2019 (UTC)[reply]

No, I use Vector and the image I uploaded is obviously Vector. When I visit Special:UserLogout and then click the "Submit" button, the icons appear, but not if I click on the "Log out" link next to the "Contributions" link, regardless of the skin. GeoffreyT2000 (talk) 23:01, 26 June 2019 (UTC)[reply]

That is correct. I can also attest that it used to show the icons before. But again, not much of an issue. --qedk (t 桜 c) 06:34, 27 June 2019 (UTC)[reply]

@GeoffreyT2000: In accordance with WP:WPSHOT, please crop out the Wikipedia puzzleball and any other non-essential portions; you might also consider indicating where the missing icons should be appearing. --Redrose64 🌹 (talk) 14:47, 27 June 2019 (UTC)[reply]

Major accidental deletes when editing pages.

Hello, I have been experiencing a peculiar bug. Twice in two days, when I've saved a section source edit where I added my comment starting with colons and ending in four tildes, the page has registered deletions of thousands of characters into my edit history. They are entirety of paragraphs or complete messages from other users. The diffs are here and here. In each case, I used preview and publish. The first time I previewed multiple times before publishing while the second time, it was a straightforward, typing, previewing, publishing. The page had loaded slowly because of low bandwidth in the second instance but I don't think that was the case the first time (don't well remember). I am also quite certain that in the first one, when I first opened the page (the talk page to view, not the edit interface of it), the page that was displayed to me didn't have those s-tags at all which the edit history says I edited out (the most impossible thing to me in all this). I haven't added tools or changed preferences in quite some time but I changed my signature a few days ago (recombining code from multiple signatures I'd come across). Now I am afraid to edit any page with any amount of activity. I don't know if there were any incidents before the first one. I was warned by an admin for that first one, so I was checking back on history every time I published an edit ever since, which is how I caught the second one. I don't even know what kind of information would be helpful here. So, feel free to ask me. Thanks! Usedtobecool ^✉️ ✨ 20:10, 26 June 2019 (UTC)[reply]

@Usedtobecool: It sounds to me like servers aren't recognizing edit conflicts when they should be. See above, for the opposite problem. I have no idea what could be causing this. To start:

What browser/version?
For the first edit, is it possible that you had the edit page open for at least four and half hours before saving? It looks like you were somehow editing an old version of the page. But you say you were section editing, and old revision don't have section editing links.
I see you used the 2017 wikitext editor. For either of those edits, did you switch back and forth between the text editor and VisualEditor? Or were you in wikitext mode the whole time?
Do you have the "Two column edit conflict" feature enabled (under "Beta")? Suffusion of Yellow (talk) 20:37, 26 June 2019 (UTC)[reply]

Suffusion of Yellow, thanks for answering. I apologise for the delay. It couldn't be helped. I am just thankful it's got a reply and isn't yet archived.

Google chrome Version 75.0.3770.100 (Official Build) (32-bit), unless it's been updated in the last three days (in that case, whatever came immediately before.)
It looks 99.99 on that version being the page that was given to me but whichever version was given to me, it was given as the current revision. I went to the page via notification of my mention (could the page have been loaded to the edit version that generated the notification while giving it as the current version?). That edit took me time (first time I wanted to find and use an emoji) but it couldn't be that long, 20 minutes tops. When an edit has been too stale, I copy it to the clipboard and go back to current page and start a fresh edit.
No, I rarely, if ever, use the visual editor (too half-baked IMO). Because of my preferences, I get "edit" and "edit source" options on each section header. I clicked "source edit" from there, clicked preview from the save box and publish from preview.
Yes, I have "automatically enable all beta features". I get edit-conflict window sometimes but haven't found a way to merge edits yet (haven't looked). So, I copy my edits to clipboard, give an ok on whichever edit is suggested to have been in conflict with mine (or just leave the page discarding all my changes) and try again after loading the page fresh.

In the first case, it seems I was editing the page while everyone else was asleep. So, I don't understand how it could have been an edit conflict related bug but I was definitely shown a stale version as the current page. In the second case, it seems the other editor was shown the edit conflict. I am going to be "bold" and continue editing. If it happens again, maybe there will be additional insight there. Thanks for your help! Usedtobecool ^✉️ ✨ 14:57, 28 June 2019 (UTC)[reply]

@Usedtobecool: Sorry, I can't figure this one out. My first theory, after your latest response, was that you clicked on the "view changes" link from your alerts drop-down, which will take you to an old revision. But (1) diff pages don't have section editing links, and (2), that would have taken you to this revision, which is even older than the one you were editing. I also successfully produced edit conflicts in my sandbox, using the same combination (section edits/2017 editor/two-column conflict). Anyone else want to give this one a go? Suffusion of Yellow (talk) 18:37, 28 June 2019 (UTC)[reply]

Thank you very much for trying, Suffusion of Yellow. I'll just wait and see if it happens a third time. And if it does, I'll trying tweaking preferences, adding/removing features/tools, etc. If I find anything interesting, I'll be sure to let you know. Thanks again!Usedtobecool ^✉️ ✨ 19:21, 28 June 2019 (UTC)[reply]

XTools replication lag?

There's quite a bit of replication lag with XTools right now, particularly with TopEdits which right now has a 2 day lag. What happened? Is this related to the recent Cloudflare outage or is this just a coincidence? Narutolovehinata5 ^tccsdnew 00:01, 27 June 2019 (UTC)[reply]

Geez, that might be a new record! The replag refers to the lag between production and the Toolforge replicas. So many other tools are affected, too. See toolforge:replag. I'm fairly certain it has nothing to do with the Cloudflare outage. There's been general slowness with the replicas in general. I will poke some people to see if there's anything that can be done. — MusikAnimal ^talk 00:07, 27 June 2019 (UTC)[reply]

Hmm okay if you keep refreshing at toolforge:replag you'll notice the lag keeps jumping between multiple days and just multiple seconds. Something else is going on (in addition to the general database slowness) — MusikAnimal ^talk 00:09, 27 June 2019 (UTC)[reply]

This is due to being down a host due maintenance (T222978). — JJMC89 (T·C) 05:52, 27 June 2019 (UTC)[reply]

All back to zeroes now. :-) William Avery (talk) 08:38, 28 June 2019 (UTC)[reply]

was en.WP out of service just now?

Hi, there. A moment ago I heard (and verified) that this site (en) was down. Not sure how long was it, 30~50 minutes? Any comments? Thanks. -- SzMithrandir ❈ Ered Luin ❈ 01:26, 27 June 2019 (UTC)[reply]

There was issues for a while, yes. Headbomb {t · c · p · b} 01:35, 27 June 2019 (UTC)[reply]

Site was working fine, I left for an hour, came back and it was fine again, saw this thread. Obviously, my fear that Wikipedia will fall apart without me is not so irrational after all. Someguy1221 (talk) 01:37, 27 June 2019 (UTC)[reply]

Getting frequent and random stalls and errors at the moment, so system problems are still in play. Dl2000 (talk) 03:00, 27 June 2019 (UTC)[reply]

I see. Thank you all for the comments. (o well, my frequency of getting online isn't very suitable for watching out the technical issues). -- SzMithrandir ❈ Ered Luin ❈ 03:25, 28 June 2019 (UTC)[reply]

There's frequent accessibility issues. Per T226685, Marostegui et al are looking. ∯WBG^converse 04:42, 27 June 2019 (UTC)[reply]

I am definitely noticing now, on both toolserver and just cruising the wikis, frequently get database errors, and incompletely loaded pages. The curious thing is, I guess similar to what Dl2000 experienced, it's not slow but stalling. So sometimes pages usually either load without issue or time out. Someguy1221 (talk) 05:07, 27 June 2019 (UTC)[reply]

Purge cache on Wikipedia App (Android)?

How do I "purge" a page using the Wikipedia Android app? The instructions at WP:PURGE seem to apply to the desktop and mobile versions of Wikipedia only, and not the App. My specific problem is that after editing an article my revisions are not showing up and I'm still seeing the "old" version of the article. (And yes, I have disabled the App option called "Prefer offline content.") Muzilon (talk) 09:15, 27 June 2019 (UTC)[reply]

Muzilon, which specific article? (Purging is something that should never be needed. It basically indicates bugs in the software. And how much time between editing and getting the new version, etc etc. —TheDJ (talk • contribs) 12:33, 27 June 2019 (UTC)[reply]

@TheDJ: In this particular case, Gerald Savory. The revised version is displaying correctly on my laptop, but I can't get the App version to "refresh". Muzilon (talk) 12:40, 27 June 2019 (UTC)[reply]

@Muzilon: Well, then you need to clear cache of the application and not purge the page's cache on the server. If you tap and hold on the app icon from your launcher, you'll find an "app info" option, which takes you to another "page" with the option to clear cache of the application. —RainFall 05:48, 28 June 2019 (UTC)[reply]

@RainFall: I'm afraid that doesn't seem to work for me either. My mobile device has an option under Settings > Apps > Wikipedia App > Storage where I can choose an option to both "Clear Data" and "Clear Cache" for the App... but the darn page still won't refresh for me. Muzilon (talk) 06:01, 28 June 2019 (UTC)[reply]

Clearing the app's "app data" is the last resort, which definitely should have worked. I installed the application to see if I can reproduce the issue but unfortunately couldn't. —RainFall 06:10, 28 June 2019 (UTC)[reply]

I even tried uninstalling and reinstalling the App, but that didn't work either. Something is rotten in the state of my mobile phone, it would seem :-/ Muzilon (talk) 06:42, 28 June 2019 (UTC)[reply]

Muzilon, that's weird. I checked the api call and that does also give the updated content.. so it must be something in the web request caching of the Android App in that case. I suggest filing a ticket in phabricator. —TheDJ (talk • contribs) 10:02, 29 June 2019 (UTC)[reply]

Two days later... the revised article has finally "refreshed" itself in the App. But I've noticed this problem before, and there is apparently no option to force the App to refresh/purge an article. Sorry, I am not familiar with Phabricator at all – how/where do I lodge a support ticket? Muzilon (talk) 10:13, 29 June 2019 (UTC)[reply]

Still can't play MIDIs

If I remember correctly, there was no difference between [[File: and [[:File: when it came to MIDI files. Now [[File: links to MIDI files behave differently. But you still can't play them, contrary to what Tech News claimed:

(File:Beethoven Op. 33 no. 1.mid)

With the beta player turned on in Preferences, all that shows is a big cross mark and the text "No compatible source was found for this media." With the old player, nothing shows up, not even a link to the file. This is also the case in the description pages of MIDI files, including on Commons.

Is this something transitory? Can we expect it to work properly soon, or does something need to be fixed? Nardog (talk) 09:59, 27 June 2019 (UTC)[reply]

Nardog, this is because for already existing files, the transcoding will need to be manually initiated right now to generate the files the for the player to playback (Purge the file description page on Commons, then kick of the derivate transcoding at the bottom of the description page). For new midi files it should do that automatically. It's possible to run a maintenance script on the servers to trigger all these, I'll see if we can get something arranged for that. (This is not automatic, as they are very expensive workloads, esp. on 4K video) —TheDJ (talk • contribs) 12:29, 27 June 2019 (UTC)[reply]

@TheDJ: Thanks, that makes sense. I'll purge the files used under Category:Articles with audio generated from MIDI files to facilitate the transition of {{Listen}}, which uses the Score extension to convert MIDIs on site.

Tangentially, would it be able to link to the derived Ogg or MP3 rather than the original MIDI using [[Media:...]] (or {{filepath:...}})? There are ~900 articles linking to MIDIs via {{Audio}} (as opposed to the ~100 using {{Listen}}). (If not, perhaps I shall make {{Audio}} link to the file description page if a MIDI is given.) Nardog (talk) 13:30, 27 June 2019 (UTC)[reply]

Nardog, no you cannot link to derivative files —TheDJ (talk • contribs) 14:21, 27 June 2019 (UTC)[reply]

Nardog, the english wikipedia files have now all been purged. With exception of the other issue with audio/mid you identified, all previously uploaded files should now have their derivatives and be playable. —TheDJ (talk • contribs) 12:12, 28 June 2019 (UTC)[reply]

Meanwhile, this file cannot be transcoded and even the player doesn't show for some reason: File:J S Bach -- Canon per augmentationem contrario motu (dulcimer-piano-harp) (ornam).mid (see also Category:Counterpoint). I thought maybe there was something wrong with the filename, but similarly named files on Commons work just fine. It may be the file that's corrupt, but it seems the Score extension can convert it to Ogg just fine: Canon (music)#Mirror canon. Nardog (talk) 13:52, 27 June 2019 (UTC)[reply]

Nardog, more likely that part of the software change hasn't landed here yet. en.wp get's changes on Thursdays, Commons on Wednesdays. —TheDJ (talk • contribs) 14:25, 27 June 2019 (UTC)[reply]

@TheDJ: I think I found the problem: Some of the MIDI files on this wiki have their MIME type as "audio/mid" as opposed to "audio/midi", and those are the ones that the player does not appear for. Compare Special:Search/file: incategory:"All free media" filemime:"audio/mid" vs. Special:Search/file: incategory:"All free media" filemime:"audio/midi". But I don't know how the MIME types are determined, let alone how to change them. Nardog (talk) 14:46, 27 June 2019 (UTC)[reply]

Nardog, that could well be the problem. I filed T226784 —TheDJ (talk • contribs) 22:56, 27 June 2019 (UTC)[reply]

Nardog, I can play the file okay, but that might be because I have another MIDI player on my browser. Adam9007 (talk) 14:29, 27 June 2019 (UTC)[reply]

Nowrap makes template topicboxes too wide

FYI

– Pointer to relevant discussion elsewhere.

Please see Template talk:Nowrap#Nowrap makes template topicboxes too wide. I don't know what to make of this. --Redrose64 🌹 (talk) 17:43, 27 June 2019 (UTC)[reply]

Help at Template talk:Automatic archive navigator#Arrow issues?

Could someone help with some weird issues involving {{Automatic archive navigator}}'s behaviour? Thanks to those who drop by! Headbomb {t · c · p · b} 22:03, 27 June 2019 (UTC)[reply]

This will involve some LUA shenanigans, btw. Headbomb {t · c · p · b} 22:22, 27 June 2019 (UTC)[reply]

Blackscreen notification problems

There is an issue with the blackscreen gadget whereby notification shew black text on a black background. I raised this here a year ago, it was kicked over to Phabricator, who kicked it back. I have started a new thread at MediaWiki talk:Gadget-Blackskin.css#Notifications problem. The edit notice there suggested announcing it here, so that is what I am doing. Your kind attention would be appreciated. DuncanHill (talk) 23:37, 27 June 2019 (UTC)[reply]

Replied there. --Redrose64 🌹 (talk) 11:00, 28 June 2019 (UTC)[reply]

Filter revisions on page history

Something weird has happened to the view of a page history, there's now a filter revisions box and I don't understand it. Help! DuncanHill (talk) 23:40, 27 June 2019 (UTC)[reply]

It allows you to filter the revisions by date if you click show on it. I for one prefer the old way; it's less fiddly. Graham87 03:35, 28 June 2019 (UTC)[reply]

See Wikipedia:Village pump (technical)/Archive 173#Hideous history page. Graham87 03:40, 28 June 2019 (UTC)[reply]

Is there any way to get the old way back? And I have no idea what the tags are, and it doesn't attempt to explain them. I expect the Foundation will want lots more money this year now it's "improved" it. Sorry, I really can't put up with being fucked around much more. I know it's not your fault chaps. DuncanHill (talk) 14:31, 28 June 2019 (UTC)[reply]

Location access request?

I just opened an article using the mobile web interface, and I got a popup from Chrome asking if I would give permission to Wikipedia to access my device location. See my screenshot where it shows it still wants to know, and Chrome is blocking it. What's going on here? Is it WP:THURSDAY? And can this be disabled ASAP? --rchard2scout (talk) 06:05, 28 June 2019 (UTC)[reply]

@Rchard2scout: In the screenshot, the site isn't necessarily asking for user location. If you deny location permission on a site, the "Location – Blocked" info sticks there throughout the site, including in pages that don't require it. This can be reproduced by denying access to location in the Special:Nearby page. Go to "Site Settings" and reset the location permission and it should be fine. Drink every time I said "location". —RainFall 06:40, 28 June 2019 (UTC)[reply]

RainFall, really ??? never knew this about Chrome for Android.. how annoying is that. —TheDJ (talk • contribs) 07:58, 28 June 2019 (UTC)[reply]

@TheDJ: Isn't this how it works with other browsers? AFAIK, mainstream browsers "block" sites instead of their specific pages, preventing new popups for previously-denied permissions on the same site to show up. —RainFall 08:19, 28 June 2019 (UTC)[reply]

RainFall, for me on Safari it only shows something when the page is requesting info. On Chrome for desktop, there is an icon but again only when the page is requesting the location. On FF, there is an icon that is indeed shown on every page. But still far from being a huge banner. —TheDJ (talk • contribs) 08:56, 28 June 2019 (UTC)[reply]

@TheDJ: https://imgur.com/NiSjnlE (Chrome) Do you see something like this after you deny a permission? Not same as "Location – Blocked", but my point is: browsers manage permissions site-wide. —RainFall 09:19, 28 June 2019 (UTC)[reply]

RainFall, i see it after doing the action on Desktop, but it doesn't stay. It doesn't show that all the time on every single page that is NOT requesting the location. —TheDJ (talk • contribs) 09:26, 28 June 2019 (UTC)[reply]

Oh... kay. We might be using different versions of Chrome. —RainFall 09:29, 28 June 2019 (UTC)[reply]

@RainFall:, Ah, I see, thanks. Just checked again, and yes, the "blocked" stays once one page has requested it and you've denied it (same on desktop, btw). Also, TheDJ, the huge banner in the screenshot only shows when you click the padlock in the address bar, which I did in order to show the issue (because I'd already dismissed the popup).

I'm fine with Special:Nearby requesting location access, my primary concern was that the initial article that I opened this morning (Emma Nutt) should not have asked me for my location. I feared something, somewhere (MediaWiki, template, module, etc), had changed, and now every article would want to know the user's location, which is not something anyone here would endorse. I don't know why it happened this morning, and I can't reproduce it now, on either mobile or desktop. So it's probably just a strange fluke. rchard2scout (talk) 10:46, 28 June 2019 (UTC)[reply]

Yeah, definitely more people would notice if MediaWiki suddenly started harvesting our locations (/s). Also, reading this made me realize TheDJ and I misinterpreted each other. I was referring to the block/allow option that shows up when the padlock is clicked; sorry for the confusion. —RainFall 11:02, 28 June 2019 (UTC)[reply]

RainFall, ha. ok that makes sense :) Still like to figure out which page requested that location.. As far as I know, we only have that functionality in the Special:Nearby, not anywhere else.. —TheDJ (talk • contribs) 12:32, 28 June 2019 (UTC)[reply]

Undo script

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

mobileUndo script is an userscript created for mobile. It basically adds a button to revert the latest revision of an article while previewing a diff on the mobile website. Currently there isn't any undo feature in mobile version of the mediawiki software (as far as I know). It meets the general criteria for gadgets and I have the original creator's permission. Therefore I am proposing this script to be approved as a gadget. Should we approve of this script as a gadget? Masum Reza^📞 12:01, 28 June 2019 (UTC)[reply]

Source code – Here (maintainer's copy, ~~probably outdated~~)

Author – meta:User:FR30799386

Features – mobileUndo#Features

Note – The original creator of this script is blocked on en-wiki for sockpuppeting. But it is possible to reach him on meta-wiki.

Maintainer on en-wiki – User:DannyS712

My statement – I am a regular user of this script and have been using it since January, 2019. I can assure you that it possesses no threat to sensitive data of it's user. This is a very useful script for both editing and counter-vandalism. Making it a gadget will benefit many users editing on on mobile devices.

Questions

A list of questions and answers I believe would be useful.

1 Does it work if just included with no further configuration?: Yes. It works with no further configuration.
2 Is it configurable via personal common.js?: No. The current maintainer and the original script creator can provide more information.
3 Is it compatible with all major browsers in other words, cross-browser compatibility?: Yes. It is compatible with most major browsers on mobile except Opera mini. So far I've tested it's compatibility myself with Mozilla Firefox, Chrome, Chromium and Microsoft Edge.
4 Does it have any duplicates?: No, not on en-wiki except the current maintainer's copy. I've copied the script to my userspace on test wiki and meta wiki for performing tests. I am willing to delete those copies if necessary.
5 Does it require any special permission?: No. It even works with very new accounts. But I think we should not give its access to non-autoconfirmed editors to prevent misuse.
6 Which skins are compatible with this script?: Minerva Neue obviously as this is the only skin available on the mobile website.
7 Does it have cross-wiki compatibility?: Yes it has. I've tested this script myself on meta, wikidata and test wiki.

Discussion

I am willing to answer any questions you may have about this script (please ping me when you reply). Thanks. Masum Reza^📞 12:01, 28 June 2019 (UTC)[reply]

@Masumrezarock100: Noting that I have synced my version with FR's on meta - I plan to make some optimization tweaks, but otherwise it should be good to go --DannyS712 (talk) 15:44, 28 June 2019 (UTC)[reply]

@DannyS712: Thanks Danny. What do you think the suggestion in my answer to the 5th question. Masum Reza^📞 20:48, 28 June 2019 (UTC)[reply]

@Masumrezarock100: That can be set very easily if the script is a gadget (see mw:Extension:Gadgets) - but as just a user script, its harder to implement. I think its fine to leave it as it is, with the understanding that if it is enabled as a gadget it should, like twinkle, require autoconfirmed. --DannyS712 (talk) 20:50, 28 June 2019 (UTC)[reply]

@DannyS712: I see. Since it has cross-wiki compatibility, I highly suggest we make this a global gadget, what do you think? Masum Reza^📞 20:59, 28 June 2019 (UTC)[reply]

@Masumrezarock100: well, I don't think those exist yet. --DannyS712 (talk) 21:06, 28 June 2019 (UTC)[reply]

@Masumrezarock100: Please observe how this RfC is currently listed at WP:RFC/TECH, and include a brief, neutral statement of or question about the issue immediately below the {{rfc}} tag, in accordance with WP:RFCST and WP:RFCBRIEF. --Redrose64 🌹 (talk) 12:08, 29 June 2019 (UTC)[reply]

@Redrose64: Done. I am very new in this RfC stuff. Thanks for pointing out my mistakes.Masum Reza ^📞 12:59, 29 June 2019 (UTC)[reply]

It's now worse, in that nothing is now displayed other than the link. You need a timestamp (if not a full signature) after the statement so that Legobot knows where to stop parsing: WP:RFCST does state "Failing to provide a time and date will cause Legobot to remove your discussion from the pages that notify interested editors of RfCs." and that is precisely what has happened here. At the moment, the first timestamp that it encounters is the one at the start of this "Discussion" subthread, by which time the statement is no longer neutral and certainly not brief. --Redrose64 🌹 (talk) 13:33, 29 June 2019 (UTC)[reply]

User survey

Please state your vote using '''Support'' or '''Oppose'''. Explain why if you choose the latter option. Masum Reza^📞 05:07, 29 June 2019 (UTC)[reply]

I'm a bit baffled by your second sentence. By nature of this being an addition, the onus is on the supporters to explain why it should be added. However, in discussions like these, explanations from both sides would be useful to all. Killiondude (talk) 19:53, 29 June 2019 (UTC)[reply]

I meant that one must add a reason if they oppose it. Explanation from Support side is helpful as well but I am not explicitly asking them to state their reason. Masum Reza^📞 22:15, 29 June 2019 (UTC)[reply]

To support: say "aye"; to oppose: rehash the Bible. —RainFall 08:07, 1 July 2019 (UTC)[reply]

Would like a small change to my watchlist

Would anyone happen to know the right CSS code to put the (diff|hist) links in my watchlist to the left of the article title (as in user contributions) rather than on the right? I would very much prefer them to all be lined up rather than wherever the title happens to end. I tried figuring this out myself but CSS is not my thing. I swear it used to be that way, but I'm not sure. Thanks. Someguy1221 (talk) 23:01, 28 June 2019 (UTC)[reply]

@Someguy1221: I saw a similar inexplicable change in my watchlist a couple of weeks back and resolved it by unchecking "Group changes by page in recent changes and watchlist" at Preferences->Recent Changes. Worth a try. Abecedare (talk) 02:21, 29 June 2019 (UTC)[reply]

It can't be done purely in CSS, which cannot rearrange the order of presentation. --Redrose64 🌹 (talk) 12:10, 29 June 2019 (UTC)[reply]

Androit

How can I create a new article using Androit?Nedim Ardoğa (talk) 12:09, 29 June 2019 (UTC)[reply]

@Nedim Ardoğa: This is really a WP:HD matter. --Redrose64 🌹 (talk) 12:11, 29 June 2019 (UTC)[reply]

@Nedim Ardoğa: I guess you mean Android (operating system). Assuming you use a browser and not a Wikipedia app, the key thing is not the operating system but whether you use the mobile or desktop interface to Wikipedia. In the mobile interface you can for example use the second box at Wikipedia:Your first article. Or you can click "Desktop" at the bottom of a mobile page to get the desktop interface you may know better. PrimeHunter (talk) 17:46, 29 June 2019 (UTC)[reply]

Remove fbclid=... from all links

Hi all,

I happened to notice that hundreds of links in hundreds of articles include fbclid=longstringofrandomlookingletters parameters. According to what I read, Facebook adds these to track users' browsing behavior. It works like this:

Let's assume I discover something on www.example.com/cooltopic.html and share this URL with a friend on Facebook: "HEY CHEK THIS OUT!!!!!!!11"
Facebook automatically adds a unique FaceBook CLick ID (fbclid) to every link that is passed through them by adding &fbclid=... or ?fbclid=... to it. This doesn't change the destination of the link i.e. the URL still works the same.
The friend decides to add my URL as a reference/link to Wikipedia. Except, now the URL will read www.example.com/cooltopic.html?fbclid=xyz123.
Thanks to their Click ID Facebook can now track the URL: If the link is emailed to a 3rd person, who sends it to a 4th via Whatsapp, Facebook recognizes the (modified) link as the one I originally shared with my friend, thus gathering data about which persons are communicating with whom.
If the destination site of the link (example.com) has added a like-button to their page then Facebook even gets notified whenever anyone follows the link, i.e. they will know exactly which visits to www.example.com are a consequence of my original communication with my friend. (They use this to find out who is a valuable influencer.)

Long story short, IMHO all fbclid=... should be deleted from all (current and future) references and links on Wikipedia, because

Facebook has no business tracking Wikipedia contributors or readers.
The huge fbclid=... strings make references harder to read and edit.
The fact that an Wikipedia article's reference's URL was passed through Facebook's infrastructure earlier is not relevant to the topic the article covers, so this information need not be preserved.
The links work just the same after deleting the fbclid parameter.

So it would be great if some Wikipedia wizard could program and unleash a bot for this? Please?? Supposedly there are also Google Click IDs and others, however I haven't found their 'additions' in links. Maybe there is already a bot in place filtering them out? Then this bot would just need a little expanding.

I hope this is the right place to ask. Someone at the Teahouse was kind enough to point me here.

Thanks and regards, Jens (84.173.225.148 (talk) 20:27, 30 June 2019 (UTC))[reply]

I believe there's a bot that's removing them already, though in a gradual way as there's no immediate harm while they're here. I think the bot is also removing them not only from Facebook's URLs but similar ones from Amazon.com and the like. – Ammarpad (talk) 20:35, 30 June 2019 (UTC)[reply]

Yup, Wikipedia:Bots/Requests for approval/KolbertBot 4 was approved for this, but may be stalled/paused right now. User:Jon Kolbert is the operator, who may have more information. — xaosflux ^Talk 20:39, 30 June 2019 (UTC)[reply]

Template:Cite web#URL says "Remove tracking parameters from URLs". insource:fbclid currently gives me 1720 results in articles. The normal place for a request would be Wikipedia:Bot requests. PrimeHunter (talk) 20:42, 30 June 2019 (UTC)[reply]

(edit conflict) Hi Jens, looks like User:KolbertBot per Wikipedia:Bots/Requests for approval/KolbertBot 4 should be removing it, but the bot isn't running; ping Jon Kolbert. Galobtter (pingó mió) 20:44, 30 June 2019 (UTC)[reply]

I'll talk to him. Many thanks to all of you. --Jens (84.173.225.148 (talk) 21:14, 30 June 2019 (UTC))[reply]

Jens, thank you for bringing this to our attention! While we wait for him, I have begun (slowly) manually removing a lot of these trackers, if anyone wants to help, please do! TheAwesome Hwyh 22:59, 30 June 2019 (UTC)[reply]

There are 1700 pages, many of which will have several affected links (the article where this issue came to my attention has 8 of them). While I admire your diligence, I do think it's best to let the bot handle this. Please consider that doing such tedious work manually is very error-prone, if you accidentally remove a bit too little or too much the link won't work any more. Best regards, Jens (84.173.225.148 (talk) 23:54, 30 June 2019 (UTC))[reply]

Ah- I'm not planning on doing them all, just however many I can get to today (also, I check all the links before I upload), but yeah this is definitely something that's best suited for a bot once that gets running again. TheAwesome Hwyh 00:07, 1 July 2019 (UTC)[reply]

Hi there, I have been very occupied with a lot of other things - but I will make sure this task runs :-). Thanks for the note Jon Kolbert (talk) 18:14, 2 July 2019 (UTC)[reply]

"Show preview" toolbar needs to be above the edit summary in the wikitext editing window

Or there needs to be a setting in preferences to allow this. Scrolling is a pain. Half the page has to be scrolled to click the "show preview" button.

Weird thing is that the edit window here does not have the "Edit summary (Briefly describe your changes)" toolbar. It only has the "common edit summaries" toolbar.

So look at an article edit window, or an article talk page edit window. -- Timeshifter (talk) 08:34, 1 July 2019 (UTC)[reply]

If you begin editing by using the "new section" tab, then no, you don't get an edit summary window. Instead, a standard edit summary is constructed for you, consisting of the name of the new section wrapped in /* ... */ markers plus the words "new section". The edit summary window only appears when editing an existing section, or the whole page. --Redrose64 🌹 (talk) 16:25, 1 July 2019 (UTC)[reply]

Thanks, Redrose64. I see now. -- Timeshifter (talk) 08:42, 2 July 2019 (UTC)[reply]

Edit window length is not remembered

A related problem is that the wikitext edit window length is not remembered. I can drag it up or down in length. But when I open another article or talk page, and then open an edit window, it is back to being a very lengthy edit window.

This exacerbates the previous problem of the "Publish changes" toolbar being separated by almost half a page of edit summary and terms of use stuff.

Lots of scrolling to do multiple previews. I am using Firefox on a 21-inch LCD monitor. --Timeshifter (talk) 08:24, 1 July 2019 (UTC)[reply]

This in your CSS sets the edit box height:

textarea {height:15em}

User:Js/ajaxPreview#Installation adds a small preview button above the edit box. It makes other changes. PrimeHunter (talk) 09:59, 1 July 2019 (UTC)[reply]

Or you can use alt+shift+p to preview. Galobtter (pingó mió) 10:14, 1 July 2019 (UTC)[reply]

Thanks, PrimeHunter. I installed both, and they both work great. They both should be preferences. -- Timeshifter (talk) 08:38, 2 July 2019 (UTC)[reply]

@Timeshifter: It has previously been suggested (see e.g. this thread)) that a setting such as the above rule textarea {height:15em} should be made a user pref. Unfortunately, this is not feasible since a value of 15em is not suitable for every user - we do not know how high anybody else's screen is. --Redrose64 🌹 (talk) 18:30, 2 July 2019 (UTC)[reply]

@Redrose64: Thanks. I see from that old thread that it was possible in the past to choose the size of the textarea. I vaguely remember that this existed at one time. You wrote in that old thread: "Each pref removed marginally improves page load time for logged-in users." Is it only prefs that are changed from default settings that effect page load time? If so, then the more preferences the better.

There should be a way to open up and activate a whole new set of preferences. That way newbs could start with a manageable set of preferences. Then over time, if desired, then people could look at other preferences. Without having to paste stuff into CSS and JS pages. People could make their own decision as to whether the marginal loss of page load speed was made up for by the improvements provided by the additional preferences. -- Timeshifter (talk) 02:53, 3 July 2019 (UTC)[reply]

Why can't I enable the 2010 editing toolbar along with the 2006 editing toolbar?

I would like to have both toolbars. Please make this possible. See: Wikipedia:Legacy toolbar.

See: Special:Preferences#mw-prefsection-editing. There one can enable this:

Enable the editing toolbar. This is sometimes called the '2010 wikitext editor'.

I can't enable it because I have the 2006 editing toolbar (plus extensions) enabled:

I have the following 3 gadgets enabled in the editing section of gadget preferences:

Enable the legacy (2006) editing toolbar. This will be overridden by the "Enable the editing toolbar" option in the Editing tab.
refToolbar: add a "cite" button to the editing toolbar for quick addition of commonly used citation templates
Add extra buttons to the old (non-enhanced) editing toolbar

They just add more buttons to the 2006 editing toolbar. -- Timeshifter (talk) 09:36, 1 July 2019 (UTC)[reply]

Anybody? Is this technically feasible? -- Timeshifter (talk) 02:56, 3 July 2019 (UTC)[reply]

RefList falling in the wrong place

I need help getting a reflist to fall at the bottom of the article. It is falling between 2 tables. [[5]]

I would like to understand why this happening so I can fix it myself in the future.

Thank you. Lore E. Mariano (talk) 14:02, 1 July 2019 (UTC)[reply]

Fixed by [6]. PrimeHunter (talk) 14:10, 1 July 2019 (UTC)[reply]

Thank you so much! Lore E. Mariano (talk) 14:40, 1 July 2019 (UTC)[reply]

Cite error created by bot.

Apparently there is a new bot creating cite errors. Article: WZ-551 Tag: Rescuing 14 sources and tagging 0 as dead. #IABot (v2.0beta15)

Is there a review process for new bots/tools? I have encountered many repeated errors that I assume are created by them. e.g. "coauthors=", "DUPLICATE_date". User-duck (talk) 17:39, 1 July 2019 (UTC)[reply]

Communication failure between the bot owner and the community at WT:CS1. I fixed the WZ-551 page that Gog the Mild edited and will leave it to that editor to similarly repair any other error caused by the tool.

—Trappist the monk (talk) 17:56, 1 July 2019 (UTC)[reply]

This is IABot via Oauth request by Gog the Mild. It was due to some miscommunications, my fault, iabot has been patched/rebooted and will look into fixing the errors added onwiki. -- GreenC 19:36, 1 July 2019 (UTC)[reply]

Edit conflict. I had just written:

Thank you Trappist the monk. That would have been from me clicking "Fix dead links" on the "Revision history" page and not checking the result thoroughly enough. I shall recheck my other recent clicks of that button.

GreenC, do I need to do anything, other than recheck previous uses of "Fix dead links", and/or cease using it? Thanks Gog the Mild (talk) 19:44, 1 July 2019 (UTC)[reply]

You are good, it's ok now. Looks like the bug lasted 3hrs and somewhere between 100-200 articles. I might script a quick fix or request something at AWB request wouldn't worry about manually repairing. -- GreenC 19:48, 1 July 2019 (UTC)[reply]

Question re: new translations of articles linked out to other languages

Progression of events was:

Editor created a link to de:Otto Kirn (in article Pandeism, correcting from wrong link to Otto Kern).
Translated Otto Kirn added here.
Wikidata updated for articles now in two languages.
Tagged as an orphan here.

Question: Why doesn’t English addition to Wikidata automatically prompt changing of links previously made to point other languages? Hyperbolick (talk) 19:49, 1 July 2019 (UTC)[reply]

The edit said [[:de:Otto Kirn]]. This explicitly tells to link the German Wikipedia. {{Interlanguage link|Otto Kirn|de}}} could have been used instead to test for an English article called Otto Kirn. It would only have examined whether the page name exists and not whether it's in a Wikidata item. As far as I know we have no template for the latter. It is possible to pull information from Wikidata so maybe it could be added as a feature in {{Interlanguage link}}. I don't think it's possible for an English template to look up the Wikidata item for a German article so Q24529752 would probably have to be a parameter. A bot could be coded to automaticlly add the parameter when it's not supplied. PrimeHunter (talk) 21:12, 1 July 2019 (UTC)[reply]

Could a bot check whenever a Wikidata item is connected from here? Got a notification here when it was, so somebody’s telling this Wiki. Hyperbolick (talk) 21:41, 1 July 2019 (UTC)[reply]

Question, watchlist listing error & problem

Dear All,

initially I turned to administrator regarding the issue, but unfortunetly he could not give an idea for solution. The details may be read there...Shortly, if I set it to list the changes back to 7 or 30 days, it is not working, just listing the last 250 changes, not more and I have as well no (previous/next) buttons...I need a solution, Thank You(KIENGIR (talk) 20:21, 1 July 2019 (UTC))[reply]

@KIENGIR: This is Wikipedia:Village pump (technical)/Archive 174#did something break watchlist and make it too short again?. --Redrose64 🌹 (talk) 20:36, 1 July 2019 (UTC)[reply]

@Redrose64:,

Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the "Expand watchlist to show all changes, not just the most recent" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(KIENGIR (talk) 10:39, 2 July 2019 (UTC))[reply]

Tech News: 2019-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 development of Wikidata Bridge has started. The goal is to allow Wikidata edits from Wikipedia. [7]

Problems

Sometimes pages load slowly for users routed to the Amsterdam data center. Investigation is in progress. [8]
Wikidata query service was overloaded between 11:50 UTC until 13:15 UTC on June 24. It has been fixed. [9]

Changes later this week

You will be able to read but not to edit all wikis for a short amount of time, on 3 July at 06:00 (UTC). This is to move a database. [10]
There is no deployment of a new version of MediaWiki on the wikis this week (calendar).

Meetings

You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 3 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.

21:22, 1 July 2019 (UTC)

Database issue

Could someone knowledgable comment here, centrally, on whether there are database issues beyond the apparently temporary ones outlined in the above Tech News, and if so, what are their extent and when do we think they will be resolved? It appears multiple bots have for some time not been running DB intensive tasks (such as certain Wikipedia:Database reports), and it is very difficult to parse through all the bot/report talkpage chatter to get a true picture of what is actually going on. Thanks in advance! UnitedStatesian (talk) 02:46, 2 July 2019 (UTC)[reply]

The database replicas are undergoing maintenance (see T222978). This involves taking one replica host out of service at a time. The other two hosts then have increased load, which leads to replication lag and increased query time (previously long queries could fail to complete). Maintenance is usually ongoing during the week and paused over the weekends. I would expect this to be an ongoing issue for a while. I don't know how long the maintenance will take, but the DBAs are reaching the end of the maintenance one the first replica. The database items in the Tech News are unrelated. — JJMC89 (T·C) 05:29, 2 July 2019 (UTC)[reply]

Fake edit conflicts when I edit talk pages

Pretty much most of the time for several days. On my iPad and my Windows laptop. they aren't real as my edits still appear. Doug Weller talk 16:57, 2 July 2019 (UTC)[reply]

@Doug Weller: didn’t you return back to edit form (in the browser) after saving an edit? Incnis Mrsi (talk) 17:02, 2 July 2019 (UTC)[reply]

@Icnis Mrsi: I'm not sure what you mean by edit form, but it's the nature of an edit conflict that you can't save. I can't save but my edit appears. Note that I just had a normal edit conflict with you and had to repost it in the upper text field as usual and save. Doug Weller talk 17:41, 2 July 2019 (UTC)[reply]

Problem with CSD category counts, again

I wrote a query regarding CSD category counts being incorrect and SoWhy helpfully pointed me to archived threads on this board, like Category count wrong and several others with the same complaint going back to spring 2018. Editors responded by listing Phab tickets, like T200402, T195397, T221795 or T18036 (and there are probably more). I've checked all the different tickets that were mentioned in these threads on this common problem and they are either marked as a) closed, resolved, b) closed, duplicate or c) low priority. I don't see how this issue can be considered resolved when it continues to be a problem and it is disappointing to think that there is little to no chance that anyone will work on actually solving this problem. It's clear that a lot of work on this started last year, but then the ticket was mistakenly closed as resolved.

Is there any way to restart the process of review so that there is some investigation of this problem? Because as a "resolved, low priority" task, that means to me that it will never be examined again. Liz ^{Read! Talk!} 23:35, 2 July 2019 (UTC)[reply]

Piped link with lang template

In the lead sentence of the page Xiquets Copenhagen, however, the wikitext ([[Castell|{{lang|ca|castells}}]]) is obviously intended to produce the anchor text "castells" linking to the page Castell; but actually it does not produce a link at all, and most of the wikitext shows up as ordinary text in the article. If this is supposed to work as intended, perhaps someone can fix the bug. If it's intended not to work, perhaps someone can edit the article to do what is necessary to achieve the desired effect.

(If you have something to say, please say it here. I only came across the article via Special:Random, and don't expect to look at it again.) --76.69.117.113 (talk) 04:06, 3 July 2019 (UTC)[reply]

@@ Line 826: / Line 826: @@
 Is there any way to restart the process of review so that there is some investigation of this problem? Because as a "resolved, low priority" task, that means to me that it will never be examined again. <span style="font-family:Papyrus; color:#800080;">[[User:Liz|'''''L'''''iz]]</span> <sup style="font-family: Times New Roman; color: #006400;">[[Special:Contributions/Liz|'''''Read!''''']] [[User talk:Liz|'''''Talk!''''']]</sup> 23:35, 2 July 2019 (UTC)
+== Piped link with lang template ==
+It is easy to see that | is a permissible character to the right of the active | in a piped link.  For example, <code><nowiki>[[red|green|blue]]</nowiki></code> produces the anchor text "green|blue" linking to the page [[red]]: [[red|green|blue]].
+In the lead sentence of the page [[Xiquets Copenhagen]], however, the wikitext <code><nowiki>([[Castell|{{lang|ca|castells}}]])</nowiki></code> is obviously intended to produce the anchor text "{{lang|ca|castells}}" linking to the page [[Castell]]; but actually it does not produce a link at all, and most of the wikitext shows up as ordinary text in the article.  If this is supposed to work as intended, perhaps someone can fix the bug.  If it's intended not to work, perhaps someone can edit the article to do what is necessary to achieve the desired effect.
+(If you have something to say, please say it here. I only came across the article via [[Special:Random]], and don't expect to look at it again.) --[[Special:Contributions/76.69.117.113|76.69.117.113]] ([[User talk:76.69.117.113|talk]]) 04:06, 3 July 2019 (UTC)