This is an archive of past discussions about Template:Portal. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
The margin on the side with text is set to 0.5 em and should be 1em; 1em is bog-standard on floating things such as thumbnails and infoboxes and this should match those. As it is, text is getting too close to these portal ads. Br'er Rabbit (talk) 10:19, 10 September 2012 (UTC)
An unlimited number of portals can be displayed, as opposed to a maximum of 18 portals in the old version.
The "No portals specified: please specify at least one portal" error is displayed only if there are no portals specified; previously it was displayed if the first positional parameter was empty, regardless of other positional parameters.
When the "No portals specified: please specify at least one portal" message is displayed, the box size now matches the size of the text.
Some special characters display slightly differently, but this only applies to characters which break wikilinks, so I don't think we need to worry about getting an exact match. See for example Template:Portal/testcases#ASCII null value.
Differences in the back-end:
The table is generated by html directly, rather than through a wikitable.
I think the Lua version is ready for deployment, but as this template has more than four million transclusions, I want to get this right first time. If anyone finds any bugs, has any objections to the implementation, or if you can think of new features you would like to see, etc., your feedback will be most welcome. — Mr. Stradivarius♪ talk ♪18:20, 1 April 2013 (UTC)
I would suggest adding a pcall trap at "imageloc = mw.title.new(imageloc, 'Template')". mw.title is an expensive function (as is #ifexist), and it fails with script error if the expensive parser function limit is reached. (By contrast, #ifexist just returns its false value, which tends to be less disruptive.) There aren't that many pages in Category:Pages with too many expensive parser function calls, but it does come up occasionally and Module:Navbox already tripped over this. Dragons flight (talk) 04:26, 2 April 2013 (UTC)
I made some changes to simplify the code a bit, including removing the lines where you nil out variables that are no longer needed. Unless there's some particular reason for doing this in the Scribunto environment, it seems like a negligible premature optimization. Toohool (talk) 06:13, 2 April 2013 (UTC)
Thanks, those changes all make a lot of sense. And you're probably right about the optimization - Lua is highly likely to know more about optimization than I do. :) — Mr. Stradivarius♪ talk ♪06:48, 2 April 2013 (UTC)
In this code, if pcall fails then imageloc takes the value of the error message string. This means that the imageloc portion of the if test would actually return true. The code still worked because imageloc.exists returns nil anyway, but it's probably better to make things transparent. I've changed the code so that it checks _ as well (and I've given all the variables more descriptive names). — Mr. Stradivarius♪ talk ♪09:08, 2 April 2013 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I am suggesting that for the Portal/Images/Television image, it be replaced with File:Television.svg in order to make it a vector. Most non-photographic images in the template are vectors.
PS I think that image isn't such a good choice for the portal. It's too detailed to be displayed at that small size. Something more iconic like a famous Bigfoot photo or the famous Loch Ness Monster photo would be better. Jason Quinn (talk) 14:47, 16 June 2013 (UTC)
Merge functionality from Template:Portal-inline
I recently discovered a template variant of {{Portal}} called {{Portal-inline}} and I think the functionality of that template should be merged with this one. A lot of people complain about the space that Portals take up on articles and how they overlap sections, where they are located, etc. I personally think this Portal-inline template looks very clean and professional and is a great improvement over the rather clunky and cluttered looking Portal. With that said, I realize others may feel differently so it seems appropriate that the functionality be available and allow the editors to choose. Kumioko (talk) 18:44, 26 June 2013 (UTC)
Hi Kumioko. Which part of the functionality would you like to see merged? I'm not quite getting that from your description. Are you suggesting that {{portal-inline}} be updated to allow for multiple portals, or that the styling for the existing {{portal}} be changed in some way? — Mr. Stradivarius♪ talk ♪22:04, 26 June 2013 (UTC)
What I meant to suggest and sorry if I wasn't clear was to eliminate {{Portal-inline}} and incorporate the functionality of that template into portal by adding a parameter for |inline= and |tiny= which I think are the only 2 in Portal inline that aren't in this one already. If that isn't possible then yes I think it would be good to make this template be able to support multiple templates. I hope that explains it well enough but please let me know if it doesn't. Kumioko (talk) 01:16, 27 June 2013 (UTC)
It wouldn't be too difficult to add that functionality to Module:Portal, but we wouldn't be able to just redirect {{portal-inline}} to {{portal}} without going through all 43,000 transclusions first and adding |inline=yes. Also given that the existing code of {{portal-inline}} is pretty simple (and therefore fast) I don't really see a big reason for making that change alone. Having said that, I would be in favour of porting this template plus all of the other portal templates over to Lua if it involves getting rid of all the image subpages. I have had thoughts about replacing these thousand-or-so subpages with three Lua submodules (one for each level of protection) that simply list all of the image names, but compiling the lists will be a laborious task, and I think it needs to be done by bot. — Mr. Stradivarius♪ talk ♪09:39, 27 June 2013 (UTC)
I think that sounds like a great idea. If you just need a list of the images I can get you that without a bot. Retagging the pages would probably need a bot your right but why couldn't we just do it a s awrapper template like I do for some of the WikiProject templates supported by WPUS? Template:WikiProject Arizona is one example. Kumioko (talk) 14:11, 27 June 2013 (UTC)
(edit conflict) I was almost able to do it with a Lua script, but I was thwarted by the need to know the protection level. Lua can't detect the protection level yet, and the relevant magic word only works for the current page, not for other pages. So it's going to need the API, and probably a bot, though I'm not all that knowledgeable about such things. The information I would need to know is the portal name, the image name, whether the page is a redirect or not, and the page's level of protection (none, semi, or full). Once I have that information in some format, I will be able to convert it into a Lua table with the help of some scripting and/or regex. After that, creating the submodules and updating the main module shouldn't be too hard. Any mistakes would affect thousands of articles, though, so it is important that we get it right. — Mr. Stradivarius♪ talk ♪14:46, 27 June 2013 (UTC)
Compiling a list of images on one page would introduce a disadvantage which is that it will be impossible to protect highly-used image names and leave unprotected those ones that have only few transclusions. --DixonD (talk) 14:41, 27 June 2013 (UTC)
My idea was to have three lists - one unprotected, one semi-protected, and one fully-protected. The module would check the fully-protected list first for any matches, then the semi-protected one, then the unprotected one. That would ensure that new images could be added to the unprotected list without too much fuss, while still meaning that highly-used images cannot be vandalised. — Mr. Stradivarius♪ talk ♪14:49, 27 June 2013 (UTC)
Fortunately new portals aren't added or removed all that often and the images don't change that much either so it shouldn't be to much work to keep updated even if the whole list is fully protected. Kumioko (talk) 16:19, 27 June 2013 (UTC)
Image request
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
It would be possible with a little tweaking, but I don't think there would really be much point. Portal-inline is quite a simple template, and we wouldn't get any real performance gains from porting it to Lua. I don't think there's any need for increased functionality either (though correct me if I'm wrong). — Mr. Stradivarius♪ talk ♪18:53, 8 April 2013 (UTC)
Edit request on 27 July 2013
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I've found some vector images, which can be better to illustrate its topics.
It does have that disadvantage, yes. However, it should be faster than using subpages for each portal, and doesn't increment the expensive function count. If changes to portal images are very frequent, then it might be worth switching back to the old system, though. I suggest we wait and see how many requests come in - it will be easier to assess which way of doing things is better after we have some solid data. — Mr. Stradivarius♪ talk ♪15:06, 28 July 2013 (UTC)
Portal request
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
That's definitely better. But come to think about it, how about using something which will be more recogniseable at small resolutions, like File:Gandhi Setu Bridge in Patna, India.jpg? this is what they would look like at portal size:
Sorry, but we can't accept fair use images for portals - they have to be available under a free licence. The old one is probably your best bet, as it is simple enough that it doesn't fall under copyright. The new one is complicated enough that it looks copyrightable to me, and it is listed as fair use on the file description page. — Mr. Stradivarius♪ talk ♪06:47, 8 August 2013 (UTC)
need Image removed from Module
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Can someone please update the image for "acc" to "ACC Map crop 2014.png"? The image of the map that is in use is now out of date as the conference has expanded. Thank you! CrazyPaco (talk) 23:53, 17 August 2013 (UTC)
Done. Ok, the new version is now up. Portal image names can now be accessed from the module. For example, {{#invoke:portal|image|Calgary}} produces Portal-puzzle.svg. The next step is to update all the other portal templates to use this function, which I should get round to tomorrow. — Mr. Stradivarius♪ talk ♪16:16, 2 September 2013 (UTC)
It now works because you added Calgary to the module, Template:Portal/Images/Calgary is not being used. I am I right in assuming that because you haven't added the pre-Lua function to look for a Template:Portal/Images/... page you want to reserve the ability to change portal images to administrators? Perhaps that's the wrong tone, but I am shocked that this hasn't been brought up yet. 117Avenue (talk) 02:44, 3 September 2013 (UTC)
This does have the effect that only administrators can add, edit, and remove portal images, yes. I see this as an unfortunate side-effect of the move to Lua, though, and not something I want in particular. It is possible to write Lua code that accesses the old Template:Portal/Images/... pages, and indeed there was code in the first version of the module that did exactly this. The problem is that it's not very good from a coding standpoint. If we access the old image pages, we have to do so through the MediaWiki parser, which is a lot slower than using native Lua functions. And if we store several image names in one module, as is the case now, then each of them will have several thousand transclusions, which necessitates protection. I suppose we could change it to a system where each portal gets its own image module written in native Lua code. The code would be fairly simple; for example, for Portal:Art the module would just consist of:
return"Ballerina-icon.jpg"
There are about 1500 portal images in use, though, so this would need a bot to do properly. And because it would need to protect the module pages as well, it would have to be an adminbot. And also, having 1500 image subpages is hard to maintain; the current system of 28 subpages is a lot more manageable in that respect. That said, if people are unhappy with my technical choices here, we can always talk through the other options. Best — Mr. Stradivarius♪ talk ♪07:35, 3 September 2013 (UTC)
Have noticed many many many images attached to theses portals were being vandalized or replaced. After some investigating come to find out that if someone clicks on the image in the portal box it takes them to the image ...not the portal they wish to see. We need to fix this as the space to click on is so small ....cant have 40 percent of the space in theses small boxes linking to the image that is there. Need to go back to old format - that is even if you click the image it takes you to the portal -- Moxy (talk) 22:52, 4 September 2013 (UTC)
@Moxy: See #Image attribution above. A [rather complicated] workaround would be for the module to tell the templates whether the selected image is public domain. This would lead to inconsistencies that would trip up the readers. An easier workaround, but disruptive in the short term, would be to remove all the CC-BY and GFDL images from the lists in the module, and insist that all portal images have to be public domain images from here on. -- John of Reading (talk) 06:30, 5 September 2013 (UTC)
I've just created Template:Portal/doc/all, which uses Module:Portal/sandbox to create a portal box with all existing portal images. This could be used for cascading protection - but again, it won't do much good if the images themselves are on Commons. This page might also be useful for visually checking the images that we use (I already found one glaring error). The red links are deceptive though, as there is no way for the module to know the proper capitalisation of the portal name, so as a quick hack I just did the Lua equivalent of {{ucfirst:}}. — Mr. Stradivarius♪ talk ♪10:04, 5 September 2013 (UTC)
Done. By the way, you need to set the "answered" parameter in {{edit protected}} to "no", or leave it out altogether, otherwise admins won't notice your request. I only saw it because I happened to be watching this page. Best — Mr. Stradivarius♪ talk ♪11:02, 16 September 2013 (UTC)
Image attribution
According to Help:Visual file markup there should be restrictions on which images can be used as clickable portal links: "Unless the file is public domain attribution must be provided in some other fashion". This rule hasn't been enforced; should it? I started looking through Module:Portal/images/j and found about half of them have CC-BY and/or GFDL licenses. The template documentation needs to say which licenses are acceptable. -- John of Reading (talk) 06:55, 4 September 2013 (UTC)
The images are clickable (at least the ones that are output by {{portal}}), so attribution is provided by the image description page. So there is no problem with images licensed CC-BY-SA/GFDL. It's probably a good idea to note in the docs that we can't accept free fair-use images, though. I'll go and do that now. — Mr. Stradivarius♪ talk ♪09:17, 4 September 2013 (UTC)
@Bleff: That's a good image for the 50s, but I'm not sure about the saxophone - as far as I'm aware saxophone jazz music didn't become popular until the swing era in the 1930s and 40s. But maybe there's something I'm missing here? — Mr. Stradivarius♪ talk ♪08:49, 11 October 2013 (UTC)
@Mr. Stradivarius: I proposed the saxophone beacause the 1920s are also often referred to as the Jazz Age. I didn't know if saxophone jazz was popular, perhaps a trumpet like this one File:Trumpet01.svg would be better. Or any other image that isn't jazz-related but represents the 20s.--Bleff (talk) 22:21, 11 October 2013 (UTC)
There's nothing wrong with having the same image for two different portals, but I can see a problem with using File:Pentagon satellite image.jpg. At small resolutions it's very hard to make out what it is actually supposed to be an image of, because there is not much contrast between the building and the car park. I've made a mock-up of what the template would look like so that you can see what I mean. Is there an image of the Pentagon which is easier to make out? If not, maybe sticking with the flag would be better. — Mr. Stradivarius♪ talk ♪07:09, 24 November 2013 (UTC)
I see nothing at Commons that would adequately work here. As simple as we need images to be here, I doubt anything other than a line drawing of a pentagon would work, which would be...unattractive. For that reason, I think keeping the flag icon is the best option. — Huntster (t@c)07:53, 24 November 2013 (UTC)
I don't think this is necessary. It's pretty obvious what a portal is after you click through to an individual portal page, and if anyone is in any doubt then there your link is included at the top of many portal pages anyway (e.g. at Portal:Art). — Mr. Stradivarius on tour♪ talk ♪16:19, 4 January 2014 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit protected}} template. I agree that this is unnecessary. Thank you for your interest in contributing to this template though, Rezonansowy. If you can however build a consensus other than that of Mr. Stradivarius and I, I'm sure either one of us would be happy to carry out your request. Technical 13 (talk) 04:32, 5 January 2014 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I can't believe that this was seriously considered. I don't think it's a BLP issue, as ultimately Miley did strike that pose, but I still think that it's an inappropriate image for representing the portal. Something like File:MileyCyrus signature.svg is a much less controversial choice, and doesn't condense the subject matter into once incident. I propose that the current image be switched out for the signature. Sven ManguardWha?01:19, 2 February 2014 (UTC)
Given that the subject of the portal is a specific genre of fiction, it may have been best to have replaced the image with a representative fictional character from that genre for which the copyright has expired. I would like to propose a revised alteration:
I personally am not in favor of that. The thing about portal icons that makes them tricky is that they have to look good not only in the related portal section of Portals, where they're in the 50x50 pixel size range, but also in portal bars in articles, where they're in the 20x20 pixel size range. The image you're suggesting wouldn't be identifiable at 20x20 pixels. See http://oi57.tinypic.com/155rvgp.jpg for what I mean. Sven ManguardWha?18:28, 3 February 2014 (UTC)
Right, I often try to check which images will still be identifiable as smaller thumbnails. I didn't realize my suggestion wasn't going to function well, but I'd still like to see a more representational image used. However, I recognize that this is not a priority, so I'll do some work to find a better image before making another recommendation. --Cast (talk) 03:16, 4 February 2014 (UTC)
Unfortunately, several useful images presently in that category would also likely be contested in the same way the original image was. Others may be too distorted as a smaller thumbnail. What may function best would be a superhero from the golden age that has fallen into public domain, in a simplistic pose that remains distinguishable when small. Here's a potentially useful one:
["superhero fiction"] = "File:Flame 002.png",
Incidentally, I dimly recall experimenting with this image as the portal thumbnail some years ago. As I recall, it looked well, but I avoided it because the character is too generic to be representative. Given the lack of better options, I think it will serve now.--Cast (talk) 06:59, 14 February 2014 (UTC)
Resolved
.svg){kind=link}
