Don't use conpherence with me, I won't read nor reply. Instead write me by email or my user talk on mediawiki.org.
- User Since
- Oct 10 2014, 2:32 PM (184 w, 4 d)
- LDAP User
- MediaWiki User
- Nemo bis
Mon, Apr 23
For now I've just restarted the old way, adding a False for the force argument (to reduce redundant lookups) and a try/except.
Sun, Apr 22
To speed up things, it should be easy enough to run the longer function in the background with https://docs.python.org/3/library/multiprocessing.html
Sat, Apr 21
This report is a collection of issues and it was closed despite having a subtask which was open (until today). Better discard this and continue dealing with specific issues in specific tasks.
This was fixed at some point. A suggestion was correctly generated:
$ stat ~/www/python/src/cache/2015_in_paleontology.json File: ‘/data/project/oabot/www/python/src/cache/2015_in_paleontology.json’ Size: 8160 Blocks: 16 IO Block: 1048576 regular file Device: 20h/32d Inode: 119351899 Links: 1 Access: (0644/-rw-r--r--) Uid: (52920/tools.oabot) Gid: (52920/tools.oabot) Access: 2018-04-21 09:54:21.713825933 +0000 Modify: 2018-04-21 09:54:21.713825933 +0000 Change: 2018-04-21 09:54:21.713825933 +0000 Birth: -
I'm not sure if https://github.com/dissemin/oabot/commit/5361bf122c27ac6220fc113e1a3767fe7773f62b has been deployed already when this bug has been observed.
Declining per above. No need to add extra steps or clutter the next page.
https://github.com/dissemin/oabot/commit/9f729396ce541147adc0e768dbc9c6350216e123 was merged in February and I see it on https://tools.wmflabs.org/oabot/ . I still recommend switching to an on-wiki blacklist, but such improvements can be filed separately.
There is no point forcing users to click the same checkboxes hundreds of times.
I'm happy with the current shortcuts for the main buttons. There are two main ways I'm currently "forced" to use the mouse:
- a lot of text and assorted clutter has been added on top of the screen, so that the preview of the PDF is often below the fold and I'd need to scroll (this discourages people from checking the PDFs they're adding, should be fixed);
- when the edit fails, there is one button at the centre of the screen, quite far from the position of the other buttons: but sometimes I click it to proceed, sometimes I go back to check the page manually, so I'm not yet sure what shortcuts are most needed.
These issues should be filed separately.
Based on my survey of available suggestions yesterday, I'd say it's fixed, yes. Separate tasks exist for specific issues, such as T187791.
This is an issue in the source data, needs to be fixed there. Some directions are available from https://dissem.in/faq#missing-paper
I would decline this. There's a link to the user page, which I regularly use to reach the contributions and the undo button. Alternatively, one can go back to the previous page, click the title and go to the history. It's standard wiki editing, we don't need to rebuild MediaWiki core in python.
This is "by design". Suggestions are kept in a cache and can get stale. Usually OAbot runs rather short of suggestions, so it's currently skewed towards giving a bit more rather than less.
I find the title and description very hard to understand. Is your problem that an article is not discarded even if all the corresponding suggestions have been rejected?
Fri, Apr 20
Wed, Apr 18
Meanwhile, I don't even understand if the redis host still exists. tools-db:6379, referenced in settings.json, does not seem to connect. /etc/hosts mentions another host, 10.68.22.56 tools-redis tools-redis.eqiad.wmflabs.
Tue, Apr 17
Doesn't fit the definition of stalled.
Mon, Apr 16
The jsub error was
Fri, Apr 13
Thu, Apr 12
Why is this a problem?
Wed, Apr 11
Maybe the bug summary should be rephrased: the issue is that page previews attempt to load something that is not suitable as thumbnail.
In the graphical interface of the local wikis, this is only spotted on specific rows of Special:ListUsers, right? Or in other words, you encounter it only if you're looking for it.
Wed, Apr 4
This request is a bit too much Wikimedia-centric. The idea of the interwiki map is to hold together all the MediaWiki wikis in an collaborative division of labour (http://meatballwiki.org/wiki/InterWiki ). Wikimedia wikis might decide that they no longer care about integrating with non-Wikimedia wikis, but for most wikis the fact that an interwiki is not local makes very little difference. It's also a two-way street: do we prefer non-Wikimedia wikis to refer to Wikipedia articles, Wiktionary lemmas etc. as if they were local, or do we want to encourage forking?
Mon, Apr 2
Thu, Mar 29
Wed, Mar 28
This is not a configuration matter and cannot be changed for individual wikis. Language fallbacks involve various components and on-wiki messages (the "database" messages) are just one. See T50956 where the issue is tracked.
Tue, Mar 27
Mon, Mar 26
What criteria have you used to define those groups? I'd think a group is valuable if it relates to a specific audience, hence to possibly interested translators who would not be interested in other content.
Mar 23 2018
Mar 22 2018
Mar 20 2018
Mar 19 2018
Mar 17 2018
It would require parsing the old text, which would be slow
Mar 13 2018
Mar 10 2018
Changing to "New messages (0)" would be ok. It's arguably more consistent with "New messages (999)" or whatever the number.
Mar 9 2018
Mar 7 2018
Mar 6 2018
If the higher usage is periodic, I want to encourage setting up automatic clean up jobs after the dumps are processed
Option 2 is nice. If we find out later that the mechanics to register new languages are similar and the code gets duplicated across repositories (e.g. those which use Gettext for Django?), they can always adopt some shared syntax sugar.
Mar 4 2018
Mar 3 2018
But I guess this front end limit might not currently be configurable, at least not on a per-project basis?
The original task description doesn't follow How to report a bug , in that it doesn't describe a problem or goal but only a specific proposed solution.
The comment posted on the village pump doesn't reflect Wikimedia best practices, in particular where it suggests that once an extension is installed we commit to keep it forever because otherwise the logs would not look pretty. The real policy is that we install things when they pass some strict requirements and we uninstall them when they do more harm than good, otherwise our technical debt and interface clutter would always go up.
If I understand correctly, the summary is something like "Create a maintenance script that lets a wiki be in a clean state after Flow uninstallation". @DannyH raised the concern that Flow leaves wikis dirty.
The (public) wikis where at least one Flow topic exists are:
for db in $( echo "select dbname from wiki" | sql meta ); do echo $db ; echo "select count(page_id) from page where page_namespace=2600" | sql $db ; done [...]