abbrcode / abbreviations-in-code

The list of common abbreviations in program codes.
https://abbreviations-in-code.vercel.app
MIT License
426 stars 52 forks source link

Request: Make the project more inclusive and accessible #47

Open oood opened 1 year ago

oood commented 1 year ago

Requests:

Rationale:

Suggestions:

This issue is a fork of a previous thread (#41), you may be interested in reading the previous discussion history.

T1xx1 commented 1 year ago
  • Use text to explain how recommended an abbreviation is, or other emojis πŸ‘/πŸ‘Œ/πŸ‘Ž.

Great πŸ‘

oood commented 1 year ago

Great πŸ‘

Not sure if it can be considered as the final solution, since a single color hand lacks inclusivity. that's why I prefer to use a simple text as an explanation of the degree of recommendation.

kisvegabor commented 1 year ago

Thank you for bringing up these points. I think :green_circle:, :yellow_circle: and :red_circle: are very intuitive for ~95% of people. So I think we should keep these in some form.

What about this?

Although italic and normal are hard to distinguish, but yellow is usually not subject of color blindness.

What do you think?

T1xx1 commented 1 year ago

Thank you for bringing up these points. I think :green_circle:, :yellow_circle: and :red_circle: are very intuitive for ~95% of people. So I think we should keep these in some form.

What about this?

  • :green_circle: abbr1
  • :yellow_circle: abbr1
  • :red_circle: ~abbr1~

Although italic and normal are hard to distinguish, but yellow is usually not subject of color blindness.

What do you think?

Also this method seems good

oood commented 1 year ago

Thank you for bringing up these points. I think 🟒, 🟑 and πŸ”΄ are very intuitive for ~95% of people. So I think we should keep these in some form.

In fact, Github's colors are carefully designed, it uses green and purple to mark open and closed issues.

Green 🟒 and redπŸ”΄ can be hard to tell apart for some, but purple 🟣 is a lot better.

RedπŸ”΄ and blueπŸ”΅ are also fine for most colorblind readers.

And, if you're going to develop it into a dictionary, then I think there can be multiple formats out there.

We don't have to tangle here.

There can be a raw data there, and then use GitHub Actions to automatically generate dictionaries in various formats. like json, and red and green. we only need to maintain a basic raw data.

oood commented 1 year ago

So, I think we don't really need to care too much about the color of the circle, we just need to create a raw database, then maintain the database, and use scripts to automatically generate readme files.

kisvegabor commented 1 year ago

I've just suggested the same thing here :slightly_smiling_face:

philipeachille commented 1 year ago

Green 🟒 and redπŸ”΄ can be hard to tell apart for some, but purple 🟣 is a lot better.

I am happy to switch red to purple, if it increases readability for the last 5% of humans. It is also a nice purple and maybe even less of a "hard no".

oood commented 1 year ago

I am happy to switch red to purple, if it increases readability for the last 5% of humans. It is also a nice purple and maybe even less of a "hard no".

Yes, glad you can think so.

But now making the database format is prioritized over this issue, because once we update the abbreviations in the database, then, we can create lists in various formats, suitable for all people and all machines.

Please discuss the format of the database here: #48