Difference between revisions of "User talk:Clotho"

From SpiralKnights

Jump to: navigation, search
m (New Redirect Tags: To Files: *)
m (New Redirect Tags: To Files: another * with an explanation)
Line 118: Line 118:
 
::: I would advice against this. It's better to move the page to the correct location to preserve history in one place. The pages that link to the old file should be updated and point to the correct name. --[[User:Clotho|Clotho]] 03:46, 7 April 2016 (UTC)
 
::: I would advice against this. It's better to move the page to the correct location to preserve history in one place. The pages that link to the old file should be updated and point to the correct name. --[[User:Clotho|Clotho]] 03:46, 7 April 2016 (UTC)
 
::::I'm not sure how moving files/updating old files helps in this case? Wouldn't it just be better to upload duplicates? The reason Hikaru and I worked on this is because wikipedia frowns so much on duplicates. --[[User:Novaster|Novaster]] 11:46, 7 April 2016 (UTC)
 
::::I'm not sure how moving files/updating old files helps in this case? Wouldn't it just be better to upload duplicates? The reason Hikaru and I worked on this is because wikipedia frowns so much on duplicates. --[[User:Novaster|Novaster]] 11:46, 7 April 2016 (UTC)
 +
::::Looking at potential candidates, I don't see how it's actually possible to move any of these files without totally disrupting the established naming system and/or moving something to an incorrect name. The issue is not incorrect/out of date files, but avoiding huge duplicate files on the wiki, so that when the "slot" for a new file (most often a news image) demands an upload, we can just redirect the new, demanded "file" page to an old, already existing file instead of uploading a duplicate that takes up a lot of space (relatively) if we are sure every pixel is the same. Hikaru figured out that this works because our wiki automatically displays the redirect destination file as if the called file is the actual file.
 +
Example relationship, using the most recent to demonstrate how the system works with time:
 +
*File:SpiralKnights News 149-big.png (original artwork)
 +
*File:SpiralKnights News 190-big.png (reused artwork)
 +
 +
We have this on the reused artwork file page:
 +
<pre>
 +
#REDIRECT [[:File:SpiralKnights News 149-big.png]]
 +
{{R to file}}
 +
</pre>
 +
 +
So that <nowiki>[[File:SpiralKnights News 190-big.png|100px]]</nowiki> displays as:
 +
*[[File:SpiralKnights News 190-big.png|100px]]  (displayed is file 149, called by 190 - see page code)
 +
 +
As you can see, the call for "190" displays the original file "149" through the redirect, even though templates/the wiki in general call for the new file, which otherwise would be an "enormous" duplicate of the older file (and repeat countless times with existing past files and future files for event posts in particular). It's rather fascinating in our opinion. I think Hikaru discovered the behavior/wiki-ability to do this by accident. But the wiki can definitely do it, so, we figured this is meant to happen in some way (otherwise, why would the wiki be able to display destination files through redirects?) As mentioned before, we thought about doing this for accessory icons, but decided against it because they're small and one day we might have to undo that net of redirects if the game gives accessories their own icons (which happened with costumes), while we wouldn't have to undo "news" unless editors agree to/admins mandate it.
 +
 +
If this is still inadvisable, we'll undo the system and upload a bunch of duplicates (that sounds snotty...I don't mean it to be, haha). --[[User:Novaster|Novaster]] 12:09, 7 April 2016 (UTC)
  
 
== More Issues ==
 
== More Issues ==

Revision as of 12:09, 7 April 2016

Archived discussions can be found here. If you have a suggestion for Spiral Knights, please use the Suggestions Forum instead. If you need assistance with your account, use the links on the Support Portal to get help.

Operation Crimson Hammer

Okay! As you can see, several of us are working on getting anything mission related up to date, and Operation Crimson Hammer (OCH) is a mission - expansion subtype. Editors really need to be able to edit this page, because it is a large part of the game and connected to several things. Correct me if I'm wrong, but as far as I can tell, the only reason it's locked to general editors is because it has Billing information. My solution to this problem:

Create the subpage: Operation Crimson Hammer/Billing and protect that.

Have {{main|Operation Crimson Hammer/Billing}} in an acquisition section somewhere on the OCH page, and let the main OCH page be edited by us (unprotect it).

