Repo badges

[TinoDidriksen]

As discussed a bit in https://github.com/apertium/apertium-init/issues/51, we probably want badges for the monolingual and pair repos. But how should they look? Time for bikeshedding!

I've implemented a proof-of-concept https://github.com/apertium/apertium-stats but that's a very thin wrapper around the existing scripts. I don't expect that repo or code to survive, hence why this issue is filed here. E.g., https://github.com/mr-martian/apertium-lint might be a better place for this kind of statistics gathering.

But to get the conversation started properly, I've added this to the nightly builder so that each successful build of a language or pair will yield statistics for that commit and update the badges.

E.g., for apertium-kaz:

• https://apertium.projectjj.com/pkg-stats/apertium-kaz/
• 

For apertium-ote:

• https://apertium.projectjj.com/pkg-stats/apertium-ote/
• 

For apertium-pt-gl:

• https://apertium.projectjj.com/pkg-stats/apertium-pt-gl/ which has JSON statistics for each point in history.
• 

All subject to change. Should it look like that? Probably not. Should it be stored there? Absolutely not. Are these the stats we want?

But this works. Adjusting it and storing everything on apertium.org instead is easy. Stuffing the statistics into a service is similarly easy.

@sushain97 @ftyers @unhammer @flammie @IlnarSelimcan @mr-martian @xavivars

[mr-martian]

The lexc and lexd ones seem awkwardly long to me. The others look good though.

https://github.com/mr-martian/apertium-lint/issues/2 might also be relevant if there is some question about the proper way to count certain things

[TinoDidriksen]

They are definitely too long, but what's the alternative? Multiple badges? Shorter words?

E.g. lexd: 42 ls (5108 e), 18 ps (35 e) ?

[mr-martian]

I would say probably determine which part of that people care most about and drop the other numbers (which may end up being the same as multiple badges if there's disagreement)

[jonorthwash]

At first glance, I don't mind how they look. It would be good to get things like coverage or WER in there too, if that's an eventual possibility.

[mr-martian]

Both of those could easily be included in my test framework and thus be available as badges sometime this summer.

[flammie]

I like the basic stats but definetely coverage / wer too, I also think if we still assume that apertium pairs fall under these: incubator / nursery / release labels and they are useful classification that should be the most useful badge to show.

[TinoDidriksen]

Coverage would be nice. But badges for things that are already part of Github's UI is superfluous. We have tags that say what release-quality a pair is at.

[flammie]

But badges for things that are already part of Github's UI is superfluous. We have tags that say what release-quality a pair is at.

My experience is that most users don't know how to look at github's tags at all. tbh most users cannot find the releases either (some even struggle with issues), you basically have to duplicate most of github functions in readme to avoid getting those questions.