User Details
- User Since
- Oct 22 2014, 10:09 PM (438 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Strainu [ Global Accounts ]
Tue, Mar 7
@TJones one more question regarding this change: will it affect the results on Romanian wikis? I know the search is diacritics-insesitive, but I wonder if cedilla redirects will be favored in relation to the redirect targets, which are using comma diacritics.
Wed, Mar 1
@TJones is there something the Romanian community can help with? What would it take to accelerate the changes upstream?
Jan 22 2023
This is a site request that cannot be approved without clear consensus obtained on the Romanian wikis first, and not on meta or here. I suggest you open a discussion on the Romanian Wikipedia and invite participation from the rest of the projects if you are really serious about pushing this.
Jan 19 2023
@John_Smith_Ri I still do not see any consensus or discussion on this in the Romanian projects. Please provide a link to the discussion before reopening.
Jan 13 2023
Jan 12 2023
Sometimes they use the Ǧ ǧ and Ș ș letters as Ğ ğ and Ş ş.
Dec 20 2022
Let's clarify the terminology and separate the concerns here:
- I suggested that, based on the usecase, pageview data might be better retrieved from the Wikimedia.org REST API ( https://wikimedia.org/api/rest_v1/#/ ) which is different from the REST API on the other sites (see here). As usual, extensions can add their own endpoints (see for instance /pages/talk at https://en.wikipedia.org/api/rest_v1/ which is missing from MediaWiki Confusing, I know.
- Pageviews are only part of the Wikimedia API, so it is not exposed through the PageViewInfo extension. From a design point of view, they're totally separated and could potentially return different data at least occasionally (although I suppose they share a common data source)
Dec 8 2022
Dec 7 2022
@Edtadros both tests seem to have been made in landscape mode. Would you mind confirming that the fix also works in portrait mode? I know that since there is a fixed viewport it is very likely to work, but I think it makes sense to check before deploying. Thank you.
Nov 14 2022
Nov 13 2022
Oct 28 2022
Oct 27 2022
I'm not so sure that would help in my case. The screen resolution is (2340 ×1080 pixels), but experimenting with the basic code from Mozilla seems to indicate the limit is ~200px in portrait mode and ~750px in landscape. Do you have any idea why I would see these results?
Oct 26 2022
Oct 18 2022
Hi folks, is this task being actively worked on or planned for the near future? If not, maybe we should remove links to https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide/Citations-Full until it can be translated? We're sending people from wikis to these help pages (e.g. https://m.mediawiki.org/wiki/Help:VisualEditor/User_guide/ro ) and we would much rather have them localized.
Sep 26 2022
Confirmed working, thanks @matmarex
Probably not the same as T303109, that one is FF+SwiftKey. You can try reproducing this one with SwiftKey to confirm.
Sep 25 2022
Sep 22 2022
Aug 13 2022
@Yupik could you explain what smn and sms are in this context?
Jul 24 2022
I think it can be closed, I haven't seen a 504 in a long time.
Jun 14 2022
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?