What should be done with emoji redirects, particularly with emoji redirects that are found to represent vague concepts that are not well reflected on Wikipedia?

Note that the discussion only pertains to emojis that do not have their own pages (as in 😂 which links to Face with Tears of Joy emoji), in which case the redirect consensus is clear in that it should direct to the article. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC)[reply]

Background (emoji redirects)[edit]

There was a previous RfC (with the cute shortcute WP:😃↪️📊) for which I will include the relevant background here:

Over the last several months, there have been several Redirects for Discussion entries at increasing frequency about the justification for the existence of emoji redirects. At this point, there are often several different discussions happening on a weekly basis, which often boil down to the same general viewpoints about how to deal with redirect emojis as a whole. Some past discussions that have recently closed in September and early October include the following: RfD on 🤪, RfD on 🙀, RfD on 🤭, RfD on 👩%E2%80%8D💻, RfD on 💨, RfD on 🫸, among many discussions which were also ongoing during this period, as well as many others which have cropped up and still have not been closed. The only precedence which has been recorded is in an RfD subset page which documents the common outcomes of discussions, and under the section for WP:REMOJI. During recent discussions, however, this documentation has been challenged and dated, particularly relating to emoji that can be depicted and interpreted differently on multiple platforms and different people, and whether or not a redirect is necessary for these emoji in the first place. Comments on this matter would be appreciated to help determine whether or not all emoji should inherently be considered as "likely search terms" and automatically exist as redirects, or whether there should be criteria for inclusion for emoji redirects to exist in the first place. Utopes _{(talk / cont)} 02:52, 16 October 2023 (UTC)

The RfC, however, was derailed when some of the options were reorganized, stricken, and combined; this caused confusion and the only consensus to be made at the end was a call for a new clean RfC without presupposed options.

Survey (emoji redirects)[edit]

Given the confusion previously, I hesitate to presuppose too many options here. Instead, if you feel like your preference is not covered here, I encourage you to add it here for easy identification for the ensuing conversation. I've transposed the options included previously, or that were brought up at the previous RfC.

The options only discuss what happens to redirects that do not have a clear article, as in the case with 😂 which links to Face with Tears of Joy emoji.

I invite your comment here. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC)[reply]

• Option 1: I think a list should be created that has an anchored table of the emojis with their official unicode description and things within that description can be linked. I've begun making such table at Draft:List of Emojis and, for example, where ‼️ could link to Draft:List of Emojis § ‼️ and then within the description, there is a link to exclamation mark. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC) Stricken, option 7/8 per below. microbiologyMarcus ^{(petri dish•growths)} 17:41, 23 November 2023 (UTC)[reply]

  See also Draft:List of emojis (faces) Gonnym (talk) 17:46, 16 November 2023 (UTC)[reply]

  I have to say, I'm not particularly attached to the list I gave, I like the (faces) list as well. I think the list would be beneficial to include all as it would encompass the discussion here for all emojis. But I completely agree that having the links (under meaning) just like the descriptors are linked in the first is the most beneficial way of creating a navigable and descriptive, helpful list. microbiologyMarcus ^{(petri dish•growths)} 17:50, 16 November 2023 (UTC)[reply]

  We already have List of emojis; we don't need another (separate) one (i.e. Draft:List of Emojis) with the word 'emojis' capitalized. Some1 (talk) 23:25, 16 November 2023 (UTC)[reply]

  Stricken above. I really like option 7/8, but @Alexis Jazz: why not combine the ((Character info)) infobox with ((User:Alexis Jazz/Emoji)) template? I think I like the info provided by both and I don't think it's too much to provide links and wikidata. microbiologyMarcus ^{(petri dish•growths)} 17:40, 23 November 2023 (UTC)[reply]

  MicrobiologyMarcus, okay, I combined them. But I'm still unsure about this. Just the thumbnail looks cleaner to me. ((Character info)) feels a bit busy to me, and infobox-like templates tend to present poorly on mobile devices with narrow screens. And the next/previous character navigation seems rather pointless to me.
  I'll see if I can get the information in the text instead. — Alexis Jazz (talk or ping me) 09:27, 24 November 2023 (UTC)[reply]

  @Alexis Jazz: I can see what you mean. I'm a big infobox fan myself but those concerns are valid. I agree that next/previous navigators are unnecessary for emoji navigation. I do like the info so maybe inline in text would be good. Also, what about separating the links into two sections with a level 3 heading so it's bolded for a See also for Wiki-projects and then a External links for projects that aren't under the WMF umbrella? By all means, just a suggestion from an arm chair quarterback on Monday morning, no need to implement my suggestions, I terrible at these things so don't feel the need to listen to me.

  I do think the userspace template you've made is awesome by the way, I think it is ready for the template space and that is now my vote for what should be done with the redirects. It's a much more elegant solution than the list and it includes all the necessary information for wikipedia without adding all of the unsourced/opinion disadvantages that people have raised below. —microbiologyMarcus ^{(petri dish•growths)} 14:24, 24 November 2023 (UTC)[reply]

  MicrobiologyMarcus, thanks! 😀
  The issue with splitting the list is that a Wiktionary entry only exists for a few emojis. In that case there's only Wikidata, resulting in a list with only one link. The same thing could happen with external links if there's any emoji for which Wikidata has no external links. (the Unicode link I just added is generated locally)
  If lists with one item are okay it's no problem. All the info from ((Character info)) (not including the navigation) should be inline now. — Alexis Jazz (talk or ping me) 17:36, 24 November 2023 (UTC)[reply]

• Option 2a because some emojis have a clear meaning, like fire mentioned above. There are many others too that I wouldn't know about, and it's best to have the others redirected to the list of symbols. The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:50, 16 November 2023 (UTC) Option 4 per Thryduulf. The 🏎 Corvette 🏍 ZR1^{(The Garage)} 20:05, 18 November 2023 (UTC)[reply]

  How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 05:23, 18 November 2023 (UTC)[reply]

• Option 1 directly contradicts fundamental policy and long-standing practice at RFD for similar cases, but all the others except 5 [and 6, which didn't exist when I wrote this] contradict it more. People who want to write about glyphs as glyphs are encouraged to contribute to our sister project Wiktionary, where that's in-scope. —Cryptic 17:52, 16 November 2023 (UTC)[reply]
  • Clarifying my position a bit (and refraining from piggybacking on LaundryPizza03's comment, since I don't actually disagree with him): any of 1, 5, and 6 are ok. 2a, 2b, and 4 are actively harmful; 3 is unacceptable since RFD has shown its local discussions can't adhere to policy - either overall, or RFD's own precedent; and 7 is no good because Wikidata is unreliable in both the Wikipedia- and non-Wikipedia senses of the word and we should never use it for content (using such a template with data pulled from our own lists would be ok). Even the non-existent wikt:👿 is more useful to our readers than our redirect from 👿 to imp: it gives its official name "IMP" and displays File:Emoji u1f47f.svg for if your browser or installed fonts can't render the emoji, gives its codepoint and html entity for if you're trying to type it, and links to adjacent emoji and to Wiktionary's list for the appropriate unicode block. They do the same (except, when not available, the image) for every single-character title that they don't have an entry for - in a very real sense, they do cover every emoji, and every other character appearing in Unicode. We can achieve the same by creating a zillion soft redirects to Wiktionary; or by leaving them as redlinks and letting our users click the automatic Wiktionary link; or by leaving them as redlinks and copying Wiktionary's machinery that displays this information on their redlinks; or by linking to a sufficiently-developed and comprehensive list (which we don't currently have). But supposing, as suggested below, that someone who types "🔥" may really be looking for information about fire but doesn't know what to call it, and further that they'd be able to get some benefit out of fire or even simple:fire in that case, is absurd. —Cryptic 03:06, 18 November 2023 (UTC)[reply]
    • Cryptic, copying Wiktionary's machinery that displays this information on their redlinks; I kinda had to make ExportAllTheThings before I could do that, but we have ((Character info)) now. Images don't work yet because of a protected page I can't edit, see Module talk:Unicode data#Edit request 20 November 2023.
      Demo (without image): 🔥 (revision 1185990054) — Alexis Jazz (talk or ping me) 06:50, 20 November 2023 (UTC)[reply]
• It's between option 1 and 2a for me. The question is really whether people searching emojis such as 🔥 are actually trying to go to Fire, or whether they're trying to get more info on the emoji itself, and I don't know the answer to that. I'd lean towards Option 2a until the list of emojis is completed – at that point, we can probably just target all emojis that don't have an article to their section on that list, which can link potential target articles such as Fire for 🔥 and give a bit of info on the emoji. Skarmory (talk • contribs) 17:57, 16 November 2023 (UTC)[reply]

  I now prefer Option 7 (or 8) to Option 2a; no preference yet between Option 7 and potentially full and more useful emoji lists. Skarmory (talk • contribs) 04:18, 22 November 2023 (UTC)[reply]

  Let me know when other glyphs that mean fire like 火 redirect there. And yes, its current target is Wiktionary material too; nearly all Chinese glyphs are correctly redlinks, not redirects to their meanings or lists like List of jōyō kanji. —Cryptic 18:10, 16 November 2023 (UTC)[reply]

  I don’t think that’s a fair argument because 火 has its own article and it redirects to its own article (I agree, I don’t think that article would meet notability guidelines at an AfD currently). That’s akin to saying that the 😂 emoji redirect to Face with Tears of Joy emoji which it does. Lacking that article, though, I don’t think the emoji should be allowed to redirect to tears or joy, so many emojis are ambiguous. microbiologyMarcus ^{(petri dish•growths)} 18:27, 16 November 2023 (UTC)[reply]

  It's not really a good example; the Chinese character for fire is simple and common enough a concept that it's very frequently used in other characters, which is what the article it redirects to is about. The parallel for 🔥 would be an encyclopedia article about emoji containing flames. A more complex character with a similarly-basic concept - and hence a better example - is 家, which should no more redirect to house or home than 🏠 or 🏡 should. —Cryptic 19:16, 16 November 2023 (UTC)[reply]

  I mentioned below but I think we're both in agreeance if I understand you correctly: 🔥 is a bad example because it's so simple, extracting policy or consensus based on the principles developed around 🔥 is not a good idea, and further, emojis should not redirect to the subject of the emojji because that adds no encyclopedic value and no one navigates by emojis; if someone searchs for an emoji on Wikipedia, they should land on a page that describes the emoji not what the emoji represents. microbiologyMarcus ^{(petri dish•growths)} 20:56, 16 November 2023 (UTC)[reply]

  Do you have a citation for this claim that no one navigates by emojis. It's been made multiple times, but given the prevalence of emojis in contemporary usage I find it extremely hard to believe. Thryduulf (talk) 21:18, 16 November 2023 (UTC)[reply]

  I think the fire emoji might be simplifying the complexity of emojis. Take, for instance 👩‍💻, I would find it hard to make an argument that people are using that to navigate to Women in computing. microbiologyMarcus ^{(petri dish•growths)} 18:39, 16 November 2023 (UTC)[reply]

  I agree; those emojis are good candidates for a target to a list of emojis, and are what I had in mind. Fire is an interesting case for me, because there's a fair bit of slang usage, but I think it's about as simple as you're going to get. I'd still prefer a good list entry for it over just redirecting to fire. (Side note: ideally, that list of emojis would also cover the same type of navigation that option 4 is looking for.) Skarmory (talk • contribs) 18:45, 16 November 2023 (UTC)[reply]

  @Skarmory: How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 03:53, 22 November 2023 (UTC)[reply]

  I like option 2a more, mainly because I think in ambiguous cases people are unlikely to search for the emoji looking for one of the concepts (hence why I considered option 1). However, looking at options 7/8, I think I prefer those over anything besides potentially a list of emojis. Option 7 is better, though I think both could be implemented on the same page. Skarmory (talk • contribs) 04:10, 22 November 2023 (UTC)[reply]

• Option 4 seems to make the most sense for getting our readers to the information they want. I would only strongly oppose options 2b and 5, though; deleting most emoji redirects would not be useful to our readers at all. Elli (talk | contribs) 17:58, 16 November 2023 (UTC)[reply]
• Develop a set of lists like Draft:List of emojis (faces) and retarget them all there. -- Tavix ^(talk) 18:00, 16 November 2023 (UTC)[reply]
• Option 2a per Skarmory’s reasoning Yoblyblob (talk) 18:02, 16 November 2023 (UTC)[reply]

  How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 16:42, 20 November 2023 (UTC)[reply]

• Oppose options 2b and 5 unless all relevant redirects (are 🎾 and 🎦 considered ambiguous?) are properly tagged and nominated for deletion, per WP:LEOPARD. The main question I see is whether we want to use emoji redirects only as a search help (then a list would be best) or also as something that we expect people to link to (then 2a or 4 would be best). —Kusma (talk) 18:02, 16 November 2023 (UTC)[reply]

  Option 6 is best for those cases where Wikipedia doesn't have an article about the emoji but Wiktionary does. But that is likely what the default Option 3 would find in each of these cases, so I'm not sure we need to spell this out explicitly. —Kusma (talk) 07:25, 18 November 2023 (UTC)[reply]

