Talk:XTools/2018

This page is a feedback forum for XTools. For reporting bugs, it's preferred that you use Phabricator.

If the issue is urgent and you're unable to use Phabricator, feel free to ping one of the active maintainers.

Pages Created misses some articles?

Hi, two groups of articles are imho not listed: own redirects that were later converted into an article and redirects by others that were converted to articles. Ghilt (talk) 20:57, 26 February 2018 (UTC)

Unfortunately, MediaWiki has no log of pages that came redirects, and vice versa. This means there currently is not an efficient way to identify articles that were created from redirects. There might be some really hacky ways to do it, but ideally we'd fix this in MediaWiki and not in XTools.

There is a ticket for a very similar issue at phab:T182183. You can follow it for updates. — MusikAnimal ^talk 21:09, 26 February 2018 (UTC)

Admin Score mistake?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Why in section Admin Score edit summaries used in the article space and edits to the article space count is same for all users? Manvydasz (talk) 21:20, 2 March 2018 (UTC)

Edit summaries are measured only in the mainspace because that's a strictly collaborative area. For instance you generally aren't expected to use edit summaries in your userspace.

Your second point sounds like a bug. This tool admittedly has not been given much attention. I'll try to look into it soon. — MusikAnimal ^talk 17:06, 6 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Edit Counter/General Statistics/Global edit counts links

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

IMHO the links on wiki names in this section should switch statistics to another wiki (there is no easy way to do it now); the links on numbers would be better to link to contributions on that wiki (as the links on names do now). Mik (talk) 12:05, 6 March 2018 (UTC)

I like the first idea, having it show the Edit Counter for that wiki when clicking on the wiki domain. For the numbers, I kind of like linking to Top Edits, which gives a quick synopsis of their editing activity on that wiki. However Edit Counter also shows this information... so I guess your idea makes sense :) — MusikAnimal ^talk 17:04, 6 March 2018 (UTC)

The requested changes have now been made. Thanks again — MusikAnimal ^talk 16:37, 13 March 2018 (UTC)

Thanks :) Mik (talk) 09:47, 14 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

EditCounterGlobalOptIn.js on meta.wikimedia.org

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The global opt-in ceased to work on most wikis (it seems to work only on enwiki). Mik (talk) 12:13, 6 March 2018 (UTC)

It looks like your EditCounterGlobalOptIn.js is empty? Try adding any content. Per consensus enwiki always shows advanced statistics, which is why you're seeing them there. — MusikAnimal ^talk 16:52, 6 March 2018 (UTC)

It worked, thanks. Mik (talk) 17:07, 6 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

help! Articles incorrectly counted as deleted

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, would you please be able to help? A couple of my articles have been moved, and now the tool is incorrectly showing them as deleted. This makes it look like I have 2 deleted articles: https://xtools.wmflabs.org/pages/en.wikipedia.org/DrVogel. This is clearly a bug in the tool, and it's also really unfair because I'm always extremely careful :( Thanks for your help, ~ DrVogel (talk) 15:03, 19 March 2018 (UTC)

It is not a bug. A page you created was deleted, so XTools is reporting it. It doesn't know if it was for a good reason or bad. If you hover over the "deleted" text it will say the deletion reason, which in your case is "G6: Deleted to make way for move". For both of those articles, it also says "recreated", and there is a message at the top "Some deleted pages may have been recreated by this user or a different user.". This unfortunately is the best we can do. We want to report all deletions, regardless of why they were deleted. Another example, someone created an article and it was deleted for copyright violation (bad), then they recreated it and the new version was kept. We still want to know about the old version that was deleted. Hopefully that makes sense. In short, "deleted" is not necessarily a bad thing :) — MusikAnimal ^talk 15:21, 19 March 2018 (UTC)

Hi, thanks very much for your reply. This was not a deletion, it was a move. And it was not recreated, because it was never deleted. The reason it looks like it was deleted is because there was a redirect at the target address, and because it's impossible to simply swap an article and a redirect, the redirect (not the article) was deleted, then the article moved with a new redirect created. So it is not a deletion at all. So what it shows is incorrect. There was no article deleted. Please help to put this right. Thank you. DrVogel (talk) 15:33, 19 March 2018 (UTC)

There is already some logic to exclude pages that were moved over redirect (and hence caused a deletion), but that is not what happened here. Here the redirect you created was deleted directly (and for good reason :).

