Solve possible issues for brands with the same name

[ericcornelissen]

Kind of issue

• Improvement
• Bug
• Other, namely: Future proofing

This issue concerns

• The NPM Package
• The Packagist Package
• The website
• Other, namely:

Description

In #2205 we came to the conclusion that name clashes might become a problem in the future. As we currently use the brand name as a unique identifier for the icon and brand data we need to find a suitable solution.

One option is to add an additional field to the data file for the "official brand name" (VOX in this case) and keep "title" as the unique name/file name (VOX TV or VOX DE in this case). This would not affect anyone depending no Simple Icons and requires only minor changes on our side (make the new field optionally allowed and somehow resolve how to display both the brand name and unique filename on the website).

Any feedback on that idea or any other ideas?

[runxel]

I think it's a good idea to add another field.
However the current "title" is already the 'nice' name...
A new field should directly coincide with the file name.

brand name & current title	file name & UID
FOO bar.js	foobar-dot-js

Just my 2 cents.
(I also thought about adding an alternative color field, because often enough there are two colors who could be suitable, but that might be a different thing.)

---

I will also link #2068 because if we going to change the json we should only do it once.

[runxel]

To chime in again:
This is my proposal for a JSON structure in the future.

{
    "title": "Foo Bar.js",  // stays as now
    "uid": "foobar-js-framework",  // new, same as the filename
    "hex": "FFCC60",
    "althex": "99E500",  // new, optional
    "source": "https://en.wikipedia.org/wiki/FooBarjs",  // where the logo was taken from
    "web": "https://foobar.io"  // actual webpage of brand, if there is one
},

[PeterShaggyNoble]

My thoughts below, @runxel.

• I'd make uid optional and, if omitted, generate it from the title as we currently do.
• Are we going to suggest any guidelines on what the uid is to be, if it is provided or leave that up to each individual contributor?
• I don't personally see a need for althex.
• I think one of source or web should be optional and, if omitted, should default to the other. It would probably make most sense to make web optional so's it's not a breaking change.

[runxel]

* I'd make `uid` optional and, if omitted, generate it from the `title` as we currently do.

Sure! That will help will the transition, too.

* Are we going to suggest any guidelines on what the `uid` is to be, if it is provided or leave that up to each individual contributor?

I think, we should do that. But until now there weren't so many collisions. So I'd rather argue we should build that over time – thats way easier.

* I don't personally see a need for `althex`.

Noted. I'm still in favor of it :D
See, many brands actually have at least two colors which is always a pain to decide.
I just thought this would make things easier. (if rarely used and just in cases the brand really uses two colors equitable)

* I think one of `source` or `web` should be optional and, if omitted, should default to the other. It would probably make most sense to make `web` optional so's it's not a breaking change.

Oh yeah! Sorry, I wasn't explicit enough: web is of course supposed to be optional, and only in those cases, where e.g. we get the source from Wikipedia.

[ericcornelissen]

Apologies for the delay 😅 @runxel I like where your suggestion is heading. Here are some comments:

• uid: I would prefer to use the uid as little as possible and really only use when there are name clashes, for the exact reason that it would require additional guidelines otherwise. If we use it only in these cases we can review everything on a case-by-case basis. E.g. for "Vox" we could have "vox-tv" and "vox-news".
  In practice I suppose we use either the uid that is in the data file, or compute it as we currently do from the brand name (title). For this reason I think we should call it slug as that is its current name in our Node package.
• althex: is a neat idea but perhaps better for a project like BrandColors. We could use it, under a different name if we decide to add support for multi-colour icons. But for now I think we should not add it. In any case I would make this an array of colours 🙃
• web: feels unnecessary to me. Part of "being popular enough" should be that I can find your website if I enter your name into Google (or w/e).

[runxel]

Good feedback, as always, @ericcornelissen! (response time isn't crucial :)

It's very reasonable and I think we can come to a satisfying conclusion here!
What's our milestone? Version 3?

[ericcornelissen]

It's very reasonable and I think we can come to a satisfying conclusion here!
What's our milestone? Version 3?

I think that should be manageable, at least the uid field so #2205 can be included. If we call it slug instead (perhaps a bit ugly, but you know... backwards-compatibility) we wouldn't even need a major release for it.

[runxel]

Skimming through the open issues I also want to link to your very own idea, @ericcornelissen: #755 (comment)

Looking back at this again, do we still want to only incorporate the slug?

[ericcornelissen]

@runxel I don't see why we would need a major release to include press kit (or similar) in the metadata. Adding a new field wouldn't break backwards compatability.

Again, if you agree to using slug to close this issue, we may not even need a major release to begin with.

[PeterShaggyNoble]

Cross-posting a comment from #3219 in relation to brands that share an icon but differ in colour, which we might be able to solve here:

One possible way could be through the changes being proposed and discussed in #2260, which might allow us to have multiple JSON entries pointing to a single SVG file.

[PeterShaggyNoble]

Ah, but, of course, that would then create the issue of the <title> tag not being correct. Feck!

[ericcornelissen]

After reconsidering this (the original issue) I think there are only two viable solutions:

• Allow for the slug property to be defined in the data file in the case that we foresee a name clash (e.g. VOX and Vox) or we encounter one for an existing icon. This leaves us with two problems we need to consider:
  1. Communicate the slug with users of the package, as it cannot be derived from the name anymore. (not that it is obvious now, but it is definitely easy in most cases). This can probably be done through the website.
  2. How (and if) we prevent, e.g., VOX from being returned on simpleIcons.get("vox"). The reason being that adding the other Vox may cause the result to change (potentially breaking something for a user). And also if it should show up for e.g. simpleIcons.get("Vox TV").
• Enforce a different title if we foresee or encounter a name clash. Though a bit ugly, it is the simplest and clearest solution and would require no extra work.

Given the extra work required in the former solution, I'm currently tending towards the latter.

[ericcornelissen]

Cross-posting a comment from #3219 in relation to brands that share an icon but differ in colour, which we might be able to solve here:

One possible way could be through the changes being proposed and discussed in #2260, which might allow us to have multiple JSON entries pointing to a single SVG file.

Ah, but, of course, that would then create the issue of the <title> tag not being correct. Feck!

Regarding #3219, as you pointed out, the primary problem is the <title> element which can only be correct for one SVG. In the NPM package we couldsomewhat sidestep this problem by changing the title dynamically, but given that that doesn't solve the problem anywhere else I'm against doing this.

[PeterShaggyNoble]

Allow for the slug property to be defined in the data file in the case that we foresee a name clash (e.g. VOX and Vox) or we encounter one for an existing icon.

My understanding of and suggestion for how it would work is that the slug would be optional and that we only include it when a clash with an existing icon occurs. For example, to get around #3008, the JSON would look like so:

{
    "title": "Hive",
    "hex": "FF7A00",
    "source": "https://www.hivehome.com/"
},
{
    "title": "Hive",
    "slug": "hive_blockchain",
    "hex": "E31337",
    "source": "https://hive.io/brand/"
}

I've used an underscore there to separate the brand name from the additional info for clarity and because it's a character we don't currently allow in filenames but that's just my suggestion, I wouldn't say it's _strictly necessary.

Communicate the slug with users of the package, as it cannot be derived from the name anymore.

Through the website, as you say, and also through the README, release notes and, of course, the contributing guidelines. Ultimately, it's a (somewhat) breaking change which is something people should always be looking out for in major semver releases. All we can do is communicate the information to them in as many places as possible.

How (and if) we prevent, e.g., VOX from being returned on simpleIcons.get("vox"). The reason being that adding the other Vox may cause the result to change (potentially breaking something for a user). And also if it should show up for e.g. simpleIcons.get("Vox TV").

I'd say that, to prevent this from being too much of a breaking change, that we leave that as-is so that simpleIcons.get("hive") & simpleIcons.get("Hive") would still work and, in that instance, return the first brand without the slug - to access the second one, the "hive_blockchain" slug would have to be passed as the argument. (Sidenote: in the particular example of "Vox", I do think we should invoke "first come, first served" on #2205 and add it as it currently is. If consensus says otherwise, though, I'd go with "vox_de" or "vox_germany" for the slug to avoid any future clashes with other TV stations that may exist with the same name - I believe there's one in Norway?)

Enforce a different title if we foresee or encounter a name clash. Though a bit ugly, it is the simplest and clearest solution and would require no extra work.

I very much believe the title should remain faithful to the brand's actual name. But if there is a way to circumvent the clash through official variations on its name (e.g., "Sky" vs. "Sky Group") then those options should be explored before resorting to the slug. As well as that, outside official variations, I could easily see changes to the title becoming incredibly subject - it's clear enough above why @selabie68 chose "Hive Blockchain" and I think makes sense to most people but, in the Vox example above, we can see how it would be less clear as to what we should go with.

Regarding #3219, as you pointed out, the primary problem is the <title> element which can only be correct for one SVG. In the NPM package we couldsomewhat sidestep this problem by changing the title dynamically, but given that that doesn't solve the problem anywhere else I'm against doing this.

I'd agree with that. Plus it would also cause problems for our linter. To play devil's advocate, though: if we ensured that the SVG was always assigned to the parent brand then it wouldn't be entirely inaccurate for (e.g.) the icon returned for "Sapper" having a <title> of "Svelte icon". I'd still be opposed to having identical SVGs that differ in <title> alone, though, so we'd need to come up with an alternative solution separately.

[PeterShaggyNoble]

Enforce a different title if we foresee or encounter a name clash. Though a bit ugly, it is the simplest and clearest solution and would require no extra work.

I very much believe the title should remain faithful to the brand's actual name. But if there is a way to circumvent the clash through official variations on its name (e.g., "Sky" vs. "Sky Group") then those options should be explored before resorting to the slug. As well as that, outside official variations, I could easily see changes to the title becoming incredibly subject - it's clear enough above why @selabie68 chose "Hive Blockchain" and I think makes sense to most people but, in the Vox example above, we can see how it would be less clear as to what we should go with.

Thinking about this again some more last night, one approach we could use to allow us to take this simpler approach would be to wrap the "modifier" in parentheses (e.g., "Hive Blockchain" would become "Hive (Blockchain)") and only add it to the JSON entry, allowing the SVG to use a different filename (e.g., "hive_blockchain") while retaining the correct name (e.g., "Hive") in its <title>. We'd still need a little bit of work on our existing linter to filter anything in parentheses, though.

[ericcornelissen]

Given that the consensus seems to be to use the "slug" property to resolve this issue, I suggest we hold of on trying to get this in before v3 as this solution is not breaking backwards compatibility. The main reason for this is to take the time to find and implement a suitable solution for getting icons through the NodeJS API.

Personally, it seems non-optimal that simpleIcons.get('hive_blockchain') (or similar) would be required to get that icon. From my point of view it should at least be possible to use simpleIcons.get('hive blockchain').

Also, we need to decide on rules for the slug value. I'm personally in favor of using an underscore for this, as @PeterShaggyNoble suggested. This would avoid any potential problem where the title would map to a custom slug value.

[PeterShaggyNoble]

From my point of view it should at least be possible to use simpleIcons.get('hive blockchain').

How would that translate to the filename, if we using underscores? Simply replacing spaces with underscores wouldn't work.

[ericcornelissen]

I wasn't thinking in term of implementation yet, just in terms of usability 😅 Just replacing spaces with underscores won't work, but don't forget that we are not looking for a filename in the NPM package, see the index.js template file for reference. Currently we check if either the title or slug of an icon matches the query value (case insensitive).

[mondeja]

After I've reviewed all the discussion I would like to leave my opinion on how to solve this problem:

I understand that this is an unique entities identification problem, as it would look from a database point of view. Essentially, using a slug field would be the solution, but I disagree on how it is being discussed about how to handle the possible fallback collision in the package. If you want to get a unique entity in a database, you would obtain it using their ID (slug in this case). So, if the user get an icon using their title, is problem of the user that could get another, because the unique way of obtaining an unique icon is using their slug property.

Also, we need to decide on rules for the slug value. I'm personally in favor of using an underscore for this, as @PeterShaggyNoble suggested. This would avoid any potential problem where the title would map to a custom slug value.

So I disagree with this kind of discussion.

Having said that, my proposal to solve this is:

• If a lowercased icon title collapses with another lowercased icon title: a slug properly must be added to both icons.
• If a slug collapses with another slug or lowercased icon title, another slug must be added because it's not an unique slug. I would build slugs using the same rules of filename build to maintain the consistency with all implicit slugs (filenames). The difference would be to use some string after the filename. For example: for VOX would be VOX as title and vox-de as slug (in optional slug property). The subjectivity here is necessary in terms of implementation, to avoid more complexity.

Following this, we need only to add two tests:

• Icons with slugs: their slugs must be unique against lowercased titles of all icons.
• Lowercased icons titles repeated must have a slug.

---

Complete solution (breaking change)

• In addition, to maintain the consistence with an unique identifier database-like behaviour, I would suggest to use slugs for icons object indexes in the package. This would favor users who perform a consistent search for icons.
• Another change in index.js template would be to remove icon.slug === normalizedName as check in the getter conditional, because if the user is searching for unique names, it is assumed that they have chosen the unique identifier (slug), so no normalization is required.
• In addition, if the match happens against a title, build an array because we are sure that the user is searching against titles, that could be multiple. If the array ends with 1 item, return the item else the array. This would be consistent with a database behaviour.

I'm not sure if I'm ignoring something, but I'm sure this issue needs resolution 👍

[ericcornelissen]

So, if the user get an icon using their title, is problem of the user that could get another, because the unique way of obtaining an unique icon is using their slug property.

I'm unsure what my old position this was, but at least now I agree. Given that the filenames are already the slug anyway, I think it is fair to expect package users to relay only on the slug as well and don't support querying by title. This would, of course, be a breaking change so we can't do this until v5 - as you also mentioned.

So, what I don't like is your last suggestion. I don't think it is a good idea to return different types based on the input value of the getter, I can see very few situations where this is actually beneficial, and many where this is a problem. I 100% prefer dropping support for getting with the title.

So I disagree with this kind of discussion.

I'm not sure what you mean 🤔 What I intended to say in the part you quoted is that requiring the usage of underscores (_), as opposed to no special character or using hyphens (-), in custom/manual slug names is a good idea because it will 100% guarantee that no collisions happen with automatically created slugs, including in the future. Which is in conflict with:

I would build slugs using the same rules of filename build to maintain the consistency with all implicit slugs (filenames).

I can see the argument here, and would honestly be fine with it. Just keep in mind that now if we want to add some new brand "Vox DE" this would require a different slug because it's already taken by a brand named "Vox". Not the end of the world, but definitely not what I would expect.

• If a lowercased icon title collapses with another lowercased icon title: a slug properly must be added to both icons.

I'm not sure if I agree, because this would require changing the slug of the existing icon, breaking backwards compatibility. One reading of this is that the second icon cannot be added until a major release. Another is that the second icon is immediately added and the existing icon slug is changed with the next major release. But at that point I don't really see a reason for changing it.

---

For clarity, to (re)state my current position:

• Drop support for getting an icon by their title in the NPM package. Only support getting by slug.
• If a new brand name is in conflict with an existing one, only the new one should get a custom slug.
• To support the previous point, the .jsonlintschema should be updated to allow for an optional "slug" field (similar to Keep track of brand guidelines/presskits/etc. explicitly #2846).
• Furthermore, the build script should be updated to take this slug value into account.
• Custom slugs can be chosen "arbitrarily", but should definitely be 1) relevant and 2) short. Moreover, I would suggest that custom slugs must include a character that cannot appear in automatically generated slugs to avoid collisions, e.g. _. (Though I can see the argument that consistency makes sense as well).

[runxel]

I agree with all that Eric said.

• Drop support for getting an icon by their title in the NPM package. Only support getting by slug.

This will help with the next points. Breaking change, but a good one for 5.0.

• If a new brand name is in conflict with an existing one, only the new one should get a custom slug.

Absolutely. I think we already agreed on a "First comes – first served" based principle. It's the easiest to handle.

• To support the previous point, the .jsonlintschema should be updated to allow for an optional "slug" field (similar to Keep track of brand guidelines/presskits/etc. explicitly #2846).

• Furthermore, the build script should be updated to take this slug value into account.

• Custom slugs can be chosen "arbitrarily", but should definitely be 1) relevant and 2) short. Moreover, I would suggest that custom slugs must include a character that cannot appear in automatically generated slugs to avoid collisions, e.g. _. (Though I can see the argument that consistency makes sense as well).

Yes. Vox the tv channel should be vox_tv then. I think clarity is much more important than some weird concept of consistency here. (Not meant to be rude; but in this case it's not about consistency since this is a property that only comes into play, when there is no consistency to maintain)

[mondeja]

• Custom slugs can be chosen "arbitrarily", but should definitely be 1) relevant and 2) short. Moreover, I would suggest that custom slugs must include a character that cannot appear in automatically generated slugs to avoid collisions, e.g. _. (Though I can see the argument that consistency makes sense as well).