• Option 1 I do not see why anyone would want to learn about Fire when they see a 🔥 emoji; to me, it's much more likely they want to learn about the emoji itself, and if there's no dedicated page for the emoji, the best information can be found on the general Unicode block page. (If various lists of emojis are created in line with Tavix's suggestion, then I would support targeting there.) -- King of ♥ ♦ ♣ ♠ 18:04, 16 November 2023 (UTC)[reply]

  Responding to the WP:NOTDICT argument against 1 above: There is plenty of precedent for targeting an article (in particular, an article covering the word itself) other than the main topic when the method of referring to the topic is considered unusual or non-neutral in the English language. For example, Dubya targets List of nicknames of presidents of the United States rather than George W. Bush, and Niemcy targets Names of Germany rather than Germany. This is because English Wikipedia readers are unlikely to search for "Dubya" if they really wanted an article on GWB or the Polish name for Germany if they really wanted an article on the country. Likewise, who searches for actual encyclopedic content using an emoji? -- King of ♥ ♦ ♣ ♠ 18:24, 16 November 2023 (UTC)[reply]

  Yes. Exactly. Nobody searches for encyclopedic content with emoji, and most options take it for granted that they do. This RFC isn't about cases where we have encyclopedic content about emoji, like the 😂 shown just above the list of options. If someone's looking for information about other emoji, and there isn't anything encyclopedic to write about it, the best option is to send them where there's something at all to write about it. Like wikt:🔥, which is far more useful than fire or a local list entry that's likely only going to say "U+1F525 'fire'". —Cryptic 18:31, 16 November 2023 (UTC)[reply]

  @Cryptic: So you would like to create soft redirects to Wiktionary? -- King of ♥ ♦ ♣ ♠ 18:39, 16 November 2023 (UTC)[reply]

  I think redlinks are sufficient. If titles like 🔥 didn't uselessly redirect to articles like fire, they'd show Mediawiki:Noarticletext, which links to the Wiktionary version. Even when there's no Wiktionary version, what they display on their version of wikt:Mediawiki:Noarticletext is at least as useful as what would be put on a list here (example: wikt:🏡). A list with links to Wiktionary, set up like List of jōyō kanji, seems like an ok compromise, though I expect most users will just look at our entry that only gives the official unicode designation of "FIRE", roll their eyes at how obvious and unuseful that is, and not click through to the Wiktionary entry. With the "We have no article, here's a list of other places to look" they'd get from a redlink or failed search, they're at least a little more likely to. —Cryptic 18:51, 16 November 2023 (UTC)[reply]

  To me, a list with links to Wiktionary makes the most sense. It serves readers well when there is no encyclopedic content to write about, but also encourages the addition of encyclopedic content to list entries that might not have enough to justify individual articles. As a backup option if no such list exists, I still support redirecting to the Unicode page (and we should add Wiktionary links there as well). -- King of ♥ ♦ ♣ ♠ 19:18, 16 November 2023 (UTC)[reply]

  Update: With the addition of new options, I think Option 7 is also a very good (and creative) solution. While it does require adding a new class of acceptable mainspace pages (which currently consist of the Main Page, articles, lists, redirects, disambiguation pages, and set-index articles), I think emojis are important and distinct enough to deserve special treatment.

  This reminds me of Chinese-character disambiguation pages, which are a special exception to the rule that all pages must use Latin script. Because of competing priorities (we want to make redirects from terms in their native language, the characters have different romanizations, and ambiguous redirects should be disambiguated), the only solution is to allow disambiguation pages at non-Latin titles. Likewise, I think it is reasonable to invent a totally new paradigm here because emojis do not fit nicely into any of our existing ways of doing things. -- King of ♥ ♦ ♣ ♠ 23:37, 22 November 2023 (UTC)[reply]

  rule that all pages must use Latin script - huh? I wasn't aware of any such rule. * Pppery * _{it has begun...} 23:55, 22 November 2023 (UTC)[reply]

  Page titles must, not entire pages. WP:UE, and specifically for dab pages WP:DABNAME. —Cryptic 00:04, 23 November 2023 (UTC)[reply]

• (edit conflict) Option 4 is my first preference, with Draft:List of emojis (faces) and similar being the target for those that don't have a clear single target article or dab. I would also support hatnotes like 😗 redirects here, for information about the emoji see List of emojis (faces) as this seems the most useful to readers. Strongly oppose option 2b and option 5 as actively unhelpful to readers. Thryduulf (talk) 18:06, 16 November 2023 (UTC)[reply]
• Option 1 emoji's should not redirect to anything other than an article on the emoji or a list of emoji's article. Polyamorph (talk) 18:17, 16 November 2023 (UTC)[reply]
• Option 1 or 5 with equal preference, options 2-4 will inevitably continue the status quo of wasting way too much time arguing over emoji at RfD. _signed, Rosguill ^talk 19:23, 16 November 2023 (UTC)[reply]
• Option 4 as the best compromise. We don't know what readers are looking for, but I think this is the best guess. Certes (talk) 19:30, 16 November 2023 (UTC)[reply]
• Option 1 A reader who is looking for information on fire will search for "fire". A reader who wants information on the fire emoji will search for 🔥.There's also the messiness of trying to figure out what's unambiguous. Is 🔥 fire? flame? Should we base it on the common usage of that emoji to mean "lit" (aka Cool (aesthetic) or Hip (slang))? --Ahecht (TALK
  PAGE) 19:47, 16 November 2023 (UTC)[reply]

  See RfD: 🔥, the decision to keep was unanimous because the emoji name is unambiguous. Enix150 (talk) 07:58, 24 November 2023 (UTC)[reply]

  Technically it wasn't unanimous; I suggested soft redirecting. Edward-Woodrow (talk) 15:00, 24 November 2023 (UTC)[reply]

• Option 1 unless there is an article for the emoji already a list is a better idea. If I search for 🔥 I don't want to be redirected to Fire I'm not blind. If someone searches for the emoji they are searching for the emoji. The fire article gives no indication of what 🔥 is as a symbol, or why it might be used. -- LCU ActivelyDisinterested «@» °∆t° 20:11, 16 November 2023 (UTC)[reply]

  Obviously this should be read as opposing options 2a/b and 4, I also oppose option 5 (redirects are cheap). I do not support, but would not oppose option 3. -- LCU ActivelyDisinterested «@» °∆t° 20:14, 16 November 2023 (UTC)[reply]

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:57, 24 November 2023 (UTC)[reply]

  Technically it wasn't unanimous; I suggested soft redirecting. Edward-Woodrow (talk) 15:01, 24 November 2023 (UTC)[reply]

• Option 2b There's always WP:IAR, but I find this most appropriate as a baseline. --BDD (talk) 21:01, 16 November 2023 (UTC)[reply]
• Option 4 or Option 2a: Every single emoji currently has a redirect on Wikipedia, and every emoji redirect discussion brought up this year has concluded in a keep/retarget decision, so deleting them would go against all the consensuses we've had so far. (See prior discussions here: 🤭, 👩‍💻, 🛋️, ⏫/⏬, 🫸/🫷, 🤪, 🙀, 👯‍♂️, 🫥, 👾, 🧑‍🦳, 👏, 💨, 😶‍🌫, 🤗, 😬, 🏚️, 💁‍♂️/💁/💁‍♀️, 🫗, 🔞, ☄️, 🏴󠁭󠁭󠀱󠀶󠁿, & 🔥) Enix150 (talk) 21:11, 16 November 2023 (UTC)[reply]

  Strongly oppose Option 2b & Option 5: Deleting everything does not serve the reader in any way, and it goes against all of the discussions we've had so far this year. Enix150 (talk) 05:27, 18 November 2023 (UTC)[reply]

• Option 5: It's unclear what people actually want when the copy/paste an emoji into the search box. Do they want information about the emoji itself, or about the concept(s) it represents? And often, there's more than one concept. Given that we can't answer this question without launching some kind of reader poll, I think it is best to delete all emoji redirects that try to guess at one answer or the other. Option 6 – soft redirect to wiktionary – is my secondfirst choice, and option 2b is my third. Okay... option 7 or 8 is my first choice; let's keep it local if we can; option 6 is my third. Edward-Woodrow (talk) 21:17, 16 November 2023 (UTC)[reply]
• I don't really have an opinion but I beg the eventual closer to find some result here, even if not a specific consensus – it doesn't need to be codified policy; even a summation of the arguments for each course of action will do. A straight no consensus is highly undesirable. In the absence of support for option 3, just like at RfD something analogous to an WP:NCRET would be appreciated. J947 † ^edits 22:27, 16 November 2023 (UTC)[reply]
• Option 3 This entire discussion feels like a lot of energy being spent unnecessarily - the community is coming its own decisions at RfD, and I see no reason why we can't just let it. * Pppery * _{it has begun...} 23:17, 16 November 2023 (UTC)[reply]

  I oppose options 7 and 8 - they amount to creating thousands of new articles by the back door without any consideration of notability criteria. * Pppery * _{it has begun...} 04:29, 22 November 2023 (UTC)[reply]

  Pppery, I view option 7 as a rich soft redirect/disambig. Option 8 could also be deployed through ((No article text)) / MediaWiki:Noarticletext and wouldn't require page creation. — Alexis Jazz (talk or ping me) 05:13, 22 November 2023 (UTC)[reply]

  Since, as Enix150 will remind us,^[FBDB] the grand majority (if not all) emojis have redirects or pages on Wikipedia, there will be little to no actual page creation. Edward-Woodrow (talk) 13:29, 22 November 2023 (UTC)[reply]

• Any except 2b or 5 Deletion does not help our readers. As long as the target helps the reader identify the symbol, I don't have much of an opinion on whether 😀 goes to smile or Emoticons (Unicode block) or wikt:😀 or an undraftified Draft:List of emojis (faces). Anomie⚔ 23:27, 16 November 2023 (UTC)[reply]
• I'm a little irritated that this "RFC without presupposed options" has presented a long numbered list of presupposed options. I'm not sure which option to pick. King of ♥, whose sig contains an emoji, can't imagine why I'd want to use the search bar to find out what a particular emoji is. (I've got a guess about about his age, though, and it's "not quite old enough to need reading glasses".) Having 🔥 redirect to Fire and ♥ to Heart symbol are both perfectly fine. Sure, I might not be interested in reading a whole article about fire, but that's okay. Most readers only spend a few seconds on each page, because most readers are only trying to find out one or two little things, often "What's that?", and if I put that symbol in the search bar, I'll end up at Fire and have my question completely answered. In such cases, I really don't want to end up a long list of all possible emojis, so that having already searched for the emoji, I know have to search through the whole page to find out what the character is. I don't want them deleted; Wikipedia:Redirects are cheap, and these are useful (and, per WP:R#KEEP #5, I encourage editors to not tell me that you somehow know that I don't actually find them useful, even though I've just told you that I do). Even if they are used only a few times a week, they are still useful in those few times, and retaining that utility costs us nothing. WhatamIdoing (talk) 23:58, 16 November 2023 (UTC)[reply]

  I'm fine with ♥ redirecting to Heart symbol because it contains content about the heart emoji. But if it didn't exist, I would strongly oppose redirecting to Heart. -- King of ♥ ♦ ♣ ♠ 00:07, 17 November 2023 (UTC)[reply]

  Well, a symbol of love isn't really a vital organ, so I wouldn't necessarily redirect it there. I'd be more likely to choose Playing card suit or Hearts (suit). But imagine the existing Heart symbol article, only without any mention whatsoever of the emoji. That would still be my first choice for the target of such a link. WhatamIdoing (talk) 00:43, 17 November 2023 (UTC)[reply]

  On second thought, I would also support targeting a Heart symbol article that doesn't mention the emoji. But there's a big difference between that and Fire. For me, as long as the article is about a symbol then it's fine, but not if the article is about the broader topic. It's like the difference between Antidisestablishmentarianism (word) and Antidisestablishmentarianism. I got my analogy a bit mixed up; usually, the heart symbol does not represent a literal organ but rather the concept of Love. And that is the kind of target I would oppose, just like Fire. -- King of ♥ ♦ ♣ ♠ 04:20, 17 November 2023 (UTC)[reply]

  Heart symbol is the best target. More controversially, my second choice would be Heart. We shouldn't add interpretation by redirecting it to Love, and I'm not even going to think about 🍆. Certes (talk) 09:37, 17 November 2023 (UTC)[reply]

  IMHO, when people are searching for an emoji, they're not asking "What's that?" They're asking "What does that emoji mean?" If they see someone text, "Wow, that dress is 🔥🔥🔥" Searching on Wikipedia, they'll find 🔥 -> fire, so does that mean that dress is fire? Or does it mean the dress is "lit, super stylish, or even hot (as in attractive) or sexy"? [1] Some1 (talk) 02:35, 17 November 2023 (UTC)[reply]

  @Some1, when I am searching for an emoji, I'm usually trying to find out what it is. Keep in mind that I'm far more likely to be saying "Wow, that dress is machine washable, doesn't require ironing, and is on sale" than "Wow, that dress is 🔥🔥🔥". WhatamIdoing (talk) 03:47, 18 November 2023 (UTC)[reply]

• Option 2a or 4 These two seem to be the best for our readers --Lenticel ^(talk) 00:00, 17 November 2023 (UTC)[reply]
• Option 1, the meaning of emojis is not clearcut, and 🔥 is a case in point. Despite it being the standard example of an emoji with a clear meaning here, this is an emoji that receives actual everyday use and it emphatically does not usually mean fire. Dictionary.com even has an entry for 🔥: "It is used to signify that something is cool, awesome, exciting, or more colloquially, “on fire.” It can also convey that someone is sexy, (i.e., hot)...signifying that a person, object, album, movie, or so on, is “lit,”...sometimes the fire emoji is used to reference marijuana". CMD (talk) 00:56, 17 November 2023 (UTC)[reply]
• Option 1 Not all of these emojis have literal meanings that one can just redirect to. See Chipmunkdavis's 🔥 emoji example above. 💀 currently redirects to Skull even though it really shouldn't, because that emoji can also mean “I’m dying with laughter” or “I’m dead from laughing” (Dictionary.com's How Gen Z Uses Emoji: A Guide For Millennials). If an individual searches 💀 on Wikipedia to find out what that emoji means because they keep seeing their friends use it in their chats, would the Skull article really help them find their answer? I think not. Retargeting all other emoji redirects to the lists that the emojis appear on (e.g. Supplemental Symbols and Pictographs or Symbols, Pictographs Extended-A, etc.) would be the most efficient approach. The tables on those list articles could then be revised and expanded upon to include columns such as Description, Meaning, etc. (similar to the table in Draft:List of emojis (faces)). Some1 (talk) 02:24, 17 November 2023 (UTC) expanded on !vote, Some1 (talk) 00:46, 20 November 2023 (UTC)[reply]
• Option 1: If the lists would have descriptions (not just on hover) and the redirects had an anchor maybe, but if there's no better target sure.
  Option 2a: Worse version of option 4.
  Option 2b: Redirect cheap, deletion bad.
  Option 3: Meh, having some guideline is probably helpful.
  Option 4: Seems okay, this is an improved version of 2a?
  Option 5: Redirect cheap, deletion bad.
  Option 6: Seems interesting, but Wiktionary doesn't have entries for all emojis.
  How am I even supposed to vote on this. Can we like transclude the description, maybe from Wikidata, on the soft redirect so you don't have to actually follow it for the answer to the "what's that" question? — Alexis Jazz (talk or ping me) 11:02, 17 November 2023 (UTC)[reply]

  I agree, Option 2a and Option 4 should probably be merged, with Option 4 being the ideal choice. Option 6 is interesting too, but it would be a daunting task to create an entry for every emoji on Wiktionary. I strongly oppose Option 2b and Option 5 because deleting everything does not serve the reader in any way, and it goes against all of the discussions we've had so far this year. And yeah, having so many options makes tallying an actual decision pretty difficult if not impossible. Enix150 (talk) 17:42, 17 November 2023 (UTC)[reply]

• Option 2 or 6 Wiktionary does not cover every emoji, but there is no reason why it shouldn't. For example, we have wikt:💀 but no wikt:👿. –LaundryPizza03 (dc̄) 13:02, 17 November 2023 (UTC)[reply]
• Options 4 or 6, the latter for cases where the figurative meaning would turn the dab into a dictionary. Mach61 (talk) 02:08, 18 November 2023 (UTC)[reply]
• Option 6. If people want to look up the meaning of an emoji (which is what they're doing when they put an emoji into the search box), take them to an article that will explain the meaning: either a Wikipedia article about the emoji, if it exists, or, if no Wikipedia article exists, a Wiktionary article about the emoji (which will have more info than a list of emojis or no page at all). Option 6 gets the reader the information they're looking for. Levivich (talk) 02:05, 18 November 2023 (UTC)[reply]
• Option 6 is the most sensible because people pasting emojis into search are likely looking for dictionary treatment, not an encyclopedia article. Sandizer (talk) 02:24, 18 November 2023 (UTC)[reply]
• Comment: Option 6 would only work if there were Wiktionary entries for these emojis, but that isn't the case for most of them. This would require the creation of several thousand Wiktionary entries. Enix150 (talk) 05:09, 18 November 2023 (UTC)[reply]

  I agree with this; Option 6 doesn't solve this redirect problem since we'll still be dealing with emojis that don't have corresponding Wiktionary entries, which are most of them. The tables on the list articles (Options 1 and 4) could always be revised to include a 'Meaning'/'Definition' column. Some1 (talk) 12:56, 18 November 2023 (UTC)[reply]

  @Enix150 and Some1: Although, as someone (maybe Cryptic?) pointed out above, the blank wikt entries are still fairly useful, e.g. look at wikt:🤤 – it gives the unicode block number, has a big, easy-to-see picture of the emoji, and gives the name of the emoji which probably at least hints at its meaning. Edward-Woodrow (talk) 23:01, 18 November 2023 (UTC)[reply]

  Hovering over the 🤤 emoji at Supplemental Symbols and Pictographs shows the same info. As always, the tables on these articles could be revised and expanded upon e.g. to include a 'meanings' column, make the emojis larger, provide information in text to avoid having readers hover over the emojis, etc. Redirecting readers to non-existent/blank Wikitionary entries is nonsensical. Some1 (talk) 00:36, 20 November 2023 (UTC) Some1 (talk) 00:47, 19 November 2023 (UTC) Add to statement. Some1 (talk) 00:36, 20 November 2023 (UTC).[reply]

  A small part of the same info, and providing information only through hovering is inaccessible. —Cryptic 06:04, 19 November 2023 (UTC)[reply]

• Option 7 Alternatively option 8 would also be acceptable for me, likely combined with option 5, transcluding ((Character info)) through ((No article text)). But a user who visits 🔥 or 😼 should be given something useful. — Alexis Jazz (talk or ping me) 20:58, 18 November 2023 (UTC)[reply]
• Option 7. I've been following these discussions for a bit without a very strong opinion. I think this "Emoji disambiguation" treatment is the best option I've seen yet. There'd need to be some sort of specialized dab template to use for the majority of cases where the emoji itself doesn't merit an article. —siroχo 09:16, 19 November 2023 (UTC)[reply]
• Option 7. I agree that this sort of emoji-dab layout would work quite well, and it's better than sending it directly to some sort of article when we don't have an article on that emoji. — Red-tailed hawk _(nest) 21:22, 19 November 2023 (UTC)[reply]
• Option 1 first choice, option 6 secoind choice. Redirecting 🔥 to Fire is completely absurd. Options 7 and 8 are not solutions to the question of where links/titles like 🔥 should go, but only what to do with markup to the symbols after the user already gets to where they go, so they shouldn't even be in this list of options, and just confuse the matter.  — SMcCandlish ☏ ¢ 😼  07:53, 20 November 2023 (UTC); rev'd. 19:21, 20 November 2023 (UTC)[reply]
  • SMcCandlish, but only what to do with to markup the symbols after the user already gets to where they go I don't understand, did you make a typo somewhere?
    Option 7 and/or 8 could be shown on 🔥 instead of a redirect. For option 8 that could technically be done through MediaWiki:Noarticletext / ((No article text)). — Alexis Jazz (talk or ping me) 08:16, 20 November 2023 (UTC)[reply]

    Yes. Fixed.  — SMcCandlish ☏ ¢ 😼  19:21, 20 November 2023 (UTC)[reply]

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:55, 24 November 2023 (UTC)[reply]

  @Enix150: The extent to which you have WP:BLUDGEONed the hell out of this discussion with the same claim (which is not actually true) over and over and over again would almost certainly result in a WP:Topic ban if anyone bothers taking you to WP:ANI for it. Please don't ever do anything like this again.  — SMcCandlish ☏ ¢ 😼  07:04, 3 December 2023 (UTC)[reply]

• Option 7/8 is appealing and in my opinion the most helpful solution. If I understand it correctly, they will require little maintenance so I don't think lack of notability is a problem – I'd even be fine with formatting them in an article-like way. J947 † ^edits 03:00, 23 November 2023 (UTC)[reply]
• Option 1 - (Summoned by bot) Someone typing 🔥 would likely be looking for an article discussing the emoji itself, not the concept of fire in general. These emoji redirects should target articles about the emoji themselves. - Aoidh (talk) 18:30, 23 November 2023 (UTC)[reply]

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:53, 24 November 2023 (UTC)[reply]

I've gone over the discussion and all the options. Here is my thoughts.

I oppose 2b, 3, 5, and 8. 2b and 5 because they support deletion of emoji redirects. I believe all emojis are valid search term. 3 adds unnecessary work at RfD. The last month or two of emoji deletion disscussions are evidence where this is compeltely unhelpful. 8 is a personal taste opinion, but I think it's just visually bad and it also doesn't help with the actual issue as it doesn't really offer enough information for it to be a non-redirect. And if it was added to the redirect, most readers won't see it anyways.

I support 1 and 4. These brings the reader to the most viable target we have to offer.

I'm neutral with 2a. This seems like 4 but with less of information on how to handle most situations.

I find 6 and 7 problamatic. 6 is under the assumption that every emoji has an entry on Wikidata. Has that been checked? What if there isn't? Do we now create one there? What if entries are deleted there, would we be informed? It's hard for me to support being dependent on a different website. While I don't dislike the style of 7, that small piece of text requires a huge amount of modules to support it. I really don't think that is necessary, but even if it was, who here is going to take over that and support it when issues arise? Also, the RfC's question is about emoji redirects and option 7 turns these into stubs. While I don't oppose that, that needs to be made clear. Gonnym (talk) 11:00, 24 November 2023 (UTC)[reply]

Gonnym, 6 is under the assumption that every emoji has an entry on Wikidata.
You mean Wiktionary. And no, they don't. Wikidata however most probably does, and if they don't it's within their scope for us to create. (and we could track this)
While I don't dislike the style of 7, that small piece of text requires a huge amount of modules to support it. I really don't think that is necessary, but even if it was, who here is going to take over that and support it when issues arise?
Option 7 can work without any of the imported modules. It can work 100% on ((Wikidata)). I'm reworking option 7 to use Module:Unicode data if it exists for the basic information with Wikidata fallback as at least Cryptic doesn't like Wikidata. If the modules break and nobody can fix them you can quite easily switch to using Wikidata instead.
Option 8 does depend on modules, but the parts from that which we actually need are limited. I just imported ((character info)) with all its dependencies, but I don't think we'll end up using (all of) that. — Alexis Jazz (talk or ping me) 11:49, 24 November 2023 (UTC)[reply]

Yes, I meant Wiktionary for option 6. Thanks for the correction. Option 8 is just not really helpful (or visually pleasing in my opinion). If/when option 7 has a different implementation I'll check it again. I just cannot currently support it. Gonnym (talk) 12:02, 24 November 2023 (UTC)[reply]

Gonnym, do you like User:Alexis Jazz/Emoji / 🔥 revision 1185755899 now? — Alexis Jazz (talk or ping me) 12:36, 24 November 2023 (UTC)[reply]

• 6, 7, or 1 in order of preference, because they are mechanistic. Any option that involves editors discussing and interpreting the meaning of emojis without enough RS to achieve notability for a dedicated page will lead to endless 💩 Sennalen (talk) 23:38, 26 November 2023 (UTC)[reply]

• Option 7, 1, or 6 (in no particular order). Basically I think we should treat emojis as characters, not as likely search terms for the concepts they represent. Option 8 is fine by me as well, though I slightly prefer the look of the similar option 7 result. Ajpolino (talk) 01:51, 1 December 2023 (UTC)[reply]
• Option 4, or 2a, per Lenticel. Quiddity (talk) 23:57, 1 December 2023 (UTC)[reply]
• Option 4 as per Thryduulf. I have a general dislike of emoji redirects, but I realize that an editor can use emojis in a talk page post, etc., and another editor should be able to look up what is meant. So there should always be a target, so that a reader will have recourse in interpreting a post by a fool who uses too many emojis. Option 4 does this best, giving an explanation if possible, or a list that permits some research. Robert McClenon (talk) 06:43, 4 December 2023 (UTC)[reply]
• Option 2a or 4 per Lenticel BluePenguin18 🐧 ( 💬 ) 21:12, 4 December 2023 (UTC)[reply]
• Comment: I think that Option 7/8 could be implemented on redirect pages even if another option (my current vote is Option 4/2a) is selected, similar to how Template:R from emoji is currently implemented. Enix150 (talk) 06:58, 4 December 2023 (UTC)[reply]
• If they are to exist, then they should be targeted according to their unicode text definition per WP:EMOJI. How they appear varies by computer platform and font. e.g. ♂️ , i.e. MALE SIGN, may have an appearance in some fonts that has no relation to the concept but will always have a constant consortium-defined text definition. Can be discussed regarding ambiguity as always if necessary. If they are not targeted in that manner, then they shouldn't exist. — Godsy ^(TALK_CONT) 02:42, 5 December 2023 (UTC)[reply]
• Option 7 per Hawk. voorts (talk/contributions) 04:46, 8 December 2023 (UTC)[reply]
• Option 2a first choice. Failing that, Option 6 then Option 1. Option 4 is also okay. We should not delete en masse emoji titles unless if they are obviously implausible. Case by case is how best it should be handled. Awesome Aasim 19:23, 13 December 2023 (UTC)[reply]
• Option 4 seems the best to me, though with the caveat that I expect that any single Unicode character should lead the reader somewhere. -BRAINULATOR9 (TALK) 03:21, 14 December 2023 (UTC)[reply]
• Option 4 puts into words what we've been doing at WP:RFD and it makes sense. There shouldn't ever be an emoji that doesn't link anywhere unless the emoji is independently notable and doesn't have an article. ~ F4U (talk • they/it) 02:49, 19 December 2023 (UTC)[reply]
• Option 1 (alternativily option 2b) And certainly not link to disambiguation pages as that kicks maintenance bots into action. The Banner talk 15:06, 26 December 2023 (UTC)[reply]

Discussion (emoji redirects)[edit]

Attention @A smart kitten, ActivelyDisinterested, Awesome Aasim, BDD, BilledMammal, CaptainEek, Certes, Chipmunkdavis, ClydeFranklin, Cryptic, Edward-Woodrow, Elli, Enix150, Enos733, Espresso Addict, Firefangledfeathers, Frostly, Gonnym, Hey man im josh, Illusion Flame, Isaacl, Isla, Ivanvector, J947, King of Hearts, Kusma, LaundryPizza03, Lenticel, Levivich, Martin Tauchman, ObserveOwl, Patar knight, Polyamorph, Pppery, Qwerfjkl, Rosguill, Sandizer, Serial Number 54129, Shells-shells, Skarmory, Some1, Stifle, TartarTorte, Tavix, The Corvette ZR1, Thryduulf, Utopes, Walt Yoder, WhatamIdoing, and Yoblyblob: I'm notifying you here because you either participated in the previous discussion, or you were notified the last time. I hope I didn't miss anyone. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC)[reply]

Yes? The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:44, 16 November 2023 (UTC) Now I understand. Thanks Marcus! The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:52, 16 November 2023 (UTC)[reply]

• My issue with these titles which comes up in nearly every discussion about them, and has again with the fire emoji above, is that very little of the information we're publishing with respect to these glyphs is verifiable. What do reliable sources say is the meaning and common usage of the fire emoji? Nobody has yet provided a source; instead many well-meaning editors have added their own opinions as to what it represents, and now we're preparing a draft list of those almost entirely unsourced opinions to publish in an encyclopedia. We're not supposed to do that. If we brought up a discussion on any other topic about how best to manage a collection of editors' unsourced opinions in mainspace, the answer would be utterly simple: delete it. If we dump the opinions out of these discussions and base them solely on information previously published in reliable sources, like we do for every other topic, then in the vast majority of cases these glyphs should redirect to a page with technical information only, because that is the limit of reliably-sourced information about them. A tiny proportion will have more reliably-sourced information available and those can be dealt with case-by-case. Ivanvector (^Talk/_Edits) 10:52, 17 November 2023 (UTC)[reply]

  Meh, we've always relaxed NOR and V with regards to names (in the form of Foobar G. Smith, also known as Foo Smith). You don't need a citation from a source specifically noting the different names Mach61 (talk) 14:53, 17 November 2023 (UTC)[reply]

  OTOH, you don't want editors redirecting an icon away from its literal meaning because "I just know that 🔥 (U+1F525) means sexy and not fire, even though it's official name is fire". But I'm sure there are sources (perhaps not of the highest quality), because someone's got to explain to Mrs Grundy what her grandchildren are saying. WhatamIdoing (talk) 03:52, 18 November 2023 (UTC)[reply]

  If Mrs Grundy does not want a formal source like "the Fire emoji (🔥) is frequently used as a positive force marker, from the positive idioms 'on fire' or 'lit'.", a source of not the highest quality can be found in this article by The Sun . On emojis as a whole, I found this interesting small survey of emoji meaning ("human agreement about the context-free meaning of emojis ranges from completely unambiguous (16 emojis) to indistinguishable from random (55 emojis), with emojis covering the whole spectrum of ambiguity"), and I recommend having a look through this paper covering the interpretation of emoji by courts. Our Emoji article drops four sources to reinforce that 🍆 means penis, while also noting that this meaning of 🍆 led to the word "eggplant" being used as a synonym for penis. CMD (talk) 07:37, 20 November 2023 (UTC)[reply]

  Yeah, we don't know what people are using emojis for. Did You Know, 😹 means ketamine? and 🤷🏾‍♀️ means WTF (Internet slang)? and 🌻 means "you're doing a good job; it's ok"? and ☃️ means "it's cold in the office; can a lead please contact maintenance to have them turn up the temperature"?

  Well, they don't mean those things. Except sometimes. We shouldn't decide things like that for the reader. Folly Mox (talk) 09:10, 20 November 2023 (UTC)[reply]

BTW, the section heading says "RFC", but it's not listed as an WP:RFC. @MicrobiologyMarcus, was that intentional? WhatamIdoing (talk) 22:08, 21 November 2023 (UTC)[reply]

Mea culpa—yup, that was my mistake, this is my first time submitting such to the VP and that escaped me in my review of the formatting. microbiologyMarcus ^{(petri dish•growths)} 13:46, 22 November 2023 (UTC)[reply]

Would you rather get it listed as an RFC (just add the template to the top of the existing section), or take the "RFC" out of the section heading? WhatamIdoing (talk) 18:48, 22 November 2023 (UTC)[reply]

@WhatamIdoing: based on the way this is going (trending no where near a consensus as far as I can tell, though I think recently people have preferred the DAB-like templates) I'm guessing this may have to be posted again if anyone wants to do any consensus building or advocacy. What would you (or the community) recommend? I've never done something like this before, so I'd like to know which makes more sense in this moment? microbiologyMarcus ^{(petri dish•growths)} 19:43, 22 November 2023 (UTC) For what it's worth, I'm okay with either happening. microbiologyMarcus ^{(petri dish•growths)} 19:44, 22 November 2023 (UTC)[reply]

@MicrobiologyMarcus, what really matters is whether people basically agree to something. Wikipedia is not a bureaucracy, so a decision like this doesn't have to be an RFC. But years later, someone looking at an archived copy of this discussion might assume from the section heading that it used the RFC system (basically an advertising mechanism), and we wouldn't want to leave them with a misconception.

You can, even at this stage, list it as an RFC, since converting an existing discussion into an RFC is explicitly and intentionally permitted. All you have to do is edit this section and paste this wikitext code at the top, above your first comment (which is already a nice RFC 'question'): ((rfc|policy|style)) Then save the page. That's all it would take. WhatamIdoing (talk) 22:47, 22 November 2023 (UTC)[reply]

Thanks!! 😊 microbiologyMarcus ^{(petri dish•growths)} 02:44, 23 November 2023 (UTC)[reply]

• Every single emoji currently has a redirect on Wikipedia, and every emoji redirect discussion brought up this year has concluded in a keep/retarget decision, so deleting them would go against all the consensuses we've had so far. (See prior discussions here: 🤭, 👩‍💻, 🛋️, ⏫/⏬, 🫸/🫷, 🤪, 🙀, 👯‍♂️, 🫥, 👾, 🧑‍🦳, 👏, 💨, 😶‍🌫, 🤗, 😬, 🏚️, 💁‍♂️/💁/💁‍♀️, 🫗, 🔞, ☄️, 🏴󠁭󠁭󠀱󠀶󠁿, & 🔥) Enix150 (talk) 06:28, 22 November 2023 (UTC)[reply]

@MicrobiologyMarcus and WhatamIdoing: Is it reasonable to have a moratorium on further options being added to the RfC, as that would only create more confusion? Edward-Woodrow (talk) 13:31, 23 November 2023 (UTC)[reply]

@Edward-Woodrow: personally, I think a better option would be to summarize the votes and drop the ones that seem to have been opposed most frequently above and then start a voting period where you have an option for (1) DAB-like templates, (2) list pages, or (3) as is/no consensus because that seems to be what is transpiring. There seems to be a clear consensus against blanket deletes (although with some supports). The votes for the list pages identify issues such that they aren't complete or that there might be multiple pages (one for all, one for just faces). That's my personal opinion, it seems that this "RfC" has turned into a proposing options one, which may be my fault: I've never formatted one before and I was just following up on the previous thread. Now that everyone has had a chance to suggest options, I think this is the logical step. But I'm not sure if that's procedure. microbiologyMarcus ^{(petri dish•growths)} 17:34, 23 November 2023 (UTC)[reply]

@Edward-Woodrow: Said with love, but I'm assuming your suggested option 6 fits nicely into one of the template suggestions. I'm hesitant to say no more suggestions, that's not really feasible and prevents suggestions of brilliant out of the box ideas that others might have missed, like the template from User:Alexis Jazz. microbiologyMarcus ^{(petri dish•growths)} 17:44, 23 November 2023 (UTC)[reply]

I understand where you're coming from, and I'm sympathetic to how complicated this occasionally is for someone who is trying to write a summary statement, but an RFC is a Request for Comment, not a "request for votes", and that means that editors can say anything during an RFC that they would otherwise be allowed to say during a non-RFC discussion. This is one of the strengths of the RFC approach, since it prevents editors from being trapped in false dichotomies, and sometimes even results in the proposal of brilliant compromise. WhatamIdoing (talk) 20:22, 23 November 2023 (UTC)[reply]

I do appreciate that fact, that's why I do think if this were to be posted again like I said above with narrowed options, I understand that 'votes' is a loaded word, which is why I suggested a as-is/no consensus option. AFAIK I don't think there's a way to actually put something to a vote. I do see other RfCs on this page from time to time that are straight up and down support-oppose which, while not votes, are a lot more simpler to keep tract of than 8 different options that each person has their own opinion on. Unfortunately, reading the above, I think a lot of people aren't happy with the status quo but there's no organized drive to or consensus to land on any alternative. microbiologyMarcus ^{(petri dish•growths)} 21:34, 23 November 2023 (UTC)[reply]

MicrobiologyMarcus, IMHO let this discussion run for a while longer (few days, a week) and create a new thread with the options narrowed down. Always include a "status quo" option, otherwise you get lesser evil or cake or death situations. I think at least SMcCandlish dismissed options 7/8 because the title of this RfC says "emoji redirects" and options 7/8 aren't redirects.
I think there's a chance of consensus emerging in a new well-worded thread with the options narrowed down. Feel free to draft that in user space and ask me (and/or others) to have a look to try and shoot holes in it. — Alexis Jazz (talk or ping me) 04:25, 24 November 2023 (UTC)[reply]

In re people aren't happy with the status quo: I'm not sure people actually know what the status quo is, but glancing through the responses and noting the comment about none of the RFDs have been ending in deletion, perhaps the status quo is what people want (namely, to not delete them). WhatamIdoing (talk) 18:52, 24 November 2023 (UTC)[reply]

With one or two exceptions, option 4 approximates the consensus of nearly all the recent RfD discussions about emoji redirects. Indeed emoji redirects that match that option don't often get nominated. Thryduulf (talk) 18:57, 24 November 2023 (UTC)[reply]

Meta: There are more than 100 comments in this discussion (the longest on this page), and as a result, this page is over 300K long (~10X WP:SIZESPLIT, and a length that some editors report having problems at, especially on a smartphone). If we expect many more comments in this discussion, please cut and paste it to a dedicated page, e.g., WP:Requests for comment/Deletion of emoji redirects. (If it feels like the conversation is dying down, then it may not matter.) WhatamIdoing (talk) 23:27, 26 November 2023 (UTC)[reply]

Comment: Just to bring up one specific case that I've found useful: redirects from flag emoji, such as 🇷🇸. Nice quick way to identify an unfamiliar flag when used as an emoji without further context. So I'd politely request that, whatever is decided for other emoji redirects, those stay. (I should note I'm utterly unfamiliar with RfD policies, so please consider this as a comment from a reader and not a substantive policy argument.) Gaelan 💬✏️ 11:31, 29 November 2023 (UTC)[reply]

As it turns out, flags are a special case and can't be handled by the template (without some major work) or any other method: Regional indicator symbol. — Alexis Jazz (talk or ping me) 12:21, 29 November 2023 (UTC)[reply]

Oh god, there's going to be a flag sub-consideration the next time an ambitious editor brings this up. microbiologyMarcus ^{(petri dish•growths)} 14:14, 29 November 2023 (UTC)[reply]

MicrobiologyMarcus, if not simply redirected I'd recommend a separate template for that. I quickly put User:Alexis Reggae/FlagTemplate together, but should be a separate vote. (if ever voted on) Frankly a redirect to the article about the flag or the flag section on the country article works about as well for me. Andrew Gray, I think the only question users who enter 🇵🇷 in the address bar or search box have is "whose flag is that?", which can be answered equally well by both the country and the flag article. — Alexis Jazz (talk or ping me) 17:15, 29 November 2023 (UTC)[reply]

@Alexis Jazz: personally, I think that flag emojis should redirect to the flag of the country, like established above. Don't ask me why, and don't ask me how that's consistent with my prior held stances—that would require too much thinking at the moment and a lot more ink to be spilled on this topic. microbiologyMarcus ^{(petri dish•growths)} 17:19, 29 November 2023 (UTC)[reply]

MicrobiologyMarcus, yeah, it's best to simply keep them as redirects to the flag article. (or flag subsection of the country article if there is no flag article) KISS. — Alexis Jazz (talk or ping me) 17:35, 29 November 2023 (UTC)[reply]

Apologies - I absolutely didn't mean to suggest any changes! And agree that any confusion is trivially answered by the result. I was just very struck that my reaction here was "well of course, the meaning of those are unambiguous ... oh, it's something else?" Andrew Gray (talk) 18:06, 29 November 2023 (UTC)[reply]

Interesting that (while I agree these are useful and should stay), they're still a bit ambiguous - I had assumed before checking that the icon would redirect to Serbia, not Flag of Serbia... Andrew Gray (talk) 13:39, 29 November 2023 (UTC)[reply]

Same here. One problem I've noticed with these emojis is that they could mean too many things. The 🏎 Corvette 🏍 ZR1^{(The Garage)} 18:06, 29 November 2023 (UTC)[reply]

Comment: I think that Option 7/8 could be implemented on redirect pages even if another option (my current vote is Option 4/2a) is selected, similar to how Template:R from emoji is currently implemented. Enix150 (talk) 18:13, 5 December 2023 (UTC)[reply]

Recap[edit]

Maybe time for a recap to consider how a new proposal might be written?

• Option 1: IMHO barely helps our readers as just finding the emoji in question on those pages is difficult and information on hover isn't accessible, so volunteers would be required to make different pages.
• Option 2a: essentially redundant to option 4.
• Option 2b: RfD outcomes are against deletion in general.
• Option 3: status quo.
• Option 4: okay.
• Option 5: RfD outcomes are against deletion in general.
• Option 6: essentially a subset of option 7.
• Option 7: okay.
• Option 8: not getting much support.

So I'd suggest a new proposal with options 4, 7 and "status quo/do nothing". And even option 4 is kind of a subset of option 7 as the template has an "article" parameter. @Thryduulf, any thoughts on that? The way I see it, a proposal that says "option 7 or status quo and btw flags not included because technical reasons" would probably have the best chance of passing as it's a simple binary choice. — Alexis Jazz (talk or ping me) 17:14, 2 December 2023 (UTC)[reply]

The issue with option 7 is that consensuses at RfD are almost exclusively option 4 (which is why I wrote it). The only recent no consensuses have been disagreement about what target is the best, not about whether to keep, retarget or delete. Thryduulf (talk) 20:25, 2 December 2023 (UTC)[reply]

This just confuses me. — Alexis Jazz (talk or ping me) 21:18, 2 December 2023 (UTC)[reply]

There have been consensuses in almost every past RfD discussion: 🤭, 👩‍💻, 🛋️, ⏫/⏬, 🫸/🫷, 🤪, 🙀, 👯‍♂️, 🫥, 👾, 🧑‍🦳, 👏, 💨, 😶‍🌫, 🤗, 😬, 🏚️, ☄️, 🏴󠁭󠁭󠀱󠀶󠁿, & 🔥. I think Thyduulf is pointing out that in some of the most recent decisions there has been no consensus on where to retarget the emoji (💁‍♂️/💁/💁‍♀️, 🫗, & 🔞), but none of the discussions have ended in the decision to delete. Enix150 (talk) 21:52, 2 December 2023 (UTC)[reply]

Yes, this. When there has been a consensus it's always been to do what option 4 says to do. Thryduulf (talk) 22:05, 2 December 2023 (UTC)[reply]

Option 7 isn't delete either, and it automatically provides a link to the article with the same title as the Unicode description, or a different article if the article= parameter is passed. And option 7 didn't exist before November 18 so nobody could vote for that anyway. — Alexis Jazz (talk or ping me) 22:13, 2 December 2023 (UTC)[reply]

Consensuses or consensi? Edward-Woodrow (talk) 23:02, 2 December 2023 (UTC)[reply]

I actually had this same thought! Only wikt:consensuses has an English entry though; wikt:consensi is just an Italian/Latin entry. Enix150 (talk) 18:13, 3 December 2023 (UTC)[reply]

Option 4 then is more of the status quo (I'd actually say it's 2a, I haven't seen DABs used, but I digress). I don't think looking at previous consensus is much help here, because this discussion is more to set the status quo, and there are options that have never been considered prior to this RFC. I personally have voted for what 2a/4 would end up giving many times at RFD, but I prefer option 7 to either. The main reason option 7 has never been the result of an RFD is because it wasn't considered until this discussion. Skarmory (talk • contribs) 07:30, 3 December 2023 (UTC)[reply]

Yeah. For me, at least, part of the reason why I've been keeping out of RfD emoji discussions is because of my dislike for anything but something along the lines of option 7 in the knowledge that without a proper discussion on 7's merits an in-betweeny article/redirect/dabpage for an emojo would never gain consensus, not because I don't like it. (So I'm glad it's been brought up as an option!) J947 ‡ ^edits 10:06, 3 December 2023 (UTC)[reply]

Support for a new super-serious, I mean it this time, final vote proposal. I think we've exhausted all possible options, received any views possible, and spilled enough ink for any policy proposal. In summarizing the above, I agree that the list options aren't a great choice right now as nothing is ready. I also agree with the above that 4 is the status quo. I think you could just have a clean proposal that is: Do you agree with replacing all emoji redirects^[a] with a template that describes the emoji and provides wiki-links and off-site links? where the !oppose vote is status quo. microbiologyMarcus ^{(petri dish·growths)} 16:34, 4 December 2023 (UTC) microbiologyMarcus ^{(petri dish·growths)} 16:34, 4 December 2023 (UTC)[reply]

Support that question. Given that option 4 is the status quo, and the template fulfills the same purpose as option 1, I think that RfC could actually get something done. Cremastra (talk) 16:36, 4 December 2023 (UTC)[reply]

Option 4 might be the closest of any of the real options to the status quo, but Option 3 is still the actual status quo. That is, if we reach no consensus here, adding the verbiage behind Option 4 is not the right thing to do (because there may not be a consensus that Option 4 is actually an accurate reflection of the status quo); instead, everything should remain as-is, which is Option 3. -- King of ♥ ♦ ♣ ♠ 05:54, 5 December 2023 (UTC)[reply]

That's a valid point, very technical on the semantics, and I had gotten mixed up in the shorthand of everything. Given that, do you think a vote on the above would be appropriate? microbiologyMarcus ^{(petri dish·growths)} 18:03, 5 December 2023 (UTC)[reply]

MicrobiologyMarcus, draft: User:Alexis Reggae/Emoji proposal — Alexis Jazz (talk or ping me) 20:37, 5 December 2023 (UTC)[reply]

Well, I see this as a surprisingly well-written proposal. But I seriously pray that this is the last and final RfC on emoji redirects. The 1st and 2nd (this one) both failed because of the same reason; they derailed when some of the options were reorganized, stricken, and combined; this caused confusion and the only consensus to be made at the end was a call for a new clean RfC without presupposed options. After the 3rd, this should be done. Finished. Ended. Zero, zip, zilch, nada. (I like to put emphasis on things) The 🏎 Corvette 🏍 ZR1^{(The Garage)} 00:05, 6 December 2023 (UTC)[reply]

@The Corvette ZR1: I agree, hopefully a combination of time (let everyone cool down from two quick RfC's that people felt very strongly about, while the next one gets perfectly drafted) and a simplified option ("listen, this seems to be a solution to everyone's prior concerns and is easy to implement in mainspace as a template") that received an arguable plurality of the votes during the prior RfC here, is the best solution to achieving consensus, and if that doesn't work, I don't think anything would. microbiologyMarcus ^{(petri dish·growths)} 19:46, 7 December 2023 (UTC)[reply]

Yeah, hopefully this will work. I feel very strongly about the 3rd RfC, considering it's a support/oppose, which means we pretty much solve the problems caused by the 1st and 2nd RfC's. But if the 3rd fails or ends with no clear winner, we stick with the status quo. But seriously, thank you Marcus for taking the tribulation to make this. . The 🏎 Corvette 🏍 ZR1^{(The Garage)} 20:18, 7 December 2023 (UTC)[reply]

• If I hadn't voted in the first RfC, I'd close this as no consensus. I understand it is a rite of passage to craft a poorly done RFC, from which one may learn a great deal. I've crafted my share of bad RFCs. But twice in a row? Come on. How did WP:RFCBEFORE get ignored twice?? Somehow I don't think a third RfC is going to magically reach consensus, when the first two each had like eight options. Maybe that should have been the red flag: there were so many different proposals, that no one could possibly receive consensus. I think this RFC has revealed a common flaw in RFC drafting: attempting to cover every possible conformation of the given elements. But the VP is not a chemistry exam question. Proposing an obviously unworkable or unfavorable solution just complicates things. If there is to be a third RFC, it needs to be a runoff between the two or maybe three top options identified here, and done by a veteran RfC drafter. CaptainEek ^{Edits Ho Cap'n!}⚓ 01:35, 6 December 2023 (UTC)[reply]
  • CaptainEek, so how do you feel about my draft for option 7? It seems to have a chance, looking at the votes after option 7 was introduced here. The only other option that IMHO has a chance is the status quo (which options 2a/3/4 represent, more or less), which can be voted for by opposing in the drafted proposal. — Alexis Jazz (talk or ping me) 02:43, 6 December 2023 (UTC)[reply]

    @Alexis Jazz What do you mean "how do I feel"? Do I support option 7? Do I think it should be the run-off option? Do I think it is well crafted as an RfC? CaptainEek ^{Edits Ho Cap'n!}⚓ 19:30, 7 December 2023 (UTC)[reply]

    @CaptainEek: I know Alexis Jazz has had to step away for a wikibreak but I would be curious about how well you think it is crafted/what your suggestions would be? Also noting the ongoing improvments to the template on the talk page microbiologyMarcus ^{(petri dish·growths)} 01:02, 9 December 2023 (UTC)[reply]

  @CaptainEek: I agree that it is clear there is no consensus on this page, and with your final point that any future option should be a runoff between an option or status quo. Everything else, however, is very unnecessary—I strongly disagree with your assessment of the creation of the RfC. Issues regarding the sheer number of possibilities have been addressed and raised above, your analysis doesn't add anything new to that regard. And in your complaint about starting a second RfC, what you failed to see was that the reason that this one was created was because of the reshuffling of the options on the previous RfC resulted in a great deal of editors calling for the creation of a new discussion.

  The fact that there has been so much added to this RfC is a sign that many people have a strong opinion about these. Proposals on the WP:VPR page currently are closed for a lack of engagment. Without listing the sheer number of RfD discussions, the amount of suggestions and otherwise good-faith arguments on this page show that people are invested with the outcome of this discussion. I'm sorry if you think consensus-building is messy, but it's a part of the project. microbiologyMarcus ^{(petri dish·growths)} 19:03, 7 December 2023 (UTC)[reply]

  @MicrobiologyMarcus In hindsight, I realize my comment came off rather mean, which I didn't intend. I'm sorry about that. I was trying to point out a teachable moment, in that RfC design is a rather tricky thing, and I was disappointed that the second RfC here also ran into problems in that numerous options were added after it began. But I guess that was all rather ancillary to the ultimate issue, which I see we agree on, in that the next RfC should be a run off. I appreciate you stepping up the plate on this RfC, and hope this all gets resolved rather soon. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:28, 7 December 2023 (UTC)[reply]

  @CaptainEek: thank you, I agree that this was a messy RfC but I do think progress is being made. Personally, I don't think it's an issue that other options were added after if began, without them, we wouldn't have the template suggestions that seemed to pick up support in the later part of the RfC that's now grown into Alexis Jazz's RfC draft. It seems to be more thought is being put into that one, and we're learning from our mistakes. Hopefully the next one is a clean and smooth-sailing RfC, though I'm happy to pass the torch and let someone else start the RfC—I can appreciate that I'm still green in learning all the ways the backend and policy is conducted on the project. I look forward to working with you in the future. Cheers, microbiologyMarcus ^{(petri dish·growths)} 19:40, 7 December 2023 (UTC)[reply]

• Just noting, to avoid any duplication of effort, that I intend to close this tonight or tomorrow. -- Tamzin^{[cetacean needed]} (they|xe|she) 01:39, 28 December 2023 (UTC)[reply]