You are correct, however, that these were redirects that got deleted, not full articles. Unfortunately it is not easy (or at least performant) to detect if deleted revisions were redirects. It may not even be possible, not sure... The issue being that there is no formal log of when redirects are created. There are some tags, so we might be able to go off of that... maybe. I've created phab:T190065 for this, feel free to follow it for updates. However I can make no promises that it will get resolved :/

Overall I don't see a big issue here, because one can simply hover over the "deleted" text to see why it was deleted, and in this case would immediately be able to tell it was a deletion to make way for a move. — MusikAnimal ^talk 15:59, 19 March 2018 (UTC)

It '''is''' a big issue, because it puts people who are very careful and create valuable content, on a par with people who add rubbish and spam to Wikipedia. That's pretty terrible.

The only reason there was a redirect that got deleted, was that, because I'm so careful when I create articles, I always make sure that all possible spellings etc are also created as redirects. Another user then decided to move one of my articles (over a redirect for a name that I had foreseen, hence the existence of the redirect), and that is why it shows (incorrectly) as a deletion.

Do you realise that this basically punishes me for doing the right thing (creating redirects for all possible alternative spellings), when I would have been better off being lazy and just creating the article?

How can it be a good idea for the project to make people be better off being lazy?

Come on, you have the power to put this right, please use it. Discouraging people who create valuable content can't possibly be a good idea. DrVogel (talk) 16:19, 19 March 2018 (UTC)

No, I think you've got it all wrong. Deleted != bad, period :) What if you G7'd some of your own articles? Or G2 (test)? Those are innocent, but should still show up, no?

XTools just reports what's there. It is not any sort of an authority, nor is it a way to definitively measure an editor's success. It just gives the data. It's up to the user to decide how to interpret it. For instance, if you were applying for autopatrolled privileges, any admin will know to check the deletion log. We've tried to make this easier by providing the deletion summary when hovering over "deleted".

As I said I can look into phab:T190065, but it will be very challenging, and only handle your edge case. I'm still not sure it's even possible (a lot of data around deleted revisions isn't present on the Toolforge database). Even if we did manage to do this, it wouldn't work for historical data, because the redirect tag system was only recently introduced (roughly December 2017). Otherwise we'd have to go off of the content of the deleted revisions, which is fragile and moreover only accessible to admins, so XTools can't do it :(

There are certainly some improvements that can be made, and we'll do our best to get those done. At the very least, I hope I've convinced you that we're not trying to punish or discourage valuable editors such as yourself. That's downright silly!

Thanks for your understanding :) — MusikAnimal ^talk 16:51, 19 March 2018 (UTC)

Clearly, if the tool is counting a name swap between an article and a redirect as a deletion, it is wrong. DrVogel (talk) 17:51, 19 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

New tool idea: Category activity

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi there,

I recently learned that the RecentChanges table now also stores information about pages added to and removed from categories, at least for 30 days. I think it would be really informational if there was a tool that could - going from the current number of pages in a category - display how many pages were added and removed, thus allowing to visualize whether there was a significant shift in activity (for example, it seems to me that the category containing GA nominations waiting to be reviewed became significantly larger since ACTRIAL ended on en-wiki on 14 March, so it would be nice to see whether such a spike really happened).

The SQL to query such changes seems easy enough (cf. [1]) and with the existing frameworks, visualizing the data should be easy as well. Is this something someone might take on? Otherwise, I will try to create a tool myself but I probably need much longer...

Regards

SoWhy SoWhy (talk) 14:52, 22 March 2018 (UTC)

Yeah that seems like a useful tool! I think it might benefit outreach programs too, as they often work within specific categories and want to see how much they've grown. This tool would also work for any (recent) MediaWiki installation, so it's XTools-friendly. Would we want to show the fluctuation in size of the category on a chart? That'd be pretty neat!

I personally can't devote full time to this right now, but I am interested. If you want to contribute to XTools, by all means, we'd love it :) Does that interest you? If so, I'll run the idea of this tool by the rest of the XTools team, just to make sure we're all OK with it (but I think they will be :) — MusikAnimal ^talk 19:03, 22 March 2018 (UTC)

Well, as you can see from https://tools.wmflabs.org/sowhy/, my skills are sub-par at best. I can't even begin to understand the complexities of the kind of coding you guys do. So it would probably be easier if someone from the XTools team handles it.

I think a graph showing the ebb and flow of pages would be the best way, no? Since the query is simple and all the tool has to do is $i++ on "added to" and $i-- on "removed from" rows, the actual code for this tool would probably be minimal. Someone who knows the existing code could probably cobble something together in half an hour I'm guessing. SoWhy (talk) 19:19, 22 March 2018 (UTC)

