The Contributors Team of the Wikimedia Foundation's Product department build collaborative, inclusive tools for creating and editing free knowledge.
We work on extending and improving the editing tools used at Wikimedia – Editing-team who work on content tools, Growth-Team, Language-Team tools for translation, content and communication, and the Parsing Team. We exist to support new and existing editors alike across desktop, tablet and phone platforms.
Rather than page properties, which are stored and indexed in a separate database table, probably ParserOutput::setExtensionData() would be sufficient for this use case.
This makes my week. Thank you :) (:
So I've posted a patch that is basically what I outlined in T35186#7487506. Rough next steps:
Change 973279 had a related patch set uploaded (by Legoktm; author: Legoktm):
[mediawiki/core@master] WIP: Implement file rotation via Shellbox
MediaWiki-extensions-DocBookExport now exists, which I guess doesn't quite resolve this task.
Changed from "stalled" to "open" since apparently the Wikidata issues mentioned before were resolved.
I have removed a log filter from Kibana MediaWiki New Errors dashboard which pointed back to this task. There is no hit over the last four weeks.
The MobileWebEditing schema, in which these errors were logged, has been decommissioned ages ago. I don't see anything unusual in the errors logged in the current EditAttemptStep schema. I'm afraid the cause of this issue has been lost to time.
Seems like this got fixed in core – the request URL now produces:
Change 65176 had a related patch set uploaded (by Winston Sung; author: Parent5446):
[mediawiki/core@master] Automatically move category members when redirected
These days there are a lot fewer browsers that are served JavaScript by MediaWiki, but not supported by VisualEditor (in fact there might not be any). I don't think this is worth building any more.
Agreed re: just offering 90/180/-90 for under-X-MB files. Raise that to 20MB and you'll cover most good/featured images.
I think simple rotating (let's leave cropping out of it for now) is a must for Commons and something that should be supported at production quality, especially given the recent emphasis on better multimedia and technical support for Commons. Anyways it seems like low hanging fruit.
@Legoktm @Ladsgroup it seems crop and rotate (by 90/180) are such a common use case they should be "on" by default, whether by closer integration of CropTool into the upload wizard or otherwise.
I can't reproduce. It's likely that some logging refactoring since 2015 fixed this.
Not a strict duplicate; the removal of the old code isn't done yet, and we don't have a solution for non-Vector users.
Change 274328 abandoned by Aklapper:
[mediawiki/core@master] [WIP][POC][OMGWTFBBQ] Replace the searchSuggest box with an OOUI widget
Reason:
T125725 is duped into T244392. T244392 is resolved.
Change 901233 merged by Giuseppe Lavagetto:
[operations/puppet@production] graphite::alerts: add alert on mediawiki account creation failures
Change 901233 had a related patch set uploaded (by Giuseppe Lavagetto; author: Giuseppe Lavagetto):
[operations/puppet@production] graphite::alerts: add alert on mediawiki account creation failures
Removing SRE, I don't think anyone from the team(s) is working on this.
Using something simplistic like the proposed return require( "Module:Target" ) can easily be detected by the target module, perhaps even affecting its functionality. Specifically, ... will have a value during the module initialization because the module is required and not directly #invoked and mw.getCurrentFrame():getTitle() will refer to the #invoked title and not the redirection target. Also reported script errors will list the #invoked module in the call stack because the target module is not truly treated as the Lua "main" module.