Can we keep one of the "Waiting for an available worker" reports open so we can ping you without opening up a new task every time it happens? (it seems dead atm)

Also https://github.com/OpenRefine/OpenRefine/issues/6580 I'm guessing

3.7.9 working as expected. Thanks!

@rook Create a simple project with data from clipboard, like

ID,taxon
120,Cedrus atlantica
121,Cedrus deodara
122,Cedrus libani
123,Larix decidua
124,Picea omorika
125,Pinus cembra

Then in "taxon" column from the drop-down menu choose Reconcile>Start reconciling...
Select service (any of the two links above)
Normally, there would be something in "Reconcile each cell to an entity of one of these types:", like "Taxon".
"Start reconciling..."
That should return some matches (you'd see blue links to wikidata items in that column).

@Reedy, primarily Croatian (hrwiki) because a user complained to me that [[mišić]]ā isn't working (though [[mišić]]a is), but also English, as I mentioned above, because the two examples on the Help page do not look like they should (according to the descriptions there).

@Samwalton9-WMF: I checked again with my other account and on enwiki, hrwiki, and testwiki — clicking on (thank) at Special:RecentChanges did work inline until I pressed the button [(oo-ui-image-progressive) View new changes since 00:00, 22 March 2024].
Live updates will kill it as well.

How about...
Either
A) add a shortcut somewhere in MW software to do a null template edit whenever its /doc page is saved (not everything has to be perfect)
or
B) add a note next to "This template is missing TemplateData, and its parameters have been autogenerated" so people know what's happening.

I short-circuited the translation, which is now only valid for 000's. If that's what this number will ever be, then we're fine. If the translation will show up somewhere for other numbers, it'd be good to have PLURAL working, because:
100000 članaka
100201 članak
100202 članka

@Osps7 Unfortunately, this might be impossible for any users to debug. A developer should start translating a (long) article, leave it open over a day or two, monitor what's happening from both browser and server side. Close the browser, re-open the translation, remove wikilinks, edit the wording, etc.
For me, the tool was reporting it was saving the changes for over an hour. Two days later they were gone. I don't really know how to trigger this behavior, and trying to figure it out while doing anything useful might be a huge waste of time (as it was several times by now). The browser console is full of errors, of course, but it's hard to tell which ones were relevant over the course of a few days.

A while ago I reported (T346653) that translations are not being saved once the source page had changed, but there were notifications of something strange happening.
Now I'm observing the problem of this ticket while translating en:Photosynthesis, which has not been changed in the last 10 days.

@Esanders , I still see it on both hr.m.wiki and test.m.wiki.

Now it's not only mobile vs. desktop, but mobile itself changes its state considerably depending on the screen size. Things, unsurprisingly, are broken: T350438

This probably has to do with the diff tables becoming 'responsive'. The switch happens at the at the same time as I make the window narrower (see screenshots). Both scripts inject the diff tables into DOM, though not before they're told to and the problem is there before they do.

Narrow: the gray icons appear and the elements are all over the place

In T348869#9275250, @Samwalton9-WMF wrote:

Huh - I'm surprised to see de.wiki with such low numbers here. I wonder why that is. FlaggedRevs maybe?

Currently, Vector 2022 re-uses MediaWiki:Wikibase-editlinkstitle and MediaWiki:Wikibase-addlinkstitle from other shell(s), which are tooltip messages and can be quite long in languages other than English. In drop down menus these are then wrapped, which looks and feels bad.
I made them short(er) for my language, but a user complained.

@Peachey88 So that could be this message (Wikimedia:Portals-wiki.entries). I could change it to genitive plural (članaka), since the numbers we're showing are round thousands (000), then hope it's not being used anywhere else.

@Umherirrender: Thanks. All clear, but it took me some time to realize that useve=false does nothing. When you read https://www.mediawiki.org/wiki/Extension:InputBox, you're under the impression that the opposite of useve=true is useve=false. So maybe only that page needs to be updated - somehow.

@matmarex, when you're autocreating you're coming in already logged in from another wiki, so there's already a global account with global_user_editcount well defined on other wikis.
When you're creating, all I want is global_user_editcount be 0 instead of undefined.

In T345632#9149347, @matej_suchanek wrote:

When "createaccount" in action is true the variable global_user_editcount seems to be null

I think you mean it isn't set at all.

@rook I haven't observed it since the latest upgrade to 4.0
(reporting that EVERYTHING is finally working fine!)

Good news, @rook. Nothing in the last 60 minutes of heavy testing seemed suspicious: my notebooks are loading, running reasonably fast, no resets, no JS error messages in the console. It lets me save the notebooks (save button is not disabled this time). FF is showing low energy impact of the paws window in about:performance. Only switching between jupyter notebook tabs takes a little too long, 1 to 2 seconds, but that's pretty much all that's different from my local jupyterLAB.
Previously, it wouldn't take me more than 1-2 minutes to see all the glitches. I hope this solves the problem; will let you know if anything pops up.
Many, many thanks!

@rook Yes, my local minikube behaves pretty much the same as those at test-hub-paws and hub-paws-dev (with the notebooks that I know would trigger the problem).

@rook I followed your recipe and was able to test everything off of T338981. (Un)surprisingly, all the symptoms are still there: the notebooks that I used at PAWS are slow in FF, Chrome and Chromium, the javascript errors are still there, and the view is resetting itself. Those same notebooks work fine in my regular local installation of jupyter-lab.
If you think of some other tests I can try, I'll be happy to help (though I can't say I know what exactly I'm doing, and will probably not have time to learn more about it). I wonder if the guys who reported the saving issue in T310622 would see this slowness with their "problematic" notebooks as well.

@rook: apologies, I've been mostly away from my laptop for over a week. Just got an email update from this T. I can do some testing, but it won't be before Friday night.
I haven't read the instructions yet. Before I do, please let me know if today's closure will affect my ability to test. Sorry again, and thank you.

@rook No, it wasn't an extension: I've had all extensions disabled for a day, and right now the "thing" at test-hub-paws.wmcloud.org is pretty much unusable (even worse: unpredictably unusable): extremely slow, the view is resetting itself again today, and second after second the console is throwing (now that's new!) messages like

@rook I do have a few extensions in FF, and none in Chrome since I rarely use it. All recent test were done in private/incognito windows, which is supposed to reduce the number of running extensions. I will disable all FF extensions and see if that helps.

Nah :(
I checked twice in Chrome and once in Firefox, shift-entering only when the previous run was complete. Surprisingly, it didn't take more than 10 cells for the reset-to-top to happen. I wouldn't say that the overall slowness is my problem (though I notice it from time to time, especially - as you say - in the first few minutes). Right now it's the cell freeze, followed by the focus reset to the topmost cell. Also, just a few hours ago my forVRookCOPY.ipynb was working fine, now I cannot even open it. No changes were made except for the cell runs, and the notebook was automatically saved.

@rook At some point someone mentioned this ever growing file .jupyter_ystore.db and NFS. I was just reading https://jupyterhub.readthedocs.io/en/stable/explanation/database.html, where they specifically say "The SQLite database should not be used on NFS. SQLite uses reader/writer locks to control access to the database. This locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. Therefore, you should avoid putting SQLite database files on NFS since it will not handle well multiple processes which might try to access the file at the same time."

Did everything from Chrome/Linux now. Before I copied any files: I only thought the server took too long to respawn... some 2 minutes. Firefox complains about a script being too slow before I click on any files, Chrome does not.

@rook Hm... sorry, I do not remember logging in before. I did check if there was https://public-paws.wmcloud.org/User:Ponorić/ - there wasn't.
Sure, let's clear it out and I'll try again.

@rook no problem at all!
I logged in with my secondary account. No change. Slow server start, slow file load with browser complaints about a script. Resets with TypeError: e is undefined.
Noticed at least 20 error messages in the browser console as the server was respawning of the following kind:

There were signs of it being weird even before I !pip installed anything (that slowness). It's the same JS problem as before.

@rook : no change I'm afraid. Some files were not loading, and the one that did load was kind of slow (slowing down my whole browser).

@rook: after a quick test I can confirm these old traits:

• the browser complaining about a script slowing it down on the load of the "problematic" notebook (works fine in v. 3.4.8),
• the view resetting itself to top of the notebook upon running some 30 cells in sequence (browser console showing: TypeError: e is undefined; TypeError: undefined has no properties, and similar - for index.es6.js:257:16),
• jupyterlab failing to load that same notebook (appears blank)

Any idea what's happening with the latest patch, why is it not in the wikis? ccnorm("ČĆŽŠčćžš") is semiworking.

@rook I used it for an hour or two yesterday, and this morning it's still running fine. I think this was the most reasonable decision. I don't think I miss anything from the newer versions, and tbh I don't remember seeing anything *that* new in them. Would it be possible to install and run 4.x from a different URL in the future? I'd be happy to help testing, just LMK.
Many thanks!

@rook, first of all: THANK YOU very much for taking care of this.
It looks promising — I was able to load the files the old version was getting stuck with, the interface appears to be running much faster, and in my quick test the notebook view does not seem to be resetting itself (as I reported on IRC). It will take a few days for me to see if the old saving bug (T310622) is gone; I'll keep you posted about that.

Thanks, @cscott. This is actually quite easy to reproduce: add a character anywhere within https://hr.wikipedia.org/w/index.php?title=Antika&uselang=en&veaction=edit and before saving just "Review your changes".

Editing Template:Infobox film on test.wiki and "Previewing page What We Do in the Shadows with this template". Got this:

Here to report the same problem, but for unpatrolled files with a single revision. If left unpatrolled, then deleted, the file still shows in recent changes as unpatrolled, and API returns it in the list of unpatrolled changes. All delete actions (files, pages) should mark all unpatrolled changes as patrolled; what's the point of having to patrol something that no longer exists?

@Jdlrobson: yes, that helps, though I'd expect this to work out of the box. Thanks!

@Jdlrobson, please have mercy on patrollers, remove all this clutter and add nothing more. Imagine someone added those "pills" or any repetitive content after EVERY line of the code you write.

I feel like we're doing things here just because we can: adding more complexity where there are already decent solutons. Somewhere near the top of your screenshot, @matmarex, there's "Filter revisions" drop-down menu that does all this and more, without adding same, rarely used links to hundreds of listed changes.
As for the wishlist, I believe there are more people who oppose this change than there were supporters of it here.
This could be a javascript gadget for those few who really need it (right?), not something imposed on everyone by mw core.

In T326399#8504347, @stjn wrote:

Easier solution would be to just revert the change in T301063: The "tag name" on the change line should link directly to "tagged changes" entirely.

With this change tags got very long, and the repetition of "(other edits)" all over Recent Changes is too distracting. In other languages "(other edits)" can get even longer.
On mobile devices each tag has a frame, and many tags with this addition use a full line (see German example in T326399). It's not uncommon to see 3, 4, even 5 tags on some changes, and more screen space used by the tags than the change itself. All this clutter so that (very) few users could (sometimes) filter by a tag, a feature already available in the filter by tag menu???

Thanks @Daimona. The execution times are what I typically see in filter statistics, though the numbers vary. All filters that I'm managing run in under 0.5 ms, but the one with a list of 30-something words is always above 2 ms, and on some days up to 5 ms. A filter with about 15 rlike invocations (short patterns - historical reasons) on a ccnorm'ed string runs in under 0.5 ms. A similar filter with a ccnorm_contains_any shows an average of nearly 3 ms today. Btw, is ccnorm_contains_any() just contains_any( ccnorm() )?
I don't know if this is much of a problem IRL. I see people trying to optimize their filters (make them 'green'?), so I though this might be something worth investigating further.

I see the code page_namespace in "^(0|11|20)$" more often than I'd want to (probably because of the note here). This is wrong: in does not test regex patterns, only literal strings. The proper way to check namespaces is equals_to_any(page_namespace, 0, 11, 20).

@rook My session had some 4-5 tabs open and only the one that was running the code (few hours or so) stopped saving the changes. I really don't know how it all works, but it's different from my experience some months ago. Back then even if there was a disconnect, my notebooks would respawn, and the kernel would keep all variables alive. Now nothing really tells me my session got disconnected, I mean, all notebooks execute the code, even the one that cannot be saved.
I'll try to find a way to reproduce this in a minimal notebook; will keep you posted.

@rook No, restarting the server does not help. Only when I close the tab and reopen the notebook I'm able to save it again, but by closing the tab I also lose all the changes (Save does nothing, I can only close it by Discard-ing).

@Harej, there are two cases:

We've had many cases of this happening on Croatian Wikipedia, and I've tested it myself: you let CX2 do all translations, do some edits to the text so it would let you save it. Repeated references are all bad, example of me fixing it is https://hr.wikipedia.org/wiki/Special:Diff/6327071/6327095. If a reference is defined on its first ocurence as

<ref name=":1">{{Citiranje weba ...}}</ref>

all other mentions will be added as

Given how many clicks it takes to mark a change patrolled, I'm surprised that there's no option for patrollers to quickly view a diff in recent changes and (at least) mark it as good without going to other pages (and back). So much time of our most experienced users is wasted for patrolling, having this in Navigation Popups, if not in the wm software itself, should be high on priorities list.

In T291751#7382722, @Aklapper wrote:

Why should we add ~300 project tags to most tasks (when an issue happens on ALL languages)

My support for this, it would be much easier to track hr.wiki related tasks. I'm surprised there's no such tag for all wm sites by default.

@JoKalliauer Your timing results for Inkscape were a big surprise for me, and I ran all your tests in inkscape --shell on my little laptop.

The following two special pages have weird translations: it's possibly some Slavic language, but definitely not Croatian. Can someone please change to the names in bold:
Special:Impact -> Posebno:Djejstvo -> Posebno:Učinak_uređivanja
Special:ClaimMentee -> Posebno:Tvrde_pridošlica -> Posebno:Preuzimanje_mentorstva

@Urbanecm_WMF It's already Wednesday and the train should be arriving tomorrow, but can you make sure translations later than Sunday are on it as well... I mean, mixed en/hr messages should not be too bad, but if this is a two-click operation for you, it'd be great to have the full interface translated. Thanks!

Few questions:

1. The help panel button (the blue bottom-right-corner round button) does not show up when reading a regular random page, but does when it's being edited, either in VE or CE. It does show up when reading random pages in other namespaces, such as Wikipedia, User, Help... and also when arriving on a regular page from "Suggested edits". Is this intentional? Why is the button not there when one's on a random article page?

@Trizek-WMF Strange, because everything on my Homepage tab is still mostly in English. We're at 88% translated, 14% reviewed.