Yes. Vox the tv channel should be vox_tv then. I think clarity is much more important than some weird concept of consistency here.

But, what is the point of using a _ here? There are brands that uses underscores in their titles, for example see #3769. So this not ensure nothing, at the end, we would need a test that compares all slugs (keep in mind that slug could be the slug autogenerated from title or the slug property) to make sure that all are unique. Currently we wouldn't have this kind of problem, but with more and more icons added, this should happen in the future. We can't rely in the simplicity of the "VOX" icon title uniqueness problem, in the future we could get colissions between slugs autogenerated with explicitly defined ones. And, what is the difference of clarity between vox_tv and vox-tv? If the usage of _ doesn't solves the problem of uniqueness, we don't should maintain consistency with other autogenerated slugs using - instead? I think it's more clear use the same style of slugs in all brands.

If a new brand name is in conflict with an existing one, only the new one should get a custom slug.

I'm fine with this, but again, should be consistent with other slugs too, not only brand names.

[ericcornelissen]

But, what is the point of using a _ here? There are brands that uses underscores in their titles, for example see #3769. So this not ensure nothing, at the end, we would need a test that compares all slugs (keep in mind that slug could be the slug autogenerated from title or the slug property) to make sure that all are unique. Currently we wouldn't have this kind of problem, but with more and more icons added, this should happen in the future. We can't rely in the simplicity of the "VOX" icon title uniqueness problem, in the future we could get colissions between slugs autogenerated with explicitly defined ones. And, what is the difference of clarity between vox_tv and vox-tv? If the usage of _ doesn't solves the problem of uniqueness, we don't should maintain consistency with other autogenerated slugs using - instead? I think it's more clear use the same style of slugs in all brands.

