Fix broken badges with statistics

[Aracki]

I suggest we remove the following two badges.

• GitHub contributors is not needed as you can see that in the top bar.
• Number of files seems broken and nevertheless I think we do not need this (maybe the number of pages by OS would be better statistic)

[waldyrious]

I agree with removing the number of files badge, although I'd prefer if we could replace it with another service providing a count of pages in the repo or in a specific folder. I think it was @pxgamer who mentioned that we could even contribute new badges to shields.io, so even if such a badge doesn't exist, maybe we could create it.

As for the contributors badge, I think it's worth keeping it since it matches well with the ones counting merged PRs and issue resolution time. Essentially they're signals of community activity, and the fact that we chose to include those numbers in the README also reflects our project's focus on welcoming contributions.

[sbrl]

That's a really good argument for keeping the page count badge, actually.

On Gitter, we considered a few approaches, all centred around the new dynamic badge feature of shields.io:

1. Reconfigure @tldr-bot to emit statistics.
2. Alter the build process to emit a stats.json containing various interesting statistics.

Personally, I really like the 2nd option here. It could even be used to make a 'status panel' that shows various things like page counts per platform, translation percentages, etc.

[Aracki]

@waldyrious Why there is 406 contributors showed in the badge and 741 in the top bar?

[owenvoke]

Anon users maybe? You can do:

GitHub Contributors (current badge) With anonymous contributions

Maybe GitHub has merged some duplicates or something?

[waldyrious]

It would indeed be nice to have a more concrete idea of the reason for the discrepancy. That would be relevant e.g. for #1076.

[mebeim]

For the number of files badge, the second option proposed by @sbrl seems like the way to go IMHO. I think having some kind of statistics about the project would be cool and helpful, and that would of course make the file count badge trivial to generate from shields.io's dynamic badges.

For the PR badge the thing is, as you guys pointed out, that it doesn't match any other contributor count. If that matched, then I think that'd make more sense, but since it doesn't it actually ends up looking kind of confusing. It may be redundant, but as @waldyrious said it's a good indicator of this project's main objective, do I'd keep it while investigating about the number.

---

PS: some stats which I think could be cool to have if we decide to produce them:

• Overall page count and page count per OS.
• Translation progress per language.
• Translation progress for coreutils per language (+ details on missing ones).
• Overall size of all pages (maybe even per language?).
• Number of open "page request" issues (slightly more complex than previous ones).

[waldyrious]

Overall size of all pages

Size measured in what? Number of examples? And how is this useful information?

Also, let's make sure we don't overload this plan with too much stuff, otherwise it'll never get off the ground! 😅 I'd say let's just focus on providing a count of pages for now.

[owenvoke]

I assumed it was size in MB, KB, or bytes.

But I agree it would be good to get it done initially, we can add more later if necessary.

[mebeim]

@waldyrious size in bytes. That'd be a useful indicator of the actual weight of the pages on a system. Anyway, I was just throwing out some ideas, since I liked the idea of having some statistics. All of those would be very easily doable along with the page count, but yes the latter would still be the most important one.

[Aracki]

I think the size in bytes is not useful at all. People would only care about the actual number of pages (per OS).

I think that would be the best indicator of overall progress of tldr-pages.

[owenvoke]

@Aracki, I actually kind of agree with @mebeim. With the tldr clients, they download the entire ZIP archive for caching. I'd want to know the size of what I'm downloading. 🤔 (Maybe that's just me though) 😛

The number of pages is (more) important obviously, but the size isn't a bad stat to include. It's currently 8.3M to store the cache directory in ~/.tldr/cache

[mebeim]

@pxgamer yep that was exactly my thought, but again I was just throwing some ideas 😅

[sbrl]

If the stats json file is located alongside the zip archive, then it would make sense to also include the size of the archive file in bytes as a property. If however the stats file is located inside the archive, then it's a bit challenging to include the size of the archive because it won't have been generated yet - and by the time the user has downloaded the archive file they'll know how big it is anyway :P

In other words, if we include the size of the archive as a statistic in the stats file, the stats file should be located alongside the archive so that they can be downloaded independently of each other.

[owenvoke]

Alongside the ZIP, definitely not in it. :+1:

[mebeim]

Well, of course any stats would be in a separate file, just like index.json is also served as a separate file now, there would be a stats.json file in the same directory, but not inside the ZIP. Point is, anyone who downloads the ZIP already has everything they need to create any kind of statistics they want, so having them inside of it would definitely be redundant. Also, having stats.json inside the archive would prevent us from creating a badge from it which is the whole point of why we even started thinking about it 😅 .

[sbrl]

I'll rename this issue to better reflect what we're going to do then :-)

[andrik]

Hi guys, I'm a big fan of translation progress stats even because it was the way I started to contribute.

[Aracki]

I would like to close this one if we agreed on keeping the contributors badge...?

[mebeim]

@Aracki I think we should leave this open until we have implemented a simple statistic as we agreed in the comments above. There's no rush.