Due to lack of time I didn't work in this in months and even if I might get into this later again I prefer unasigning myself from the task for now to avoid discouraging others from working on the task.

In T316936#8225124, @Lydia_Pintscher wrote:

Do you have an example where this is happening so I can have a closer look?

@Theklan in the examples you provided do you know if they're using indicators or absolute positioning? Because most of the examples look like absolute positioning, and in eswiki I didn't see any problem since we changed the different modules and templates to use indicators...

I think that's intended and based on the design of T284243

Having a self link in the sticky header is not useful at all, and it would be nice if it could link to the content-namespace version instead (with a different icon to distinguish both) as @Tacsipacsi suggested.

In T277826#7926652, @Lucas_Werkmeister_WMDE wrote:

For the multi-multi case I would suggest a message with more than one paragraph, something like:

An entity should not have statements for both $1 and $2.

Replacement properties:

• …

Replacement values:

• …

How can I do a message with multiple paragraphs as the one in the example above? The only way I can think of is adding HTML code to the messages, but checking the list of the existing messages in the extension I don't see any message with HTML tags in it, so I suppose there's a better way to get the same result.

In T277826#7926652, @Lucas_Werkmeister_WMDE wrote:

Note that it’s also possible to have only a replacement value but no replacement property.

In this case should I assume that the same property with a different value should be used instead?

I started working on this, but I'm not sure how should I handle the messages when multiple properties and multiple values are specified with the replacement property and replacement value qualifiers.

From the list in the description I wouldn't consider the Special pages element would be fine in the more menu. I don't know which should be the best location for that link if the idea is to remove the current box completely, but it shouldn't be by default in the list of article tools. It's not even related to the current article...

@alexhollender_WMF it's not about the visual difference, it's about making the visual difference known to assistive technology through something like the aria-selected attribute.

@Jdlrobson: But adding an id would force me to define the SVG icon myself, and what I want is adding an icon from this list. IIUC to make that work as expected without having to declare the icons myself to add the clock icon to the UTC Live Clock gadget I should change this:

var node = mw.util.addPortletLink(
    'p-personal',
    mw.util.getUrl( null, { action: 'purge' } ),
    '',
    'utcdate'
);
if ( !node ) {
    return;
}

In T152330#3515891, @Fomafix wrote:

It may be useful to add two additional CSS classes for the authors for overriding the normal behavior for the print version:

.mw-collapsible-hide-on-print

and

.mw-collapsible-show-on-print

where it may be useful for the content.

In T282027#7406120, @Theklan wrote:

But that is not the way to show it. They should go over the title line, just to the left of the language switcher, as it was previously. I have opened a ticket here: T292617

I understand that they're not in the same position as they were previously, and I also understand that they won't go back to the title line because developers want to use that space for languages. I just suggested a different design to fix the problem (too much space between the title and the content of the article) without reverting the changes related to the new position of the language selector.

Oh, yeah, now I see the problem. That happens because indicators are part of the header even if they look like they are part of the content instead. Clearly making them float at the end of the header wouldn't change anything.

Adding a float: right to the indicators section would work to remove that white space in an acceptable way? AFAIK that way it wouldn't generate that space and it would only move the infobox down instead of the whole content.

I might be wrong or even misunderstanding the issue, but the description in wikibase shouldn't have any wikilinks nor templates. I don't know if that applies to formatting too, but wikilinks and templates would make them only useful for the wiki in which they were added and completely useless for third party users where even if they could format those links they can't know to which wiki they should be linking to.

I expected filling the API Sandbox form to be quite straightforward, but I described those steps regardless now.

@Aklapper I added the missing info to the description and unstalled the task. Let me know if there is something more missing.

If the idea is decreasing the number of icons in the bar merging the alerts and notices ones would be better, at least I never understood which is the difference between those two kinds of notifications, just that some notifications go to one and the others go to the other one.

@Lydia_Pintscher, I just tested it and it's still happening in production right now. I connected this article to its Wikidata entity, but even if the rendering of the page changed to reflect that the IMDb ID of the template parameter is the same as the one of the Wikidata entity it's still displayed in the category that tracks the mismatch of identifiers.

In T280910#7198841, @Lucas_Werkmeister_WMDE wrote:

