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 (140 w, 6 d)
- LDAP User
- MediaWiki User
- Nemo bis
I think it makes sense to remove users who have been inactive for a long time (several months or years) and who are not currently doing any code review. The two users mentioned have exactly 0 open patches requesting their review.
We are not defining any namespace with ID 206 in our configuation. I think it's SF_NS_FORM, defined by https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/src/NamespaceManager.php (which in the past caused https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/1975 ).
Not resolved: the language selector was simply removed, wasn't it? T113114: Make all wiki-facing error pages consistent
Personally i would just care about errors and warnings in the log files, but no a strong opinion either.
Tue, Jun 20
Mon, Jun 19
Sun, Jun 18
Sat, Jun 17
It's not acceptable to break core functionality of Wikimedia (content) wikis for an entire class of users just to combat a minority of abusers. Targeted blocks must be used instead, see T168142#3357904. Let's close this one to avoid having a hundred parallel discussions.
I've blocked a few ranges for a month on mediawiki.org based on AFRINIC information, just because it's mediawiki.org and we need something quick (but not too painful) to protect Phabricator, which is not as robust as a wiki. Let's see if it helps anything until T167915: Disable media for Morocco Wikipedia Zero or similar is fixed.
This request doesn't seem especially legit. You "just" want to block them from using Phabricator, don't you?
Translation pages cannot be edited directly, so you cannot patrol (or move, or delete) them directly either. You only can patrol/undo/rollback the edits in Translations namespace.
Fri, Jun 16
Why are we restricting Zero-rated users to only the "not a wiki" version of our wikis?
Why restrict this mechanism to Zero, making Zero different from other access? We could instead deny access to unpatrolled files for users that aren't logged-in.
Wed, Jun 14
LanguageFallbackChain::extractPreferredValue() returns a language value which should be what we need, if it's passed on in the next steps; TermIndexEntry provides a getLanguage() function.
Funnily, the good old action=render works well. :)
Are such clicks (counts) recorded in EventLogging and for how long?
Search engines and users are confused if we give them results in unexpected languages, so T167872: Correctly set lang HTML attribute for each article placeholder string is rather important to fix.
There is still an open patch associated to this report, at https://gerrit.wikimedia.org/r/#/c/118101/ . Now that we went a more minimalistic way with the WikiEduDashboard etc., I wonder if this feature request can be declined/repurposed, to focus on exploiting MediaWiki core/s watchlisting (with enotif and other notification systems hooked into it).
Tue, Jun 13
Well, I haven't tested again since then.
Mon, Jun 12
Finally a naming discussion. ;)
If the point is that only *editors* have a need for watchlist (to see followups to their edits), then the threshold should be 1 edit, not 10. 10 is an arbitrary number.
Let's please avoid repeating identical comments over and over.
Not quite fixed, we're still forcing people to use GitHub (advertised with links at the top right of e.g. https://phabricator.wikimedia.org/source/mediawiki/ ).
Sure, there's no reason to block the fix. It would still be nice to make the commit message more detailed, to show what the consequences are on magic words, namespaces, special pages, formats.
Sun, Jun 11
My request was posted by the local users in their village pumps, thanks!
Please upload screenshots locally: https://phabricator.wikimedia.org/file/upload/
FYI I've updated gerrit-reports to use the new gerrit API parameters and we have new updates: https://www.mediawiki.org/w/index.php?title=Gerrit%2FReports%2FOpen_changesets_by_newbie_owner&type=revision&diff=2486934&oldid=2201127
Sat, Jun 10
I guess one good argument for an intervention on the download side would be that it's nice to our partners to prevent blatant abuse of their bandwidth?
I think the action items are sensible (though we didn't find a magic wand) and they're being worked on. This specific event/effort can be considered closed with success. Thanks Zache!
I've read https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service#The_Present and I don't understand what's wrong with the current vector maps. They look good to me. Being more specific about the problems you see would help. At any rate, no difference in quality however big can justify a loss of privacy.
Fri, Jun 9
The feature is currently documented at https://www.mediawiki.org/wiki/Page_content_language . We could link that from Translate docs.
Thu, Jun 8
On the minus side, with Github they will miss an opportunity to learn what LDAP is.
Isn't this a duplicate of T119343: OAuth login for phabricator impossible on MobileFrontend?
I guess I could uncompress the archive and use something like filelight.
Despite what I said, the difference in graphs is not great e.g. for an account like mine:
Additionally, we may want to handle cache and I already got some "complaints" for complexity added elsewhere (the Theil index), so maybe better not overload the interface.
Wed, Jun 7
I think what the interface says isn't necessarily true.
they are private data
This specific issue is solved, the general conversation continues in the parent task for additional changes.
Especially those who have never heard about issue tracking/XML/WMF/etc. (people who only know Wikipedia, Commons, and the Android app, as users)
I think the GitHub guide is clearly aimed at smaller projects which don't know better and have few repositories. Otherwise there would be some reassuring sentence "yes, we know that adding thousands copies of such a file can be daunting, but we think it's worth it!". :-)
Tue, Jun 6
one of our major goals is to attract new developers
Mon, Jun 5
Where does it say that?
Currently not supported by Translate: all Wikimedia projects (as defined by the namespace) are expected to use the same issue tracker, and I believe this is the only exception. It would be easier for the Commons Android app to resume using Phabricator, but we'll see. :)
Thanks for the report :)