Change 326315 had a related patch set uploaded (by Ladsgroup):
Align colors with Wikimedia color palette.

https://gerrit.wikimedia.org/r/326315

@Ladsgroup I'm not convinced by this change, as it lowers the focus on the 'yes' tabular data cell. Is 'yes' the most important information to convey in the view or are the 'no's equally important? (I'm not familiar with the Interwiki view)

From the docs:

Enabling forwarding ('local' true) is normally done between all languages and projects in the same group, as it allows a link to any one of the languages to be used as a gateway to the others. The English-language Wikipedia, for instance, sets the 'local' bit true for all of the other-language Wikipedias and for projects like commons:, wikinews: or wikivoyage:. A user on a wiki outside Wikipedia where the wikipedia: interwiki prefix points to en.wikipedia.org could create a link like wikipedia:fr:Encyclopédie. That link goes initially to "fr:Encyclopédie" on the English-language Wikipedia. The en.wikipedia server immediately recognises fr: as a 'local' interwiki link, so replies with a redirect to la Wikipédia where fr.wikipedia.org/wiki/Encyclopédie displays the requested French-language Wikipédia page [[Encyclopédie]] et voilà.

So not sure if "Yes" and "No" means the same, If you want to make the extension page more noticeable, we can go with #00af89 (and if you think we need to colorize the "No" ones, we can with #d33)

This one looks more OOUIy:

No, the last approach doesn't make sense as the accent blue should only be used for interactive elements.

You're right, What about #00af89?

@Legoktm @siebrand @bd808 Any inputs on the importance of coloring “yes“ or the priority of the table data in general? (asking the three of you as you've been in the recent Git history for the extension)

Some info on what this actually is:

Forward: setting to allow chaining interwikis together like wikt:en:word and the like to directly get to the final page, instead of only allowing one thing at a time. Usually only actually used for directly related projects to prevent abuse. As an example, wikis within wikimedia would forward to each other, and to their languages, but probably not to wikia ones.

Thus it's not something that is turned on for most things in the table, and it's also important to visually see that it is turned on in order to be able to quickly read if it's turned on for the needed things. Highlighting the 'no' instead thus makes no sense because that's the normal value, and not a good or bad setting either.

Whatever colour it is, it just needs to be consistent with the rest of it (as I recall, red is used elsewhere for potentially dangerous settings, so it should match that scheme) and stand out enough to be seen. And not be annoying. The original green was kind of annoying.

Thanks @Isarra for the insights, this sheds a light on the color coding in use.
One more word on consistency, consistency is good, but if the pattern underneath is flawed or the wrong pattern is applied, consistency doesn't make for a good user interface. That was the reason for me to get clearer understanding of the information presented here.

Change 326315 merged by jenkins-bot:
Align colors with Wikimedia color palette.

https://gerrit.wikimedia.org/r/326315

In T153049#2924297, @Volker_E wrote:

One more word on consistency, consistency is good, but if the pattern underneath is flawed or the wrong pattern is applied, consistency doesn't make for a good user interface.

Doesn't matter. From a UX standpoint, it's still better to be consistent because then the users don't need to learn new patterns, and don't get overloaded by many different styles. And from a development standpoint, if something is consistently implemented as a specific thing, this makes it much easier to change down the road once a better approach is found.

That was the reason for me to get clearer understanding of the information presented here.

In the future, if you know nothing about a product, I highly recommend not weighing in either way unless you have actual reason to suspect the change might be for the worse, especially when your gripe isn't even about the change, but questioning the feature that's being changed.

Agh, I'm sorry. This is coming out way too harshly and I really shouldn't be attacking you over what is essentially nothing. My apologies.