Template talk:Essay

  1. Home
  2. Wiki

Categorisation and DEFAULTSORT

[edit]

Is there any way that this template can be modified to recognise the use of {{DEFAULTSORT}}, and to sort essays into the relevant category appropriately? To take this userspace essay as an example, I added the defaultsort magic word to negate the impact of the quotation mark at the start of the title on sorting; but (I’m guessing) as this template uses {{SUBPAGENAME}}, the default sort key seems to be being overridden when I look in Category:User essays.

Apologies if I’m missing something! Best, user:A smart kittenmeow 13:41, 20 September 2023 (UTC)[reply]

Probably not technically feasible. But see next subtopic.  — SMcCandlish ☏ ¢ 😼  12:27, 10 December 2023 (UTC)[reply]

Alternative: category sort string

[edit]

The way to fix this is to support adding a category sort string. In bare category markup, this looks like [[Category:Books about foobar|Bazquux, The]].

  • Using a {{!}} escape trick should work, as it does in, e.g., {{Distinguish|Plus and minus signs#Minus sign{{!}}Minus sign}} to produce link output of [[Plus and minus signs#Minus sign|Minus sign]].  But when you do {{Essay|cat=Category:User essays on categorization{{!}}Over-categorisation}} to produce cat. link output of [[Category:User essays on categorization|Over-categorisation]],  this fails for some reason, and the literal string Category:User essays on categorization|Over-categorisation appears in the rendered page text instead. I'm not sure why this is happening or what the fix is.
  • If for some reason the above problem is not soluble, then the next best thing would be to add a |sort= parameter that would take a value like |sort=Over-categorisation.

 — SMcCandlish ☏ ¢ 😼  12:39, 10 December 2023 (UTC)[reply]

Shortcut index

[edit]

As of now, the shortcut index just says "SHO:RTCUT". That is a red link, and is not likely to redirect to this page as it is not relevant. Can someone help change this and make a proper list of shortcuts? Thank you! 2003 LN6 06:35, 15 February 2024 (UTC)[reply]

Template-protected edit request on 2 June 2025

[edit]

Can some admin or template editor remove the redlinked shortcut and place some another shortcut in its place? I don't think redlinked shortcuts should be visible. Thank you. Yelps ᘛ⁠⁐̤⁠ᕐ⁠ᐷ critique me 08:36, 2 June 2025 (UTC)[reply]

 Done in Special:Diff/1293544043. —⁠andrybak (talk) 08:41, 2 June 2025 (UTC)[reply]

Icon

[edit]

I think this icon should be updated to match the one which is already being used for {{bca}}:

This icon is better in several ways: firstly, it's cleaner and clearer. The lines of text are easily recognisable. The pencil is also larger and more towards the middle of the page, which is also great because it allows the small upside-down warning sign in {{humorous essay}} to be much more visible, as it's currently at the very bottom and very small. The colours are also more nice and in general this icon isn't cluttered with unnecesssary stuff, like the holes in page on the left side.

FaviFake (talk) 15:01, 30 September 2025 (UTC)[reply]

 Done - lets try it out. If concerns raised will restore till ....if need be...a wider talk. Moxy🍁 15:31, 30 September 2025 (UTC)[reply]
Thanks Moxy. I got to work and also created File:Wikipedia_Humorous_essay.svg for {{humorous essay}}, so now they're both updated. The new "humorous essay" essay image also looks much better and is also more clearly about humour.
ㅤ ㅤ
However, their widths are different, so could you kindly change the size of the image in {{Essay}} from 30px to 40px, so that it's similar to the old size, and matches {{humorous essay}}? You can see the difference it makes in the two examples in my first message above. Thanks for the collaboration. FaviFake (talk) 16:33, 30 September 2025 (UTC)[reply]
 Done Moxy🍁 16:38, 30 September 2025 (UTC)[reply]
Neutral I would have preferred a darker border or higher contrast between the icon and the mbox background. 173.206.37.177 (talk) 23:06, 30 September 2025 (UTC)[reply]
@Moxy Per WP:BRD, could you please revert this change? I'm contesting it on the basis that community consensus is required. A lengthy discussion was recently held at the Village Pump (spanning about two months) regarding flaticons and Codex, where consensus was reached against altering the proposed icons, and there was broad disapproval of flaticons in general. Given that recent consensus on a directly related matter was opposed to such changes, I believe this edit clearly requires prior consensus. waddie96 ★ (talk) 09:18, 1 October 2025 (UTC)[reply]
Done - Moxy🍁 12:09, 1 October 2025 (UTC)[reply]
Waddie96 Thanks for partecipating! I indeed created this discussion to judge consensus. Do you oppose this proposal for other reasons? FaviFake (talk) 14:50, 1 October 2025 (UTC)[reply]
Actually, now that you pointed it out, i agree! Would you prefer it over the current icon if the sheet were as distinct from the mbox background as it is currently? FaviFake (talk) 14:57, 1 October 2025 (UTC)[reply]
If the border from the old icon were added, I would weakly support the new icon, whose 5 thicker lines are easier to see on mobile. 173.206.37.177 (talk) 19:22, 1 October 2025 (UTC)[reply]

Template-protected edit request on 30 September 2025

[edit]
−
[[File:Emoji u1f4dd.svg|40px|link=|alt=]]
+
[[File:Emoji u1f4dd.svg|40px|alt=icon]]

@Moxy: MOS:PDI The new icon is not public domain. 173.206.37.177 (talk) 23:08, 30 September 2025 (UTC)[reply]

 DoneMoxy🍁 03:41, 1 October 2025 (UTC)[reply]
And just a pointer for the future: as a screen reader user, there is nothing more frustrating than encountering this kind of markup. It’s completely useless to us. What my screen reader reads out (before the text, since that’s where it sits in the DOM) is something like:
Unlabelled image, unlabelled image, “icon” (in a really loud, staccato tone). To get missing image descriptions [etc…]
That’s the equivalent of developers naming a search box “search”, giving it the role “search”, an ARIA-label “search the archives”, and the placeholder “search the archives”—resulting in the screen reader announcing:
Search box, you are on an input box, search, search, search the archives…
I think you can see the problem. For us, the ARIA/DOM is our CSS—it’s all we “see”, just as you see the styling with CSS. Imagine if I went and made all the text in an Mbox bright blue: that’s how intrusive and distracting “alt=icon” is when it’s read out every time.
If you want to suppress that noise, the best practice would be to wrap it in something like <span aria-hidden=“true”>...</span>, so the redundant information doesn’t get announced at all.
Please kindly enact that change too.
−
[[File:Emoji u1f4dd.svg|40px|alt=icon]]
+
<span aria-hidden="true">[[File:Emoji u1f4dd.svg|40px|alt=icon]]</span>
waddie96 ★ (talk) 09:29, 1 October 2025 (UTC)[reply]
This is directly at odd with the change implemented in Template talk:Essay#Template-protected edit request on 2 June 2025. Pinging @SWinxy and @HouseBlaster as participants in that discussion.
I think the parameters |link=|alt= should remain empty per MOS:BLANKALT. FaviFake (talk) 15:00, 1 October 2025 (UTC)[reply]
Not seeing where I commented in that edit request? But it does sound an awful lot like an edit I would make... HouseBlaster (talk • he/they) 15:05, 1 October 2025 (UTC)[reply]
it seems i copied the wrong request. sorry for the ping. the editors i meant to ping were Andrybak and Yelps FaviFake (talk) 15:13, 1 October 2025 (UTC)[reply]
Yes as mentioned, I'm more phased about the aria-hidden on all icons and figures/images/visuals that provide only aesthetic benefit (not to forego that it is still an important component of usability). But if I had my way, I'd make alt and link prohibited onwiki unless for linking by requirement in license, as is evidenced by the above examples, it's terribly annoying for something the coder just sets and forgets (some times paragraphs long to describe a 5-pointed yellow star, or just to ICON) and for eternity afterwards we hear the melody. I wish we all think hard before we consider using ARIA as bad ARIA is worse than no ARIA, but we also take into consideration when we should omit implicit elements like alt too. waddie96 ★ (talk) 16:28, 1 October 2025 (UTC)[reply]
Sorry I undid your revert at {{bot use warning}} before seeing this.
You quoted MOS:BLANKALT. In that shortcut, it says:

For CC BY-SA, GFDL, or similarly licensed images, blank |alt= and |link= attributes should not be used. It is Wikipedia's policy to link those images for attribution, and linked images must have a non-blank alt attribute to prevent empty links, which result in confusing announcements in screen readers. When a blank alt attribute is desired, consider replacing CC BY-SA images with public domain equivalents. Otherwise, use a brief alt attribute (such as |alt=photograph, |alt=painting, |alt=sculpture, or |alt=icon) to minimize the confusing text.

@Waddie96: I thought the bigger problem was empty links, which result in confusing announcements in screen readers. Do we want to move this discussion to Wikipedia talk:Manual of Style/Accessibility/Alternative text for images? 173.206.37.177 (talk) 19:11, 1 October 2025 (UTC)[reply]