Are there bug reports (subtasks) defined that block this one?

(In reply to comment #1)

Are there bug reports (subtasks) defined that block this one?

Not yet.

Will there be some? Otherwise I'm going to close this.
I don't need empty tracking bugs that track nothing...

(In reply to comment #3)

I don't need empty tracking bugs that track nothing...

I don't care what you need.

I'm going to expand this bug to be more generic. There are English Wikipedia-specific enhancements in places other than the edit window now.

Shall this bug be listed under Wikimedia project, rather than MediaWiki? (I don't know of a change in the MediaWiki itself that was done specifically for En WP; but I do know of configurations of the installation used by Wikipedias bein tweaked in a special way for En WP).

Also, shall we mark bugs like Bug 43630 as blocking this tracking bug?

(In reply to comment #5)

Shall this bug be listed under Wikimedia project, rather than MediaWiki? (I
don't know of a change in the MediaWiki itself that was done specifically for
En WP; but I do know of configurations of the installation used by Wikipedias
bein tweaked in a special way for En WP).

Yes, I think so.

Also, shall we mark bugs like Bug 43630 as blocking this tracking bug?

No, I don't think so.

Thanks for filing this bug; actually I think this was better as MediaWiki>General bug: it's not sustainable as Wikimedia>General request.
In fact, the problem with micro design improvements, GettingStarted, Onboard, ACUX etc. is that they are not code but local system messages/template/JavaScript/bot solutions which *can't* be exported anywhere else, as pointed out by Nikerabbit at [[mw:Talk:Micro_Design_Improvements#Work_on_templates]] but also by https://meta.wikimedia.org/?diff=5211749 and https://www.mediawiki.org/?diff=643250 .
Like bug 43690 which was duped to bug 44628, the blockers of this should be requests of implementation in core or in extensions of features/experiments currently done with JavaScript hacks or even outside MediaWiki. It could also be generalised to cover 1) things which are now disabled like https://meta.wikimedia.org/?diff=5189826 , 2) modifications on other wikis like the long-standing section [edit] move (bug 41729).
The problem with all this is of course that such a tracking bug is useful as reminder for non-WMF people but WMF doesn't actually use those bugs for such coding projects.

swalling wrote:

(In reply to comment #7)

Thanks for filing this bug; actually I think this was better as
MediaWiki>General bug: it's not sustainable as Wikimedia>General request.
In fact, the problem with micro design improvements, GettingStarted, Onboard,
ACUX etc. is that they are not code but local system
messages/template/JavaScript/bot solutions which *can't* be exported anywhere
else,

That's not actually true about GettingStarted, ACUX, etc. It is difficult in their current form, but not impossible in the least.

In any case, I don't like the comparison between Micro Design Improvements and those projects. Our work is inherently experimental, and how we implement an experiment is often different than a real product. This is by design. The problem with MDI is that they are permanent product changes implemented in a single wiki. That's not the same as you needing to hold your horses while we implement successful experiments in core or an internationalized extension, and so forth.

(In reply to comment #8)

(In reply to comment #7)

Thanks for filing this bug; actually I think this was better as
MediaWiki>General bug: it's not sustainable as Wikimedia>General request.
In fact, the problem with micro design improvements, GettingStarted, Onboard,
ACUX etc. is that they are not code but local system
messages/template/JavaScript/bot solutions which *can't* be exported anywhere
else,

That's not actually true about GettingStarted, ACUX, etc. It is difficult in
their current form, but not impossible in the least.

Yes, ACUX, GettingStarted, and GuidedTour are all extensions. However, there are some message and CSS interactions in GettingStarted that make it somewhat more complicated.

The latter two can both moved to other wikis relatively easily (GuidedTour more so).

GuidedTour is already on other wikis. We are moving ACUX to core (bug 44628).

This bug seems headed in a bit of a strange direction.

It was originally filed to cover this particular case: when a user goes to https://en.wikipedia.org/w/index.php?title=Talk:iPad&action=edit&useskin=vector currently, the interface looks different than when a user goes to (for example) https://en.wiktionary.org/w/index.php?title=Talk:iPad&action=edit&useskin=vector. Below the textarea, we can see "View templates on this page" is a collapsed list, as is "View hidden categories on this page". There's also a grey background coming from somewhere.

As far as I'm aware, these changes came from the "Micro Design Improvements" team. I quite honestly have no idea how they're implemented. I think it's in JavaScript somewhere, but it could be in an extension. Dunno.

The purpose of this bug is to track this change _and any others_ to the English Wikipedia (from the Micro Design Improvements team or otherwise) that are not available on other wikis when they should be (i.e., "Implement English Wikipedia-only enhancements for other Wikimedia wikis (tracking)"). Whether this bug relates to E3 or any other current Wikimedia Foundation team is a judgment call to make when determining which bugs depend on this bug.

(In reply to comment #10)

As far as I'm aware, these changes came from the "Micro Design Improvements"
team. I quite honestly have no idea how they're implemented. I think it's in
JavaScript somewhere, but it could be in an extension. Dunno.

Kill me if I know why, but it's in Vector. No, really.

To clarify, I meant "impossible" as is: for instance, it's not feasible to run SuggestBot on hundreds (or even dozens) of wikis. I know that GuidedTours is already ok and that some work is planned on the others.

(In reply to comment #10)

This bug seems headed in a bit of a strange direction.

Sorry if I added confusion...

(In reply to comment #12)

To clarify, I meant "impossible" as is: for instance, it's not feasible to
run SuggestBot on hundreds (or even dozens) of wikis.

Why not? Labs should be able to provide infrastructure for this. It could run on multiple wikis in rates proportional to the number of requests (if only a few people are subscribed, it won't have to make as many edits, and it could probably slow down a bit).

usermono wrote:

This should be done, along with all the hidden easter eggs strewn about from the Usability Initiative and everything the WMF is pushing to ENWP.

There are no more dependencies left. Is there anything to do here? What is the state of the Micro Design Improvements project?

swalling wrote:

(In reply to comment #15)

There are no more dependencies left. Is there anything to do here? What is
the
state of the Micro Design Improvements project?

The micro design work has made some local changes to enwiki (wikitext) edit window, IIRC. So that stuff likely applies.

If this is really a general tracking bug for all enwiki-only enhacements, there are no doubt many extensions or gadgets that currently apply. (We plan to roll out GettingStarted which is enwiki only for now).

I don't see any open dependency tasks left here.
Can this task be closed?

No, I'm sure there are many more that are still open, but just not linked yet. I added one I could think of for a starter (T50552: Make PageTriage wiki agnostic).

Detaching task from T28751, since the two are related but not strictly a superset or subset of one another. Extensions can become generic and remain as an extension, possibly bundled. E.g. T50552: Make PageTriage wiki agnostic is a subtask here but is not proposed for moving into core.