Most of the cases are resolved, but curiously enough the formulas in the first section of https://de.wikipedia.org/wiki/Gro%C3%9Fer_Fermatscher_Satz the error is still happening for me.
Wed, Jan 17
I don't see how the idea of this ticket is directly linked to the AHT, as it's a general improval of the integration of Phabricator into MediaWiki, increasing usability and transparency for many users.
Tue, Jan 9
Sun, Dec 24
I don't think there's need to treat css pages the same way, as you can't inject complex scripts with stylesheets. What do you want to do about them?
Dec 18 2017
These kind of maintenance tasks is the reason the nominornewtalk permission was implemented, I think?
Dec 9 2017
I really appreciate the multi-color top line in widescreen view, as it's dividing the three columns timeless has in a really natural way. However, if your screen is smaller, it doesn't look this well indeed.
Dec 1 2017
Sorry, I missed that line.
Nov 29 2017
I orchestrated an example that should show the issue on every device: https://de.wikipedia.org/wiki/Benutzer:MGChecker/Percent . In the App, the Spaces between the 20 and the % are breaking, on the actual site they aren't.
Nov 28 2017
One quick design question where I'm unsure if it's worth it opening up a seperate task for: Is there a specific reason why the main content window stops getting wider at 100 em? It creates useless whitespace that could be used more effectively.
I'd really support an approach like this.
Nov 27 2017
To be honest, I like even this better than the alternative MobileWatchlist is providing. Compared to a collapsible watchlist, it has a incredibly low information density and isn't usable by users with more than a few items on their watchlists at all.
Nov 22 2017
Is this a duplicate of T160653?
Nov 21 2017
Nov 16 2017
How would you extract the pageview information? It isn't stored by MediaWiki itself and it really doesn't seem like a good idea to depend on external services for actual extension functionality.
As stewards are a global group (too), it will be no problem to assign it to them for all wikis.
Nov 12 2017
Nov 8 2017
Nov 7 2017
I just noticed this problem only occurs if file loading is disabled. Maybe this is expected (I'm unsure, you didn't adress this until now), but nevertheless i think it shouldn't behave that way: In opposite to pictures formula are a key element of the article they're embedded in, and are quite light-weight. I don't think disabling pictures should make our article unreadable for most users.
I'm using a Samsung Galaxy Device with Android 7.0 installed. This isn't any kind of new issue for me, but has been this way as long as I can remember.
Nov 6 2017
I still have never seen a properly rendered formula to this day, I still just get the markup to render them. An example of this is the article about Keplers's laws of planetary motion at enwiki. I'm really looking forward to this issue being fixed, as it greatly reduces the usability of the app.
Nov 3 2017
How would the autoconfirmed restriction be managed internally? In my opinion, it should be a new user right (sendemail-restricted maybe).
Nov 1 2017
I propose to rename that to "If a user has never triggered a logged action on a wiki, they should not be able receive emails by non-privileged users from there." The title is getting out of hand ^^
Oct 31 2017
If a user has never edited AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.
Oct 30 2017
Wouldn't it be a better idea to include all logged actions than to just evaluate edits?
Oct 22 2017
Opps, I was really sure these tags were used by the software. Sorry I didn't check the logs further.
Oct 21 2017
Oct 20 2017
In my opinion, it's more important that you're able to paste wikitext than literaly anything else you could come up with.
Oct 15 2017
The idea of the wontfix argument is that it's technically possible to protect any pages by editing cascade protected ones. However, while this might be theoretically true, I think there's some distinction in practice:
- If I have an cascade protected main page, in practice I won't use this to protect anything that isn't on the main page – it would be disruptive. It's something else than doing individual protection decision.
- You can finally combine protection levels and cascade protection in a useful way (as someone who can protect pages usually also can edit all protected pages.) This way, you could imagine a main page cascade protected to be editable just by a trusted user group (with its own protection level), while most other cascade protected pages stay on sysop level.
Oct 13 2017
Off-topic: Why does enwiki even hide this setting? It does no harm afaik, but is really useful if you to some maintenance task for a while.
Oct 12 2017
Note that in the proposal € is normalized to E, not to G. However, I agree that pi shoudln't be normalized to r, this equivalence would be kind of random. If anything, pi resembles an n, but I'm not even sure that this is needed.
Oct 11 2017
I think the existent RateLimit Mechanism is enough to deal with this situation. Nevertheless, an extension to allow sysops to set RateLimits dynamically would be really interesting for Non-WMF-Wiki, perhaps something for MediaWiki-Stakeholders-Group .
Oct 4 2017
Oct 1 2017
Sep 30 2017
Sep 29 2017
Sep 27 2017
I don't think that way. If an aesthetic change contradiscts the whole idea of the skin, it shouldn't be done, even if there's some functionality increase. (But as always, it's dependent of the proportion of usability increase and aesthetic decrease.)
I don't really understand this argumentation. The worst thingg that can happen is that the skin doesn't work completely on an wiki and someone will fix it within a timespan of some weeks. As it is just an optional feature I don't see any problem there. It isn't like there would be any guarantee that this skin works perfectly.
Sep 26 2017
It's kind of the whole idea, that content, and so the search bar, is at the center instead of many user tools. Shrinking the search bar would undermine that (and probably look really ugly).
On the one hand, it's a simple approach conceptwise and codewise, on the other hand, it reduces the feature flexibility. To get autoconfirmed isn't that difficult, and many wikis have groups kind of representing trusted users.
Sep 20 2017
As we have global single user login it is nonsense and irritating if you are allowed to be notified about logins on some wikis, but not on other wikis. Technically, it even kind of is a security flaw.
Sep 19 2017
I'm against this idea, as it undermines the wiki principle. Everyone should be able to reach other users on their talk page, this is a fundamental part of onwiki communication. I don't even think to "allow users to broadly prevent groups of users from interacting with them" is something we event want in a wiki!
Sep 18 2017
I think relying on Git is a good idea, but I think you underestimate that by moving contributing to these files to a git, you remove it from direct access from the wiki. I think it will feel like we're taking away control form the community, even if this isn't the intention, as we in some way remove the direct editing possiblity from the wiki and make it more difficult to contribute there for normal user.
Sep 17 2017
When we get GlobalPreferences, why don't we define a preference that does only makes sense globaly als global only? I really don't understand at all what's goinf on here.
Still, I think such a special page should be readonly, no matter what. You shouldn't be able to change fundamental wiki settings on a special page. However, I think we agree that it's a good idea to build a read-only special page like Special:Version/Configuration and allow extensions (like Configure) to modify its behavior to add a write functionality.
Sep 12 2017
I think there is no necessity anymore to wait to deploy for the other skins. I could perpare a patch adding Timeless to the remaining wikis with status so someone can merge it soon.
I'm not completely sure you mean this, but I really think this shouldn't be part of Configure, but a core feature. Configure seems quite dangerous to me and i doubt it will ever be installed on major wikis.
And now we reach a point where we get problems if we treat all Notification settings as one in global contect… You could solve this by using the proposed globalonly feature,but I don't know if it can be assigned to single notifcation points with the current approach.
Sep 7 2017
Sep 6 2017
Sorry, but I hope noone here tries to create new example for this xD
@Legoktm: Well, I wasn't aware of this.
Sep 3 2017
Sep 2 2017
Sep 1 2017
Currently, AbuseFilterRestrictions contains array( 'block' => true, 'degroup' => true, 'blockautopromote' => true, 'rangeblock' => true ). (These actions aren't used at enwiki at all.) However, you talk about "blocking, preventing, and warning" in the task restriction.
Aug 31 2017
I just wanted to point it out because of
I think T169268#3556789 was the reason that this task was set private.
Why would you want to modify this setting that nearly noone can use this feature in a useful way anymore? If no sysop can edit a filter to prevent and warn at editing, they become quite useless.
Aug 30 2017
Wasn't it planned to deploy Timeless to the wikis with consensus some days ago?
Aug 24 2017
The muting should still work even if the muted user changes their username. See T173475.
Now we've finally reached a level where treating this as an security bug becomes laughable…
As I see it, this is the thing that most users like abbout this skin: Non-conent stuff is hidden in dropdowns. I'm not completely against this, but I don't want it to be done without some thought put into the decision.
Don't you think this is kind of premature. Once we have it on multiple wikis, migrating to an global-only setting will become much harder.
Aug 22 2017
To be honest, I personally really like the RBG header.
I don't know if you're aware of that, but I could see the title of T173475 and the title and initial description of T173854 in my email. (Note I'm a watcher of Anti-Harassment.) This shouldn't happen if they were created properly, which I can't check. (Besides, the first one is so obvious, I wouldn't hide it at all, while I remember reading about the second one in public areas of WMF infrastructures.)
Aug 21 2017
Wouldn't it be possible to disallow the edits to his own talk page by another abuse filter as an interim solution?