Thu, Sep 12
At first glance, this certainly sounds necessary. It's a multilingual site, and should work for everyone.
Mon, Sep 9
Ideas to lower the number of potential problems:
- Make the numbers less precise, somehow? Something like making each unique editor have a 10% chance of being skipped in the count and 10% chance of being counted twice, or some such. (This would need to persist per editor between reports, I think. Maybe even do the same thing to the changes in numbers when someone leaves.)
- Don't generate a new report when only one editor has joined or left since the previous report. Perhaps even per-country, don't update unless there's a change of at least several counted users since the last report.
(Probably stupid question: Aren't there people who actually specialize in this kind of thing, with established methods for preventing leaking data on particular individuals?)
Sun, Sep 8
Sun, Sep 1
Okay, I know this was closed as declined, but the problems mentioned seem really easy to solve. Variable naming conflicts with keywords can be handled the same way any decent transpiler handles them (adding/removing underscores as necessary to avoid conflicts), and importing/exporting and cross-wiki maintenance can be handled by a "base" form in English not normally visible but easily accessible. Here's a working English-to/from-other Lua translator: https://gist.github.com/YairRand/e22aded969e6de8cbb283e62868153a1 .
Thu, Aug 29
So, to be clear: This is about when developers need temporary local user rights necessary for software testing?
In what cases would T&S need to add local user rights to staff accounts?
Wed, Aug 28
Tue, Aug 27
I modified the Graph module to use the user-specified order (ie y1 goes before y2), rather than alphabetical order, and copied the changes to the version on mediawiki.org. Seems fixed.
Sun, Aug 25
Wed, Aug 21
Several examples of ways to find out a user's country: (Note: A lot of this depends on how frequently this report will be published.)
- Data is published, some time passes, during which precisely one new editor has shown up who wasn't there previously. The counter for one country goes up a step from, say, 20-30 to 30-40. This user's country has been revealed.
- A very small wiki that normally wouldn't have the data published has exactly one editor. A malicious user trying to determine that editor's country creates nine "active" accounts in a particular country. If the counter shows 10+, the country has been revealed. The malicious user can repeat, and also test many countries at once to narrow it down.
- Combination of the above tactics: A malicious user tries to keep several countries' counters at the boundary, so that either a new user will cause the count to increment, or a leaving user will cause it to decrement. If all users joining in the same duration but one can be ruled out by time-zone data or similar, the remaining user's country has been revealed.
- There are ten active editors on a project. One of the countries shows 10-20. The country of all of the editors has been revealed.
- There are 16 active editors on a project. A malicious user creates four active accounts in a country. The counter shows 20-30. The country of all of the editors has been revealed.
Mon, Aug 19
For "Wikimedia", the original colored Wikimedia logo would be correct, IIRC.
Sun, Aug 18
Unless I'm very much mistaken, the described system will make it possible to determine the country of specific editors, in some situations.
Aug 13 2019
Aug 9 2019
I've been working on a template on Meta for working with staff data at m:Template:WMF Staff, which can be used to automatically populate various kinds of navboxes and team galleries on Meta-Wiki. It also fills m:Wikimedia Foundation staff and contractors, which is in the process of being styled like the current WMF site's list in the hope that whoever manages that site might redirect the page to Meta, and fills m:Wikimedia Foundation staff and contractors/oldstyle (probably to be renamed at some point), which maintains the design of the old list, including subteams.
Aug 8 2019
Aug 6 2019
Aug 5 2019
Jul 31 2019
Jul 18 2019
I would recommend moving the contents of the docs on-wiki as well. Using Google Docs is very problematic in various ways (closed-source, non-transparent, far away from Wikimedia activities, privacy issues, etc).
Jul 4 2019
Agree, having all redirect special pages work preserve safemode would be a good thing.
Jun 27 2019
Jun 26 2019
Apr 30 2019
Mar 25 2019
@Nuria The WMF internal wiki isn't publicly accessible, making its contents unavailable to the community. Unless there's particular reason the guidelines need to be withheld, I would think that reasonable transparency would require that they not be hidden inside the WMF's private wiki.
Mar 19 2019
Couldn't the complex constraints be migrated to statements, if that's what it would take?
Mar 6 2019
Mar 5 2019
While that will solve many applications of linking to directly editing a statement, I suspect it will not solve all of them.
Mar 3 2019
Another suggestion: When ?x is declared as a variable, ?xLabel should be on the list of suggestions for variable names.
Feb 26 2019
Dec 10 2018
This should also work in the "Constraints" section, which, afaict, only allows the "property constraint" property (P 2302).
Nov 22 2018
The issue appears to have since been fixed, I think.
Nov 21 2018
The current policy of prohibiting passwords that are only lowercase letters prohibits the strongest passwords (eg correct horse battery staple) from being used. Adding extra requirements of this sort basically means that people will start recording their passwords in non-secure locations.
Oct 31 2018
This is basically going to force people into having bad passwords. Length is not a good indicator of password strength, and the current requirements prohibit the strongest memorable passwords. Forcing people to have less memorizable passwords means that they'll use more easily guessable passwords.
Oct 22 2018
This worked until recently. It showed a diff of everything that was added, which was quite useful. (My userscript relied on it, and is now getting errors as a result of this change.) Requiring a different API call to get all the added lines from the first revision as from all other revisions seems needlessly complicated.
Oct 21 2018
Is there a particular reason the draft data access guidelines linked above need to be specifically confidential? If not, could they be posted to a public wiki?
Oct 18 2018
Based on fixes to similar bugs, this could presumably be fixed by changing line 227 of mediawiki/includes/specialpage/RedirectSpecialPage.php from
Oct 16 2018
I don't think this is a duplicate. T189746 appears to be about having automatic conversion. This task appears to be about direct database/UI support for this calendar, without converting dates to Gregorian.
Perhaps there could be an equivalent of Mediawiki:Sidebar for personal tools, that would allow arbitrary links to be added to it.
Oct 15 2018
Yes, sorry, I meant Wikistats 2, at the linked address. Thank you.
Sep 17 2018
Related: T174766 .
Sep 16 2018
Sep 13 2018
Sep 12 2018
Sep 11 2018
Sep 4 2018
Sep 3 2018
See https://en.wikipedia.org/wiki/Template:Outdent , which is already used to solve this problem on desktop.
Including share buttons is a heavily rejected perennial proposal. See https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Share_pages_on_Facebook,_Twitter_etc. .
Aug 30 2018
Looks like Vega is up to version 4 now, so it might be worthwhile to work on supporting that too.
I would be extremely hesitant to further reduce the oversight of use of the CentralNotice by removing Meta admins from those who can edit the CentralNotices.
Aug 29 2018
Try editing any page through Tor. (Presumably, a similar response would show up for any blocked proxy/IP/account.)
Aug 27 2018
Aug 19 2018
T135963 is relevant, I think? If the plan is to completely remove inline JS everywhere, CentralNotice's JS system will need to be reworked anyway, as the current system is to have all JS inline, I think. (Including using copy-pasted code for the close button, IIRC.)
Aug 16 2018
Aug 15 2018
Aug 14 2018
Jul 30 2018
Jul 25 2018
Jul 24 2018
(Note: This effect seems to be quite inconsistent. Only sometimes do the styles end up this way.)
I suspect this would also be useful for Wikibooks.
Jul 17 2018
(I'm assuming this task is for the general area of modernizing page histories, and not for a specific intended design.)
Jul 10 2018
Distinguishing deprecated statements sounds like a good idea because deprecated statements are (usually) actually false, but I don't think it would be helpful to have a different background between preferred and normal statements.
Jul 8 2018
Jul 2 2018
Current practice is to use Mediawiki:Common.css for this. See d:Mediawiki:Common.css, for example:
Jun 25 2018
The footer element is blocking the lower part of the popup. Is there any reason this can't be fixed just by fiddling with the CSS so that its width doesn't stretch across the whole element, and repositioning things so that this doesn't affect the appearance?
Ah, for historical reference, I should point out that this feature was originally part of Hovercards in the first place back when I wrote it in 2014. See https://www.mediawiki.org/w/index.php?title=File:NavigationPopups_V1.pdf&page=7 for Vibhabamba's first version of the design. It was removed shortly after.
Can we set up a temporary bug tracker that users can be redirected to until this is fixed? Unless I'm misunderstanding the summary here, Phabricator is completely non-functional for all but established users because of this.
Jun 21 2018
With the resolution of T195375, the example diff is rather ... different than it was before, showing the paragraph having been moved to a point before the lines deleted in the same diff. I don't know whether to consider that an improvement on that diff, but it might make solving this task somewhat easier.
Jun 19 2018
Probably related: The buttons in the language settings box are also off in Timeless, with the "Apply settings" button a very different height than its neighboring "Cancel" button.
Jun 11 2018
The developers are a continuing massive security risk, and one that is only being kept in check by these "vulnerabilities" that this plans to "fix". We've had confrontations in the past that only failed to be catastrophic because the WMF doesn't actually have the technical ability to stop people from editing JS. Control over the site can't be easily decoupled from powers necessary for basic maintenance, so the WMF and the developers can't seize power without causing everything to fall apart.
May 29 2018
IIRC, this has been discussed extensively over the past 13 years or so, with the general conclusion being that this would be a bad idea. Also, Phabricator is really the wrong place for this discussion.
Apr 8 2018
Apr 3 2018
A week isn't long enough to gather consensus for enabling it for logged-out users either. There isn't a separate shorter process for different classes of users, and limiting it to logged-out users doesn't make it okay to defy consensus.
Apr 2 2018
Deploy is scheduled for Monday 9th April
Feb 5 2018
@ovasileva @CKoerner_WMF I'm sorry, but your posts are both somewhat ambiguous and I'm having trouble understanding exactly what the plan is. Is the intention to post a summary of the bugs that have been fixed, and then launch a new RfC on whether to enable the feature? Or just post the summary, request some feedback/bug reports, and wait to see if someone there starts an RfC to enable it?
Jan 3 2018
@Izno This is not the same as either of those, though it does deal with a related issue. The default contents of the log summary box can be changed by the deleting admin, and do not prevent hiding of information. Since there's no issue of the admin being unable to hide certain content, and there aren't substantial technical barriers here, the problems with the other two tasks don't apply.
@Sjoerddebruin The way that's handled for other types of pages is for the deleting admin to manually remove any problematic text from the deletion summary. Seems like that would work here as well.
Dec 31 2017
Correct, this is about https://incubator.wikimedia.org/wiki/Special:RecentChanges .
Dec 27 2017
Dec 20 2017
@Lucas_Werkmeister_WMDE Ideally, sure, but it doesn't matter that much since that would also show up in the child chain.
Some such properties: father/mother/child (P-22, 25, 40), parent/child astronomical body (P-397, 398), part of/has part [of the class] (361, 527, 2670), subclass of (279), located in/contains administrative territorial entity (131, 150), parent organization/subsidiary/business division (749, 355, 199), has immediate cause/immediate cause of/has contributing factor/contributing factor of (1478, 1536, 1479, 1537), based on (144), parent taxon/parent peak/parent club/parent cell line (171, 3137, 831, 3432).
Dec 7 2017
inform enwiki and dewiki communities of upcoming page previews deployment
Enwiki already knows about page previews, and had a lengthy discussion rejecting it for the time being... Given that, I would think that any informing of a deployment would go in the other direction, from the community to the developers. Or is this talking about just the addition of some new features to the beta feature, while keeping it in beta?