The answer is accepted, thanks a lot.

I see. Thank you, I'll thing about it.

@Prototyperspective, now I know much more about the labels, and I'm not sure any more how to do this, though I do want to do this. Could you describe how do you see it, please? The obvious way - show on Special:GlobalWatchlistSettings the list of user's labels and choose some of them for collapsing - will not work, because the labels list could be changed any time after this.

In T416947#11611210, @Prototyperspective wrote:

Because this one asks for something different.

You mean making the setting a default / changing the default display (something different) versus enabling the user to configure the GW so via introducing a new setting (this task)?

How exactly it can be done? I have know idea how to determine the extension users.

No. I mean this task is about every mode. Now we are talking about non-grouping mode.

One could display a note about the GlobalWatchlist linking to a survey. Don't know anymore how these notices are configured (it's not centralnotices I think). However, it would probably be best if it asked about several settings, not just this one to ask what the default display should become and maybe even further things. So for example if a setting is added to move the history and xy changes buttons to the front to a nonvarying location before article title, also whether the buttons should be displayed there by default or as they are now.

There's probably also other things one could ask such as which things people need or would like to have in the GW and what their greatest troubles with it currently are etc which could serve as a basis to improve it most effectively.

It would however be biased toward the user-set that already uses the GW and against those would like to use it if certain things are implemented so one would also post about the survey in the Tech News post and/or via new threads in VillagePump/Technical boards.

I see, but not so sure it's viable. The task that fixes the local time problem, the most "visual" problem in the extension for me, is ready, but stuck many weeks because there is a need to decide how to say to everyone the clock is changed, and how to implement it. And every timestamp is still in UTC.

In T417319#11614274, @Lydia_Pintscher wrote:

Is this a duplicate of T395178 or T53044?

In T416947#11603335, @Prototyperspective wrote:

I would bet quite a lot that the default is not "rare used". It's most likely the most-used mode. Only a subset of users test and change a lot of preferences. That it's rare used is an unsubstantiated hypothesis and I'm quite sure it's false.

I can't know for sure, I just asked people from wikipedia I'm usually talking with.

Why would it need a new task.

Because this one asks for something different.

Who are those people? I'd wonder why there is special attention payed to what they say which implies they have some sort of privileged position on this instead of this being a matter of the community overall (or at least users of this extension overall), not any particular small group within it.

They are those whom I attach to my every Gerrit change in this extension that I submitted in the last weeks since I started to do this. Any other person invited too, of course, but there should be at least them. From my experience most of them will not participate, but they should be aware.

It makes a lot of sense to base this on some sort of survey of people actually using the Global Watchlist and/or interested in doing so, thanks.

How exactly it can be done? I have know idea how to determine the extension users.

In T416147#11609470, @Samwilson wrote:

Should you also check the case when the content page does not exist?

I'm not sure I understand. Do you mean when you label a watched non-existing page, and then that page is later created? That works, as far as I can see, with the current set-up. A page and its talk page are given the label, regardless of if either exist yet.

(Moving back to in-development because there's still a maintenance script to write here to backfill the missing talk pages.)

Should you also check the case when the content page does not exist?

Yep, found it. Well, it's default, but rare used mode. So this it what I can say. I can't make distinct changes to the watchlist, like "move this one here, and that one there", because everyone can ask their favorite, and there will be hundreds of possibilities. I can theoretically agree to implement "Change the full layout for non-fast non-group mode to accordant layout in Special:Watchlist in user settings". Which means that it will looks exactly as the same mode in Special:Watchlist, as I could found at this picture, with adjustments to needed or missing functionality without changing the order, and people could turn it on and off, such that in non-fast non-group mode they could see it as now or as in the picture, by their choice. I can do it after creating a new task especially for this, and after two weeks discussion there, with the people that I usually invite to such discussions about this extension, at least. If they agree, I will do it. If they also decide that this mode will be default, I will do this too, otherwise it will be opt in.

Please provide the Special:Watchlist user preferences that put time after the page title, I never saw that in any of many possible modes, as far as I can remember. I need them to decide if I'm going to do this or not. Thank you.

@Tol, I think it's easy to do for me, but can you explain me what is the reason for this? Do you really expect there will be enough people that want to have 1065 sites in the list? It is huge settings page and a lot of running time to fetch the data.

A report. I spent hours today trying to solve this somehow. If I can't use combobox, I tried some other options that do not need for me to add any javascript code on purely php Special page. Adding a single dropdown list with 1065 entries is completely non-practical, there should be some search. I can theoretically add eleven lists with 100 wikis in each. But they will return only one result. So, for 10 wikis we'll need 110 dropdown lists, which is ridiculous. I can't see any solution until T154027: HTMLComboboxField does not provide autocomplete in ooui format fixed.

Thank you for the feedback in the Gerrit, @Lucas_Werkmeister_WMDE. Indeed, looks like all your comments are about existing code, not the current change. All of it was written by Danny, not by me, and I'll need time to understand and to fix them. But I'll definitely check them out and try to write a new change in the foreseeable future with all you suggested. Possibly will create a new task for them and add you as subscriber.

In T416619#11588776, Ammarpad wrote:

I can reproduce. The key is deleted by Vector legacy. I believe ruwiki still uses it as the default skin.

In T413967#11585983, @Samwilson wrote:

I'm not sure I understand, why would it be better to set labels via action=setnotificationtimestamp rather than action=watch? But if you think it's a good idea, then feel free to open a task for it! (We should keep this one about the deployment.)

One more idea for you. Add a single label optional parameter to setnotificationstamp Action API, alongside with entirewatchlist parameter. Hope you consider it. Thank you.

I don't know what to do. There is no answer for 15 days. Tacsipacsi almost never here in the last ten days, probably from some IRL reason. Wait more? Continue with the change?

Great. Does this mean we can wait to get one day a labels dropdown menu when clicking on a page watching star, alongside with the dates menu that is there now?

In T413967#11577136, @Samwilson wrote:

Well, sometimes that do not emerge with many chcekboxes.
Well, sometimes they do not appear after minutes.

If this annoying behaviour persists, could you please open a new bug report? Thanks!

Very well, but I'm not sure how much I will use them until T416154 is resolved.

set this label to that page in my watchlist API

That'll be done in T416291.

And btw, I just thought about it, could be nice to add a "set this label to that page in my watchlist API".

In T413967#11573331, @Samwilson wrote:

So, until then we can't use the new feature at all?

No, you just have to click one or more checkboxes and the disabledment will disappear (or the enabledness will emerge).

Well, sometimes that do not emerge with many chcekboxes.

You mean if the buttons do not appear at all, I need wait?

Yeah, just make sure the page has completely finished loading. If it has, and they still don't appear, then that might be a bug. But it sounds like you're getting this intermittently, is that right? Like the buttons load sometimes and sometimes they don't?

Well, sometimes they do not appear after minutes.

In T413967#11573298, @Samwilson wrote:

Thank you for your answer.

The greying out of the buttons has already been done away with in favour of popups that explain the states in which the buttons will not do anything (e.g. if you don't first select any pages to apply labels to). Those fixes will go out in tomorrow's train.

So, until then we can't use the new feature at all?

As for the buttons not appearing at all, that's because they're front-end only (i.e. Vue components) and so the page's full JS has to load before the buttons will appear. There is not yet a no-JS interface for adding or removing labels.

You mean if the buttons do not appear at all, I need wait?

And thank you for the reminder about the watchlist API; I've created T416154. Please amend as you see fit.

Exactly, thank you.

In T415450#11573267, @Lucas_Werkmeister_WMDE wrote:

In T415450#11571500, @IKhitron wrote:

@Lucas_Werkmeister_WMDE, could you tell me, please, if the fact that Lexemes labels do not get language fallback is a bug or a feature? Thank you.

Lexemes don’t have labels, they have lemmas. When displaying lexemes, all lemmas should be shown at once (example), so language fallback doesn’t really apply.

So, it's a feature. Thanks a lot.

And btw, why wbsearchentities ignores all the language parameters? The call https://www.wikidata.org/w/api.php?action=wbsearchentities&format=json&search=E1&language=es&strictlanguage=1&type=entity-schema&formatversion=2, and another without the strictlanguage flag, return both the English results, while the Spanish do exist for this page.

language= controls the language of the search input, uselang= controls the language of the result output. You probably want to set both of them (language= doesn’t really matter if you’re searching for an entity ID, but it’s a required parameter so you can’t omit it either); strictlanguage= shouldn’t matter when searching for an entity ID.

I see. Great, I can fix it now. Thanks a lot for your help.

Well, looks like good things are happening, but they are stuck in the middle or something. Today we get a guided tour on Watchlist labels at Special:Watchlist. Creating new labels works. But the buttons "assign labels" and "remove labels" sometimes appear greyed, and sometimes does not appear without a reason. Is there a chance there are more Gerrit changes to deploy today, maybe? And couldn't find the most important task, at least for me, that adds the labels data to query/list/watchlist entries Action API call. Still, thanks a lot you're working on this.

In T416000#11571861, @matmarex wrote:

In my experience the sites are currently always shown in the order defined in settings. I thought it was a feature :)

I do not know enough to see the difference or at least to understand what you just said. So I said the tests are much slower and they are, I waited at least triple time this time.

In T416078#11571580, @Jdforrester-WMF wrote:

In T416078#11571578, @IKhitron wrote:

It started to run, but extremely slow.

Do you have some data for this claim? From my monitoring, castor jobs are running and exiting in 5–25 seconds as normal.

Sure. Today just before this bug:

It started to run, but extremely slow.

@Lucas_Werkmeister_WMDE, could you tell me, please, if the fact that Lexemes labels do not get language fallback is a bug or a feature? Thank you.

In T416000#11570940, @matmarex wrote:

If this change would cause the page content to shift as the data for each wiki comes in, users would still have to wait for every wiki to be finished before they can start using the page. It may feel worse than before, even if it would be faster.

Can you explain why? The page works like a feed, so each new wiki will appear at the bottom, without shifting anything at all.

In T415458#11564382, @matmarex wrote:

I think I would remove it, and just wrap the "Tags:" in <bdi> like everything else. It seems like the most complex and least valuable part of your change :)

