User Details
- User Since
- Oct 8 2014, 11:45 AM (492 w, 5 d)
- Availability
- Available
- IRC Nick
- Thiemo_WMDE
- LDAP User
- Thiemo Kreuz (WMDE)
- MediaWiki User
- Thiemo Kreuz (WMDE) [ Global Accounts ]
Today
Looks like there are ⋮ in the visual diffs now at exactly the points where we missed them before.
Fri, Mar 15
Thu, Mar 14
Serious question: The black rectangles on the bright map look somewhat misplaced to me. I mean, the map is not inverted, and probably shouldn't. The footer with the license information is not inverted as well. Why the buttons? Wouldn't it be better to stick to bright buttons in this situation, i.e. exclude them from dark mode?
My understanding is that the mw data structure with its body and attrs is a 1:1 representation of what can be seen in the wikitext. We know the attribute was always called <ref group="…">. From what I have seen Parsoid just passes this along. Because of this I'm relatively sure this was really a copy-paste mistake. I suspect the feature (removing a group) is just never used, or used so rarely that it never made it into a bug report. The effect is also quite confusing. The user probably thinks they made a mistake.
I had a closer look at the remaining messages.
These UNIQ--ref-00000002-QINU sequences are temporary placeholders for multipass parsing. They start with what's called MARKER_PREFIX in the code, followed by the tag name "ref" and an 8-digit sequence number. The sequence number in the example just happens to be 2. That's why it's unaffected when the other digits are replaced.
Here is a before vs. after comparison for the patch https://gerrit.wikimedia.org/r/1010895.
For reference, here is where I have seen this:
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/87601/console
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/87887/console
Whoops., sorry, T360026 already exists.
More failures: https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/87887/console. That's not good. Should we create a new ticket for this or is it ok to consider this one at least partially unfinished?
Wed, Mar 13
Quick proposal for the TechNews:
Tue, Mar 12
Oh no. I see the new test failing in unrelated repositories, e.g. https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74-docker/87601/console.
make the list of docblock tags that reference class names configurable […]
Can I somehow help pushing this forward? The Flow boards on wikis like mediawiki.org are currently heavily hit by spam bots. This is especially frustrating when the bots do exclusive Flow actions like editing the same topic summary over and over again. While this can be undone it's clumsy and frustrating as it is – by the nature of the separated Flow databases – not fully integrated into the normal MediaWiki workflows. And then there is this: T309941: IPInfo refuses to show IP informations if IP made only Flow modifications.
Mon, Mar 11
Thu, Mar 7
Minimal example:
<maplink> { "type": "Feature", "geometry": { "coordinates": [ 0, 0 ], "type": "Point" }, "properties": { "title": "[[File:Profil A.jpg|50px]] & B", "marker-symbol": "water" } } </maplink>
Wed, Mar 6
I believe https://gerrit.wikimedia.org/r/1009213 is the most minimal patch possible. Either that or reverting https://gerrit.wikimedia.org/r/981622 as a quick workaround, if that's still possible, and re-applying it later.
Tue, Mar 5
@MSantos, just some code clean ups I couldn't find a better task for. 😇️ Totally optional.
Mon, Mar 4
For reference, here is a direct comparison of the old 800px vs. the new 1024px setting. It's not a massive improvement, but already better.
Thu, Feb 29
This never happened, but we will try again via T358770: Improve user-facing Cite errors, one at a time. Let's close this as a successful investigation task.
Wed, Feb 28
Tue, Feb 27
Mon, Feb 26
I have an easier time talking about code. Considering that the patch https://gerrit.wikimedia.org/r/1005462 triggered all this, I wonder what I'm missing in the following proposal?
class EditEntityStatus extends StatusValue { public static function wrap( StatusValue $status ) { if ( !( $status instanceof static ) ) { $status = static::newGood( $status->value ); } if ( !( $status->getValue()['revision'] instanceof EntityRevision ) ) { throw new UnexpectedValueException( 'Unexpected status' ); } // Can add more assertions here… return $status; }
Fri, Feb 23
If you want to know more about how the MediaWiki ecosystem is developed I suggest https://www.mediawiki.org/wiki/Developer_hub. https://www.mediawiki.org/wiki/Bug_management/Development_prioritization is also a good read.
I don't think anyone actually needs numbers for this feature any more.
The Grafana page still exists, but all graphs stop in 2019. Nobody is looking at them any more anyway.
The worlds of desktop and mobile devices are getting closer again over the years, and so is MediaWiki. See T158181: Aim for workflow equivalence for MediaWiki on desktop and mobile web and related.
Long solved via a user option that can have different defaults per wiki: https://codesearch.wmcloud.org/search/?q=ShowRollbackConfirmation
As far as I understand it this is solved via T215303.
While I understand the idea, I don't think it will ever be implemented. It would be quite a big investment (notice how the regular diff page became more complicated especially the past months) for not much benefit (only no-JS users). It's also very easy to achieve pretty much exactly the same by clicking one of the diff links first before doing the rollback. I'm sorry, but for the sake of keeping our priority lists in a manageable state I would like to archive this ticket.
A ticket as brief as this is probably not worth keeping around after 7 years of inactivity. Please feel free to re-open if anyone plans to work on this.
https://gerrit.wikimedia.org/r/281195 mentions 3 bugs as possibly being fixed, including this one. Since there was no response after that I assume we can close this here as well. Please feel free to re-open the ticket or submit a new report if there is still an issue.
I think this effectively qualifies as a new feature. very similar if not the same as T130134: Watching (only) categorization (additions and removals) of an arbitrary category.
Sounds like this is effectively the same issue as T130888: Category addition/removal should be displayed in the watchlist independently of further edits on articles?