Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alias for the icon name to accomodate technologies being renamed #327

Closed
Thomas-Boi opened this issue Oct 18, 2020 · 7 comments
Closed

Alias for the icon name to accomodate technologies being renamed #327

Thomas-Boi opened this issue Oct 18, 2020 · 7 comments
Assignees

Comments

@Thomas-Boi
Copy link
Member

Thomas-Boi commented Oct 18, 2020

Hello all,

I've been going over old issues. One of them involves creating alias for the name of technology because they got renamed. I think that this is a necessary feature to accommodate future changes or different naming scheme (dot-net and dotnet for example).

Here is a devicon.json object that we have:

    {
        "name": "oracle",
        "tags": [
            "database"
        ],
        "versions": {
            "svg": [
                "original"
            ],
            "font": [
                "original"
            ]
        },
        "color": "#EA1B22",
        "aliases": [
            {
                "base": "original",
                "alias": "plain"
            }
        ]
    }

Based on this current interface, I can think of these solutions:

  • Create a new attribute called aka. It will be a string[] that would look like this:

    {
      "name": "dot-net",
      "aka": [
        "dotnet"
      ]
    }
    

    or

    {
      "name": "node-webkit",
      "aka": [
        "nwjs"
      ]
    }
    
    • If there are no other names, aka would be an empty array/list.
    • Some cases (such as angular vs angularjs) would not need the aliases if it's at the end of the name. I can add something in the CONTRIBUTING.md for that.
  • Create a new attribute called aliases that would keep track of aliases of the technology name. The current aliases attribute (which tracks the versions) will be moved inside the versions attribute. It would also be renamed to font-aliases for clear distinction. It can look like this:

    {
        "name": "oracle",
        "aliases": [],
        "tags": [
            "database"
        ],
        "versions": {
            "svg": [
                "original"
            ],
            "font": [
                "original"
            ],
            "font-aliases": [
            {
                "base": "original",
                "alias": "plain"
            }
        ]
        },
        "color": "#EA1B22"
    }

In order to achieve any of the above changes, we will need to:

  • Create a convert script (easy for either of the above solutions)
  • Add an extra step in our css generation task to create the name aliases.

Priority: Low (in my opinion). We can do this after the gh-pages migration and the npm publish workflow.

Let me know what you guys think. Feedback are welcome :)

@amacado
Copy link
Member

amacado commented Oct 21, 2020

Thanks for the good ideas on this topic.
In my opinion having aka and aliases according to your first idea seems pretty confusing. Could you help me with understanding

Some cases (such as angular vs angularjs) would not need the aliases if it's at the end of the name. I can add something in the CONTRIBUTING.md for that.

I like the second approach more since i think it's more intuitive, although I'm not very happy with having a growing model in our devicon.json . It gets more and more complex and harder to maintain, specially for new contributors. I agree with you that this topic has low priority and we may can come up with a more advanced solution. For now I have no better idea.

@Thomas-Boi
Copy link
Member Author

In my opinion having aka and aliases according to your first idea seems pretty confusing. Could you help me with understanding

Some cases (such as angular vs angularjs) would not need the aliases if it's at the end of the name. I can add something in the CONTRIBUTING.md for that.

So some libraries have multiple names and I don't think it's necessary to make an alias for it. One, most people will know to try searching for the other alias. Two, when they use our site to search for the icon, they will see an icon regardless of what name they use.

For example, angular is also known as angularJS. If someone were to search for the icon angularJS in the repo, the angular icon will show up as well => don't need to make an angularJS for angular. Also, adding an extra alias for this case is unnecessary. If for some reason searching angularJS won't give them the result they want, most people will know to try angular.

So any cases that has a suffix at the (i.e javascript libraries) won't need an alias.

I think we should revisit this in the future. I would like to minimize changes to the devicon.json as much as possible and hopefully we can find a better way.

@Snailedlt
Copy link
Collaborator

Oh, I missed this issue entirely.

I made a PR on almost the exact same thing yesterday though, only difference is that it's called altnames instead of aka/aliases in my PR.

#1167

Only good thing about adding suffixes like "js" that I found, is that most, if not all js libraries now show up if you just search for "js". So it can be used to sort of categorize icons.

I think in the future it would be better to have more advanced search options, so you could choose if you want to search just for the name/altname/tag etc, or all of them.

@Snailedlt
Copy link
Collaborator

So, has anyone looked at the PR yet?
Any feedback?

@Thomas-Boi
Copy link
Member Author

I'm fine with it but the choice rests on the current maintainers of the team.

I'm now more of a background passive maintainer so even though I'd love to accept the PR, I can't do much 😄

@Snailedlt
Copy link
Collaborator

@amacado @Panquesito7 @maltejur
Iirc you guys are the maintainers now. Any comments on the PR?

@Snailedlt
Copy link
Collaborator

@amacado @Panquesito7
This should have the in-develop label

@amacado amacado closed this as completed Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants