Unfortunately, I do not know. I payed attention just before the task creation.
Well, I went to enwiki global preferences, and changed "he" to "en". It still shows he on both sites, but it does work now.

Hello and thank you for your answer.

1. No, I do not. I'm actually talking about the button "Set your global preferences".
2. Indeed.
3. Indeed.
4. Indeed.

See also T262879.

Jdlrobson, I'm still not there.

Hello, @ovasileva, when it should start to work? It does not now.

Please do. The current format is very inconvenient.

Yes, but there is no need to visit the page for logs.

I'm talking about using it for new pages too.

Could you also consider a possibility to add a link mark as read, because for now we should click stop watching and then watch agsin to remove the log entry on-page?

Hi, @DannyS712. Please consider a possibility to use special:diff/<page creation revision>, to make the entry format the same for all pages.

Well, I think you can find them using regular wikisearch. And yes, I did fix it once on MediaWiki-extensions-GlobalWatchlist.

Fixed a little to remkve ambiguity.

@Bharel?

In T259385#6417187, @Jdlrobson wrote:

@IKhitron I've fixed the citetooltip issue, but I've found another issue with a user script - this one with https://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Ori/monobook.js which throws Uncaught ReferenceError: AddTemplateToList is not defined. Would it be possible for you to reach out to User:Ori to get that fixed?

Is there a typo in the task name?

In T258959#6338058, @Huji wrote:

@IKhitron I updated the task description a bit, without knowing the exact problem. I may have made things worse. Please edit further as you see fit. The goal is to have very clear specifications on how to reproduce the issue.

Fine.

If on particular wiki some page was created and then edited, the script shows two lines, one for creation diff, and one for all the rest.

In T255536#6287037, @DannyS712 wrote:

Because I'd like to wait until the current development is complete before tackling unexpected work (cf Unplanned-Sprint-Work)

In T255536#6287016, @DannyS712 wrote:

Yes, but I'd wait until its more complete - the extension is very much not done yet

Hi @DannyS712. Is there a way that I can inform your about some problematic issues in GW, that were irrelevant to the script, but are very relevant to the extension? I ask here, because some of them are a part of the functional frontend.

Iniquity, as you asked.

Well, I think it affects all the users, it's just too difficult to pay attention that the displayed data is wrong. A pity.

Hi, @DannyS712. Congrats. I can understand why you've declined all the future requests. But I do not see why to decline this. The main software engineering rule that I teach my students every year is "Never make red refactoring". If something is broken, you can't convert the script to the extension, you should make the script green first. Only if you're going to forget about the script code and write the extension from scratch. It's possible, but it's a waste of time. Not saying that it will be broken for script users in the four years that will take to write and deploy the extension.

The hewiki site should use secondary parent in 97.2% articles. Without this feature, we are forced to write very ugly and non-exeptable code in hundreds of templates.

In the last twenty minutes this was happened on many wikis at the same time, thanks @DannyS712 for his global watchlist script. And stopped at the same time, so it is not local.

In T218511#6141902, @Etonkovidova wrote:

@IKhitron - as far as I could see the gadgets you mention are not on Special:Preferences#mw-prefsection-gadgets list?

It is there. WLM, the last one in Watchlist subsection.

Thanks, but just to know if there are more than 1000 (for example) is not enough. If the number is 100, one should not read them quickly. If it's 900, they should, because it will be 1001 soon. This is why I've asked for a number.

In T218511#6117158, @kostajh wrote:

@IKhitron can you please post detailed steps of what you did, what you expected to see, and what you saw?

• About 4,000 pages.
• A categorization filter only.
• Sorry, I do not understand. How can one see filters?

... And today.

It happened yesterday for the last time.

Found the problem, @DannyS712. Forget about it.

Found the problem, @DannyS712. Forget about it.

With html element attribute? Not realistic. Let's see the console later on.

Weird. Well, it's the same Chrome on which my Watchlist Manager new tabs work well...

In T245455#5962456, @DannyS712 wrote:

Done in 8.3.3

Very well. Thanks a lot.

In T246876#5958277, @DannyS712 wrote:

Oh, okay. Can this be closed?

Indeed. The commas are fine, by rtl syntax rules, if you're talking about the spaces at the left side of the comma.

In T246876#5958124, @DannyS712 wrote:

Can you try it now? I've deployed the change

In T246876#5957924, @DannyS712 wrote:

@IKhitron sorry about that, forgot I needed to deploy this. Is there a test case I can look at to see the current failure and the new fix? In the future, feel free to post a ping if I forgot to do this

Here you are, the current state:

In T245298#5941826, @DannyS712 wrote:

I tried with Chrome, and it works for me

In T245298#5941786, @DannyS712 wrote:

I don't have firefox installed, sorry

In T245298#5941781, @DannyS712 wrote:

Cannot reproduce

In T245298#5941729, @DannyS712 wrote:

What skin, and what site?

Vector. Ruwiki.

In T245298#5941714, @DannyS712 wrote:

Are you using the latest (development) version?

Yes, I do.

In T245298#5941697, @DannyS712 wrote:

The bottom list of empty sites should be collapsed... is it not?

No, it isn't.

@DannyS712?

In T245298#5906081, @DannyS712 wrote:

{{done}}

Continuing working. Opened two windows on hewiki with GL on the same wiki, emptied all, waited to a new edit. Clicked Refresh on the first, get nothing. Clicked F5 on the second, get the result. After running a query on both consules, get the same output:

var api = new mw.ForeignApi( 'https://ru.wikipedia.org/w/api.php' );
api.get( {
    action: 'query',
    list: 'watchlist',
    wlshow: 'unread'
} ).done( function ( data ) {
    console.log( data );
} );
Object { abort: abort(), state: state(), always: always(), catch: catch(), pipe: pipe(), then: then(), promise: promise(), progress: add(), done: add(), fail: add()
 }

Well, working on this in meta:User:IKhitron/Global Watchlist.js. Now I'm certain that the problem is in script, in api usage, and not in api itself. This what I have now on a console, while there is no wikidata in the list:

Yes, you can. You can remove the Refresh button, because it can't work as promised. In any case, I'll try to find some time to investigate this. Seems quite impossible that api returns different answers in different tabs at the same time, depends on the screen layout, which this api even does not need to see. Maybe the api just gets wrong parameters from the script in this case - timestamp or something else and as a result of this return wrong answer. Especially when we can see the right answer on the console, and it must come from somewhere, it is new, so couldn't remain from before. @Masumrezarock100, can you help in this investigation, please?

Nevermind why. The result is that the button does not do what it supposed to do.

So it will remain there, but will not work?

Exactly what I said, you can't use the refresh button, because api does not return the right answer.

I do not understand. Do you mean that you're going to remove the refresh button entirely, because api does not support its functionality? And there us nothing you can do?

I understand now. Thanks, I'll think if I can do it.

Funny. Of course, but all I want is avoid doing this hundreds of times every day. Now I run attr in console every time. Unfortunately, I couldn't find a way to catch the moment when all the lists are shown, so javascript could do something.

Sorry. I meant @DannyS712.

One more observation. I did a lot of tests in the last couple of hours, and can focus the problem much better.

1. Open the GW.
2. Open in other tabs and read all the shown diffs for some wiki.
3. Click refresh.
4. See the list is gone to globalWatch-col.
5. Wait until there will be at least one new edit from that wiki.
6. Click refresh.
7. Expected: The list moves from globalWatch-col up and shows the new edits.
8. Got: The list remains in globalWatch-col without showing edits.

Thanks a lot.
P10428

OK, but once again, if the user can set the new value in global.js only, why do you need to do something with settings at all? If there is a new value in global.js, it will be used on each browser refresh, otherwise it will not. Why do you need to keep it in user settings if you'll never use this setting?

For example,

GlobalWatchlist@www.wikidata:getWikidataLabels wdlabels: index.php:195:11
{…}
​
Q17523682: Object { type: "item", id: "Q17523682", labels: {…} }
​
<prototype>: Object { … }
index.php:196:11

About the debugLog, where do you want me to paste it?

In T245312#5890833, @DannyS712 wrote:

There is no timeout field on the settings page, but you can still manually set one

In T245312#5890782, @DannyS712 wrote:

• If the user has manually set a timeout by previously editing the settings, the timeout should be kept when saving again

The user cannot set a timeout by editing the settings, because there is no timeout field in the settings.

@Danny, we're talking about different things here. Let me try to explain once again. I do not talk about pinning. I talk about the state when all edits lists will start un-collapsed and only the bottom list will start collapsed, because no one needs it, except for special occasions.

Do you mean to spend an hour to open all the objects again, or the new one you've added?

No apologies are needed. I'm the stupid one here.

I just quoted the last line. Not meant that my answer is to this line only.

In T245312#5889996, @Masumrezarock100 wrote:

The meaning of this part should be obvious.

In T245312#5888660, @DannyS712 wrote:

It'll be awhile before I'm motivated to do this, because I'm not planning to use it myself, but if anyone wants to submit a patch please do so:

• Can be submitted as either a git patch/diff, or a fork on enwiki or meta (so that I can use Special:ComparePages)
• The config setting should not be added to a user's preferences if you are using the default
• The config setting should be kept when saving new settings
• No new field should be added to the settings page

So, what do you say, @DannyS712?