Mockups were developed separately, so this can be marked as done.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 4 2021
Change 685107 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Add Link: Select visual diff mode on save dialog setup
Change 684494 merged by Andrew Bogott:
[operations/puppet@production] wmcs-policy-tests.py: add Trove policy tests
Change 684494 merged by Andrew Bogott:
[operations/puppet@production] wmcs-policy-tests.py: add Trove policy tests
Change 681500 merged by Dzahn:
[operations/puppet@production] ci/deployment-server: adding kubernetes namespace for miscweb
Declined per the movement towards wvui. We'll open a new task for porting MobileFrontend to Vue.js when time allows.
Declined per the movement towards wvui. We'll open a new task for porting MobileFrontend to Vue.js when time allows.
Change 685105 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] trove.conf: use our custom policy.yaml
It's probably caused by this part of ve.ui.MWSaveDialog.getSetupProcess:
this.reviewModeButtonSelect.selectItemByData( ve.userConfig( 'visualeditor-diffmode-' + surfaceMode ) || surfaceMode );
getting confused by our custom surface mode.
Revision to implementation
Per this today's team meeting, to start, the Subscribe / Unsubscribe affordance on desktop will:
- Be located on the right side of talk pages in LTR languages and on the left side of talk pages in RTL laguages
- Be styled to appear like all other link affordance on talk pages (e.g. [ reply ] / [ edit ] / [edit | edit source]
Awaiting output of T279108
Awaiting T279108
Declined awaiting output of T279108
Adopt where it makes sense (in fact this has been happing in MobileFrontend), I don't think this task is useful.
One thing that would need to be changed would be to change all the data on wiki from the current code based language identifiers to the new ZIDs, at least for the data to be loaded in. We might also want to have a task to provide a maintenance script to update an existing wiki.
Our long term plan is to swap out the mobile search for the desktop search but that's probably going to take a while. Is this blocking work your side @Cparle ?
Hm, that patch fixed the underlying issue, and running the check manually produces the intended result:
Not sure what "Change the PHP side to define a monolingual as an array of Z60" means, but if it means that a Monolingual string should use the Z60 instead of a Z6 for the language, then that is right.
Stalled per T278590
Change 570196 abandoned by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] Make CategoryAddOverlay use Overlay.make
Reason:
This will be redundant with the approach outlined in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/ /683441
In T279388#7059219, @Jdlrobson wrote:Which if anything has been a bit of a regression where it's been implemented, as generally it's better to keep content styles consistent between all pages, whether they're parser output or special pages or whatever.
Agreed, but that's a regression that predates this change, and this change allows us to keep content styles consistent across skins by making mw-body-content a first class citizen provided by core rather than a class that skins must remember to add.
Change 684491 merged by jenkins-bot:
[mediawiki/core@master] Hard deprecate FileBackendGroup::singleton() and ::destroySingletons()
Change 673976 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Expose first JSON validation error to the user
Change 685039 merged by jenkins-bot:
[wikimedia/discovery/analytics@master] Bump glent to 0.2.4
Something I noticed testing a different patch on patchdemo (without this redesign, but with action blocks enabled):
In T279388#7059217, @Jdlrobson wrote:Well, based on a very brief look at https://codesearch.wmcloud.org/search/?q=%5C.mw-body-content&i=nope&files=&excludeFiles=&repos= it looks like all of the following will likely be impacted...
These are not impacted. While they use the class, they will not be impacted by the change here as they have no styling rules that will be broken. Skins that are using the class will continue to use that class and the styling rules in each of them will also apply.
Which if anything has been a bit of a regression where it's been implemented, as generally it's better to keep content styles consistent between all pages, whether they're parser output or special pages or whatever.
Well, based on a very brief look at https://codesearch.wmcloud.org/search/?q=%5C.mw-body-content&i=nope&files=&excludeFiles=&repos= it looks like all of the following will likely be impacted...