Template talk:Image-quality: Difference between revisions
From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
No edit summary |
|||
Line 28: | Line 28: | ||
::::::::::No, those were mistakes and there were no good reasons for it because that sort of thing is what {{tem|MoreImages}} is already here for, and I have fixed the pages to that end. We're not gonna mess around with this ''file-only'' template anymore just because people might screw up the usage every now and then, and if anything, someone getting an error if they try to upload a file using an ''article'''s name is a ''good'' thing because it ''is'' an error. Now, this case ''is'' closed: drop it and leave it alone, please. - {{User:Walkazo/sig}} 20:11, 14 February 2016 (EST) | ::::::::::No, those were mistakes and there were no good reasons for it because that sort of thing is what {{tem|MoreImages}} is already here for, and I have fixed the pages to that end. We're not gonna mess around with this ''file-only'' template anymore just because people might screw up the usage every now and then, and if anything, someone getting an error if they try to upload a file using an ''article'''s name is a ''good'' thing because it ''is'' an error. Now, this case ''is'' closed: drop it and leave it alone, please. - {{User:Walkazo/sig}} 20:11, 14 February 2016 (EST) | ||
:::::::::::I don't consider {{tem|image-quality}}'s unconventional use a screw-up but rather closer in use than {{tem|MoreImages}}. That template is for articles lacking sufficient number of images, not if the quality of a bunch of images are sub-par. I only added {{tem|talk}} back because we weren't done yet and I would like others' input on the matter. I won't put it back unless other moderators agree that should be done at this point. Trust me, I don't want to have {{tem|warning}} issued to me. I want things to go over smoothly. --{{User:Wildgoosespeeder/sig}} 20:26, 14 February 2016 (EST) | :::::::::::I don't consider {{tem|image-quality}}'s unconventional use a screw-up but rather closer in use than {{tem|MoreImages}}. That template is for articles lacking sufficient number of images, not if the quality of a bunch of images are sub-par. I only added {{tem|talk}} back because we weren't done yet and I would like others' input on the matter. I won't put it back unless other moderators agree that should be done at this point. Trust me, I don't want to have {{tem|warning}} issued to me. I want things to go over smoothly. --{{User:Wildgoosespeeder/sig}} 20:26, 14 February 2016 (EST) | ||
::::::::::::That parameter is very not necessary, I agree with Walkazo. --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 20:40, 14 February 2016 (EST) |
Revision as of 21:40, February 14, 2016
Link Change
I found a way to duplicate the link that is associated with Upload a new version of this file. Change:
'''this file should be {{color-link-piped|Special:Upload|#000000|reuploaded}}'''
(link is Special:Upload if put into File:Glide64 2.png)
to
'''<includeonly><span class="plainlinks">[{{fullurl:Special:Upload|wpDestFile={{urlencode:{{PAGENAME}}|WIKI}}&wpForReUpload=1}} <span style="color:#000000">reuploaded</span>]</span></includeonly><noinclude>reuploaded</noinclude>'''
(link is specialized if put into File:Glide64 2.png)
Should this change be implemented? You can see this in action for User:Wildgoosespeeder/Tweak/sandbox being transcluded in File:Glide64 2.png --Wildgoosespeeder (talk) (Stats - Contribs) 04:11, 13 February 2016 (EST)
- Looks good to me but more input would be needed before making the change. --
™ The 'Shroom 10:29, 13 February 2016 (EST)
- Good idea to make it link directly to uploading the file in question, bu as for the coding itself, make it:
<span class="plainlinks">[{{fullurl:Special:Upload|wpDestFile={{urlencode:{{PAGENAMEE}}|WIKI}}&wpForReUpload=1}} {{color|reuploaded|black}}]</span>'''
- The bold starts before the link so the 's are unnecessary, the colour template's a bit simpler than needing a second span, and it doesn't matter if the link's dysfunctional on the template page itself, so long as it works for other pages, which it should, as far as I can tell. The only potential problems are when apostrophes, ampersands or other characters are used in the file names; I switched the magic word to PAGENAMEE, since I think percent-encoding special characters will work better, but I'm not 100% sure: I haven't tested it by reuploading anything, just previewing and going to the upload pages, with less than perfect results even then (for either magic word). - Walkazo 13:19, 13 February 2016 (EST)
- I looked up documentation and I can go even shorter and drop
{{urlencode:{{PAGENAME}}|WIKI}}
in favor of{{PAGENAMEE}}
. The markup produces identical output. There shouldn't be problem(s) with the encoded output version of the magic word. I would just replace:{{color-link-piped|Special:Upload|#000000|reuploaded}}
- with
<includeonly><span class="plainlinks">[{{fullurl:Special:Upload|wpDestFile={{PAGENAMEE}}&wpForReUpload=1}} {{color|reuploaded|#000000}}]</span></includeonly><noinclude>{{color-link-piped|Special:Upload|#000000|reuploaded}}</noinclude>
- --Wildgoosespeeder (talk) (Stats - Contribs) 15:36, 13 February 2016 (EST)
- Yeah, that link definitely looks good. But again, ditch the unnecessary includeonly/noinclude stuff:
<span class="plainlinks">[{{fullurl:Special:Upload|wpDestFile={{PAGENAMEE}}&wpForReUpload=1}} {{color|reuploaded|#000000}}]</span>
- - Walkazo 16:00, 14 February 2016 (EST)
- Actually, I have a new set of logic that needs to be in place so that way the special link only appears on file pages:
{{#ifeq: {{FULLPAGENAME}}|File:{{PAGENAME}}|<span class="plainlinks">[{{fullurl:Special:Upload|wpDestFile={{PAGENAMEE}}&wpForReUpload=1}} {{color|reuploaded|#000000}}]</span>|{{color-link-piped|Special:Upload|#000000|reuploaded}}}}
- Trust me, this needs to be there for error correction purposes. --Wildgoosespeeder (talk) (Stats - Contribs) 16:27, 14 February 2016 (EST)
- Honestly, it really doesn't matter if it breaks when transposed onto non-file pages, or when it's sitting here untransposed: it's not supposed to be there, would be a useless link anyway even if functional, still displays perfectly fine, and is not worth fixing. We should just go with the simple thing I posted and be done with it. - Walkazo 17:10, 14 February 2016 (EST)
- For regular and experienced MediaWiki users here, you are right, because we know what we are doing generally, but for newcomers, this could throw them off if the template gives them an error link. I'll implement your approval, but I think the error correction code should be in place instead. --Wildgoosespeeder (talk) (Stats - Contribs) 17:17, 14 February 2016 (EST)
- Thanks for listening. But I can almost guarantee no one will bat an eye at it: it just brings them to an upload page using whatever the page name is, not an error page or anything. No big D. - Walkazo 18:25, 14 February 2016 (EST)
- The error potential is when they click upload when the file name is missing the extension (*.png, *.jpg, etc.). Take a look at Gallery:Super Mario Maker, Gallery:New Super Mario Bros., and Mario & Luigi: Bowser's Inside Story bestiary. You can say the template was used incorrectly but the templates must be there for a good reason to go outside of conventional use. --Wildgoosespeeder (talk) (Stats - Contribs) 18:32, 14 February 2016 (EST)
- No, those were mistakes and there were no good reasons for it because that sort of thing is what {{MoreImages}} is already here for, and I have fixed the pages to that end. We're not gonna mess around with this file-only template anymore just because people might screw up the usage every now and then, and if anything, someone getting an error if they try to upload a file using an article's name is a good thing because it is an error. Now, this case is closed: drop it and leave it alone, please. - Walkazo 20:11, 14 February 2016 (EST)
- I don't consider {{image-quality}}'s unconventional use a screw-up but rather closer in use than {{MoreImages}}. That template is for articles lacking sufficient number of images, not if the quality of a bunch of images are sub-par. I only added {{talk}} back because we weren't done yet and I would like others' input on the matter. I won't put it back unless other moderators agree that should be done at this point. Trust me, I don't want to have {{warning}} issued to me. I want things to go over smoothly. --Wildgoosespeeder (talk) (Stats - Contribs) 20:26, 14 February 2016 (EST)
- No, those were mistakes and there were no good reasons for it because that sort of thing is what {{MoreImages}} is already here for, and I have fixed the pages to that end. We're not gonna mess around with this file-only template anymore just because people might screw up the usage every now and then, and if anything, someone getting an error if they try to upload a file using an article's name is a good thing because it is an error. Now, this case is closed: drop it and leave it alone, please. - Walkazo 20:11, 14 February 2016 (EST)
- The error potential is when they click upload when the file name is missing the extension (*.png, *.jpg, etc.). Take a look at Gallery:Super Mario Maker, Gallery:New Super Mario Bros., and Mario & Luigi: Bowser's Inside Story bestiary. You can say the template was used incorrectly but the templates must be there for a good reason to go outside of conventional use. --Wildgoosespeeder (talk) (Stats - Contribs) 18:32, 14 February 2016 (EST)
- Thanks for listening. But I can almost guarantee no one will bat an eye at it: it just brings them to an upload page using whatever the page name is, not an error page or anything. No big D. - Walkazo 18:25, 14 February 2016 (EST)
- For regular and experienced MediaWiki users here, you are right, because we know what we are doing generally, but for newcomers, this could throw them off if the template gives them an error link. I'll implement your approval, but I think the error correction code should be in place instead. --Wildgoosespeeder (talk) (Stats - Contribs) 17:17, 14 February 2016 (EST)
- Honestly, it really doesn't matter if it breaks when transposed onto non-file pages, or when it's sitting here untransposed: it's not supposed to be there, would be a useless link anyway even if functional, still displays perfectly fine, and is not worth fixing. We should just go with the simple thing I posted and be done with it. - Walkazo 17:10, 14 February 2016 (EST)
- Actually, I have a new set of logic that needs to be in place so that way the special link only appears on file pages:
- Yeah, that link definitely looks good. But again, ditch the unnecessary includeonly/noinclude stuff:
- I looked up documentation and I can go even shorter and drop
- Good idea to make it link directly to uploading the file in question, bu as for the coding itself, make it: