Fri, Oct 19
Since my report I’ve disabled Wikidata edits entirely because having frequently edited items in your watchlist with Wikidata edits enabled is a massive pain for users in default configuration.
Fri, Oct 12
Tue, Oct 9
Mon, Oct 8
Sat, Oct 6
It appears that this bug was not fixed or was broken afterwards again, as I mentioned in T90435#4119854 before. If I need to file a new task, feel free to close it and forward me to this. I got down to writing a clear task description before finding this task, so I’ll just copy it below.
Fri, Oct 5
I guess that the reason for this is that there is an assumption that modules are usually not used directly in articles, but are only used internally in templates. I suspect, however, that this assumption is not quite true: searching the main space of the English Wikipedia for insource:#invoke finds quite a lot of direct module invocations.
Thu, Oct 4
@Jdforrester-WMF: sorry for writing in an old task, but would it be fine to ask you to reconsider this?
Quick question: after A/B test will be done, will new page issue design display without a delay for users or is it expected to be like this in future?
Wed, Oct 3
Don’t know the code exactly, but shouldn’t it be possible to do the hiding part correctly before doing something with every widget or whatever is blocking the performance? For people like the task author, showing first tab for 30 seconds or so still will be a visible performance bug.
≈3-5 second delay for me on Firefox 62 (Windows) before new UI starts showing me only the current tab.
Tue, Oct 2
Wouldn’t matter to people even without the apologies :-)
Here’s the right page if you want to do it yourself:
If hide-when-compact class doesn’t bring any additional styling on desktop (as far as I can see), I think that (1) wouldn’t be controversial to do.
Is there any complexity to adding this to page title? MediaWiki:Contributions already has gender support, but the parameter is not being passed to the message on Special:Contributions, would it be hard to do? (Not asking to nudge people, but rather to know if I can submit a patch.)
Sorry, haven’t read the entire discussion. My (minor) concern with this, though, is that it would be a lot harder to copy a log line that doesn’t make much sense as a list inside of a list inside of a list (like edit section links don’t really need this treatment), but I guess I can manage.
This solutions bring additional complexity without much benefit, don’t you think? We don’t render edit section links separators via CSS, why in this case it is more viable to do this than to allow customisation via some API?
Mon, Oct 1
Maybe you might find this useful: we’ve dealed with this in a gadget in Russian Wikipedia (with mw-ui-button, however) and the solution we found for overflowing was adding a margin-left of 1px on parent and having margin-left: -1px for every button. That way there won’t be unevenness in position of the buttons on the next line.
Tue, Sep 25
This, sadly, will prove more annoying for editors than useful if we’d try to implement this on a large scale, in my opinion. Especially if the thing that MobileFrontend has concerns with is in some protected template − how a user is expected to go around this if they don’t want to see the warning in the article they’ve written with it?
@Malikxan: No assistance from developers is needed for this. Append &uselang=qqx to a page URL and look for message names in places where there was a button.
Sep 18 2018
Sep 17 2018
Sep 11 2018
Issue on Github about EU copyright law banner causing this problem, for future reference:
Sorry for bothering, I’ve rooted out the source of the problem: I use Ublock Origin and one of the lists contains a line ||wikipedia.org/w/load.php?*startup$script blocking all of the scripts from Wikipedias (Fanboy’s Annoyance List, probably due to that fullscreen banner about EU copyright law). No engineering effort is needed.
Small design suggestion: maybe only ≈full translations should have icons alongside them? It seems strange to draw notice for incomplete translations, which is what these icons will do for most readers. (Other than that, it’s great, btw.)
Sep 7 2018
Sep 6 2018
This is not a snarky comment, but really: has no one tested that things like this shouldn’t happen? Can we instruct people to thoroughly test major changes like these so that this wouldn’t happen again?
Sep 5 2018
Unless I misunderstand something, maps overall just became non-interactive: if you remove that CSS, with JS active it shouldn’t go to Special:Maps/…, it should display the map in its own modal. The issue is not in having CSS that prevents maps from being interactive before JS does its job, the issue is that JS for maps stopped loading or working.
Aug 30 2018
A more general approach would also be to not show zoom-in icon if on click there won’t be any enlargement from going to the asset URL, since I’d think that many users would find this confusing (and maybe even going against the spec? haven’t investigated it).
Aug 28 2018
This is what I intended to convey with the comment above.
A problem lies here: should administrators see deleted revisions of those files if no ‘pure interface administrator’ can? I don’t really have a preference, but it would be kind of strange to provide more privileges to non-intadmins than to intadmins.
Purge did nothing. No errors were in console as far as I am aware. Any action was being sent to the fallback, yes, so events were probably not subscribing to links with new localisation.
Basically, subheaders had new localisation in edit buttons (‘править’), and all AJAX for them didn’t work at all. Properties had old localisation (‘редактировать’) and AJAX worked for them.
Aug 27 2018
Since without this any non-Wikipedia project or any user with non-conforming language would see completely botched descriptions, I’ve added the task that introduced these messages in such way as a parent task.
About the tag- messages: they should probably contain just [[Project:AutoWikiBrowser]] instead of potentially incorrect interwiki links (especially in the current wording, [[en:w: probably won’t work at all).
If there’s any way to also include undelete, it should probably be done if we’re allowing deletion of those pages.
Small question: while separating rights, you have granted sitewide JSON editing to sysops, but not granted it to other groups that had editinterface before (specifically, this situation is concerning RuWP’s engineers). Is this intentional in any way or could this be fixed without additional bureaucracy?
Aug 23 2018
@Marshmallych, please don’t close my tasks for me in the future.
Aug 21 2018
Aug 20 2018
A small comment, sorry if I am asking in the wrong place: in the documentation I didn’t see anywhere an explanation for ‘what would communities do if JADE will not prove useful or they would not want it’. The problem with some deployments is that they are irreversible. If Judgments will be rejected by any community in any events, will it leave a permanent unremoveable namespace for a wiki? There are frequent questions from users about Gadget namespace that is unused for multiple years, it would be strange to explain for years that this was (let’s assume the worst) some failed experiment that we can’t get rid of because it contains discussions and stuff.
Aug 15 2018
Aug 14 2018
Aug 12 2018
Done both pages, thanks for the reminder:
Aug 11 2018
I would say that this potentially would be a very, very, I mean, very bad feature for any project that uses both Wikidata and FlaggedRevs extensively. This unpatrolling routinely means that you have to recheck pages because file description on Commons changed in some time. When projects use Wikidata, there are some links that go outside to tens of different pages, so that problem would be even worse when each change of information in Wikidata would trigger FlaggedRevs rereview.
Aug 2 2018
Aug 1 2018
@dbarratt: If we’re going by the mockups, I would think that the merge would not be a right option even if restrictions would be used more than blocks, since they mostly would fulfil different needs. Pages and namespaces blocks will mostly be helpful in content disputes, while current blocks are more suited for dealing with bad behaviour. ‘Uploading files’ and ‘Moving pages’ just look out of place there – you make a point about restricting emails without restricting a person entirely, but it’s the only option that you could justify moving to a different block. Other options are already where they need to be – there’s no real need to block a person from creating new accounts only, there’s no need to not block IPs used by a person from editing while not blocking a person themself.
Jul 30 2018
Since I’ve been tagged: this is where we differ. In my opinion, site-wide blocks and per-page blocks are not the same type of action, with the latter being akin more to page protection but for users instead of pages. It’s a valid approach to make (to not modify page protection since the task’s design goals are much bigger), but it doesn’t make sense for me from social (communities would have to adapt to new feature because right now the ‘block’ is specifically sitewide action, it would probably increase tensions when people would apply it as an edit war deterrent if we tie it to blocks, and they probably would use it like that) or design standpoint (below).
OK, thanks, I’ve just (mistakenly) figured that I might clarify that in case of not getting that it is our template instead of original one.
I don’t see a need in revert, since it doesn’t look critically bad.
@Jdlrobson: seems like I should’ve asked you for a screenshot when you tested this. It’s been finally deployed and it looks like this in the wild:
One difference with the task you’ve provided is in that in this case, a template exists and was inserted through Content Translation interface with some means (since it has data-name="Фильм" etc. which are present in infoboxes of Russian WP), but was subsequently somehow substituted.
Jul 28 2018
I didn’t talk specifically about the documentation, it’s just one of the solutions that will be the most easy to implement.
Jul 27 2018
Seems like the icon doesn’t show in the reference drawer, where it would’ve supposedly be seen the most. Is this intentional?
Jul 25 2018
Jul 24 2018
Great. Small fix needed though: Special:UserLogin/Signup → Special:UserLogin/signup, the first one doesn’t work as intended and I only noticed this now.
Jul 23 2018
All links there are internal, not external, so plainlinks wasn’t required before. They aren’t applied to images, they are applied to links, see here:
It doesn’t do anything bad to keep them, the only thing that might be interested in removing them is probably mobile version (since every byte seems to count there).
Jul 21 2018
Not only is this a lot of duplication of existing functionality, it is confusing for new admins to have to different pages to block a user.
Jul 20 2018
As another example where this would be helpful: in Russian Wikipedia sysops and bureaucrats frequently edit a gadget for showing users with advanced groups so that it would stay up-to-date. If there won’t be a more comfortable solution such as JSON, quite a lot people might argue either for workarounds that undermine security (such as content model change?) or for giving those rights to them by default when they don’t really edit any other pages.
Jul 16 2018
Jul 15 2018
Team project tag was added because I need the opinion from the team as they are the code stewards of this extension. Was that really inappropriate?
Jul 13 2018
About the patch above: since it adds new functionality (and per guide), can someone please tell me if that would be OK? It is a frequently used functionality (adding line breaks) that even more frequently breaks the resulting wiki code and parser because of it (can’t work in lists, frequently breaks even paragraphs etc.). I figured that having it as a handled use case would be less problematic than continuing to advise using hacky HTML code.
Are you telling this after testing the patch? (In theory, it should’ve fixed the task above.) Disappointing, if so.
Flow interface was changed since then, and there is no such bug in new interface, so no point in keeping this task open.
Can’t you just do a gadget please? I seriously don’t understand why all of this development is even needed.
What exactly is, the one in the topic or the one I fixed with it? The one in the topic is still present in wikis, so it’s not in any way an old issue. TemplateData should not display a message about ‘custom format’ on _every_ format, otherwise the message should be removed entirely.
Jul 12 2018
I haven’t tested the patch above, but it looks to me like the problem is happening because isset( $formats[$data->format] ) was referencing an unknown variable, so it always returned custom. If anyone could check this, it would be more than appreciated.
Jul 11 2018
Didn’t look into a patch before, some small questions (not arguing against the patch or anything):
- Does it mean that now you should just check the checkbox if you are modifying the TOC with scripts (Ctrl+F ‘TOC hidden’ in Russian Wikipedia’s Common.js)?
- Is CSS-based solution entirely accessible? Here it says that IE11 doesn’t read CSS content.
Jul 9 2018
Ah, don’t even know how I didn’t notice added lines after clicking on ‘show skipped’. Sorry for misunderstanding.