Linguist: So, I'm not sure when this happened exactly, but it looks like GitHub is now displaying language colours underneath code-search results as well:

Created on 26 Aug 2020 · 10Comments · Source: github/linguist

So, I'm not sure when this happened exactly, but it looks like GitHub is now displaying language colours underneath code-search results as well:

Which is going to leave a lot of grey for data/prose languages...

_Originally posted by @Alhadis in https://github.com/github/linguist/issues/4506#issuecomment-544179259_

Source

MiladHassani73

All 10 comments

Whoops. I missed that originally.

This happened quite some time ago and is the case in your repo list too. This is expected behaviour.

The reason for the grey (#cccccc) is that is the default colour when no colour is associated with a language in languages.yml.

As data and prose languages don't normally appear in the language bar in the sidebar, we don't enforce a colour for them. This is also an advantage as we're (still) limited by the colour proximity used by languages for accessibility reasons so by adding a colour to a data or prose language we're potentially taking away a colour from a programming or markup language which would show in the language bar.

lildude on 26 Aug 2020

We'll accept additions of colors to data and prose languages. If you want to fix any of these grey colors, please send a pull request!

pchaigno on 29 Aug 2020

We'll accept additions of colours to data and prose languages.

Since when?

Alhadis on 29 Aug 2020

Since now I guess. Given these colors are now displayed, we should allow their addition.

EDIT: Not sure if we should remove the test now, or wait for someone to remove it when they add a new color.

pchaigno on 29 Aug 2020

I say we wait for the colour-proximity requirement to be nuked first.

Or better yet, we don't wait and just go ahead and crush it. It'd serve GitHub's design-team right for taking (literally) years to decide if similar-looking colours from two-facelifts ago are still a problem. 😜

Alhadis on 29 Aug 2020

👍1

Yeah, I agree. It's becoming tiring to have our contributions to this "open source" project blocked by dependencies to GitHub's closed source code. We're giving a lot of our time to a project that GitHub is happy to call "community-driven" when that can reduce the workload while clearly being GitHub-driven in terms of releases & design decisions.

@lildude Please improve this status quo.

pchaigno on 29 Aug 2020

We'll accept additions of colours to data and prose languages.

Since when?

Ooops. I missed that. 😊

Or better yet, we don't wait and just go ahead and crush it. It'd serve GitHub's design-team right for taking (literally) years to decide if similar-looking colours from two-facelifts ago are still a problem. 😜

I'm thiiiiiiis close to doing it and dealing with the fallout if and when it happens 😬. If I were to 🔥 it, do we want to allow duplicate colours? I'm thinking not at first as we'll end up with a million identical reds or blues.

Yeah, I agree. It's becoming tiring to have our contributions to this "open source" project blocked by dependencies to GitHub's closed source code. We're giving a lot of our time to a project that GitHub is happy to call "community-driven" when that can reduce the workload while clearly being GitHub-driven in terms of releases & design decisions.

I hear you, and I'm in the same boat to a large extent. I'm now a team of one who (informally) maintains Linguist within GitHub and I have nothing to do with the design teams and am never mentioned when there are changes in the design around the languages. The slow release cycle of late is entirely my fault and I apologise. I won't get into the details other than to say I can't prioritise Linguist so it falls into my spare time as it does for you. I also like to wait for an accumulation of approved PRs before making a release to make the release feel more substantial.

lildude on 30 Aug 2020

If I were to 🔥 it, do we want to allow duplicate colours? I'm thinking not at first as we'll end up with a million identical reds or blues

Yes, of course. Otherwise, we'd end up with squabbles over which language is more deserving of #f00, and we'd have no argument to justify this outside of a popularity contest. If a repository has identical-looking shades of red and blue… congratulations, that's what colour-blind users are already seeing. 😉

The slow release cycle of late is entirely my fault and I apologise

It's actually given me ample time to make multiple corrections in grammars, get Solidity support under the door, and also Vim Help support. 😀 If I weren't so exhausted, I'd try to squeeze a PR for .mailmap highlighting, which is low-hanging fruit: