User Details
- User Since
- Oct 22 2014, 10:09 PM (400 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Strainu [ Global Accounts ]
Tue, Jun 14
Folks, I can't figure it out from the discussion, but does this solution consider:
- users without CX enabled
- the difference between items without wikidata items and with wikidata, but no IW?
May 21 2022
Yes, I believe that table is correct.
May 20 2022
@Stang you seem to have removed the Romanian versions (see the API call in the bug description) and now Proiect:Cod Wikipedia redirects to WikiProject:Cod Wikipedia and Cod:SIRUTA:10 sends to Code:SIRUTA:10. Could you please make sure the Romanian versions are the defaults and the English only alternatives? Thank you.
May 8 2022
I added them above.
102 WikiProject
103 WikiProject talk
108 Code
109 Code talk
May 1 2022
Apr 23 2022
Confirmed working for rowiki, but I do suggest leaving the bug open until it's properly fixed.
Apr 22 2022
Do we have any workaround until the code is fixed? On the other bug it fixed itself, but rowiki has almost 100 filters.
Apr 19 2022
Checked, it works, thanks @Majavah
Apr 8 2022
It used to call the parser function. Apparently I broke that a while ago, while moving to maplink, likely because my unserstanding was that maplinks also add the coordinates to the database - something i can't find any docs about today.
Apr 1 2022
Mar 28 2022
Mar 24 2022
Note that the on-wiki proposal has been about a permanent ban on IP editing.
Mar 5 2022
Feb 24 2022
I continue to believe we need to support a version at least a year after Cloud Services have moved away from it, as described in https://lists.wikimedia.org/hyperkitty/list/pywikibot@lists.wikimedia.org/message/BSTDB6JYJ74DE3BTNWND4BAROLIXJTW5/
Feb 19 2022
Is this a duplicate of T123178 ?
Jan 26 2022
Jan 25 2022
You must create another edit in the top section of the page, save it (or preview it) and check if the text "top" is still in the edit description. It might either link to the article or appear as /* top */, depending on the context.
Jan 22 2022
Jan 21 2022
To generalize yes, but the issues I mentioned in T299380 all have a giveaway: quotes. Maybe you can work with short (3-5 words) quotes as one entity?
Jan 18 2022
It's not immediately obvious to me why 1 is a problem if 2 isn't - they seem linked. What does "enough phrases" mean exactly? Intuitively, I would say that 2 or 3 links per article should be enough for the user to practice. You could then potentially reuse the same article such as this one for other users.
As a mentor, I would recommend that you first try 3, as the number of links added per article seems a bit high at the moment, so removing some of them wouldn't be damaging. The patch should be applied as the second option, but only together with a documentation update to make the issues crystal clear. For now, we're far from that.
Jan 15 2022
Jan 13 2022
Jan 5 2022
@Jdlrobson I was able to reproduce in Chrome 96 on windows, signed out for en.wp. It seems that this codes's way of building the close window HTML is different from other such examples in the code, such as the VE (add citation popup) and ULS settings. You can open any of those, replicate the classes you use and you'll still see the problem.
@FonAfon, have you checked the translations? It looks like an ALT text of the closing icon. It can happen to show up if the text is too long - I've seen it on the mobile site a while back and it was solved by shortening the ALT text.
Dec 14 2021
Dec 6 2021
@Urbanecm I have the same complaint: since you implemented this without any advance notice (shame on you for that) we expect you to fix all the red links you created. Thank you.
Dec 2 2021
Nov 27 2021
Nov 15 2021
Nov 6 2021
Indeed, removing config.step from user-config.py solved the problem. I don't remember why I added that, maybe it's an inheritance from old versions (I have that config file all the way back from compat branch :D )
>>> page.isRedirectPage() >>> _handle_query_limit None None True 1000 None {'_count': 0, '_previous_dicts': {}, '_props': frozenset({'info'}), 'api_limit': 1000, 'continue_name': 'continue', 'continue_update': <bound method QueryGenerator._continue of <pywikibot.data.api.PropertyGenerator object at 0x7f529e17ca90>>, 'continuekey': ['info'], 'limit': None, 'limited_module': None, 'modules': ['info'], 'query_limit': 1000, 'request': pywikibot.data.api.Request<wikipedia:ro->'/w/api.php?continue=&action=query&prop=info&titles=Cod:SIRUTA:136&inprop=protection&indexpageids='>, 'request_class': <class 'pywikibot.data.api.Request'>, 'resultkey': 'pages', 'site': APISite("ro", "wikipedia")} <<<
Nov 5 2021
Nov 4 2021
$ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed)
$ python3 pwb.py version Pywikibot: [https] r-pywikibot-core (758de7a, g15553, 2021/11/03, 12:54:56, OUTDATED) Release version: 7.0.0.dev0 setuptools version: 33.1.1 mwparserfromhell version: 0.6.3 wikitextparser version: n/a requests version: 2.25.1 cacerts: /home/andrei/.local/lib/python3.5/site-packages/certifi/cacert.pem certificate test: ok Python: 3.5.3 (default, Apr 5 2021, 09:00:41) [GCC 6.3.0 20170516] PYWIKIBOT_DIR: Not set PYWIKIBOT_DIR_PWB: PYWIKIBOT_NO_USER_CONFIG: Not set Config base dir: /home/andrei/pywikibot-core Usernames for family "commons": commons: Strainubot Usernames for family "wikidata": wikidata: Strainubot Usernames for family "wikipedia": ro: Strainubot
Nov 3 2021
Thank you for your suggestions @Xqt and @matej_suchanek . Unfortunately I am still reproducing the issue after deleting all __pycache__ and apicache-py3 folders, using the simplified example (see below) and commits 28e31f98dcc2b152fde16385172a49f721394ed3 and 758de7a513c061c1741d77b8a684d24bba2c5fd0 .
Nov 2 2021
OK, so I digged a bit, it seems when leaving the article (options 2,4,5 in the description) there is an option controlling the warning which in my case was not global. When exiting to the article itself, the VE warning is shown regardless of that setting. I believe the correct behavior is to always display the same confirmation window, which should be controlled by the user option. I updated the description accordingly.
On en.wp I also see the confirmation as in your screenshot, but I find it strange that you have the VE confirmation when exiting to the article (just like on ro.wp) and what looks like a browser confirmation for the rest - it still looks like these are separate code paths and it's unclear to me why.
Yep, also reproducible on ro.wp in safe mode (signed-in) and on Microsoft Edge (while signed-out).
Can also be reproduced on FF for Windows.
Pretty much any page, I've encountered it several times. Just checked for [[ro:Cod:SIRUTA:136]], it reproduces
I agree, it would have been preferable if the change in semantics came through a rename of parameters instead.
Nov 1 2021
Oct 28 2021
If this was fixed on 2021-10-12, why hasn't it reached the wikis yet? Do you have a slower deployment pace than the rest of the code?
Oct 27 2021
Oct 19 2021
Oct 11 2021
I'll go even further than @Kudpung : most (8 out of 10) of these solutions are patches to the existing system, which the other side considers broken. What these people want is not to get and/or do work more effectively, by being able to patrol on mobile or receive echo notifications, but for the bad edits to *dissappear* from their watchlist so they have less patrolling work and implicitly more time for other activities on-wiki. Here is one of the feedbacks from pt.wp which resonates particularly well with what I am told when I try to calm down overzealous patrollers on ro.wp:
Oct 10 2021
@Ladsgroup @Urbanecm @Nemo_bis I'm tagging you as the participants to this discussion who most vocally rejected the change, but this message is aimed at all members of the technical community who support anonymous editing. I am on the same page as you on this, *strongly*, but...
Sep 19 2021
Since this is a visual issue it makes sense not to be a blocker, but a tech notice message would have been appreciated.
Has this been discussed on wiki? Last I remember,tthere was *some* community around that project.
Aug 24 2021
Aug 16 2021
Hey folks, the leftovers from this bug just hit some wikis really hard (see T288846 and duplicates). Would it be possible to get it some love, at least to the point where no math tags are inserted?
Short debugging seems to suggest the presence of empty math tags (<math />) is the cause. I remember seeing some tech notice about this a while back, can't remember the details.
Jul 13 2021
@Reedy will you do the changes or do you need us to clean up? If the latter, can you provide instructions?
Jul 12 2021
Unfortunately, adding the HD logos does not guarantee the blurriness will go away, see T274778
Jul 2 2021
I double checked all monuments not in Sibiu and this issue seems to have been resolved (at least the correct P131). There is a mess for that property, but this will be solved on-wiki.
Jun 7 2021
Can you add a link to Add a link (haha) so external watchers can get the context?
Apr 27 2021
@TheDJ , thanks for the debugging. I think that if nobody will take on this bug in the near future, it should be mentioned in the documentation at least, to make sure others don't debug as much.
Apr 23 2021
Apr 18 2021
Apr 5 2021
Apr 1 2021
Mar 4 2021
I second the community members who asked for the increase of priority. Mobile edits are on the rise and this bug blocks the normal workflow the communities use to communicate with anonymous users without providing a replacement. Since this seems to be in the Growth team, I'd like to see what @MMiller_WMF thinks. What's the grand plan for edits on mobile?
Feb 27 2021
I did not find anything relevant in the wikitech-l archives. What other options do we have here to "unblurry" the logos?
Feb 26 2021
I think it would be good to revisit this a bit, maybe see if things have changed in the last 9 years.
Feb 25 2021
Correct, that's the step. I'm no UX specialist, but I believe that having an inner scrollbar AND a lot of wasted space below (the user still needs to scroll to read the right column) is not a good experience.
Feb 24 2021
The translations are good, but now I'm a bit confused at what we're trying to achieve. Looking at the diff vs the current output (see screenshot), it looks to me that the old version is closer to what we want. I believed that the sections are fixed, but if they're fully customizable, I would suggest that knowing how to edit and how to work with images is far more important than uploading an image (especially the cross-wiki uploader that is offered by the visual editor). I propose the json below. @FonAfon do you have an opinion on that?
Yep, sounds good.
Feb 23 2021
@Trizek-WMF Does it need to be a local page? We haven't figured out the help pages completely, but VE has pretty good help pages on mw.org and I preferred to translate those rather than creating new pages.