Closed oood closed 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.
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.
- We can even import the list of abbreviations from Wikipedia if the license is compatible: https://en.wikipedia.org/wiki/List_of_computing_and_IT_abbreviations
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 fordatabase
is already included, can't see why theCPU
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 ofmaster
.
@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.
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.
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?
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.
Request: switch license #45
Request: make this project a dictionary #46
Request: Make the project more inclusive and accessible #47
Request: translate this project #48
All future discussions should go to the corresponding issue, this issue is closed.
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.
We can even import the list of abbreviations from Wikipedia if the license is compatible: https://en.wikipedia.org/wiki/List_of_computing_and_IT_abbreviations
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.Some common acronyms should also be added. like
DB
as an acronym fordatabase
is already included, can't see why theCPU
isn't on that list. Maybe create another page for acronyms.And you might want to change the default name of the branch as
main
is now recommended instead ofmaster
.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.
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.
I really like this project and hope to make some contributions.