Looks fixed. The change might have to be fiddled with, though, since I think it may have caused all the "type":"number" cells to disappear?

See for example List of busiest airports by passenger traffic. No bot involved, afaict.

Vega graphs using Wikidata queries has been available for a while, see Template:Graph:Lines for an example which is in common use.

In T245968#6946828, @lexnasser wrote:

Hi @Yair_rand, a pageviews top-per-country AQS endpoint was just released (docs). Does this fulfill your intended use case?

No, top-per-country deals with the most-viewed articles, not the most-viewed projects/language editions. This information is technically available using top-by-country, but only if one basically queries out the entire selection of all of the hundreds of domain options.

So, let's examine two models of "multi-day" occurrences:

• An organized "series" of events, with something at a particular time every day, for a certain duration.
• A single occurrence which lasts for the entire span of time.

For the former, "start time" and "end time" refer to the day-by-day individual things, while for the latter, the start time is irrelevant on any day after the first. In such cases, I think display would vary depending on style, but the options are basically to have the intervening days have a small "X continues" without a time listed, or to just leave it out and only show the event for the start and end dates.

@Lucas_Werkmeister_WMDE Seems to be gone for me (checking page source). Maybe it just took a bit of time to take effect?

No founding principle of Wikipedia would be disrespected.

I recommend reading the second Wikimedia founding principle: "The ability of almost anyone to edit (most) articles without registration."

In T120319#6180341, @Jseddon wrote:

I'm inclined to change this task to scrubbing all instances of vega 1 graphs out right. Any disagreement?

Removed most of the subscribers. Subscribing hundreds of people is not an appropriate way to notify them, and having everyone notified about every comment and change here is basically spam. Frankly, I'm surprised Phabricator even allowed that. It really shouldn't, IMO.

In T139050#6127460, @Iniquity wrote:

Maybe create a redirect to https://wikimediafoundation.org/? Or vice versa, create a redirect from https://wikimediafoundation.org/ to https://wikimedia.org?

wikimediafoundation.org is the corporate website of a particular Wikimedia organization, the Wikimedia Foundation. wikimedia.org is a movement site. Redirecting one to the other would not make sense.

In T218270#5154548, @Niharika wrote:

In T218270#5154006, @dbarratt wrote:

I think I prefer Mute options now that I think about it. :P

That was my initial thought. :) Will change.

I suspect that there may be a fair amount of new-ish users who patrol the recent changes, and wouldn't want every instance of reverted vandalism to result in another page they know nothing about added to their watchlist. Maybe the preference option can be split to not include reverts as regular edits?

@Reedy When I view that page, I don't see an "Active users" column. Also, the sentence "A maximum of 5,000 results are available in the cache." does not appear on the page.

The GadgetUsage system is maintained by Community-Tech, I think?

I notice that this runs on every wiki except for the English Wikipedia. Was this a deliberate decision (performance reasons, presumably?), or is it a bug?

When viewing a category on Commons, there's a link in the sidebar titled "RSS feed", linking to a feed of that category, generated by the CatFood tool hosted on the Toolserver. It can also generate RSS feeds of uploads from a particular account.

Most query results sets meant for human consumption would benefit from having the results sorted by pageviews. Needing to filter for a certain level of prominence is very common, and using the API isn't a workable solution for most people who would benefit from this.

In T234788#5638104, @Yurik wrote:

See my above comment, and @Lucas_Werkmeister_WMDE response -- while it stores things in the compact JSON form, the length is checked while it is in the "pretty-printed" format. A way to work around it might be to upload it to the server in the compact form via API, in which case it might get accepted.

APIs can't normally be used from wiki pages. And doing just a one-time upload of existing data sets means that Commons won't reliably have an up-to-date dataset, meaning wikis wouldn't be able to rely on them.

@Nuria Sorry, I didn't mean that it would be used on Commons itself. Data uploaded to Commons can be used on all Wikimedia wikis, via Lua modules. This would be useful on Meta and on some (statistics) project pages on some content wikis.

@Tgr See m:Talk:Wikimedia_Space#Export_strategy. If I'm not mistaken (@Qgil please feel free to correct me), using dumps and open formats for the WMF's Space project has been specifically rejected.

Promoting the use of social networks from Wikimedia projects is really problematic, IMO.

(Also relevant: T55740.)

Ideally, these would probably also be working like edittools, in the sense that clicking on the elements would add them to the code. This would depend on T55743 being fixed.

For general issues with forking/merging pages, see T113004.

In T211881#5509001, @dr0ptp4kt wrote:

Hello all. We're going to turn this into a client-side feature and divest of the server side rendering componentry.

How will this work for projects with a different main page for each language, eg Commons? The main page depends on the user's interface language. Normally, if you're a French-language user and you navigate to https://commons.wikimedia.org/ , you get redirected to https://commons.wikimedia.org/wiki/Accueil . Will https://commons.wikimedia.org/ still show the correct content to each user?

In T232983#5511920, @Qgil wrote:

I understand the initial resistance but, really, it can also be said that sending regular Wikimedia contributors to high traffic talk pages in Meta has also a risk of losing engagement. I don't think many volunteers feel engaged keeping up watching a page with a traffic like, say, en.wiki Technical Village Pump, only to check whether a certain question has been answered, check a diff across multiple sections...

We already have pings, and cross-wiki notifications, and there's a team working on increasing the usability of existing talk pages further.

At first glance, this certainly sounds necessary. It's a multilingual site, and should work for everyone.

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?)

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 .

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?

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.

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.

For "Wikimedia", the original colored Wikimedia logo would be correct, IIRC.

Unless I'm very much mistaken, the described system will make it possible to determine the country of specific editors, in some situations.

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.