abbrcode / abbreviations-in-code

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

Some advice about the licenses, contributions and more friendliness #41

Closed oood closed 1 year ago

oood commented 1 year ago

I really like this project and hope to make some contributions.

oood commented 1 year ago

Not sure if the red, green and yellow circles are a good explanation for color vision deficient readers, I think a clear text would work for more people.

About this, I have to ping @T1xx1, these colored dots make documents difficult to read for people who are colorblind, with studies estimating that 8% of men have trouble distinguishing green from red. In addition, it is not conducive to machine recognition, and reading under the terminal.

suggest replacing it with a more accessible way.

T1xx1 commented 1 year ago
  • Not sure if the MIT license is the most suitable license for this project, as there are usually better licenses for documentation, like CC or GFDL. I suggest you reconsider the license, especially since this project is intended to document facts. You can refer to the licenses used by Wiktionary.

I think we should not stall too much on the license. The projects need one just to be clear not because is really necessary infact it still lived quite sometime without any problems before @kisvegabor add it.

As @kisvegabor intended the list in the first place we don't have to add everything also on other sites but only used and well-known abbrs.

  • Also, could you migrate the content in the README.md to the repository's wiki, it would help with collaboration, while I understand the need for a check, it's not contradictory, and would allow people to better contribute to the project.

I think it will lose the status of project and become like a community to discuss things. However we could use this idea to discuss new or curr abbr to edit in the README without opening new issues every time, it's easier (still not like this solution, I just added the issue templates they will be a little wasted...).

  • Some common acronyms should also be added. like DB as an acronym for database is already included, can't see why the CPU isn't on that list. Maybe create another page for acronyms.

We stated that acronyms are not allowed and may be db can be seen as an acronym. I'm not sure for the separate page as the project it's only for abbrs. Ask @kisvegabor.

  • And you might want to change the default name of the branch as main is now recommended instead of master.

@kisvegabor stuff.

  • Not sure if the red, green and yellow circles are a good explanation for color vision deficient readers, I think a clear text would work for more people.

Plain text would make the abbr more complex and full of chars without giving a first-sight impact. I see your point for colour-blind people but I think we can find a better idea using emojis.

  • You might also consider supporting multiple languages, as most people reading this list may not be native speakers of English. It would be helpful if there was a translation contribution guide.

Yeah good idea, but there's a kinda problem with that. I'll make you an example as an Italian speaker. Let's take db for example as we already discussed over it.

d ata b ase • db. In Italian database, it's "base di dati". But there are no native abbreviations for it. So let's go for the translation but it won't work either way. If you consider the same method used in English it would be something like that: • b ase di d ati • bd (ignore "di" as it's an article) You can see where the problem is en -> db it -> bd We should define where is necessary different abbr for every lang. If we don't have native speakers or someone that know well a lang this will not come out well.

oood commented 1 year ago

I think we should not stall too much on the license. The projects need one just to be clear not because is really necessary infact it still lived quite sometime without any problems before @kisvegabor add it.

In fact I wish the project's license could be more open for better use. Since MIT is a software license, there will be some uncertainty here.

As @kisvegabor intended the list in the first place we don't have to add everything also on other sites but only used and well-known abbrs.

No, I meant importing lists from other sites into this project, since Wikipedia uses the CC license and this project uses the MIT license, which would create an incompatibility.

Because I hope to get information in one stop, let this project be a dictionary, so we don't need to flip through one part here, and then go to the Wikipedia to read another part.

I think it will lose the status of project and become like a community to discuss things. However we could use this idea to discuss new or curr abbr to edit in the README without opening new issues every time, it's easier (still not like this solution, I just added the issue templates they will be a little wasted...).

The language is created by everyone who uses it, and a new word is created when consensus exists, so it's best to make it easy for everyone to participate in the contribution of the project. The way of PR and new issue is very unfavorable to contribution.

We stated that acronyms are not allowed and may be db can be seen as an acronym. I'm not sure for the separate page as the project it's only for abbrs. Ask @kisvegabor.

This is part of an effort to make the project a complete dictionary 😉.

Plain text would make the abbr more complex and full of chars without giving a first-sight impact. I see your point for colour-blind people but I think we can find a better idea using emojis.

If it's really meant to be a dictionary, there could be multiple formats out there, maybe red green could be one of those formats.

Yeah good idea, but there's a kinda problem with that. I'll make you an example as an Italian speaker. Let's take db for example as we already discussed over it.

No, since almost all major programming languages are English, localization is impractical unless a new non-English programming language is developed.

What I mean is translating database not creating localized db.

like this:

  • database (Banca dati) • 🟢 db

About translation, you can refer to Wikipedia's practice:

  • DB データベース (Database)

Which is taken from Japanese Wikipedia.

This is even helpful for non-native english speakers reading the code, if they don't know what db mean in code, they can reverse through that dictionary to find the full word.

Grazie per la risposta.

T1xx1 commented 1 year ago

I like your ideas. Can you just wait for the PR I have to make to add new abbrs and could you please open single issues for each topic listing them down here so we can follow the process?

oood commented 1 year ago

I like your ideas. Can you just wait for the PR I have to make to add new abbrs and could you please open single issues for each topic listing them down here so we can follow the process?

Sure, why not. and I submitted two PRs, one to correct typos in the list and one to remove the script that no longer works.

oood commented 1 year ago

All future discussions should go to the corresponding issue, this issue is closed.