Sep 28 2020
- Virtually all problems may have technical solutions. The issue is whether a broader population of interested parties should be involved in the decision making.
- 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.
- The Wiktionary lists of offensive or vulgar terms is far from complete, accurate, or authoritative in any language.
- 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.
Sep 27 2020
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.
Sep 30 2019
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?
Aug 14 2018
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.
Aug 9 2018
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.
Feb 28 2018
A relatively fast-loading, but typical, example of the resulting problem is at:
Dec 10 2017
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.
Sep 28 2015
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
Sep 15 2015
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.
Sep 2 2015
Now it looks like we're getting the dumps processed TOO FAST.
Aug 31 2015
I already use an RSS feed service to let me know when the dump of interest to me IS available.
Aug 10 2015
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..
Jul 13 2015
See T89273 which led to the changes, intended to be and apparently an improvement in the reliability of the dump process.
Jun 19 2015
Re: "ought to update the docs"
Jun 17 2015
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?
Jun 16 2015
Just a few more bid wikis to go before we can declare victory, at least in the battle, if not the war.
Jun 8 2015
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.
Jun 4 2015
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.
Jun 1 2015
May 27 2015
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,
May 26 2015
Why is the priority now low? It looks like scanned arbitrary decision to me.
May 19 2015
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?