I wasn't aware of #3769 and would consider updating titleToFilename function (which is the logic that generates a slug from a title) to deal with the underscore. But I suppose this is a separate discussion. In short, may argument would be that no-one calls it "Pop underscore OS" but just "Pop OS", so the slug "pop-os" makes more sense, but I can also see why one would keep the underscore.

To be clear, the reason I suggested using _ is, again, to avoid any collisions with automatically generated slugs. This, then, of course requires that automatically generated slugs never contain a _. If they do, I agree that using _ is nonsensical and we should find another solution. I don't think this argument is limited to "VOX". As you point out, "in the future we could get colissions between slugs autogenerated with explicitly defined ones". I would just like to find a solution that avoids that.

I'm fine with this, but again, should be consistent with other slugs too, not only brand names.

I don't know what you mean by this 😕 Of course it should be consistent with other slugs too, but also definitely with the brand name. Moreover, the line you quote doesn't say anything about the value of manual slugs, just when it should be there...

[ericcornelissen]

With potentially more collision problems in light of #4797, I think we should come to a conclusion here. So, here's my take:

"Unfortunately" (from my perspective) #3769 has been merged, so at least for the duration of v4.x.x releases we cannot use underscores in custom slugs to guarentee their uniqueness w.r.t. automatically generated slugs. I still believe this would be the best way to avoid collisions between "custom" and "generated" slugs as:

• i think we should stay consistent and avoid using spaces.
• It is a common replacement for spaces among computer people (e.g. in variable names if neither camelCase nor PascalCase is used)
• The primary alternative, the hyphen, can already be used to in substitutions of "+", ".", and "&". Though it is unlikely this would case a collision, I think it is still better to avoid. (which, actually, raises the question of why hyphens are currently also kept when converting from titleToFilename - but the reader of this comment thinks that should be addressed, please open a separate issue 🙃)
• The alternative, allowing any reasonable slug will lead to more unexpected collisions in the future than not requiring a unique character in custom slugs.

Provided most people/@simple-icons/maintainers agree with the above, I think we are still safe using the underscore for this - assume a collision with Pop_OS is not going to happen, and rename Pop_OS with the v5 release. We can add the following extra field to the .jsonlintschema:

"slug": {
  "description": "The brand name as  a slug (also used as file name in icons/)",
  "type": "string",
  "pattern": "^[a-z0-9\\-]+_[a-z0-9\\-]+$",
  "required": false
}

That is, allow "slug" as a field on entries (because it is not "required"), and if it is present it must be a string that match the "pattern". The pattern is chosen so that it is a valid slug that must contain an underscore somewhere in the middle. Whether or not the slug makes sense with the "title" has to be checked manually.

Then, for the build scripts and tests, if the "slug" field IS NOT present (in JavaScript terms, icon.slug === undefined) the build script/test should behave as before. If the "slug" field IS present (in JavaScript terms, icon.slug !== undefined) the titleToFilename function should not be called and instead the "slug" value must be used.

This implies that:

• For the NPM package 1) individual brands can be required using the custom slug, 2) brands with custom slugs are enumerated as all other brands are, and 3) brands with custom slugs can be simpleIcons.get()ed by their custom slug - to keep this backwards compatible before v5 we can somehow manually ignore the title of brand with custom slugs.
• For CDNs, icon SVGs can be obtained using the custom slug.
• For the Packagist package, individual SVGs can be obtained with file_get_contents with the custom slug.

Considering only this issue, as has been said before, I think we should deprecate simpleIcons.getting brands by their title. I still stand by that, but it may give us some complications with regards to #4797 (specifically some of the bullets in this comment). That said, as per the previous paragraph, I do think we can add custom slugs safely and avoid this problem altogether (in an admittedly slightly confusing way) and deal with this collision problem separately.

Lastly, on the website, two icons with the same title is not a problem in theory. In practice one could argue that it may be confusing that there are two entries with the same name, personally I believe that anyone looking for the icon of a specific brand will know what the icon of that brand looks like and so won't be confused by the other brand with the same name.