Ha, if only! I would guess with all things considered, including code quality, testability and adding an API endpoint (not that hard after the other work is done), it's probably several days of work at least. Still, myself or one of us can probably devote time to this before too long. If not, maybe we could submit this as an idea for an Outreachy, Google Code-In, or Hackathon project.

Thanks for the fine idea. I will keep it in my mind, but I personally probably wouldn't get around to it for a month or so. Also, we're almost at the point where we have too many tools in XTools. We'd need a bit of infrastructure work to add more, and to organize that ever-growing top navigation. Just thinking aloud. Anyway, if you wanted to take it on yourself, don't let me stop you :) — MusikAnimal ^talk 19:38, 22 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

New tool idea: Global Edit Counter

Hi,

Maybe you could think of a Global Edit Counter page with only global info, like all accounts (from Special:CentralAuth or from sulinfo, the second is better because there is creation date and not attach date), and statistics (yearly, and monthly if someone has EditCounterGlobalOptIn.js, time card maybe also) summed from all wikis with colors assigned to wikis (instead of namespaces). Latest global edits would naturally belong there, and on existing Edit Counter pages there could be only latest local edits.

Regards,

Mik. Mik (talk) 14:38, 27 March 2018 (UTC)

My gut instinct is that this would go too slow for an on-demand tool. But, if we restrict to just certain stats like the year/month counts (and even timecard), it might just be feasible. Those queries actually go fairly fast.

The log counts, and other things that you see in "General statistics" are not fast, however. We'd definitely have to omit some data, otherwise the tool would go painfully slow -- 30 minutes, an hour, perhaps longer -- depending on how prolific the user is.

I'm working on other things for XTools right now, and we have a backlog of bugs to kink out, but I'd love to look into your proposal at some point. I've created phab:T190819. You can follow it for updates.

Thanks! — MusikAnimal ^talk 15:11, 27 March 2018 (UTC)

To start, there could be only information that can be retrieved from centralauth, sulinfo, and latest global edits, which are quite fast (finishes in a few seconds). There is already a tool that draws nice pie charts, and a sorted list of accounts with creation dates: https://tools.wmflabs.org/meta/stalktoy/mik, however it is very slow (finishes in a few minutes). Mik (talk) 14:37, 11 April 2018 (UTC)

Improvement: Browsable Latest global edits

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I do not know how Latest global edits is implemented, but it would be nice if it was browsable. If you do not cache all edits (I doubt it), you could get only latest ones from each wiki (like 50 or so), and on pressing next remember only the latest displayed edit for each wiki, and get the changes from that point. I hope my explanation is clear enough. Mik (talk) 14:45, 27 March 2018 (UTC)

It goes quite slow, is the problem. For a more thorough review of individual edits across all wikis, I recommend trying the Global user contributions tool, which is optimized for this purpose. This is linked to at the top of the XTools Edit Counter. — MusikAnimal ^talk 15:14, 27 March 2018 (UTC)

The GUC tool is limited to 20 edits/wiki. Mik (talk) 07:07, 28 March 2018 (UTC)

Probably for the same reason, that it goes really, really slow :/ I can see from the production logs that the XTools global contributions, as-is, often times out. That's why it's loaded via AJAX (after everything else has loaded), so as not to slow down the whole tool.

