Template:Gallery is permanently protected from editing because 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 template-protected}} to notify an administrator or template editor 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.
This is the talk page for discussing improvements to the Gallery template.
This template is within the scope of WikiProject Photography, a collaborative effort to improve the coverage of photography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PhotographyWikipedia:WikiProject PhotographyTemplate:WikiProject PhotographyPhotography
There is a way by wrapping it around a <div class='skin-invert-image'> gallery </div>
The problem is that in this way we can't invert specific images, it is all or nothing. When I was working on some pages, I would split in two galleries with one wrapped around the div, and other not. Sometimes there isn't a good option.
This gallery template works by wraps around the <gallery> core parser extension tag, its a change I wouldn't expect anytime soon, but who knows?
To make it work through this template without a change to that core would require a lot of unconventional code. I have brainstormed and the options would be:
- injecting a CSS for each gallery, and select the pictures to invert using li:nth-child(image order number), probably a lot of work and I'm unsure if it would work.
- a javascript to apply the skin-invert. Probably a big no-no too.
The other option is to add a white background to everything, but it is not ideal either.
The best option I can think of is to implement in Template:Multiple image, it's much easier to be done in that template, and it's quite similar to this gallery.
I also tested to converting a gallery to "Multiple image" in an article and it was not easy. These templates are quite different. So I also checked, and there is an issue already in phabricator:T344784 that we can subscribe and follow. -- Arthurfragoso (talk) 17:22, 5 February 2025 (UTC)[reply]
@Indefatigable and @Synpath, yesterday I got an idea for a workaround: adding some kind of non-visible marker to the filename, caption or alt text. With that I can select with the CSS.
First I tried adding a div around caption with some class, and then I could use a "next-sibling" CSS selector, but wikipedia/mediawiki doesn't allow the css "has()" selector.
I thought to add a # on front of images url to add a code, but <gallery> strips that.
I then thought to add some kind of non-printable character as a code. I could add it to the caption or alt text. The caption, besides it appearing bellow the image, it also appears in <a title=caption>. But if I added to the caption, there would be the risk of users selecting the text to copy, and pasting the non-printable character to other places, including to other captions. That would lead to other images being skin-inverted (bugs).
So using it at the end of the alt text seems to be the option with the least prone to side effects, as those characters are just like spaces " ", and I could not think of better options until phabricator:T344784 is solved. After that the code could be changed to what they provide.
Definitely a clever, working hack that can get fixed in one place rather than many after the underlying extension is updated. A potential problem is that the semantics of the class parameter is misleading as you can't apply any old CSS class. If there are other problems they're not obvious to me, but at least any visual effects would be limited to {{gallery}}'s on the same page as another (limited to the mod-gallery class).
For the article Indefatigable linked, placing image thumbnails into columns and centering would do as a workaround, for example:
{{col-begin|width=auto|style=margin: 0 auto;}}{{col-break}}[[File:220sb.svg|thumb|upright=0.7|center|class=skin-invert-image|NEMA 14-30 and 14-50 receptacles]]{{col-break}}[[File:NEMA 14-30 Dryer Receptacle.jpg|thumb|upright=0.7|center|NEMA 14-30 clothes dryer receptacle and plug]]{{col-break}}[[File:NEMA 14-50 outlet.jpg|thumb|upright=0.7|center|A NEMA 14-50 supplying 12 [[kilowatts|kW]] (9.6 kW sustained) on a 240 V circuit to recharge an [[Electric vehicle|EV]]]]{{col-end}}
A proper gallery implementation would be better, but this is a slightly more flexible way to layout images compared to multiple image ⇌Synpath02:26, 7 February 2025 (UTC)[reply]
The example you showed is great and helpful, at least for when there are few images.
One of the advantages of the gallery is that it nicely adjust the items per row according to the available width of the screen that can be a bit tricky for mobile compatibility.
There is no ideal solution, so I went ahead and I pushed the changes to production.
About the semantics, I can better explain this in the template docs. The good thing is that once the underlining <gallery> gets fixed, the changes to {{gallery}} can be done seemly, so the semantics gets corrected. This, of course, is with the expectation that it would be someday implemented. -- Arthurfragoso (talk) 04:20, 7 February 2025 (UTC)[reply]
@Arthurfragoso: Yeah I was thinking the semantics cuts both ways in that if the parameter was renamed it would have to be edited for each transclusion. Yesterday, I was looking for templates that implemented a flexbox and only found {{Flex columns}} which doesn't give an option to unset its default min-width and didn't think to just search for {{Flexbox}} which works better than what I suggested above:
{{Flexbox|min-width=150px |max-width=180px |padding=2px |style=justify-content: center;
|1=[[File:220sb.svg|thumb|upright=0.7|center|class=skin-invert-image|NEMA 14-30 and 14-50 receptacles]]|2=[[File:NEMA 14-30 Dryer Receptacle.jpg|thumb|upright=0.7|center|NEMA 14-30 clothes dryer receptacle and plug]]|3=[[File:NEMA 14-50 outlet.jpg|thumb|upright=0.7|center|A NEMA 14-50 supplying 12 [[kilowatts|kW]] (9.6 kW sustained) on a 240 V circuit to recharge an [[Electric vehicle|EV]]]]}}
Looking at the brute force template wikitext got me thinking it should be relatively straight-forward to make an alternate gallery option as a Lua module that doesn't rely on the extension tag. Flexbox is kinda purpose-built for this kind of thing. The extension tag doesn't rely on flexbox and that makes sense for browser-compatibility, but flex has been widely supported for about 10 years now. ⇌Synpath15:04, 7 February 2025 (UTC)[reply]
And now I'm seeing {{Gallery items}} which allows you to apply skin-invert-image to single images:
{{Gallery items|width=180
|[[File:220sb.svg|180px|class=skin-invert-image]]|NEMA 14-30 and 14-50 receptacles
|[[File:NEMA 14-30 Dryer Receptacle.jpg|180px]]|NEMA 14-30 clothes dryer receptacle and plug
|[[File:NEMA 14-50 outlet.jpg|180px]]|A NEMA 14-50 supplying 12 [[kilowatts|kW]] (9.6 kW sustained) on a 240 V circuit to recharge an [[Electric vehicle|EV]]}}
I'm pinging the major contributors to this Module.
I noticed the algorithm for this module was quite rigid, and it making many assumptions of image and caption order.
It was counting the number of arguments and making assumptions of how many images the gallery had.
I changed it a bit, so it counts the images by a custom isImage(filename) and get the next non-empty argument to be the caption.
The tricky thing is to identify the images. If File:, Image: and Media: was previously enforced, it would be a bit easier. So what I did was verifying those prefix and if in case it was not present I verify if it ends in an extension of 3 or 4 characters. As there can also be audio and video in the gallery, we would have to keep up with Commons to know and update the existing file extensions. Checking for ".****" seems okay, but there is the risk a caption would be identified as an image if it had a similar ending, but those endings are unlikely in most languages. An option would be to check the cases without the File:, Image: and Media: prefixes and automatically put them in some category, something like: "Category:Pages using gallery without a media prefix"
Sorry to have to revert all the way back. Please continue to experiment in the sandbox based on feedback below and the added testcases. – Jonesey95 (talk) 03:19, 10 February 2025 (UTC)[reply]
@Jonesey95 Hmmm, sorry about that erroneous edit to the doc saying captions don't accept external links when it appears they do in my sandbox, but possibley not on talk pages... like on this talk page in the past the source code for the gallery at the section header titled "Proposal: clarify "user-generated" in MOS:CALLIGRAPHY" is:
{{Gallery| title = Examples of a "digital recreation" and of "stylistic elements which are not present in the original":
| align = center
| footer =| style =| state =| height =| width =| perrow =| mode =| whitebg = no
| noborder = yes
| captionstyle =| File:Istanbul - Santa Sofia - Medalló (cropped).JPG
| real-world calligraphy of [[Ali]]| alt1=| File:Rashidun Caliph Ali ibn Abi Talib - علي بن أبي طالب.svg
| digital recreation of real-world calligraphy of Ali
| alt2=| File:UsulALFiqh.svg
| calligraphy containing stylistic elements (decorative circle, color, shadow) not present in original calligraphy as used outside WP (external links [https://m.media-amazon.com/images/I/71iObLPx1mL._SL1500_.jpg][https://www.mehbooba.com/the-principles-of-hanafi-usul-al-fiqh][https://madinahcollege.uk/product/usul-al-fiqh-an-introduction-to-islamic-legal-theory])
| alt3=}}
See the highlighted caption doesn't appear on the page. Is it a talk page only thing? Or is it specifically the code of this caption that is causing it not to output? waddie96 ★ (talk)20:23, 9 February 2025 (UTC)[reply]
Arthurfragoso, I think this may be related to your alt text changes. The alt text for the above contains unprocessed URLs that appear to be interfering with rendering of the caption; when I remove the alt text from the rendered gallery, the links above display just fine. – Jonesey95 (talk) 21:18, 9 February 2025 (UTC)[reply]
I have reverted the last twoall of the February changes, which appears to resolve the problem until Arthurfragoso can come up with a better fix in the sandbox. – Jonesey95 (talk) 02:33, 10 February 2025 (UTC)[reply]
But the above example contains no external links in the alt text... or if I'm missing the bigger picture here then excuse me because I know nothing of Module coding. waddie96 ★ (talk)09:35, 10 February 2025 (UTC)[reply]
The problem was because the url was concatenating with the pipe, and the parser was interpreting the pipe as part of the url, example:
alt1=caption with link at the end http://website.com/about|caption with link at the...
So now I added a code to strip the links added to the alt text, and I also added a space before the caption to prevent other unexpected behavior. -- Arthurfragoso (talk) 10:21, 10 February 2025 (UTC)[reply]