Adding Aliases

[PeterShaggyNoble]

Kind of issue

• Improvement
• Bug
• Other, namely:

Implementation Progress

The process of the implementation of the aliases can be followed here:

• old (Implement functionality based on the old alias #5859)
• aka (tbd)
• loc (tbd)
• dup (tbd)

---

Description

In somewhat of a follow-up of #3695, although stopping short of adding alternative spellings & keywords, and in light of #3573, I'd like to propose that we somehow add aliases to icons for (sub-)brands that share the same icon and colour (see #3270 for brands that share an icon but not a colour). Only official names should be considered covering the following points:

1. A brand that shares the same icon and colour as an existing icon (e.g., React & React Native)
2. Alternative, localised brand names. Some companies in Ireland have both an English and an Irish name, for example. (Note: this would not include translating non-English names into English or vice-versa unless it's something the company themselves do)
3. Expanding acronyms & abbreviations (e.g., National Basketball Association for NBA) as it's not inconceivable that someone might search for a brand using its full name
4. Adding acronyms or abbreviations but only in cases where the company abbreviates the brand name itself and, somewhat more subjectively, is in common usage (e.g., NJPW for New Japan Pro-Wrestling)
5. Old brand names, in the cases of rebrandings or mergers. But only if the old name isn't entirely contained within the new one (e.g., not Microsoft Bing).

I would not suggest that this data be added to simple-icons.json as I only envisage it being useful for the search feature of the website so it would only lead to unnecessarily bloated files in the package and possible confusion regarding the ability to use icons by calling them by their aliases - to do so would require all aliases, as well as titles, to be unique. I'm open to suggestion on exact implementation, though.

Thoughts from @simple-icons/maintainers and community members on whether this would be a useful addition to the project? Any suggestions for additions to the list above?

[adamrusted]

I think the icons should always be found first by the primary version used by the brand themselves, regardless of whether that's the abbreviation or the full title. Having an array of "alisases" as a second level of searching could work quite well, if proper guidelines are applied, as @PeterShaggyNoble lays out above.

[fbernhart]

I think it's a great idea! 👍🏼

I would be in favour of adding the aliases to the simple-icons.json, if that's technically possible and doesn't have any major disadvantages. Would something like this work?

        {
            "title": ["NBA", "National Basketball Association", "some other name"],
            "hex": "253B73",
            "source": "https://nba.com/"
        },

The benefit of putting everything into the simple-icons.json file is in my opinion, that everything is "at one place". Which will as well help keeping it easy for outsiders to contribute to Simple Icons.

Another approach would maybe be adding an extra, optional, alias attribute?

        {
            "title": "NBA",
            "alias": ["National Basketball Association", "some other name"]
            "hex": "253B73",
            "source": "https://nba.com/"
        },

[PeterShaggyNoble]

If we are adding it to simple-icons.json, I don't think we should touch title, instead adding a new optional alias(es) key per your second suggestion.

I updated the list in the original post with another use case: old brand names, which covers rebrandings and mergers.

[adamrusted]

If we're able to include the 'alias' array in the get method of the various forms of the module, would that mitigate some of the breaking change issues we're currently seeing where it's a rename of an existing product? You could just add the "former name" to the alias list, and have the module still find it using that.

[ericcornelissen]

I like this suggestion @PeterShaggyNoble, it provides a solution for quite some old issues and existing issues (e.g. brand renames). Nice 👍

I don't really see a reason not to include it in _data/simple-icon.json, following #2846 an aliases field can be optional (or, following this suggestion, the title field can have two possible types, string and string[] (*) - but we should probably consider that a breaking change). On the other hand, I'm not against putting it somewhere else either provided we have a good reason to do so.

One suggestion I would like to add to the discussion is the following: in addition to keeping track of aliases, we may consider recording the type of alias as well. This would serve as "documentation", and may give is some automated help w.r.t. keeping the scope of aliases narrow. Following @fbernhart's suggestion, this could look something like:

{
    "title": "NBA",
    "alias": [
        { type: "full", value: "National Basketball Association" },
        { type: "old", value: "NBA old }
    ],
    "hex": "253B73",
    "source": "https://nba.com/"
},

Where the type fields value must have one of a list of values specified in the .jsonlintschema.

Alternatively this could be a two-value array (*), e.g.:

{
    "title": "NBA",
    "alias": [
        ["full", "National Basketball Association"],
        ["old", "NBA old"]
    ],
    "hex": "253B73",
    "source": "https://nba.com/"
},

---

^{(*) I'm not a fan of this, as it is pretty easy to get wrong.}

[adamrusted]

@ericcornelissen I prefer your first solution there. We could look at having full, old, abbr(eviation), and sub(brand) as the 'types', which should differ enough from one another - and gives you more data to play with on from a website perspective than just a plain array (highlighting all old tags as 'removed in next major release', for example).

[runxel]

I am not against adding this feature, even tho I will question the need, if it is only for the website.
But maybe it is helpful, if we slowly cross the 2000s mark. 🤔

If you could use it for selecting the icon it would serve a bigger need – but in this case you need again to ensure the uniqueness – and that is exactly the one thing we can not as it defies the very purpose.

[PeterShaggyNoble]

While including the type of alias, as suggested by @ericcornelissen, could be a useful addition for us, I don't know that the benefits would justify the extra work required of contributors, especially having to check the possible values for the type each time. Therefore my suggestion would be a simple (sorted?) array along the lines of:

{
    "title": "NBA",
    "alias": ["National Basketball Association", "NBA alternative", "NBA old"],
    "hex": "253B73",
    "source": "https://nba.com/"
},

or:

{
    "title": "NBA",
    "alias": [
        "National Basketball Association",
        "NBA alternative",
        "NBA old"
    ],
    "hex": "253B73",
    "source": "https://nba.com/"
},

[ericcornelissen]

Though it is definitely up for discussion, I would say that the extra work required by contributors to look up the possible values is quite small compared to what I expect to be relatively common once aliases are a thing:

Maintainer: Excuse me [PERSON], what is your reason for including [ALIAS] as an alias for this brand?
Contributor: [REASON THAT DOESN'T SATISFY OUR SCOPE OF ALIAS]
Maintainer: Ow in that case, as per our Contributing Guidelines, could you remove it?
Contributor: commit that removes the alias

In other words, from my perspective, forcing contributors to include the type requires them to comply with the scope of aliases we have defined (apart from using the wrong value for a certain type), avoiding the need to ask for changes. Asking this, I think, is much more time consuming than looking of the available types (provided we document them properly).

Additionally, remember that aliases are optional, if a contributor can't figure out how to add them they can just leave them out and it can be added later - either in the same PR or in a different PR as adding aliases wouldn't be a breaking change.

Lastly, if we open the aliases up to the public, than I think having consistency as to which alias is what is very important. I wouldn't ever use the aliases if for one brand the abbreviation is the first element in the list and for another it is the last item in the list. Provided that we do have the data on aliases available anyway I would say it is quite likely we want to open it up at some point, and I think we would do well to avoid having to do any refactoring for that.

---

I do have further discussions topics regarding including types as well: first is whether a certain type may or may not have multiple values. If not, I think we should use the following approach instead:

{
    "title": "NBA",
    "alias": {
        "full": "National Basketball Association",
        "old": "NBA old"
    ],
    "hex": "253B73",
    "source": "https://nba.com/"
},

Second is whether we should force the title to never be an abbreviation. I get the argument that we should go with what the brand normally does (e.g. how many people want to use the string "Node Package Manager" over "npm"), but I do feel like consistency is more important as well. Additionally, forcing abbreviations into aliases prevents the need for both a full and abbr type, which should never both appear in the aliases list. On the other hand, this would be breaking change for any brand whose current title is an abbreviation.

[PeterShaggyNoble]

Given your hypothetical scenario, I can see your point for adding types now. So I'll concede that point 🙂

first is whether a certain type may or may not have multiple values

I do envisage the possibility of multiple aliases of each type so I think we'd need to allow for either an array of (sorted?) strings or a single string for the value. Some scenarios would include:

1. More than 2 (sub-)brands sharing the same icon and colour,
2. A company having different names in multiple different countries/regions, and,
3. A brand that has been through multiple rebrandings/mergers, changing its name more than once.

Second is whether we should force the title to never be an abbreviation.

I would say no. Other than it being a pretty major breaking change given the amount of icons involved, using the full name for the title in all cases wouldn't always be accurate, most especially in the title tag of the SVG. Although the full name may be the legal name of the company, there are many, many cases where the abbreviation is the brand or common name - World Wrestling Entertainment and Bayerische Motoren Werke are 2 examples that immediately spring to mind of companies that almost exclusively refer to themselves by their abbreviations and only use the full name for corporate purposes, if at all. If there's ambiguity, though - as there was with New Japan Pro-Wrestling who also refer to themselves as NJPW extensively - we should consider using the full name for the title there.

[adamrusted]

Easy way to fix the abbreviation / full name issue as far as I can tell would just be to combine both of them into an alternate property. If they're both likely to show up in results when users search for the icon, we don't need to be super specific in the 'alias' section, and can just refer to it as an alternate name. Stuff like #4308 springs to mind, whereby the project has a pretty obscure 'official' name, but goes by a more commonly known name among it's users. I'd suggest putting the more commonly used name as our title attribute, and the more obscure one under alt(ernate).

[PeterShaggyNoble]

Combining them into one could be a good compromise, @adamrusted as, realistically, we're never going to have both a full name and an abbreviation. So for the 5 types, we'd have:

1. also (I was going to suggest alternate here originally so this may not be the best term)
2. local(ly)
3. alt(ernative(ly))
4. alt(ernative(ly))
5. previous(ly) or old

So, we would then have something like:

{
    "title": "New Japan Pro-Wrestling",
    "aliases": {
	"alternatively": "NJPW",
	"also": "NJPW World",
	"locally": ["新日本プロレスリング", "Shin Nihon Puroresuringu"],
	"previously": ["Old Name 1", "Old Name 2"]
    },
    "hex": "FF160B",
    "source": "https://en.wikipedia.org/wiki/File:New_Japan_Pro_Wrestling_Logo_2.svg"
}

[adamrusted]

With regard to local(ly) you do then get into the realms of do we record the country/locality next to each entry, resulting in a real JSON hellscape!

If you wanted to shorten the tags as much as possible, might I suggest:

1. dup duplicate icon (React & React Native, for example)
2. aka also known as (full / abbreviation version of name)
3. int international variations on the company's name (we should strive to list it in it's native language first)
4. old previous names for the same brand due to buy-out / rebrand

This would reduce it to 4 short tags, which should cover all eventualities listed above.
You could even mix aka and int into one array of alternative names, but I think the separation helps should we ever want to localize the site/directory.

[service-paradis]

There are a lot of good ideas here!

I love the array of objects having the type as key, but I'm not sure it would be the easiest to use for external projects.

If I have an external package and want to iterate over every names to search for an icon for example. It might be easier to loop through a single array of objects and checking the name property.

It would be more difficult to iterate through an object, then checking if the value type is an array or a string to potentially loop again.

[mondeja]

It would be more difficult to iterate through an object, then checking if the value type is an array or a string to potentially loop again.

But access to object keys directly and then only loop through that array would be faster in terms of computation.

[PeterShaggyNoble]

It would be more difficult to iterate through an object, then checking if the value type is an array or a string to potentially loop again.

In JavaScript, for example, you could do one of the following to get all the values as a single array:

const aliases=Object.values(icon.aliases).flat();
const aliases=Object.values(icon.aliases).reduce((arr,val)=>arr.concat(val),[]);

[service-paradis]

But access to object keys directly and then only loop through that array would be faster in terms of computation.

In JavaScript, for example, you could do one of the following to get all the values as a single array:

Totally agree, and I'm not against it. Just wanted to mention that it is not necessarily the easiest way. :)

[PeterShaggyNoble]

Just realised I may have misinterpreted your concern, @service-paradis and I do see a potential issue in mixing strings and arrays if someone wants to iterate through each alias type rather than all aliases together as, using my example above, simply doing icon.aliases.alternatively[0] and icon.aliases.locally[0] would produce different and undesirable results so I think we should require that all values be arrays.

On sorting: I think we should require that the keys be sorted (so aka, dup, int, old) but requiring that the strings in the array be sorted might be a step too far, especially when dealing with multiple alphabets. Unless our linter can somehow automatically sort the array for us?

[adamrusted]

I think we should require that all values be arrays.

I agree. For consistency and ease of searching, keeping any included key as an array (even with a single entry) would make code significantly easier to manage.

On sorting: I think we should require that the keys be sorted (so aka, dup, int, old) but requiring that the strings in the array be sorted might be a step too far especially when dealing with multiple alphabets.

Again, yes. I don't think we can reliably combine icons of various alphabets (especially the likes of Chinese and Japanese) into one sorted array. This also goes alongside the issue raised in #4824, in that do we need to specify that the name under which the icon is listed on our system is in the form of a Latin alphabet spelling, so as to not cause issues with our linter trying to parse other languages.

[PeterShaggyNoble]

do we need to specify that the name under which the icon is listed on our system is in the form of a Latin alphabet spelling

As much as it pains me as a linguist to say this, I think, for consistency and ease of management, that we do. Letters in titles should be limited to [A-Za-z] and their accented variants only (I think this would be covered by point 8 below, too). Relatedly: I'll try to put together a PR later today to ensure that our normalisation scripts account for all the characters in that table.

Back to the aliases, are all @simple-icons/maintainers then agreed on the following?

1. We're adding an optional aliases entry to simple-icons.json which will be used on the new website to increase discoverability of icons under different names.
2. Only official names used by the brand itself will be considered for addition to this entry - other colloquial or common names will be rejected as will alternative spellings and keywords.
3. The entry will be a JSON object consisting of up to 4 key/value pairs.
4. The keys should be sorted and be one of aka, dup, int or old.
5. The values should be not necessarily sorted arrays of one or more unique strings.
6. aka will primarily be used for adding full names (e.g., NBA) or abbreviations (e.g., NJPW) but also, in rare cases, where a brand refers to itself by some other name.
7. dup will be used to list other (sub-)brands that share the same icon and colour (e.g., React Native for React) but only if that brand's name is not contained entirely within the title of the existing icon (e.g., React for React Native).
8. int will be for localised names where, for linguistic or trademark reasons, a brand is known by a different name in a specific country or region, including the name(s) an international company goes by in its home country (e.g., All Nippon Airways).
9. old will be used for previous names a brand went by prior to a rebranding or merger (e.g, Vercel was Zeit) but only if that name is not contained entirely within the new name (e.g., Microsoft Bing).

On point 8: for languages that don't use the Latin alphabet, care will need to be given that the spelling is actually correct and that we don't include that country's equivalent of "Ltd.", "plc.", "GmbH", etc. such as "株式会社" (kabushiki gaisha or "share company") in Japanese

[ericcornelissen]

Based on some thinking and some internal discussion I want to bring up a few points. But first, let me just put a new example here to see where we are currently at:

{
    "title": "React",
    "aliases": {
	"alt": ["doesn't actually have an alt, but this is for the sake of example"],
	"dup": ["React native"],
	"loc": ["don' know, but this is for the sake of example"],
	"old": ["Angular", "of course react wasn't previously called Angular..."]
    },
    "hex": "61DAFB",
    "source": "https://github.com/facebook/create-react-app/blob/282c03f9525fdf8061ffa1ec50dce89296d916bd/test/fixtures/relative-paths/src/logo.svg",
    "guidelines": "https://www.example.com/"
}

First, regarding:

As much as it pains me as a linguist to say this, I think, for consistency and ease of management, that we do. Letters in titles should be limited to [A-Za-z] and their accented variants only (I think this would be covered by point 8 below, too).

Just to clarify, @PeterShaggyNoble, you mean aliases have the same restriction as "title"s currently do?

Then, I have three more questions I think we need to tackle before we can implement this:

• Should the "loc" field, instead of just being strings, be an array of objects like { "title": "local name in German", "lang": "DE" }? I can easily imagine a case where someone would like to display a localized name, but only if it is in their local language, and if it is just strings this is very hard to do programmatically.
• Should the "dup" field, instead of just being strings, be an array of objects like { "title": "React Native", "hex": "62DBFC" }? E.g. to be able to cover Sapper icon #3219. I'd imagine the "hex" field would be optional in the data file which would imply it's the same as the main brand. If need be, the hex value can be inserted manually for dups that don't specify a hex in the NPM package.
• Moreover, should the "dup" field basically just allow what is currently an entry in the data file? That is, should it be possible to specify for each duplicate a "title" (required), a "hex" (optional, see previous bullet), a "source" (optional or required?), and some "guidelines" (optional) (, and given Icon licenses #1168 a "license" (optional)).

If we have settled on all of the above, and all agree that the format is good, I think we can go ahead and get this implemented so that new contributions can make use of it and we have the data available.

After that we need to concern ourselves with the following (and probably more) questions:

• Similar to Expose guidelines in NPM package #4900 (and Icon licenses #1168), should the "aliases" field be exposed in the NPM package?
• Should icons be made available under their alternative names 1) in the NPM package, 2) on the CDNs, 3) in the Packagist package (4) in the font) (*) and, if we do, crucially, how do we prevent collisions (see also Solve possible issues for (sub-)brands with the same icon #3270).
• Should icons be made available under their localized names 1) in the NPM package, 2) on the CDNs, 3) in the Packagist package (4) in the font) (*) and, if we do, crucially, 1) how do we prevent collisions (see also Solve possible issues for (sub-)brands with the same icon #3270) and 2) is that possible/feasible/smart with e.g. Japanese characters in filenames?
• Should duplicates be made available separately 1) in the NPM package, 2) on the CDNs, 3) in the Packagist package (4) in the font) (*) and, if we do, crucially, how do we prevent collisions (see also Solve possible issues for (sub-)brands with the same icon #3270).

Regarding collisions, it has been discussed that in the NPM package this can be at least partially resolved by adding a (optional) second parameter to the simpleIcons.get() function which can be used to specify that you want a particular aka or dup. However, I don't think this solution is satisfying as it isn't even tree-shakable in Node and provides no solution for CDNs (nor Packagist, but supporting that will be extra difficult as per my explanation at the end of this comment).

---

(*) Making the icons available on each of these means the following (creating such files programatically should be fairly straightforward):

• CDNs: there should be a icons/[name].svg file in the NPM package.
• Packagist: there should be a icons/[name].svg file in the commit that a git tag/GitHub release points to.
• NPM: there should be a icons/[name].js file in the NPM package, and it should be possible to obtain the icon using simpleIcons.get('[name]');.
• Font: Classes .si-[name] have to generated and properly set.

[PeterShaggyNoble]

you mean aliases have the same restriction as "title"s currently do

No, that was referring specifically to not allowing characters from different alphabets in the main title entry. We'll need to allow those for aliases, most specifically the loc ones.

Should the "loc" field, instead of just being strings, be an array of objects like {"title": "local name in German", "lang": "DE"}?

Yes, great idea including the language in the loc objects. That makes them much easier to reference for non-native speakers and also means that any change to the alias (e.g., to correct a typo or because a company changes its name in a specific country) wouldn't constitute a breaking change, assuming we expose aliases for use in the packages. It would, however, mean we couldn't, for example, have "Shin Nihon Puroresuringu" as a local alias for "New Japan Pro-Wrestling" as the Japanese alias would be "新日本プロレスリング" but I don't see that as being a major issue. See also comment immediately below this one.

Should the "dup" field, instead of just being strings, be an array of objects like {"title": "React Native", "hex": "62DBFC"}?

Yes, as discussed internally, I think that's the way we'll need to go with those ones too with, as you said, the hex entry being optional and falling back to the parent icon's colour if it's not provided.

Moreover, should the "dup" field basically just allow what is currently an entry in the data file?

Was thinking about this last night and I agree. Although, we wouldn't need the source entry as, if it's a dupe, the source will be the same as the parent. So we'd just need hex, guidelines & license, all of which should be optional. Of course, the logical follow up question is should we also allow aliases for dup entries to allow for local/alternative names. For me, things just get too messy if we do, so I'd say we shouldn't allow them.

So, to summarise, we now have:

{
    "title": "New Japan Pro-Wrestling",
    "slug": "proposed-and-optional",
    "aliases": {
        "dup": [{
            "title": "NJPW World",
            "hex": "B79C65",
            "guidelines": "optional",
            "license": "proposed & optional"
        }],
        "loc": [{
            "title": "新日本プロレスリング",
            "locale": "ja-JP"
        }],
        "aka": ["NJPW"],
        "old": ["Old Name 1", "Old Name 2"]
    },
    "hex": "FF160B",
    "source": "https://en.wikipedia.org/wiki/File:New_Japan_Pro_Wrestling_Logo_2.svg",
    "guidelines": "optional",
    "license": "proposed & optional"
}

With regards to the various packages: As the initial purpose of this issue was merely to add some alternative names so that icons could be discoverable using them on the website, I think we should continue here with that in mind and then, in a separate issue for each package, discuss which, if any, aliases we're going to expose to that package and how we're going to implement them. I already have a number of ideas & suggestions for the NPM package, some of which (I think) will get us around the potential issue of name collisions.

[service-paradis]

Should the "loc" field, instead of just being strings, be an array of objects like { "title": "local name in German", "lang": "DE" }? I can easily imagine a case where someone would like to display a localized name, but only if it is in their local language, and if it is just strings this is very hard to do programmatically.

Just want to chime in about this. It would be more flexible to accept IETF language tag (ex. en-US, fr-CA, ...). I'm in Québec, Canada. It is the only province with french as primary language. There are a a lot of particularity here that differs from the rest of the Canada. Date format, brand name, etc. We're often different from other french places too (we're very overprotective of our language).

A more specific example (related to this project) is Staples. It is called Bureau en gros here in Québec, but is known as Staples everywhere in the world (even in France).

{ "title": "Bureau en gros", "lang": "FR" } would be invalid
{ "title": "Bureau en gros", "lang": "CA" } would be invalid
{ "title": "Bureau en gros", "lang": "fr-CA" } would be valid

Another note using the same example. The corporation name of Staples in Canada is Staples Canada. Using IETF language tag could also be useful here. ex. { "title": "Staples Canada", "lang": "en-CA", "title": "Bureau en gros", "lang": "fr-CA" }

Edit: Staples was never added in this package 😅, could be a good first example to use when adding aliases support

[PeterShaggyNoble]

Good shout, @service-paradis; I agree. This would also cover cases where a brand has to go by a different name for legal/trademark reasons in a country with the same language such as "Burger King" being "Hungry Jack's" in Australia.

[ericcornelissen]

No, that was referring specifically to not allowing characters from different alphabets in the main title entry. We'll need to allow those for aliases, most specifically the loc ones.

Ah okay, thanks for the clarification. So the title stays as it is (Latin symbols, their accented variants, and (some) punctuation only) and allow localisations to be in "any" alphabet - probably limited to either UTF-X or Unicode.

Was thinking about this last night and I agree. Although, we wouldn't need the source entry as, if it's a dupe, the source will be the same as the parent. So we'd just need hex, guidelines & license, all of which should be optional. Of course, the logical follow up question is should we also allow aliases for dup entries to allow for local/alternative names. For me, things just get too messy if we do, so I'd say we shouldn't allow them.

You're right, I somehow mixed up "guidelines" and "source" 😅

Of course, the logical follow up question is should we also allow aliases for dup entries to allow for local/alternative names. For me, things just get too messy if we do, so I'd say we shouldn't allow them.

On the one hand I would be inclined to allow aliases of the type "loc", "aka", and "old" for entries in the "dup" array, though I do agree that it might get a bit messy. At the same time, it will probably (:crossed_fingers:) also be pretty rare. In any case, I would be perfectly fine with not allowing this in the initial version of the aliases field. (also, to avoid it becoming messy, #770 might interest you 😉)

With regards to the various packages: As the initial purpose of this issue was merely to add some alternative names so that icons could be discoverable using them on the website, I think we should continue here with that in mind and then, in a separate issue for each package, discuss which, if any, aliases we're going to expose to that package and how we're going to implement them. I already have a number of ideas & suggestions for the NPM package, some of which (I think) will get us around the potential issue of name collisions.

Agreed 👍

Just want to chime in about this. It would be more flexible to accept IETF language tag (ex. en-US, fr-CA, ...). I'm in Québec, Canada. It is the only province with french as primary language. There are a a lot of particularity here that differs from the rest of the Canada. Date format, brand name, etc. We're often different from other french places too (we're very overprotective of our language).

Couldn't agree more, good call @service-paradis 👍

[PeterShaggyNoble]

Coming back to this on a couple of points:

1. Contrary to what I said above, I do now think we should allow dup entries if the dup's title is contained entirely within the title of the parent icon to allow people to use the icon with the correct <title>.
2. I thought of one possible use case for allowing an optional source for dup entries; that being when the hex is different from the parent icon. Perhaps we should allow it but only if the hex entry is present for that dup?

[ericcornelissen]

Contrary to what I said above, I do now think we should allow dup entries if the dup's title is contained entirely within the title of the parent icon to allow people to use the icon with the correct <title>.

Agreed, that makes sense - provided that we do plan to automatically generate the SVGs of duplicates (which I'm in favor of, e.g. following your suggestion in a different thread).

I thought of one possible use case for allowing an optional source for dup entries; that being when the hex is different from the parent icon. Perhaps we should allow it but only if the hex entry is present for that dup?

Good, i agree that that could happen and so we should support it. Ideally, it would only be allowed if it is different from the parent's source but I don't think either jsonlint or jsonschema an check this for us - though we could implement that check as a custom linter.

[PeterShaggyNoble]

OK, so, after letting this sit for a while, I have one last suggestion before we proceed to PRS: Would alt(ernative) offer better calrity than dup for that type? And maybe int(ernational(ised)) instead of loc as well?

[ericcornelissen]

OK, so, after letting this sit for a while, I have one last suggestion before we proceed to PRS: Would alt(ernative) offer better calrity than dup for that type?

I guess that depends on what it should actually be used for 🤔 If it is intended for two brands with the same icon, I think "dup" is clearer, as "alt" suggests (to me) it is an alternative name - which "aka" is for I would say. On that note, I would be fine changing "aka" into "alt".

And maybe int(ernational(ised)) instead of loc as well?

As per the "definition" on Wikipedia i would say what we're doing is localisation, as the "title" should(?) be the international name (provided it exists).

[ericcornelissen]

Amazing, with #5369 merged (and already some PRs adding alias metadata, e.g. #5615 and #5617), we can start working on including duplicates in at least the NPM package - and subsequently the website.

There has been discussion on this before, but we need to decide on how we automatically convert aliases into actual SVGs and icon entries in the NPM package. Here are some initial thoughts

• old: This can simply be a copy of the SVG and metadata with the title replaced (and the old slug). One question I have regarding this is whether the <title> should really be the old one, or perhaps the new one?
• aka: I'm not so sure what we want to do with this one beyond exposing it publically so that e.g. we can use it for search in the website.
• loc: I would propose putting localized SVGs into a folder with the IETF language tag as name. That way all localized brands are clearly grouped. I think the filename should be the same as the original SVG, so as to avoid any potential issues with unconventional file names, the <title> should be localized though.
• dup: I think this is the most straightforward, these would just be copies of the SVGs and metadata with the appropriate values changes.

[jorgeamadosoria]

what's missing to advance this issue forward?

[ericcornelissen]

While the aliases can already be added to the _data/simple-icons.json file, there isn't agreement yet on what should be done with the alias. I created #5859 to discussion the old alias specifically (as you've seen @jorgeamadosoria) and I suggest we do the same for the other aliases.

I would say that at least until a separate thread to discuss the implementation of each alias has been created, this issue should stay open. Alternatively, we could keep this issue open and have it serve as an overview of the process by updating the issue description to something like:

# Implementation Progress

The process of the implementation of the aliases can be followed here:

- [ ] `old` (#5859)
- [ ] `aka` (tbd)
- [ ] `loc` (tbd)
- [ ] `dup` (tbd)

---

# Proposal

[The current text of the issue description]

Both closing this or keeping it open this way work for me.