We might could allow this in the dedicated global edits page (e.g. https://xtools.wmflabs.org/ec-latestglobal/en.wikipedia.org/Mik), and if it times out, well, it times out :) I see that the tool loads quickly for your account, so it is certainly true that for many people this would work quite well.

I've created phab:T190956. — MusikAnimal ^talk 18:39, 28 March 2018 (UTC)

This feature has been deployed. Let us know if you have any issues. — MusikAnimal ^talk 00:43, 16 June 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Caching data for heavy editors

Hi. Would it be possible to cache edit counter data for editors with a large amount edits on a project, and then only load that cached data, and/or cache data and show that data in the event of a timeout? This would prevent the endless loading that currently occurs for some users. Jc86035 (talk) 17:01, 23 April 2018 (UTC)

All user-related data is cached for at least 10 minutes, sometimes longer. In general, people don't query for the same user/project that often, so we'd have to cache for a long time -- 24, maybe upwards of 48 hours -- for it to be any useful, and by that time the data will probably be stale. The other issue is caching consumes disk space, and given the popularity of the tools it will fill up quickly.

You make a good point, though. Perhaps we could do this aggressive caching only for users with a high edit count, or requests that take a long time to complete. Another example that comes to mind is users who are undergoing a request for adminship. In these cases people are frequently querying for the same user, such that it'd make sense to cache for longer.

Some ideas:

• Cache for say, 24 hours, only when the request takes > 60 seconds to process. When a cache hit occurs, check the raw edit count (cheap) to see if it is different from the cache. If it is, we know the data is stale and we should generate new data. This seems most ideal but it will not be easy to implement.
• Cache for 24 hours, again only when the request takes > 60 seconds, but offer a "purge" option so that users can manually refresh the data. This is easier, but I think to many the concept of "purging" is confusing.
• Cache after hitting a throttle limit, e.g. if people look up User:Foo five times within an hour, it will cache for a whole hour instead of 10 minutes. That would handle the RfA example. This is easier to implement (we already do something similar for the ArticleInfo gadget).
• Some combination of the above.

Not an easy problem to solve :( — MusikAnimal ^talk 19:13, 23 April 2018 (UTC)

Hourly Punchcard data

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Would love the option of displaying the full hourly Time card. No great need, just interest. T.Shafee(Evo﹠Evo)^talk 06:16, 28 May 2018 (UTC)

Well, it only took 2 years, but this is finally done :) E.g. https://xtools.wmflabs.org/ec-timecard/en.wikipedia.org/Evolution%20and%20evolvability — MusikAnimal ^talk 04:17, 14 January 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

User talk links

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Why does the edit counter replicate (some) editors' custom signatures in the listing of user talk pages edited? Kind of distracting, and potentially one more place for an accessibility issue. ~ Yngvadottir (talk) 00:32, 6 June 2018 (UTC)

They are display titles (like how some titles of articles are italicized), shown when linking to the page. Some users change these into something really fancy on their user page. Maybe we should only show the display title when viewing data about that page in particular (e.g. Page History tool), which would match MediaWiki behaviour. — MusikAnimal ^talk 00:50, 6 June 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wikidata "Page title" label? in Pages Created tool

Is it possible for the "Pages Created" tool to automatically generate a list of Wikidata pages created by a user that includes "Page title" values for both Q and the natural-language label? Thanks. Oa01 (talk) 12:00, 10 June 2018 (UTC)

Average edit size

Would it be possible to calculate this as the root square to measure absolute differences?

I.e. net change average of +3, -4 and -5 = ±4

Otherwise stats like average edit size can be skewed by deletions and lead to misleadingly low (or even negative) changes.

Alternatively ignore all -ve values when calculating and report average addition size and average reduction size or equivalent. T.Shafee(Evo﹠Evo)^talk 03:54, 14 June 2018 (UTC)

Maybe you're talking about variance? If so then yes, this should be an easy change thanks to MySQL built-in functions. They also have a function for standard deviation. — MusikAnimal ^talk 04:03, 14 June 2018 (UTC)

Here's what MySQL generated for your account: https://quarry.wmflabs.org/query/27644. Average edit size 119, variance 2255. Does that sound right? — MusikAnimal ^talk 04:13, 14 June 2018 (UTC)

Although variance is the most mathematically reasonable, it is possibly a little technical for many.

I'd actually intended a simpler-to-interpret measure of average byte change whilst ignoring whether its +ve or -ve. For example:

• edit A, +2 bytes
• edit B, +3 bytes
• edit C, -4 bytes
• edit D, -5 bytes

Average

$\frac{+2+3-4-5}{4}=-1$

Average change

$\frac{\sqrt{(+2{)}^2}+\sqrt{(+3{)}^2}+\sqrt{(-4{)}^2}+\sqrt{(-5{)}^2}}{4}=+3.5$

Average addition size

$\frac{+2+3}{2}=+2.5$ accounting only for addition edits A and B

Average reduction size

$\frac{-4-5}{2}=-4.5$accounting only for deletion edits C and D

For the four edits above, the average is -1, which is tricky to interpret. Do they just make small deletions? Do they make large deletions and additions that happen to almost net cancel? By splitting the additions and reductions, it becomes possible to see whether they e.g. mostly make lost of small additions with the occasional massive deletion. T.Shafee(Evo﹠Evo)^talk 06:04, 14 June 2018 (UTC)

So much math! =P The issue here is we are bound by what MySQL can do for us. Otherwise we have to pull in the edit size of every edit, and run our calculations, which will consume too much memory for some users. I can say of the options you've laid out, the average addition and reduction size should be doable, assuming the query is still fast enough. Note we do show the number of small edits (< -20 diff size) vs large edits (> 1000), so I hope that in a way also gives an idea of the size of edits a user typically makes. — MusikAnimal ^talk 00:42, 16 June 2018 (UTC)

I think the average addition size and average reduction size would be interesting statistics to know, but being a statistician makes me more of a dork than the typical editor. The edit size distribution for most editors is probably highly positively skewed, so it might be worthwhile to report to median addition size and median reduction size (either as an alternative to or in addition to those averages). Seppi333 (talk) 13:54, 15 March 2019 (UTC)

Top edits per namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The "Top edits per namespace" only displays the top 100 pages which I have edited in the Main space. Previously, I was able to see a display of all the pages to which I had made at least one edit. Is there any way to expand the current display to more than 100 pages? I found it quite useful to track my total edits in a single place rather than having to look at the Revision history statistics on a page-by-page basis. Mtminchi08 (talk) 01:49, 17 July 2018 (UTC)

We can't list all results, unconditionally, as their could be tens of thousands for some users. But we could limit it to 1,000 results and let you use pagination to see the rest. I've created phab:T199765. — MusikAnimal ^talk 04:33, 17 July 2018 (UTC)

Thank you. That would be really helpful. Mtminchi08 (talk) 04:39, 17 July 2018 (UTC)

Following up on last month's discussion...when will this be available for public use? Mtminchi08 (talk) 04:03, 20 August 2018 (UTC)

It's on the radar :) I expect to get around to this maybe within the coming week. You can follow phab:T199765 for updates — MusikAnimal ^talk 18:52, 21 August 2018 (UTC)

This feature has been deployed. Thanks for the patience! — MusikAnimal ^talk 02:16, 17 September 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

New edit counter is overkill

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

What happened to the previous edit counter and pie chart? With all due respect, the new 'system' looks like someone's overly involved science project. Are all these new features, graphs, charts, mini-pie charts, etc, etc really necessary? Who really needs all of these features? Besides that, the new edit counter takes -very- long to come up. Is there a way to go back to the previous edit counter? Gwillhickers (talk) 00:30, 1 August 2018 (UTC)

I think you're talking about how the Supercount tool now redirects to XTools. That was done by @Cyberpower678. I will say that soon, XTools will allow you to specify which sections you want to see. With that, you could hide the "Timecard", "Top edited pages", etc., and effectively get only the information Supercount provided. — MusikAnimal ^talk 01:03, 1 August 2018 (UTC)

@Gwillhickers A new version of XTools has been released that allows you to select which stats you want to see in the Edit Counter. If you want it to match Supercount, I think that would include "general stats", "namespace totals", "year counts" and "month counts". You can generate links using the form at https://xtools.wmflabs.org/ec. So for instance, a link for Gwillhickers could be constructed like this:

https://xtools.wmflabs.org/ec/en.wikipedia.org/Gwillhickers?sections=general-stats%7Cnamespace-totals%7Cyear-counts%7Cmonth-counts

@Cyberpower678 I don't know if you want the Supercount redirect to just show these sections, but it's now an option. — MusikAnimal ^talk 00:42, 15 August 2018 (UTC)

@MusikAnimal If you can pickup referers, you can certainly make it a default option if you detect that the user just got redirected from Supercount. But Supercount is old, insecure and vulnerable. For now it will exist to redirect to a properly developed tool. Cyberpower678 (talk) 02:51, 15 August 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Browsable Latest global edits: jump

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

First of all, thank you for implementing this feature. However it is missing one thing: it should be possible to jump to a specific date or page or edit# (whichever is simpler to implement). It could be even a parameter in URL. Browsing thousands of edits page by page is not very convenient. Mik (talk) 07:08, 22 August 2018 (UTC)

Related thing: After getting the following error:

Error querying Latest global edits API: timeout

reloading will lead to the first page. It should retry to generate the same page that was last displayed. This again speaks for a URL parameter. Mik (talk) 07:38, 22 August 2018 (UTC)

Yes the API timeout is shorter than the database query timeout, so sometimes you can hit refresh and it will show up. That much I can certainly fix.

There is a hidden feature for pagination. On the dedicated ec-latestglobal page, you can add a /50 for instance to the end of the URL to offset the results by 50. For example: https://xtools.wmflabs.org/ec-latestglobal/en.wikipedia.org/Mik/50. We should make the URL update itself whenever you paginate through the results, so that this feature will be more obvious.

I would like to implement date filtering, too. I think that would be very helpful. We do this for about half of the tools (Page History, Automated Edits, etc.), so we should do the same for the Edit Counter to be consistent. This would also be a way to speed up the processing time. I have created phab:T202552. — MusikAnimal ^talk 16:15, 22 August 2018 (UTC)

The new dedicated Global Contributions tool offers date range options. This is no longer included in the Edit Counter because it is so slow. — MusikAnimal ^talk 03:06, 14 January 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Namespace colors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The colors of namespaces in the charts and graphs could relate to each other in the following pairs:

Main	Talk
User	User talk
Wikipedia	Wikipedia talk
Template	Template talk
File	File talk
Book	Book talk
Category	Category talk
Help	Help talk
Portal	Portal talk
...	... talk

Eg. the color of talk namespace could be the same hue and saturation but lighter than the related non-talk namespace color. Mik (talk) 07:21, 22 August 2018 (UTC)

I'm fairly apprehensive about changing the namespace colours. The old XTools and Supercount (now retired) used the same, so there's sort of an established, long-standing norm. I think the current colours were chosen such that if you listed each namespace in sequence (main, talk, user, user talk, ...) they won't clash. — MusikAnimal ^talk 16:01, 22 August 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Summaries

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, the tool seems to be counting more edits as being without edit summaries all of a sudden. Could you tell me what edits are now being counted as without? Is it starting new pages or use of a tool like twinkle perhaps? Kosack (talk) 07:13, 30 October 2018 (UTC)

It's due to a WMF database migration. All summaries should return in a few days (hopefully). I'm putting up a disclaimer in the XTools interface, and will look into an interim solution until WMF is done with the migration. You can follow updates at phab:T189234. — MusikAnimal ^talk 16:46, 30 October 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Edit summary

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Since few days this tool shows all semi automated edits as no summary edits. If the counting system is not changed please solve this problem. RHcosm (talk) 14:05, 30 October 2018 (UTC)

It's due to a WMF database migration. All summaries should return in a few days (hopefully). I'm putting up a disclaimer in the XTools interface, and will look into an interim solution until WMF is done with the migration. You can follow updates at phab:T189234. — MusikAnimal ^talk 16:46, 30 October 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Changes...?

Recently (I'm not sure how long ago) it seems there were some changes. The headings are now defaulted to the right, and their content to left (but lower), which makes it awkward looking, and not as easy to follow. Also, what happened to the edit summary chart? Not that it was all that accurate, but please tell me it's coming back soon, after there has been an update to improve accuracy (and by then the headings will be fixed). Thanks Thewolfchild (talk) 20:12, 21 November 2018 (UTC)

Sorry for the long response...

The headings are now defaulted to the right, and their content to left (but lower)I'm not sure what you mean. The headings always encompassed the width of the content, and the label is centered. What changed here is new headings were added for "Basic information" and "Edits (live)". We did this because we removed some statistics from the Edit Counter, so things were moved around to make use of the available space on the page. If you have any ideas on how to reorganize it and make it look nice, please share :)

For edit summaries: The WMF database that stores summaries was recently redone. Now all summaries (edits, log entries, etc.) live in a different database table. It's too slow to query these alongside all the other expensive queries that the Edit Counter runs, so instead we're showing links (see bottom of the "Edits (live)" section) to the dedicated tools to get this data: Edit Summaries and Automated Edits (which uses the summaries table).

But, you are right -- the summary stats we used to show in the Edit Counter weren't precise. They just checked where the summary was blank or non-blank, and didn't account for automated edit summaries like /* Section */. This was for performance. Enter the Edit Summaries tool, which will account for automated edit summaries, giving you what should be 100% accurate results :)

Hope this helps — MusikAnimal ^talk 04:37, 25 November 2018 (UTC)

Thanks for the reply. Would it help if I sent you a screen cap showing the layout of the page (that I'm seeing) and the placement of the headings? Thank again Thewolfchild (talk) 23:12, 27 November 2018 (UTC)

Colors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There is color inconsistency in articleinfo. While in the Year counts, IPs are red and minor edits are green, in the Month counts, the colors are assigned conversely (green IPs and red minor edits). It's confusing a bit. Draceane (talk) 16:11, 23 November 2018 (UTC)

Fixed and will be deployed with the next release. — MusikAnimal ^talk 03:11, 14 January 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.