In T18691#5550415, Pelagic wrote:

...

• Permalinks. I’d love to have a permalink option for both the URL and wikilink (using Special:Permalink for the latter). Four text fields may be too cluttered. How about a selector to switch between standard and permanent forms?

I'm running into the same issue we had with SVG Translate where responses are getting truncated; see T217815.

@bd808 From my research this has something to do with Nginx (which I think we use?) and/or fastcgi. Solutions point to a permissions issue, just as the error message suggests:

• https://stackoverflow.com/a/4515898/604142
• https://serverfault.com/a/824520/190562

I'm having the same problem with the wikiwho tool. Responses get truncated at 64 KB. If I make requests that give smaller responses, everything works fine.

Per our discussion, we are going to stay with the status-quo which is to show the timestamp according to the browser settings. The format of the timezone specified by the user's preferences is not trivial to parse. More at T235294: Add method to mw.user to get the preferred timezone offset.

I had this issue when I tried https://eu.wikipedia.org/wiki/Thorichthys_ellioti?uselang=fr (on master) in Chromium. @ifried is reporting similar issues with the deployed Firefox extension.

I don't quite see how mobile/desktop could infer a user's location, but regardless, the applications for tags in general are ample; the prime example being counter-vandalism. https://en.wikipedia.org/wiki/Special:AbuseFilter/819 wouldn't have worked without the user_mobile tag (or at least there would have been a lot of false positives). XTools Auto Edits helps reveal content contributions, which wouldn't be possible without these sort of identifiers. The VisualEditor (desktop) tag helped the community identify a bug. Admins can also identify unauthorized automated editing, etc. As I said they are not definitive, anyway; I can edit on desktop through the mobile UI, and I can edit using the Android app through a desktop simulator, etc. I of course cannot speak from a legal standpoint but it appears the privacy policy is about user agents, and I don't think that's being exposed.

I am guessing the user agent is not actually being read by the software (at least when it determines what tags to apply). It's just recording the method used to edit. For example I can edit on desktop using the mobile UI, and vice versa. In this sense it is no different than the tag added when using HotCat or Huggle (both of which suggest you're using desktop), or even AutoWikiBrowser which narrows it down to just Windows. Also there are user scripts that add "(using Foobar script)" to the edit summary, which indicate desktop. Then consider the Pageviews-API; If there is one pageview and one edit to [[Foo bar]] and it is mobile web, I know the single editor is using mobile web.

Thanks. I'm looking forward to it!

Thanks for the report. This error was due to maintenance the Cloud Services team was doing earlier today. It should be working now.

Pretty amazing of them to do this sort of code review for us!

I've been thinking of requesting +2 for PageTriage - thoughts?

it was under the Kanban board because it was created as a sub task. Should I ensure that I remove that tag each time?

Good stuff! Probably could use QA.

Much appreciated, @DannyS712! I think this is relevant to our work, so tagging with Community-Tech seems appropriate, but in general please let us manage what columns tasks go under, and whether they belong on the Kanban board. Thanks!

The automatic merges such as with Special:MergeItems certainly seems applicable. Manual merges probably shouldn't apply because they are not (semi-)automated, and I don't think we can reliably detect them anyway.

Relevant issue on Wikiwho's GitHub: https://github.com/wikiwho/WhoColor/issues/7

Thanks DannyS712! Everything looks good in my testing but we'll put this through QA just in case.

T187379: Hook up Grant metrics with TWN is an example of when we did this in the past.

I'm going to go ahead and move to Needs Review. I think T225774#5319960 and T225774#5320840 summarize the issue. Basically there doesn't appear to be a workable solution. This query was always really slow, and apparently we're at the point where there are so many revisions that it just won't finish. I suggest we retire the "Pages with most revisions" database report.

PR: https://github.com/wikimedia/WhoWroteThat/pull/58

This should be addressed, but I don't think T234067: Page triage leads to a one way action in some cases specifically is a huge concern. The idea is to unreview a page so that you can take actions on it like add tags using the toolbar. I don't know why you would do this to a page you created. There is a confirmation modal about adding pages to the queue, so that hopefully will prevent mistakes. I'm going to move this to our parent board as we typically will discuss/triage/estimate before putting a task on the Kanban board.

There have been more reports of this. Going off of the error logs for XTools, the last burst of 503s from the MediaWiki API happened from around 11:00 to 12:00 UTC on October 1.

This is a fun idea! I take it this for XTools ? Is all of the data already available to us (on the db replicas)? If so we might remove MediaWiki-extensions-Translate and MediaWiki-extensions-TranslationNotifications to reduce noise.

In T167475#5524623, @Kudpung wrote:

Looks good and works, except the pop-up calendars do not work as expected. Possibly due to the unique US date format instead of the international one?

PR merged, not sure if we are still investigating the issue with Miniatlas.

If possible, we should also format the date to match the user's on-wiki preferences.

In T232388#5489715, MusikAnimal wrote:

When I go to https://ru.wikipedia.org/w/index.php?title=TAM_(электросвязь)&action=info for instance I don't see any of the content from https://ru.wikipedia.org/wiki/MediaWiki:Pageinfo-header.

Eek, sorry! We recently did some server maintenance (T232786) and missed a very important step. It should be functioning again. Apologies for the disruption!

@bd808 With your help, Community Tech created this way back when T136862: Create project Google-api-proxy. I don't think any of us know how to set it up from scratch, though. Could you assist? :)

All set!

@Andrew All set! Everything is now running on Buster, and I've deleted the old VMs. We do not need the additional quota anymore. Thanks for the help!

In T232232#5503122, dom_walden wrote:

Also, I am not sure what happens when we hit WikiWho API's request limit. From https://api.wikiwho.net/:

Currently, there is a limit of 2000 requests/day for unregistered users, and also a 60 requests/minute limit for all users.

In T233371#5517618, @ifried wrote:

The old version screenshot (as posted above) is when the message is for the creator. If it had already been reviewed, what would the label have stated for the reviewer? ‘Add a message for the previous reviewer,’ for example?

SQL Optimizer works by putting a SLEEP(1) in the query and EXPLAINing the query using the process ID. It is only but so smart, unfortunately. Here it went with:

SELECT SLEEP(1), DISTINCT page_id
FROM page

Twinkle issue: https://github.com/azatoth/twinkle/issues/709

This seems like another example where WhoColor is incorrectly putting things together. The normal WikiWho API attributes the Olympia link to https://tr.wikipedia.org/w/index.php?diff=4019869 which appears to be correct.

That did it! Thank you :)

There is a thread on checkuser-l about this. At least three users intermittently got 503s today / this week when using Special:CheckUser. I don't know if it's related, but I'm assuming what @DannyS712 experienced is also intermittent, which suggests some broader issue. There were no recent changes to the CheckUser extension https://github.com/wikimedia/mediawiki-extensions-CheckUser/commits/master