I don't understand the issue. We have abusefilters already that block additions of specific content by users matching specific criteria, and noone is complaining there. How is this different, albeit a bit more generalized?

Requested public project User-Andreas has been created: https://phabricator.wikimedia.org/project/view/4396/

In T200856#5687411, @Aklapper wrote:

Publicly log account disable actions taken using the https://tools.wmflabs.org/phab-ban/ tool.

@MarcoAurelio: Is there an actual real problem that would get solved by logging, or is this more of a theoretical "Any actions should be logged" task?

Requested public project User-Dyolf77 has been created: https://phabricator.wikimedia.org/project/profile/4377/

This would probably a very large security threat, especially if we change the default vlaue now.

A Bulk Edit (for the backlog, although this does not seem to be an issue) and a Global Herald rule (for automatically adding the project in the future) would do this. While I am technically able to do both of these things, I do not know if this is an generally acceptable use case for Global Herald rules. (@Aklapper : What are the rules here?)

Requested public project User-Majavah has been created: https://phabricator.wikimedia.org/project/view/4370/

This is not public.

Furthermore, I do not really see how updating composer is more complicated than initializing a submodule. In the end, I consider the nuances of git submodules more troublesome than using the most common PHP dependency manager.

I implemented the php requirements for extension.json, and @Legoktm and me thought it should be used the same way @Daimona proposes: A php requirement should only be specified, if an extension requires a php version higher than the minimum supported php version for the minimum supported MW core version. I think for composer.json, we should use the same approach.

Perhaps we could simply hide tags from revision histories (as with .mw-tag-markers { display: none }), but retain the data behind-the-scenes? That'd make it semi-private

Im not a fan of this idea. If there was malicious usage of this data (an idea i find a stretch tbh) hiding it would probably mean malicious people would still find it, but normal users would be less aware and unable to make concious informed choices about their privacy. I think the most important thing is ensuring any users bothered by this are aware of it, so they can make their own informed choices whether its worth making edits with the apps that use these tags.

Basically, the developers have to take into account the best practices when standardising the interface. For forms, putting labels above the fields and putting fields on separate lines provides the most readability (it is easier to read labels that way), even though it uses more vertical space. Checkboxes and radio buttons are made bigger for the benefit of mobile users and people with physical or motor disabilities, which also uses more vertical space. Our interfaces can be convoluted, but I think folks try their best to meet everyone’s needs.

While I think UI-Standardization is a good thing, I do not understand why we have to show forms like this in such a imparactical fashion on desktop. When looking at my contributions today, I was quite shocked – I have seen OOUI migrations before that I considered questionable, as they usually take much more space with little gain for most use cases. But I never experienced it that extreme before – ironically on a page which is impossible to use comfortably on mobile anyway (try to click these links…)

There could be many more usages in user namespace.

Actually, there are enough extensions where there is no clear license information whatsoever, or the license information contradicts itself, so I do not think this is a good job for a bot…

In T232940#5520005, @DannyS712 wrote:

In T232940#5519672, @eprodromou wrote:

This seems valuable and reasonable and something that Core Platform Team should do. It doesn't seem big enough that we should start a whole initiative for it, so I'm going to move it to our clinic duty inbox to get scheduled in a future sprint.

As an intermediate step, can I introduce overwriting redirects that don't target the page that is being moved?
I.e. move C to A, which currently redirects to B

By T194588#5434893, there is no row in the extension schema where this information could possibly go to.

Adding Core Platform, as they are responsible for MediaWiki-Comment-backend and might be able to assist with reviewing here.

Please be aware that not every extension needs its own tag. Just because it hasn't got one, doesn't meant it needs to be created

I am removing archived project tags.

This would not solve the second case though.

This could be implemented by automatically assigning a tag to every log entry corresponding with the creation, deletion, and change from/to a partial block.

Or just treat namespace blocks as another, special case than the others?

As far as I could figure out, the wpReason comment is only added to the log tables, which should be ready for longer comments. If, however, FlaggedRevs also stores the comments in one of its own tables, the database schema needs to be adapted and the table updated accordingly before any change can go into effect.

In T175709#5166798, @Volker_E wrote:

@MGChecker Because there are viable alternatives already defined: code or kbd. Why leaving it in and making things more complex long-term?
MediaWiki is not an entity on its own, it's part of the Open Web. And the web evolves. With and around browsers and standards. When people come to MW they have to learn a deprecated tag which is nowhere used. That's an unnecessary hurdle.

Most of this was trivially done, as there were no open tasks, no internationalization, and no translations. There even only way a repo because it was created a year ago without referencing it anywhere.

I agree with @Legoktm here. Actually finding relevant issues without a specific project is much harder. Furthermore, this provides us with a generic, unified workflow when considering extension issues, which I think is quite nice.

I disagree here. While page creation may appear floody when viewing the log as a whole, this is not the typical use case. If you view at a log, you usually either want to see log entries of specific type and action, by a specific user or about a specific case. In the first case this question is irrelevant, in the second case it might have some merit, but in the third case it imho makes the log much less clear, as you do not see a short summary of the page history (creations, deletions, moves and administrative actions), but only a less comprehensive part of that by default.

I think this project name could be cause of confusion, because internal links on Wikipedia are often referred to as wikilinks as well. People will probably be inclined to add this project if they experience general link-related issues.

As 1.33 release is near, it would be important to do this for all repos. so the developers there hae enough time to prepare for the release.

Reflecting reality

Well, I see no reason not to support this, but I do not see anyone using this global at the moment.

Requested public project MediaWiki-extensions-TEI has been created: https://phabricator.wikimedia.org/project/view/4016/

What could be interesting is combining this proppsal with T207649, as these would behave nearly identical to template arguments (immutable and local).This kind of Variables might be compatible with Parsoid, which will be replacing the current Parser sooner or later.

While the idea is nice, I doubt there will be measureable performance improvements. Variables are already quite lightweight (maybe except var_final), especially in comparison to the other parser code.

Unstripping using mStripState is done after wikitext is parsed to HTML, but after parser functions and templates are evaluated (first, signatures and substs are parsed to the actual wikitext to evaluate, then the preprocessor inserts the wikitext produced by the templates, than this wikitext is translated to HTML).

As the documentation in insertFinalizedVars suggested, wikitext is not parsed properly if we use the default strip process. I don't think we can fix this, as even parsing the wikitext ourselves, which might be possible, will probably yield further ugly issues. However, the solution I implemented here works just fine for subst, as this is done before wikitext is parsed.

T123078 contains some information about how this works.

Well, this does not really surprise me, as substitution does not really like this extension. (T201857) I guess this won't be easy to fix, but I believe the reason why this is happening is quite simple: While ExtVariables->reqestFinanlizedVar is called without any problems and the strip markes inserted, the InternalParseBeforeSanitize function is not called in the subst parser run, so ExtVariables->reqestFinanlizedVar is never called.

After a little searching a little with code search, I believe the only place this is used is https://github.com/SemanticMediaWiki/SemanticGlossary/blob/master/SemanticGlossary.php#L25 .

Is the ParserDiffTest class still needed? This patch removes its last actual appearance according to MediaWiki Codesearch.