Fri, Aug 23
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.
Sun, Aug 11
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.
Fri, Aug 9
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.
Jul 19 2019
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.
Jul 12 2019
Jul 11 2019
Jun 6 2019
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.
May 30 2019
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.
May 26 2019
Apr 28 2019
Well, I see no reason not to support this, but I do not see anyone using this global at the moment.
Apr 24 2019
Requested public project MediaWiki-extensions-TEI has been created: https://phabricator.wikimedia.org/project/view/4016/
Apr 20 2019
Apr 19 2019
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.
Apr 18 2019
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).
Apr 17 2019
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.
Apr 15 2019
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 .
Apr 13 2019
Apr 12 2019
Is the ParserDiffTest class still needed? This patch removes its last actual appearance according to MediaWiki Codesearch.
@Legoktm I think we should get this merged in time for MW 1.33. Their shouldn't be any remaining issues in the code.
Apr 9 2019
Apr 5 2019
I think we should just archive String Functions and leave it as is.
Mar 20 2019
See also T209086.
As I understand the task title, Jayprakash considers extensions where noone in the corresponding Gerrit group (so, excluding people with +2 in mediawiki/*) has +2ed a patch in a year or two. I agree that this could be quite interesting.
Mar 17 2019
This line of thought sounds quite reasonable. I doubt creating an additional tag for these few tasks is warranted, if no additional users request one.
It is a pity that extensions like this one tend to end up unmaintained. @Florian has outlined something similar in core in T155155, which has the goal to introduce a special page listing the current wiki configuration, that could maybe be extended to allow configuration changes as well in the future.
I do not really get how this is related to the impact of the vandal. as he basically states a single claim that would have to be denied or confirmed anyway at some point. I do not think we can link information about the incident and impact of the vandal here.
I don't think removing these comments is a good idea, as people subscribed to this task recieve the respective email notifications anyway and are left with even more questions than before. If the intention is to deny the claims of @JruwJN, I would consider it the better approach to just say so, if the intention is to keep this hidden for now, it simply is not working. So I don't think these deletions do any good.
Mar 16 2019
People use these to do statictics, that is basically the only reason for public logging. And as you can filter the thanks by actor and recipient, it is not quite that useless in practice.
Mar 12 2019
@MaxSem This shouldn't matter, as the code is fine. I would be willing to adopt this change.
Mar 9 2019
Mar 3 2019
Making deleted content of whatever kind available to a larger group than sysops has been declined by WMF over and over for legal reasons. Even my proposal to allow access to the history of edits you made yourself has been declined in Community Wishlist. That's why I'll be bold and just close this one, especially since it not only targets a specific wiki, but MediaWiki defaults.
Mar 2 2019
There is a problem with Milestones: Phabricator orders Milestones by creation date in Workboard and Navigation, a behavior that can not be changed. As PAWS (JupyterHub 0.9) has been created before this Milestone, these Milestones would be displayed out of order.
Mar 1 2019
@Legoktm I would love to get this into MW 1.32.2 or something like that, so this feature is finally complete.
Oh, now I see the difference.
Feb 26 2019
I plan to take care of this in a few weeks when my schedule clears up. However, if someone else wants to do this, feel free to claim this task!
A special case that should maybe be adressed: Are there special policies for extensions that are not deployed by Wikimedia, but bundled with MediaWiki? T191741: Bundle Replace Text extension with MW 1.31 provides an example for this, where self-merges are forbidden as part of the process. (T191741#4179808)
Feb 22 2019
Wouldn't be #Tool-status the better choice? Status seems like a quite generic tag name to spend here.
Feb 17 2019
Feb 12 2019
@Legoktm Do you know when you will have time to take another look at this change? I implemented your feedback.
Requested public project User-crusnov has been created: https://phabricator.wikimedia.org/project/view/3884/
Feb 10 2019
Marking this as Resolved for the time being.
@Krinkle I don't think it is supposed that change project scopes are changed without consultig with Project-Admins first, especially as the scope of this project has been the result of a discussion here.