Overriding of badge properties doesn't seem consistent

[ELLIOTTCABLE]

• https://img.shields.io/twitter/follow/ELLIOTTCABLE.svg?style=flat&label=followers&color=blue
• https://img.shields.io/npm/v/paws.js.svg?label=release&color=blue

There's a couple other examples, but you get the idea:

1. I can't seem to change any property of the ‘social’ badges. What on earth is the logic of the flat colour for Twitter followers being red by default? I dislike any of the badges showing up as orange/red unless there's something wrong with the project at the moment. (Unmaintained, tests failing, in pre-release state …)
2. The colourization logic for some of the badges makes little sense (to me at least); and even if there's a sense to it, it'd be really convenient to be able to override those options electively. (Sure, colouring badges red when tests are failing does convey extra information; but what if I'd prefer to have a consistent style, and just want all of my badges to be black/pink? :D )

---

While we're on the topic of the social badges, I'd like to point out that there's no unit in the Twitter-followers badge, which is kind of annoying. means very little, implies that the project has 7k followers (and is ambiguous! followers on GitHub? on Twitter?), is very … awkward. I'd love an unit= option to append content to the right-hand-side of badges, or something like that? :P

(Finally, the numerical collapsing can be pretty in some cases, but I'd prefer a flag for the raw number.)

[AdrieanKhisbe]

The red color is probably a default. 18cd0c1 introduces badgeData.colorscheme = '55ACEE';, which is wrong. It turns out that colorscheme is defined in INSTALL.md as a set of two colors defined in colorscheme.json. So that's the reason for it to be red. It should have been the color that Twitter recommends as part of its brand asset definition.

I fixed it, so that https://img.shields.io/twitter/follow/ELLIOTTCABLE.svg?style=flat&label=followers will give the correct color. (as you might see in the original issue)

---

About the issue of having the power to override color. There's a patch that should allow that, which has been reviewed, but the author hasn't gone further. If you want to take over the patch and finish it, you're very welcome to do so. If not, we'll try to do it when we have time.

---

As for units, they're an interesting idea. The answer has usually been that all the information describing the right-hand side should be stored on the left-hand side. The right-hand side is meant to contain the bare minimum of information. If we gave the ability to customize it by adding text at the end, we'd need to allow adding text at the start (as some units, like currency, are shown at the start).
It is certainly something we'll consider. 😃

[ELLIOTTCABLE]

I'm all for avoiding units, to be honest. I don't think my suggest was very-well thought out. The on-brand colour looks muuuuuuch better; the final things, then, that you didn't touch on,

1. Overriding the label (Actually the primary reason I brought up this issue; badges tend to pile up, and I def. don't have room for “Follow ELLIOTTCABLE!” Woes of a long Twitter handle. :3)
2. Preventing collapse of numbers like that 7,000 → 7k (although … same room concerns, for my own use. I just think plenty of people might appreciate it? ¯_(ツ)_/¯)

[espadrine]

Overriding the label

Ah, sorry, it's a bug. Fixed.

Preventing collapse of numbers

Adding query parameters that only work for a subset of badges is tricky. I'll see if we get more requests of that type. I have got requests to add floating-point digits (as in, 7.24k for instance), so satisfying everyone may be hard.

[ELLIOTTCABLE]

Yeah, digits work too. I wouldn't suggest you go too wild with it; I think either a ?long=true or a ?exact=true or something, but I don't think it needs much more in the way of configuration.

basically, as long as there's both "200k" and "200,143" or "200.14k" or something, a single long format and a single short format, I'm happy. :3

[ELLIOTTCABLE]

@espadrine By the way, see #619; the label-overriding is only fixed for some cases, apparently!

[paulmelnikow]

Most of this has been addressed and I feel like this is resolved. Feel free to open a new issue if you'd like to discuss further.