For a warning message to be timely and not-too-intrusive it would need to be at Special:Preferences#mw-prefsection-watchlist "Watched pages". The six checkboxes there provide for automatic additions to the watchlist. But a real solution would be much better, such as the possibility of downloading a complete watchlist in editable form and allowing uploading of a properly formatted list, possibly only to an empty watchlist.

Can this be solved with a change in User CSS or JS? Can it be made to allow such a solution?

Very useful and actually used on English Wiktionary, principally for watchlists and recent changes. Is there an important storage cost issue?

Leban

1. Virtually all problems may have technical solutions. The issue is whether a broader population of interested parties should be involved in the decision making.
2. Coming up with a practical resolution to this might involve basic practicality as well as consideration of what users may expect based on their experience on competing dictionary websites.
3. The Wiktionary lists of offensive or vulgar terms is far from complete, accurate, or authoritative in any language.
4. It is not a question of whether any one user, such as Leban, has a problem with broadening the coverage of the proposed special treatment of certain terms, but whether it retards users in general in their efforts to gain access to the possibly controversial (and therefore likely important) information they are looking for.

Why should this be limited to English words offensive to (some) English speakers? What about English words offensive to (some) foreign-language ("FL") speakers? What about FL words offensive to (some) FL speakers? What about FL(i) words offensive to FL(j) speakers (j not = i). What about those who find "God" blasphemous, preferring "G-d"?

This does not seem like a technical matter within the purview of technicians, but rather a policy matter. Moreover it seems as if it gets near the core of what the projects represent to the world.

The 'example rendering' above shows each reference taking up a line of screen space, though containing just a few characters. Can't we make better use of vertical screen space by lining up the page references horizontally?

I would think that a "design choice" that most observers here find appears to be a bug is a poor design choice. I find it a little odd that poor design choices of this kind are supposedly not with the purview of phabricator. Since I am sure that this is not the first time a "design choice" was perceived as a bug, I am also disappointed that there isn't a way to export the comments to a more appropriate venue and to direct users to a specific page where the discussion can get attention from the responsible parties, assuming some will take responsibility.

But shouldn't a soft launch allow the rapid correction of a mistake and not the rejection or low-prioritizing of such a correction?

Why is this lowest priority? The page is intended to promote WMF to the general public. Isn't that important? The insertion of some bit of text from any language not the user's own is confusing at best and may be off-putting or make the whole effort and WMF look amateurish.

A relatively fast-loading, but typical, example of the resulting problem is at:

It's easy to think of use cases that might have someone asking someone else
to do something with material prepared offline or to execute or resume
executing a known routine. When there is an indication that task execution
has commenced thanks might be warranted. How common such situations might
be I don't know. I have been grateful for someone resuming execution of a
long-dormant bot at Wiktionary.

Projected availability date for each file would be ideal, based on all
known contributing factors, as soon as they are known. When something goes
wrong, projecting availability 'no sooner than" a date would be even more
valuable.

For a user a problem isn't resolved until the operation in question has
been run with the desired tools, automation and integration somewhat
predictably. I keep on noticing that scripts have to modified, schedule
smoothed out, etc. Thus the user problem doesn't really seem resolved at
the time all associated tasks have been performed and marked as resolved.

Now it looks like we're getting the dumps processed TOO FAST.

I already use an RSS feed service to let me know when the dump of interest to me IS available.

Thanks for leaving it open for now. I hope it can be closed soon based on demonstrable success, even if it subsequently blows up again..

See T89273 which led to the changes, intended to be and apparently an improvement in the reliability of the dump process.

Re: "ought to update the docs"

Doesn't this approach increase the staleness of the dumps that are later in the cycle?

This schedule for running the dumps makes them a little (about a week for enwikt) more stale than they used by the time they are finished. Are there capacity/efficiency/reliability gains that offset the staleness?

Just a few more bid wikis to go before we can declare victory, at least in the battle, if not the war.

I suppose that I thought that the incomplete May dumps, eg, no pages-articles dump or enwikt should have been a red flag.

But other end-user items were subsumed into this one.

I assumed you had a sound basis for your prediction, but the prediction
isn't the fact.

If this is to be an application open to ordinary Wiktionary project
contributors, then the criterion for closure has to be something like "what
failed ran", not "One person (no matter how skilled!) confidently predicts
that what failed will run".

Opening for now, pending completion of full cycle of runs.

Why is this closed before we know whether the fix actually fixed things all the way to completion of the runs on which the process choked before.

How would we know it was a small number of users? A small number of contributors perhaps. It only effects what we estimate to be the more than a million unwatched pages at English Wiktionary. If we could do some kind of retrospective review of unwatched pages that have been changed since the first few minutes after their creation run at least once we would know for a fact whether it should be low priority as a continuing matter,

Why is the priority now low? It looks like scanned arbitrary decision to me.

Do the partial-dump wikis in the queue have the place indicated or will they jump before those that have had full dumps more recent than their last full dumps?