No, you get a usage on Q1 (not quite sure what kind of usage – my sandbox page apparently uses “some labels”, rather than specifically the English label), and nothing on Q2. So edits on Q2 have no effect.

The usage of "some labels" instead of the English label looks fine, because Template:Q uses the user language for the label and that language can be something other than English. That usage should still be tracked for the redirect target instead though (or to both of them).

In T49544#7198673, @Inductiveload wrote:

This means that it is very difficult to make $3 a div, and also have it share a line with the mw-cite-backlink element robustly (it can work with display:inline; but not if the reference begins with something like <p>.

So you often see the backlinks on their own lines.

What it needs to happen is someone willing to +2 the patch, at least if that is enough for @Anomie's and @Huji's concerns

@Dvorapa The commit that resolved the issue is linked to the task and the only reason for not merging it AFAIK is that it's not clear if this should be resolved or declined.

That's correct. The template wouldn't be able to suppress those categories, but it's totally different of T88797, because the generated categories are controlled by the module author in this case and the categorization could be easily suppressed in the code with a parameter. Anyway using this function is completely optional, while the error category isn't.

Adding User-notice to ask for feedback.

Adding Platform Engineering for review.

@alexhollender @ovasileva And what about using the 3 part system making parts optional? The guideline could specify that, if a tagline is not configured, the wordmark should be vertically centered. Then it would be up to the skin implementing when the wordmark should be displayed alone and when with the tagline bellow.

That instructions are for using the master branches instead of a specific version. Try doing this:

cd .../extensions/WikibaseQualityConstraints/
git checkout REL1_34

That way you should move WikibaseQualityConstraints from the master branch to the REL1_34 branch.

In T245534#5896284, @Wikirik123 wrote:

1. What is the version of Wikibase and Wikimedia that WikibaseQualityConstraints is compatible with? I did not find a version on the description page of the extension.

The version of each of the branch is compatible with the same branch of WikibaseQualityConstraints.

In T236711#5835701, @AronManning wrote:

I'm finished with the patch, it has default icon and some cleanup. You can decide whether to go with just js or js+css. A js solution is necessary for customizing the icon, anyway. I find the css+js solution more consistent with other skins and working for old gadgets.

Even after reading the discussion I don't get where the problem is about this functionality nor the need to control or block who can watch your contributions. If someone wants to stalk my actions in the wiki they already can with user contributions: it's completely public and it even has RSS functionality to allow watching contributions of multiple users easier. The only thing a user watchlist would provide would be making it easier to access. The same arguments used to not create this functionality could be easily used to remove the RSS functionality from user contributions or even to block the special page completely, and I don't see anyone requesting that.

I'm not sure if this is feasible without negative impact in performance. The way LuaEngine works it's only possible getting the memory footprint at a given moment or the peak memory footprint of the whole execution. The only way I can think of to get the peak memory footprint for each of the #invokes would mean reinstantiating the LuaEngine each time the #invokeis called. To achieve that we should change this line to instantiate the engine each of the times and, after calling the Lua code, just store the data using the module name as a key, but the impact on performance could be more than it's worth.

Just to be sure I understand correctly what should be done to resolve this task. A new maintenance script should be created that removes the empty and 0 keys (their meaning is using the default skin which is the same as not having an entry in the table), updates the keys with the value 2 to cologneblue and deletes all the keys not in Skin::getSkinNames() (this way it should work too for 3rd parties with different skins installed than the ones in Wikimedia wikis).

Even if the change in hidden categories doesn't have any visible change in the page it still causes changes in the HTML in the #mw-hidden-catlinks element. If HTML wasn't invalidated in Varnish the HTML would be incorrect. Before preventing invalidation for changes in the hidden category links these categories should probably be removed from the HTML instead of just hidden with CSS.

@DannyS712 It would have duplicates if T146585#4233276 is still true.

It would be better if, instead of removing the field, it was replaced with the description from StructuredDataOnCommons instead. That way it could be a more meaningful description of the picture than the name and version of the tool used to upload the file or the changes made in the file in the latest reupload.

This was fixed when quoting the aliases unconditionally to fix T118973

I can't replicate this anymore in the category of the link used as an example nor any other I tried, so I suppose this was fixed at some point.

Hi @connorshea, that's T102324 (which is the task in which the suggestions where hidden for qualifiers in new items as a temporary measure), T147117 (the parent of the previous one) and T197991 (which is probably a duplicate of the other two).

I don't think they can be restored, this is probably related with Google closing Google+ and removing the data.

It doesn't look like it's decreasing again after going back to 150... Is it possible for the increase being related to T204031: Deploy regular running of wikidata constraint checks using the job queue instead of with the maximum number of entities checked?

In T209504#4823419, @Lucas_Werkmeister_WMDE wrote:

In the “Type Check Runtime” panel, I would expect the times of PHP checks to increase slightly, and the times of SPARQL checks probably wouldn’t change (their rate should decrease, but we don’t currently plot that).

In T150826#4784325, @jrbs wrote:

The ratelimit applies to accounts, not just to admins. And there are definitely times when admins need to block more than 5-10 users in one go, especially on large wikis.

No, what @Tgr suggested is a ratelimit for blocking privileged accounts. See bellow:

In T150826#4779179, @Risker wrote:

Let's not complicate this situation further by giving admins the ability to block the people who blocked them - in fact, that's exactly the scenario that all of this is trying to prevent. In the three cases on enwiki that immediately come to mind, the blocked admin blocked the administrators who blocked them. Status quo ante, they had to unblock themselves first to do that. This wouldn't even require them unblocking themselves. Please don't go there.

This would only allow them blocking the admin who blocked them, but not all the other admins too. It's way better than the existing status quo where they can't be blocked due to their ability to unlock themselves, and it's also better than the situation where they can block all other admins and continue vandalizing whatever they want until the account is blocked in a way they can't unlock themselves.

In T210496#4777683, @IKhitron wrote:

In T210496#4777675, @Agabi10 wrote:

It can't be added until the change is deployed. If added before it's considered normal text, not a magic word.

Checked on Mediawiki.org, group 0.

It can't be added until the change is deployed. If added before it's considered normal text, not a magic word.

In T209217#4777452, @TheDJ wrote:

FYI, unlike skins, WikiEditor is not enabled by default

Then it should probably be checked by default, but not merged into core.

In T209924#4768309, @daniel wrote:

Yes, true: User:Agabi10/Node.js would be treated as an "active" page, and the "script" page type may not like wikitext there (it *could* allow wikitext as well, but that would be confusing and partially defeat the point). You would have to rename it to User:Agabi10/Node-js or User:Agabi10/Node.js.wikitext to avoid this. Do you think that would be terrible?

I don't think that would be terrible, but I don't see any benefit on making the page type depend on the page title neither. I rather have the page type defined on the database and allow setting it the same way the content models can be set. At least from my understanding page types define mostly how the information is displayed and the available actions for that page. I don't see how it can be more intuitive making it depend on the title of the page than allowing the user selecting the desired among the list of available options on page creation.

In T209924#4768276, @daniel wrote:

In T209924#4762551, @Anomie wrote:

The "wikitext" content model would indeed be unsupported on User:Foo/Bar.js, though it wouldn't break existing pages. Maybe they could even remain editable. But they should trigger a warning, and it should not be possible to create more pages like that.

It would mean that any such existing pages would suddenly become subject to needing the editmyuserjs or edituserjs rights.

Indeed. To be honest, I cannot think of any good reason for such pages to exist. Is there any need for them?

But see above for "suddenly".

Correct me if I misunderstood, but that means that the article about Node.js of the English Wikipedia couldn't be created with the suggested changes with the wikitext content model? Or that I could not start an article about a different JavaScript framework as a subpage of my user page due to having it disallowed creating *.js pages with the wikitext content model?

I don't know when this has been fixed but in current master if you add a the wikitext [[text]] in a page with the name Text no entry is recorded in the pagelinks table for that page, so the described behavior is impossible to replicate now.

Once that latest patch is merged I think we can consider this task resolved, at least unless we want a Special:ExpectedEmptyCategories too to get the whole list of categories with that page property. I don't think I would ever use a page listing all the empty categories that should be empty (regardless of whether they are empty or not) ever, but I can implement it too if it is really useful for some use case.

The first part is already done. Now the only thing missing is the Special Page to list categories that should be empty but have at least one member. Any suggestion for the name of that Special Page?

As @stjn said, the WikiEditor extension is in the downloadable version of MediaWiki since 1.18, so I would say this is already done.