In T415458#11564382, @matmarex wrote:

I think I would remove it, and just wrap the "Tags:" in <bdi> like everything else. It seems like the most complex and least valuable part of your change :)

In T415458#11563982, @matmarex wrote:

I don't think I understand why we have to fetch the "Tags:" system message in a different language from the rest of the interface, and *only* do this for Wikidata rows? It seems that would just make them inconsistent. The tags for every wiki are displayed in that wiki's language.

Unfortunately I can't continue this conversation on these terms. I would just not answering, but my own believe always was that not to answer to anything except "you are welcome" without telling is the worst in the human behavior, so I do answer, accordingly.

Exactly. Thank you.

And by the way, there is a button "mark as seen" in Global Watchlist, it helps.

Btw, there is another workaround to mark the page. Check it's talk page (or it's page for a talk page) does not appear with edits/logs in the watchlist, and double-click the watching star (remove from the watchlist and return back), or the same using an "x" button in the watchlist.

I found a much easier way to get language direction. Rewrote the 3. above, and now there is no need in an extra API call.

In T413701#11553995, @Jdforrester-WMF wrote:

In T413701#11552097, @IKhitron wrote:

It works, thank you. Is there a chance to close the gap, or it's too late?

No, the old e-mails to mediawiki-commits@lists.wikimedia.org aren't archived so can't be re-processed, so it's not possible.

A pity. I hope somebody wants to write a one-time script that retrieves the data from the pages like https://www.mediawiki.org/wiki/MediaWiki_1.46/wmf.10/Changelog with checking the Gerrit, or just looks over the jenkins-bot log, to add all the missing project tags. But looks like it's not going to happen.

In T388336#11552570, @Prototyperspective wrote:

Danny could do this, I don't, I'm not the official ainfaner.

Don't know what you meant with ainfaner but maybe maintainer or developer – I hope @DannyS712 sees and considers this issue. Thanks nevertheless for your other developments of the GW.

Thank you, fixed the typo.

In T415450#11553296, @Lucas_Werkmeister_WMDE wrote:

wbsearchentities (not wbgetsearchentities) isn’t really the right API for this, but there isn’t another API either – EntitySchema has very poor API support, as a result of our decision years ago to not base it on Wikibase. I guess it’s possible to implement GlobalWatchlist support this way, yes.

Alternatively, GlobalWatchlist could have some sort of hook or extensibility mechanism that allows an extension, such as EntitySchema, to customize it, and then it would be EntitySchema’s responsibility to figure out how to display the page title properly. (This would be fairly straightforward in PHP; but given that IIUC this all happens in JS, EntitySchema itself would still need some kind of API to access the labels. But at least it would be encapsulated within that extension.)

It works, thank you. Is there a chance to close the gap, or it's too late?