Unless it was protected for some other reason? Could we have a similar solution(s) for that if so?

Thanks,

--Novaster 11:25, 28 July 2015 (UTC)

That page is linked to our billing documentation therefore it needs to be protected in full, not just part of it. An alternative would be to make the changes in a sandbox, once ready, let me know and I'll update the changes in the page itself. --Clotho 17:00, 7 August 2015 (UTC)
That's going to be a bit difficult. Editors really need to be able to freely edit a page that's such a large interactive and dynamic part of the game. That makes a lot of hassle to unprotect/protect a page on staff end over time. It's not possible to create Operation Crimson Hammer/Billing, protect that, and then adjust billing documentation to link to that page instead? If not, I'll have to work something out on our end, but it likely won't be as pretty. --Novaster 17:34, 9 August 2015 (UTC)

Quoted from email to support (regarding my inability to log in for a day or so, but another employee resolved the ticket so you might not have seen this): OCH issue: make a billing page about OCH, named "Operation Crimson Hammer/Billing" and protect it. This page would be a page in its own right and be able to be fully protected. Attempt to make billing documentation link to this "Operation Crimson Hammer/Billing" page instead of the "Operation Crimson Hammer" page. Unprotect the "Operation Crimson Hammer" page indefinitely and make sure it always links to the "Operation Crimson Hammer/Billing" page. This is because OCH is a major part of the game and editors need to be able to edit it freely. This method of billing protection as a subpage with a main expansion mission page should work for future expansion releases. Just imagine having to protect/unprotect OCH and any future expansions every time the game changes and editors need to update aspects of this/those page(s) - awful, right? Other editors seem to agree with me, and they should write a response on your (Clothos') talk page soon. Additional requests/details in the #subsection ("Operation Crimson Hammer") on your (Clotho's) talk page.

--Novaster 21:45, 20 August 2015 (UTC)

I'll discuss this with the billing department, but I don't foresee any changes in the near future. Sorry! --Clotho 20:42, 6 October 2015 (UTC)
Actually, what might work for the time being is a Sandbox/Operation Crimson Hammer where you guys make all the editions you want and I'll just copy/paste the contents into the protected page. --Clotho 20:46, 6 October 2015 (UTC)
I view this as a bandaid solution for reasons stated above (quite a hassle to do it this way if we continue to get more expansion missions). I/We'll work on that...soonish, most likely, but real life is very pressing for me these days. Let's hope billing can be flexible! --Novaster 20:53, 6 October 2015 (UTC)
We have another idea that might work better. I'll post here as soon as it's fleshed out. --Clotho 20:04, 12 October 2015 (UTC)
Sounds exciting. --Novaster 20:13, 12 October 2015 (UTC)
Any news about this? And btw (in response to a support request), we are totally already putting soundtrack information on location pages. Super happy staff is on board with this idea. --Novaster 23:58, 20 January 2016 (UTC)
No news I'm afraid. I've been sent to different projects so this one had to go to the back burner. I'll holler when/if that changes. --Clotho 21:43, 26 January 2016 (UTC)

New Redirect Tags

There are a few words-pages such as "Electric" that we've redirected for convenience to "go" to color categories (users can always "search" for specifics instead of "go"). We'd like to make a redirect tag for these pages, but none of our current ones really fit - "R from alternate name" and "R from related word" come close but not quite. Would it be appropriate to make the equivalent of this for our wiki, and to add it to SpiralKnights:Redirect? Or is there something better? It's a somewhat sensitive issue because these breach namespaces (main and category). --Novaster 01:21, 12 November 2015 (UTC)

There is some desire to just adjust the rules for Category:Redirects from shortcut, which we already have, which is what brought this up. --Novaster 05:55, 12 November 2015 (UTC)
I don't see an issue with adding that new tag. Has anyone mentioned a con to this proposal? --Clotho 16:58, 17 November 2015 (UTC)
Hikaru would have to make changes regarding some work they did using the "shortcut" tag in the spanish wiki. If it is unacceptable to adjust the "shortcut" tag's function to include all "misc shortcuts" (which I think is the best option because I am not particularly fond of nitty gritty nitpicky exclusive mostly useless functions, no matter how "technically correct" they are, but that's just me), then we will make the new tag - since you don't see an issue - and adjust. --Novaster 17:14, 17 November 2015 (UTC)

