Template talk:Portal

This is the talk page for discussing improvements to the Portal template.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives (index): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10: 9 months

Template:Portal is permanently protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit protected}} to notify an administrator to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

To help centralize discussions and keep related topics together, the following pages redirect here:

Centralized discussions

Template-protected edit request on 6 May 2025

This edit request to Module:Portal/images/p has been answered. Set the |answered= parameter to no to reactivate your request.

File:A coloured voting box with South Korea gorvernment emblem.svg|thumb|A yellow coloured voting box with South Korea government emblem.

May i add this image?

it used at Politics of South Korea portal]]

= "A coloured voting box with South Korea gorvernment emblem.svg|link=|alt=icon"

Whatback11 (talk) 10:07, 6 May 2025 (UTC)

It would look like this:

It may be a bit too busy to be comprehensible at 28px? — hike395 (talk) 10:16, 6 May 2025 (UTC)

Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. P.I. Ellsworth , ed. ^{put'er there} 18:36, 6 May 2025 (UTC)

Problems with dark mode and icons

When viewing Template:Education in the U.S., there is a black icon for the Education portal, which in dark mode is very hard to see on a dark grey background. Normally I'd just set "class=skin-invert-image" on the image, which would make it white when viewed in dark mode, but I don't see a way to do that with the portal template system. Perhaps images that need this should be set in the image database and the module should handle that? -- Beland (talk) 18:56, 21 May 2025 (UTC)

@Beland: There is a way to do it with the portal template system, by adding the class to the image specification at Module:Portal/images/e, see here. I don't use dark mode, can you check to see if this worked? — hike395 (talk) 09:20, 24 May 2025 (UTC)

Oops, it doesn't work because of a limitation in Module:Portal-inline. I'll think about how to fix this. — hike395 (talk) 09:32, 24 May 2025 (UTC)

Edit request 24 May 2025

This edit request to Module:Portal has been answered. Set the |answered= parameter to no to reactivate your request.

Action requested: Please copy Module:Portal/sandbox to Module:Portal

Description of suggested change: Currently, portal icons are not responsive to dark mode, which is a serious problem for portals like Education portal.

A good way to fix this is to allow editors to add class=skin-invert-image to the filespec in Module:Portal/images (see, e.g., ). However, the current code in Module:Portal interferes with this, because it appends class=noviewer to the filespec which overrides any class specified in Module:Portal/images.

The fix is contained in the new function noviewer(), which examines the filespec. If there is already a class specified, it adds "noviewer" to the list of classes. Otherwise, it just appends class=skin-invert-image. I added this to both p._portal() and p._demo().

In addition, I decided to centralize the handling of image classes here in Module:Portal. Thus, I added noviewer() to p._image(), and will edit Module:Portal-inline and Module:Portal bar appropriately if this change gets approved.

The change is tested in Template:Portal/testcases and Template:Portal image/testcases, where the behavior is as-expected.

Pinging @Pppery for their attention. Thanks for considering!

Diff: compare Module:Portal to Module:Portal/sandbox — hike395 (talk) 15:11, 24 May 2025 (UTC)

Done * Pppery * _{it has begun...} 17:36, 24 May 2025 (UTC)

@Pppery, @Hike395, I've reverted the change because it was rendering an error (Lua error in Module:Portal at line 211: assign to undeclared variable 'hasClass'.) in articles, including Chinese characters and Rodrigo Duterte (these are just some of the pages I looked at). I have no thoughts on the change itself, but I've undone the it pending a fix, since this is a very high-profile module. Feel free to reinstate it once the issue is solved. Thanks, Giraffer (talk) 17:57, 24 May 2025 (UTC)

The source of the problem was that Module:Portal bar calls this module in strict mode, which broken, and wasn't tested by either me or Hike395. Reapplied a version that doesn't break that template, hope it now works. * Pppery * _{it has begun...} 18:07, 24 May 2025 (UTC)

Thanks so much, Pppery. It appears to work now: errors are being fixed as the pages are being purged. — hike395 (talk) 18:24, 24 May 2025 (UTC)

Template-protected edit request on 30 July 2025

This edit request to Module:Portal/images/s has been answered. Set the |answered= parameter to no to reactivate your request.

I request we add = "Sf-userbox.png|alt=icon", as all "speculative fiction/subtopic" portals all have their images shared with their shorter subtopic-only portal names. IAmNMFlores (talk) 20:11, 30 July 2025 (UTC)

Done * Pppery * _{it has begun...} 16:13, 2 August 2025 (UTC)

Template-protected edit request on 31 July 2025

This edit request to Module:Portal/images/l has been answered. Set the |answered= parameter to no to reactivate your request.

Action requested: Replace image for Libertarianism Portal with vector version of diagram

Description of suggested change: Updating the imgage line for Libertarianism on Module:Portal/images/l to read "Libertarianism-groups-diagram.svg" (rather than the current "Libertarianism-groups-diagram.png"), & reference the newly added vector diagram. Bpmcneilly (talk) 19:24, 1 August 2025 (UTC)

Done * Pppery * _{it has begun...} 16:12, 2 August 2025 (UTC)

Template-protected edit request on 21 August 2025

This edit request to Module:Portal/images/e has been answered. Set the |answered= parameter to no to reactivate your request.

The border is unnecessary, as the icon is not even in a rectangular shape, and the visual identity of the contest has been changed, therefore the icon should be updated to reflect that — IмSтevan ^talk 21:36, 21 August 2025 (UTC)

Done, although not exactly as you described, see Module:Portal/images/e. — hike395 (talk) 05:42, 22 August 2025 (UTC)

It was a typo, sorry 'bout that — IмSтevan ^talk 08:14, 22 August 2025 (UTC)

Protected edit request on 23 August 2025

This edit request to Module:Portal/images/i has been answered. Set the |answered= parameter to no to reactivate your request.

For the portal of Los Angeles (which redirects to Greater Los Angeles), I would like the image snippet/preview of the template to be replaced with the city's flag: This is because of the NYC portal having their city flag, and I think it'd be more appealing than a shrunken image of a city, that to me (in my opinion) looks like Tokyo. ѕιη¢єяєℓу ƒяσм, ᗰOᗪ ᑕᖇEᗩTOᖇ 🏡 🗨 📝 17:18, 23 August 2025 (UTC) You can find the context here: Module:Portal/images/l — Preceding unsigned comment added by Mod creator (talk • contribs) 17:19, 23 August 2025 (UTC)

Not done for now --- could you get consensus at WT:WikiProject California first? — hike395 (talk) 05:00, 24 August 2025 (UTC)

Edit request 11 September 2025

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change: Module:Portal/images/e Remove outdated CSS class skin-invert-image, remove ARIA-labels (i.e. alt=icon) and every use of alt in all Module:Portal/images/*** please, that are definitely not needed please. I use a screen reader, and I can assure you we do not need to hear "IMAGE - IMAGE ICON." then only the important "LINK - EXAMPLE PORTAL." when we go past those icons.

waddie96 ★ (talk) 22:56, 11 September 2025 (UTC)

You've asked for two changes for all portal icons:

Remove skin-invert-image. This is not obsolete. This is the way that sighted readers who use dark mode have visible icons. We should keep this.
Remove alt=icon. This is a big enough change where we should get consensus. I'll start a discussion at Wikipedia talk:WikiProject Accessibility.

— hike395 (talk) 00:13, 12 September 2025 (UTC)

Is the guidance at MOS:BLANKALT to use a dummy description when a link is needed for attribution purposes outdated/in dispute? Otherwise I believe manual checking would be required before removing the alt texts. Trialpears (talk) 02:05, 12 September 2025 (UTC)

Not that I'm aware of (and I'm also a screen reader user). If the image must be linked it needs an alt text, otherwise the screen reader user would hear the file name, which is much more verbose than "Portal icon" and the like. Graham87 (talk) 04:23, 12 September 2025 (UTC)

@Graham87: I'm not a screen reader user. Is there a difference between a missing alt and a blank alt? I would have thought for a missing alt, you would hear the file name. More specifically, are the following two images equivalent?

Thanks for any information. — hike395 (talk) 04:54, 12 September 2025 (UTC)

@Hike395: There does turn out to be a difference, but neither of them are spoken in an ideal way. I'll give examples with the two main Windows screen readers, as they're what I have easiest access to. In JAWS, the first one is spoken as "Wiki/File:Flag_of_Edinburgh" and the second one with the full image filename (along with the thumbnail size). On NVDA, the first one reads as "File:Flag_of_Edinburgh" and the second one says "no description available". Graham87 (talk) 06:30, 12 September 2025 (UTC)

Thanks for checking. It sounds like leaving alt=flag in this case would be preferable. — hike395 (talk) 06:32, 12 September 2025 (UTC)

A big difference here is whether or not the link is suppressed as well. If you suppress the link, THEN you can also remove the alt for decorative images. If you do not suppress the link but remove the alt, then the img doesn't get ignored by screenreader, as it still needs a label for the link. It will then use the filename for the link. —TheDJ (talk • contribs) 08:26, 12 September 2025 (UTC)

Sorry guys I didn't subscribe to the talk.

This is not obsolete.: skin-invert is now used, I haven't seen skin-invert-image used in a long time?
Screenreader tech mostly is dumb and inconsistent, you can read up about it but you can take 10 readers and they'll all interpret the implicit and explicit semantics of HTML differently because until ARIA there was no standard, and generally developers have used HTML without a care for semantics, the focus is obviously on visual appearance.
To illustrate my point we can take a simple searchbox for example. The sitewide inputbox I've been fighting for years for the form that surrounds/nests it to be of the type="search" as currently its semantics don't give it that, so the inputbox isn't labelled, the placeholder text is seen as span text, the button doesn't operate like a search button but a button with no label too, i.e. it jsut says Form. No label.. Text. No label.. Button. No label...
To illustrate how VoiceOver on macOS interpretes an image which may be slightly different to the others, mostly it's how much detail will they skip or how much will they tell you is 'missing'. Mostly this can be configured in settings, but mine is on default for testing like this. VoiceOver will read an image in a figure element like this:

] → Unlabelled image. Unlabelled image.
] → Unlabelled image. Unlabelled image. <caption attribute>.. For example, ] → Unlabelled image. Unlabelled image. Yellow man..
] → Link, image, Banana peel. Yellow man.
] → Link. File:Example.svg. <caption attribute>
] → Link. File:Example.svg.
] → ––
<span aria-hidden="true">]</span> → –– Nothing. Skips as does not even know it's there. Preferred for all icons/images for decorative purposes. aria-hidden is equivalent to display="none" but the later doesn't show it visually either, but jsut so you aware.

Is there a difference between a missing alt and a blank alt? Yes, massive difference in screen readers, if both alt= and link= blank/null/nil it means the semantic equivalent to what aria-hidden="true" means today, i.e. unequivocally ignore me I am an icon/image for decorative purposes, ignore me. Both need to be declared null though, or at least link=.

waddie96 ★ (talk) 10:27, 12 September 2025 (UTC)

Given that there's policy on the topic and the discussion above I consider removing the alt text from any image without attribution requirements to have consensus. Actually implementing this seems like a chore and especially annoying to do with edit requests given the number of pages. waddie96 if you still want to make this change I would be happy to give you a week of template editor perms for this purpose exclusively. Any other change would go through edit requests as usual. Trialpears (talk) 09:45, 12 September 2025 (UTC)

That'd be great! To be transparent though, I did apply for the template editor right a couple days ago; but due to me having 5 or less actioned edit requests, the reviewer was hesitant. I only saw their reply literally right now, so I've responsed with the hopes they'll reconsider. waddie96 ★ (talk) 10:50, 12 September 2025 (UTC)

@Trialpears and Waddie96: Wait, hold on. Don't do a massive edit. Waddie96 pointed out the easiest solution, above. We should change Module:Portal to wrap a span with aria-hidden=truearound all portal icons. That should solve the problem in a standard way for all (?) screen readers. I'll test it in the sandbox, and perhaps an admin can promote the fix. — hike395 (talk) 11:48, 12 September 2025 (UTC)

Yes, the span aria-hidden=true is the easiest and best solution :-) I didn't suggest it in the first place since it usually comes with stark resistance since most don't think for a moment how irritating all the verbosity and clutter icons/decorative elements bring for assistive tech users, but it is the best solution! You can keep the |alt= and |link= then since it'll hide that from the accessibility tree anyway! Win, win for both. I'll mention this as the first option in future. waddie96 ★ (talk) 11:53, 12 September 2025 (UTC)

Hi all,

Sorry I'm just chiming in here - just happened to notice this request as I had an unrelated template edit request. Is there any way (in addition to adding aria-hidden="true") that we can append some additional HTML attributes to the span?

Currently, the solution of adding aria-hidden="true" will prevent the accessible names from being read out, but these links are still in the tab order. So, if a user places focus on them, the screen reader won't know what to announce these links as (because the semantics explicitly say to remove the span & its children from the DOM).

If we could add an inert attribute to the span as well, this should remove the possibility of any link that is a child of the span from getting keyboard focus. Just for reference, here's a the . Bpmcneilly (talk) 05:46, 16 September 2025 (UTC)

@Bpmcneilly Hi, yeh, the idea is to remove them from the accessibility DOM, but I assume the alt is wanting to be kept so that the tooltip still works for visual readers or because it's just way easier to set aria-hidden than to go through every photo's data and remove the alt?

However, VoiceOver never gave it keyboard focus for me, I assume because it's hidden from the accessibility DOM. When you tested this, were you actually using a screen reader, because if not, the keyboard focus would still work... Only when you are using a screen reader, will the keyboard focus be removed... waddie96 ★ (talk) 14:15, 16 September 2025 (UTC)

That's interesting to hear about VO. I don't typically test with it / on a Mac, so I'm definitely less familiar with it, but that's surprising to hear. On Windows (with JAWS & NVDA), that definitely does not happen. In general, the accessibility DOM & the focus order of a browser aren't the same (again, on Windows, where I do most of my testing), so something can be hidden from ATs, but still receive keyboard focus. That's usually why the a11y test suites have some sort of automated rule flagging code like we're discussing.

This causes the discrepancy I was trying to describe in my initial post because then screen readers know something shouldn't be exposed, but what exactly to convey gets confusing. In the past, NVDA would just announce "blank" when things like this receive focus, but doing testing right now I got the same results for NVDA & JAWS (the only difference depended on browser). In Chrome, the links got focus but the screen readers gave me just the alt (without the role) & in Firefox, they also got focus but announced the name of the portal link next to the image (e.g. Edinburgh portal to use the samples below). Bpmcneilly (talk) 14:54, 16 September 2025 (UTC)

I didn't even expect that to happen, because you'd think that doesn't woerk l;ike that., Likely because VO is intermeshed very well because it's software that's running with hardware that have the same developers waddie96 ★ (talk) 18:25, 16 September 2025 (UTC)

Well same owner or whatever the word is waddie96 ★ (talk) 18:25, 16 September 2025 (UTC)

And inert is very irritating lol, because the class=noviewer also adds inert, and irritatingly the pointer doesn't set to point so you don't even know you sitting on a link but if you key press/mouse click, it loads the file's/image's file page.... so don't use inert waddie96 ★ (talk) 14:17, 16 September 2025 (UTC)

Ok, so if we can't use inert... To solve the problem I was mentioning above, the best solution I can think of would be to set "tabindex=-1" on all of the links surrounding icons. Is that doable? Bpmcneilly (talk) 15:02, 16 September 2025 (UTC)

I have no clue then, disregard my comment because I haven't had to use this before, could you possibly edit the sandbox the way you want it implemented then we can check out the result? waddie96 ★ (talk) 18:26, 16 September 2025 (UTC)

I won't be able to review though because I don't have a Windows machine or a VM either waddie96 ★ (talk) 18:26, 16 September 2025 (UTC)

@Waddie96, @Hike395 - I've been trying to parse these for the past few days & unfortunately I'm just not familiar with Lua or WM templates, so I can't find where the actual HTML links are generated here. The actual a element itself would need to have the tabindex attribute set on it to ensure the link isn't accidentally kept in the tab order.

If either of you could help point me to where those links are actually generated, I may be able to update the sandbox myself.

Doing this test though, is there a real use for these links to the portal images? Until I dove into the template, I didn't realize that the links around the images didn't take users to the portal location, but to the file itself. One way to sidestep the keyboard focus problem would be to just remove the few portals that use these links at all. Just my 2 cents. Bpmcneilly (talk) 01:14, 19 September 2025 (UTC)

The current discussion was to remove the images from the accessibility API. My suggestion to remove alt= and link= sometimes comes with mixed reviews, either way the entire image has to be wrapped with a span tag that has the aria-hidden=true attribute for it to be hidden from the API. Regarding the link/alt that would require input from the others in the discussion, because whilst I agree with removing them 100001% it is a bit controversial so requires some consensus.

Regarding tabindex, accessibility API automatically assigns the <a> element a tabindex=0 by default, unless you want to remove the portal links from the tabindex, or increase their priority, which neither is called for in this situation. Could you be clearer what you mean? waddie96 ★ (talk) 01:43, 19 September 2025 (UTC)

But regarding where the portal link is generated in the Module:Portal:

local link = string.format(']',
portal, portal, args.addBreak and '<br />' or ' ')

In wikitext (a custom/unique MediaWiki DOM based on HTML and RDFa but not entirely the same), links are made like ] to generate the <a>...</a> HTML after it's parsed by mw:Parsoid, see mw:Parsoid/MediaWiki DOM spec if that peaks your interest. For the image's link, it's made with ] waddie96 ★ (talk) 01:53, 19 September 2025 (UTC)

@Bpmcneilly: Thanks for pointing this out! The image html generation is spread across three modules. Check out my latest edits to Module:Portal/sandbox, Module:Portal bar/sandbox, and Module:Portal-inline/sandbox: you will see the span where I added aria-hidden=true. You can modify those spans to add tabindex. — hike395 (talk) 12:16, 19 September 2025 (UTC)

@Bpmcneilly Before you do, why do you want to modify the ordering of the sequential focus navigation? If negative, it's not focusable, which we would not want for any link, including one to a portal, and there's no need to set a baseline/default since it will automatically be assigned tabindex=0, and lastly there is certainly no indication to increase it to a positive integer because then it'll have focus order preference over every other focusable element on the page it's transcluded onto... Rather the portal template should be placed in a logical sequence, i.e. in the sequence you wish the focus order to be. Manually changing the tabindex is super confusing for assistive tech users. Especially if what is inside the span turns out to not be a link (as may be the case now or in the future) as setting the tabindex forces focus even when it's not needed. waddie96 ★ (talk) 12:42, 19 September 2025 (UTC)

Test cases

I've modified Module:Portal/sandbox, Module:Portal bar/sandbox, and Module:Portal-inline/sandbox to add aria-hidden="true" to a wrapping span. @Graham87 and Waddie96: does the proposed behavior work well for you? — hike395 (talk) 13:11, 12 September 2025 (UTC)

Yes, it does, under both screen readers I tested. Graham87 (talk) 15:18, 12 September 2025 (UTC)

Ah good. Better. But may I just do some edits then I can show you a better way to ARIA label elements? It's preferrable to use aria-labelledby than a static aria-label, if possible. And I'll tweak what else I find and give feedback is that okay? waddie96 ★ (talk) 16:12, 12 September 2025 (UTC)

Yes and I only just finished testing now, I tested on VoiceOver macOS, a quick setup Chrome s-reader called Silktide that was bad application but the portal links still worked great, and it's so much better btw thanks @Hike395 waddie96 ★ (talk) 16:34, 12 September 2025 (UTC)

Thanks for the feedback! Yes, feel free to edit the sandboxes to make the ARIA tags better. — hike395 (talk) 16:52, 12 September 2025 (UTC)

Current behavior

Portal box, icon with link:

Portal box, icon with no link:

Portal bar, two portals, one with link and one without:
Portals:
- Edinburgh
- East Germany
Portal inline, icon with link: Edinburgh portal
Portal inline, icon without link: East Germany portal
Related portals, two portals, one with link and one without:
- Edinburgh
- East Germany

Proposed behavior

Portal box, icon with link:

Portal box, icon with no link:

Portal bar, two portals, one with link and one without:
Portals:
- Edinburgh
- East Germany
Portal inline, icon with link: Edinburgh portal
Portal inline, icon without link: East Germany portal
Related portals, two portals, one with link and one without:
- Edinburgh
- East Germany

Template-protected edit request on 13 September 2025

This edit request to Module:Portal/images/a has been answered. Set the |answered= parameter to no to reactivate your request.

Action requested: Replace image for American Civil War Portal with vector version of image

Description of suggested change: Updating the image line for American Civil War (line 65) on Module:Portal/images/a to read "United_states_confederate_flag_hybrid.svg" (rather than the current "Acw bs 7a.png"), & reference the newly added vector version. Bpmcneilly (talk) 18:28, 13 September 2025 (UTC)

Completed. P.I. Ellsworth , ed. – welcome! – 06:38, 19 September 2025 (UTC)

Image edit request on 29 October 2025

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

On Module:Portal/images/f, there is no more Portal:Franco-Americans, so the line = "Drapeau Franco-Américain.svg|border|alt=icon", can be removed. --Quuxplusone (talk) 19:54, 29 October 2025 (UTC)

Not done This is still in use by Wikipedia:WikiProject Franco-Americans — hike395 (talk) 01:19, 30 October 2025 (UTC)

I was looking at this because I was trying to figure out why {{Portal|Fish|Sharks}} gives one clickable image (the shark) and one not (the fish), and why {{Portal|France|Food}} gives one clickable and indexed image (the food logo) and one neither clickable nor indexed (the flag). I still haven't figured out either of those answers. IMO no portal image should ever be either clickable or indexed. Certainly not indexed. --Quuxplusone (talk) 19:54, 29 October 2025 (UTC)

Linking to File:Greyreefsharksmall2.jpg is required by the the GFDL and CC licenses for that file. Not sure what you mean by indexed. — hike395 (talk) 01:19, 30 October 2025 (UTC)

Edit request 4 November 2025

This edit request to Module:Portal/images/n has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change:

Diff:

on Module:Portal/images/n. זיו「Ziv」 • For love letters and other notes 13:56, 4 November 2025 (UTC)

Done This edit avoids a redirect. — hike395 (talk) 14:17, 4 November 2025 (UTC)

Thank you @Hike395 זיו「Ziv」 • For love letters and other notes 10:25, 6 November 2025 (UTC)

Change 2020s portal icon from brain to Ubuntu 20.04

Please change the 2020s portal icon from brain to Ubuntu 20.04. ~2025-31039-85 (talk) 18:56, 4 November 2025 (UTC)

Image edit request on 7 November 2025

This edit request to Module:Portal/images/p has been answered. Set the |answered= parameter to no to reactivate your request.

The current version of the flag is being replaced with the official version of the Portuguese flag, for instance,Portugal, Template:Country data Portugal. The reason being that File:Flag of Portugal.svg is an outdated rendering of the Portuguese flag, unlike File:Flag of Portugal (official).svg (More info at: Template talk:Country data Portugal) GumballNine1Nine (talk) 22:01, 7 November 2025 (UTC)

Completed. P.I. Ellsworth , ed. – welcome! – 08:39, 8 November 2025 (UTC)

Template-protected edit request on 9 November 2025

This edit request to Module:Portal/images/a has been answered. Set the |answered= parameter to no to reactivate your request.

Hello, I would like to suggest a small but important edit to improve neutrality in the Module:Portal/images/a listing for Abkhazia.

Current entry: = "Flag of Abkhazia.svg",

Proposed change: = "Abkhazia stub.png",

The current flag is politically sensitive, while shape is already used across Wikipedia as a neutral, non-political symbol of Abkhazia. Thank you for considering this small neutrality improvement. BlueHourDusk (talk) 20:47, 9 November 2025 (UTC)

@BlueHourDusk:

Not done for now: please establish a consensus for this alteration before creating an edit request.. Est. 2021 (talk · contribs) 17:39, 11 December 2025 (UTC)

Template Talk:Portal - Location

The Location advice for Template:Portal states that ithin articles, is meant to be placed at the top of the article's See also External links section .. ; just put it below the article text in the place that seems most appropriate (my emphasis).

But that doesn't seem to be general practice with the Wiktionary portal. Wiktionary portal boxes usually seem to

appear within articles' main sections, rather than in end-matter; and

render to the right of the running copy (appearing in the wikitext immediately above the para in which the relevant term is used).

It seems to me the Location advice for portals needs correcting / amplifying or clarifying. (Or am I misunderstanding something?)

- ~2025-32010-21 (talk) 04:36, 16 November 2025 (UTC)

Template:Wiktionary is a sidebox just like Template:Portal, but it doesn't mean that the same rules apply to them. In particular, Template:Wiktionary/doc says: The template may be placed anywhere, such as the External links section, the beginning of the article, or in the article's etymology section if one exists. It may also be placed inline. —⁠andrybak (talk) 20:23, 1 December 2025 (UTC)