Looking carefully at "R from shortcut" examples, shortcut really seems to be best. Especially considering wikipedia's policy on the matter, specifically: "Shortcuts are historically reserved for Wikipedia project reference pages and are now used in and for all namespaces." I feel we should definitely follow in these footsteps, unless staff is opposed. I'll happily adjust the criteria on the Help:Redirect page. --Novaster 18:27, 3 March 2016 (UTC)

New Redirect Tags: To Files

We are also trying to avoid uploading duplicate files that are large, especially for news images. Users appreciate easy access to the "big" art, editors like to punch in numbers because each thing is its own entity with its own name despite having the same visual, and duplicate files are bad (accessory icons are particularly annoying to me). I'd like to make a specific redirect for these: "R to circumvent file duplication" or something you think would be better. --Novaster 23:37, 25 November 2015 (UTC)

To resolve this issue, since it seems okay to add new redirect criteria sparingly and carefully and if there is significant need, I have made Template:R to file. I chose the word "to" instead of "from" because while the name should be restricted to pages in the file namespace, they are not technically always from "files" if they are "empty"/not uploaded (page), but they are always to an uploaded file (page). And this special redirect is most similar to the disambiguation type of redirect, which uses "to." I assume there is a significant reason for mostly using "from," but I do not know it. It seems to mostly be a consistency thing, or perhaps this results from the small "redirected from blah" message that appears when relevant under the page title. --Novaster 18:27, 3 March 2016 (UTC)
Bump this, relevant to a recent support request. --Novaster 23:58, 6 April 2016 (UTC)
I would advice against this. It's better to move the page to the correct location to preserve history in one place. The pages that link to the old file should be updated and point to the correct name. --Clotho 03:46, 7 April 2016 (UTC)
I'm not sure how moving files/updating old files helps in this case? Wouldn't it just be better to upload duplicates? The reason Hikaru and I worked on this is because wikipedia frowns so much on duplicates. --Novaster 11:46, 7 April 2016 (UTC)
Looking at potential candidates, I don't see how it's actually possible to move any of these files without totally disrupting the established naming system and/or moving something to an incorrect name. The issue is not incorrect/out of date files, but avoiding huge duplicate files on the wiki, so that when the "slot" for a new file (most often a news image) demands an upload, we can just redirect the new, demanded "file" page to an old, already existing file instead of uploading a duplicate that takes up a lot of space (relatively) if we are sure every pixel is the same. Hikaru figured out that this works because our wiki automatically displays the redirect destination file as if the called file is the actual file.

Example relationship, using the most recent to demonstrate how the system works with time:

  • File:SpiralKnights News 149-big.png (original artwork)
  • File:SpiralKnights News 190-big.png (reused artwork)

We have this on the reused artwork file page:

#REDIRECT [[:File:SpiralKnights News 149-big.png]]
{{R to file}}

So that [[File:SpiralKnights News 190-big.png|100px]] displays as:

  • SpiralKnights News 149-big.png (displayed is file 149, called by 190 - see page code)

As you can see, the call for "190" displays the original file "149" through the redirect, even though templates/the wiki in general call for the new file, which otherwise would be an "enormous" duplicate of the older file (and repeat countless times with existing past files and future files for event posts in particular). It's rather fascinating in our opinion. I think Hikaru discovered the behavior/wiki-ability to do this by accident. But the wiki can definitely do it, so, we figured this is meant to happen in some way (otherwise, why would the wiki be able to display destination files through redirects?) As mentioned before, we thought about doing this for accessory icons, but decided against it because they're small and one day we might have to undo that net of redirects if the game gives accessories their own icons (which happened with costumes), while we wouldn't have to undo "news" unless editors agree to/admins mandate it.

If this is still inadvisable, we'll undo the system and upload a bunch of duplicates (that sounds snotty...I don't mean it to be, haha). --Novaster 12:09, 7 April 2016 (UTC)

More Issues

Working through a very, very nasty knot of namespace issues. As expected, it is tedious. I've run into several issues/suggestions that I cannot edit due to page protections:

I'm sure I will run into more issues as time ticks mercilessly by with this project. --Novaster 04:44, 29 February 2016 (UTC)

Personal tools