User:Trig Jegman

A user most known for file management. Founder of the TMWA and lead developer for Sourcemageddon. Also, inexplicably yet perplexingly an administrator. See also: The talk page, The sandbox, Project Clean-Up, my bot, TMWA Discord.

Terminology

 * Caps = Capitalization
 * FNC = File Name Change - I usually use this on any changed talk pages
 * RFC = Renamed for Consistency - Like files, such as character icons, should be similarly named. These are usually minor fixes.
 * RFA = Renamed for Accuracy - Spelling errors, wrong names, poor formatting, or lack of specified game. More-specific-to-the-image naming. This is about 85% of when the main file name is changed. These are usually major fixes.
 * NCR = Naming Conflict Rename - Files that are almost identically named that are renamed to avoid confusing the two. Hypothetical examples: Kirby.png vs. Kirby.PNG, or Dedede1.png vs. Dedede 1.png
 * RIF = Removed Image:/File: - ''Using  means you don't need to use "Image:" (which shouldn't really be used anyway) or "File:". If I'm passing through a gallery, I'll try to remove any I see. It may also mean changing Image: to File: for single images.
 * UPI = Unused Personal Image
 * ECE = Edit Conflict Error

Additionally, because autofill is an evil tool from evil town, I add a symbol in each edit summary so it doesn't save forever.

General/Miscellaneous

 * Total edits (in thousands): 27.4 - 05:49, 19 July 2023 (UTC)
 * See also: EditCount
 * Establish stricter audio guidelines to meet fair use qualifications and a consistent playblack (max 30 seconds, 16b/44.1h;128mbps MP3 encouraged); Attempt to replace vorbis with MP3, must convert wav to compressed. - 18:05, 18 December 2022 (UTC)
 * Fully remove webp from the site as a whole. - 18:05, 18 December 2022 (UTC)
 * Re-write file policy - 16:17, 11 February 2023 (UTC)
 * Create better image guidelines for use (sourcing, resolution, purpose) - 16:17, 11 February 2023 (UTC)
 * Make a bot for discord to actively track RFR+Abuse Filter requests - 16:50, 4 April 2023 (UTC)
 * Formally define sprite, texture, and render somewhere so they stop getting used so interchangeably. - 16:17, 11 February 2023 (UTC)
 * Make a better wiki help/site page nav system. - 15:12, 26 February 2023 (UTC)
 * Re-parse Category:Post-release_content and address the existing files within this category. - 22:45, 28 February 2023 (UTC)
 * Thoroughly analyze the use of "Beta" and try to use more appropriate terminology (pre-release, unused) instead. This likely warrants policy mention. - 18:17, 5 March 2023 (UTC)
 * Similarly, try to convert use of "Promo" to "Promotional". It's more professional that way. Alternatively, switch use cases to "Official" instead. - 04:24, 25 May 2023 (UTC)
 * Rewrite most templates to actually be used by human beings - 16:50, 4 April 2023 (UTC)
 * Reparse SiteColor to use hex codes like every place on planet earth. - 00:45, 19 April 2023 (UTC)
 * Figure out what to do with solo player walkthrough guides once ported to StrategyWiki. Also, finish porting those to StrategyWiki. - 02:47, 16 May 2023 (UTC)
 * Kill off Template:Icon, possibly consider reworking to make it more consistent in application or just not use it at all. Things that rely on identical filenames=not particularly ideal. - 04:24, 25 May 2023 (UTC)
 * Convert single player campaign enemy encounters to a template instead of galleries. - 05:10, 13 June 2023 (UTC)
 * Archive all tweets. - 05:23, 4 July 2023 (UTC)
 * Make a profile archive system - 05:49, 19 July 2023 (UTC)
 * Convert infobox generic to Infobox/Person on List of keyboardists for the Splatoon series, List of composers and arrangers for the Splatoon series, List of guitarists for the Splatoon series, and List of sound engineers for the Splatoon series. - 05:23, 4 July 2023 (UTC)
 * Template:TYAD doesn't account for leap years, and I'm honestly not sure how to run a validation on it. - 05:23, 4 July 2023 (UTC)
 * Thoroughly observe inactive staff and possibly shuffle up the list a bit. - 05:23, 4 July 2023 (UTC)
 * get the videos for this - 18:58, 4 July 2023 (UTC)
 * Finish Super Mario Maker page. - 05:49, 19 July 2023 (UTC)

Immediate Replacement Files
Watermarks do not qualify well for fair use.
 * File:Alice.jpg
 * File:Tokaigi2.jpg
 * File:Tokaigi3.jpg
 * File:Tokaigi4.jpg
 * File:Tokaigi1.jpg

Templates still using Trim

 * Template:TableturfDeck
 * Template:S3Schedule/BattleFest‎

Giving a file a name
When naming a file, it is most important to keep three "C"s in mind: Consistency, clarity, and capitalization. Additionally, a well named file can answer the questions "What game is this" and "What is the file about" WITHOUT the need to see the file.

I personally try to have all files be named in the following format: (Game Name/Abbreviation) (Object or Action) (Specifics).extension, but it is more important to remain consistent amongst the files being dealt with over this format. For a specific example, if all the other files being dealt with are in the format "Game Abbreviation Character Icon.extension", your file should properly reflect this. In terms of what 'Specifics' means, it means what the type of image is. There are about five types of images, being Artwork, Icon, Screenshot, Sprite, and Model/Render (varies). The specific is what sets that image apart from the rest.

In regards to the extension, the most important part about the extension is that it needs to be lowercase. Additionally, jpeg files should be written as jpg, and ogg should be formatted as oga or ogv, depending on the file type. This is not a me thing, rather it is the creater of the ogg container's request. The reason for the former is because jpg and jpeg will display as two different files which can lead to confusion and sometimes ruin automatic linking in templates or Cargo queries.

Clarity is fairly simple: The name should make sense. Avoid using more words than necessary to convey what the image is about, and if conjecture needs to be used, try and use wording that is directly used for the intended caption or surrounding context.

Capitalization once again is about making sure all files have lowercase extensions, and proper uppercase letters for any abbreviations (use GAME over game). Don't use all uppercase, either. It also is to make sure that files don't have differentiating capitalization, as MediaWiki will treat them as different files.

What to avoid

 * Capitalized extensions. Pretty good reason as to why I'd bring it up this many times if it wasn't a big deal.
 * Inconsistency. Files named 'THE cool Song of doom.oga' have weird, inconsistent capitalization; similar multiple files that change capitalization should be renamed to prevent it.
 * Overabbreviating. Shortening game names can be nice, but shortening things such as area names or characters may lead to some confusion or NCRs later down the road. Whispy Woods is not that long of a name, and does not need to be written as WW, for example.
 * Using the gif format for static images: These can be uploaded as png files, and it is better to do so.
 * Having funny file names. While files about yoshi being named "ugly green frog" is a good chuckle, it also makes it very difficult to identify what the file is actually about.
 * Unnecessary numbers. Sometimes it makes sense to name files numerically, such as Intro 1/Intro 2/Intro 3, but if it could be reasonably avoided, it should be.
 * Punctuation. While you can use some punctuation, it should only be used if said punctuation appears in what the file is describing. Personally, if it is not a hyphen, I do not like to keep punctuation, such as exclaimation points or tildes. Most importantly, do NOT (ever) use periods or pound signs (#) in file names because that can affect the coding. Furthermore, do not use parentheses, quotation marks, unicode, funky letters like À; Æ; Ö, emojis (yes people have tried), or unnecessary hyphens (ex: KRD-Cool-Door-Sprite.gif).
 * Too broad a name. Don't name a file after only the page you are referring to, as most of the time it may come back in a later game or in another form. 'Gordo.png' or 'Kirby right back at ya.jpg' are hypothetical examples of broad naming.

Renaming existing files
The way I approach renaming a file is by first having the File page open.

I then open all the pages it is both used on and pages I can edit in a new tab, but you may opt into windows or your own method instead.

Move the file to the appropriate name.

Generally speaking, all pages can be edited for correcting file names, with the exception of archives or policy pages. In these circumstances, reach out to an Administrator for help.

Most importantly to change is the regular pages and galleries. Locate the image and where it is used (sometimes it may be used more than once) and replace it. I generally find it helpful to use copy and pasting here. If you have the find tool, it can help minimize time spent searching. I am not an all computer wizard, but it tends to be command-F for macs and control-F for not-macs.

Once all pages have been addressed, go to the created redirect and mark it with the tag. Indicate a reason for deletion (FNC would likely be understood here too). After this, check the page "What Links Here" on the left side under "Tools". On some devices, control+option+J can be pressed to get there automatically. This is helpful for two reasons: The first is to make sure you didn't miss anything! The second is to see if any linked but undisplayed files are used. Files can be listed with a colon before File is written File:Trig Demonstration Example File.png or also with alternate text. If this usage can be replaced, it should be as well.

The file File:Trig Demonstration Example File.png itself links to a variety of pages to demonstrate what has been listed above.

At this point, you are done. Should you have any questions, comments, concerns, quantums, or theorems, please ask away on my talk page. Happy editing.

Why does this matter?
Having a consistent naming structure(s) leads to easier use of the wiki! Without funky file names, people won't be confused about how to type them in, be able to search for files easier, and be able to know what each file is on a large page like a gallery without being able to see it when editing. Some people when writing could even be able to just write a filename without even having to look it up. While making file names better, it also can reach to a large amount of pages to help fix problems on those pages as well. Some less popular pages can be scanned for errors.

What Does That Mean? (FAQ)
This section is a semi-dedicated FAQ to both questions related to files and general wiki editing. Have a question? I would be happy to answer it on my talk page instead.

Why do we have different types of files?
JPG/JPEG is a lossy type of image. While compressing, the file may lose quality in order to have a better file size. They are less preferred than other file types, but that is not to say they are bad. Usually, JPGs are used for artworks or Wii U/Switch screenshots. JPG files cannot and should not be converted into other file types.

GIF is a lossless types of image, revolutionary for supporting animation and transparency. It can only display 256 colors per frame, however. These files are most recommended to be used for animated images only, as the successor file type is much more effective at displaying images. Additionally, gameplay GIFs should be avoided because too many colors at once causes dithering, a process where color values exceeding GIF's 256 are replaced with a "best guess", usually, reducing the overall quality or accuracy.

PNG is essentially GIF 2 electric boogaloo. It was designed to improve on the lossless format to be both more compressed but also have more color options available to the viewer. A majority of wiki files are in this format. PNG is also transparency supportive, and is usually the smallest file type available. The main distinction between PNG and GIF is that PNG does not necessarily have animation support. There were several attempts to add it on later down the line, such as MNG (creator:png group) or APNG (mozilla), but they do not hold universal value. While the wiki supports APNG uploads, it is not heavily suggested as it is not quite available to all users and are usually large in size.

SVGs are interesting lossless files. They are universally supported, and essentially run images off text files. The two reasons that these files may be used over PNG is because they are much much smaller, and because that they can be displayed at any size without a change in quality. You want a 9000 by 9000 pixel SVG? It'll go there and look just as good as 152x152. They are only effective when it comes to line art or very simple artworks, however.

MP3 is the primary audio format. While this format used to be license only, it has since expired and is free for anyone to use. It is a lossy audio format, meaning some quality is lost on creation. This helps keep the file size small for use. Everything should be able to play this file type.

OGA is another audio format that might be seen, using Vorbis encoding. This was the main file format used before MP3 was widely available, but otherwise should generally be roughly similar for quality. The main difference is these files are not universally supported and will not work on all devices. Sounds on OGA files should be re-recorded/exported into MP3 files—not converted—when possible to allow a wider audience to be able to see them.

Notably, there are not any good universal video formats for the web. While an H.264 MP4 file is generally your best bet, it's also not very well supported on MediaWiki. It's probably better to link to a YouTube, Vimeo, or Odysee video.

Is there a difference between JPG and JPEG?
Short answer: No. Long answer: Noooooo.

JPG and JPEG are entirely interchangeable and have absolutely no meaning over the other. That said, files should use always jpg to avoid issues when auto-filling parameters and to avoid duplicate naming issues.

For example, the files "TheoRules.jpg" and "TheoRules.jpeg" would be considered two different files, and therefore show two different pictures. This could lead to a lot of confusion.

Why isn't this gif moving?
Chances are, it is a single frame gif. If possible, try and convert to a PNG before uploading, as they are more optimal to utilize and it generally does not affect visual quality.

I thought PNGs were supposed to be transparent
PNGs can be transparent, but they might not be. Sometimes the source uses a white background and that is ok. Transparency should not be artificially created just because an image is a PNG. '''Images should never be made transparent in systems like GIMP. Only official transparency should be used.'''

What's the deal with "inter-file periods"?
Interfile periods, periods that are in a file name that aren't for the extension, are not really great to have. While other punctuation found in a subject is usually okay, sometimes systems freak out as to when the extension starts when it comes to periods. For example, it may read a file named "Mr. T Artwork.jpg" as it should be, Mr. T Artwork, with an extension of jpg, OR it might read the file as Mr T with the extension of Artwork.jpg

There doesn't appear to be a rhyme or reason as to when one happens over another, but typically it messes up in galleries over anything else. It's better to be safe and avoid them entirely. If anything, it is simply easier to read.

What's the deal with hyphens?
Hyphens are a difficult middle ground when it comes to naming files. While they should be used for anything with a hyphen specifically in the name, they should NOT be used in place of spaces. The reason for this is generally because it's easier to type without a space, and the use of hyphens simply creates more opportunities for files to be almost identically named. KSSU-Moon.png and KSSU Moon.png could be two different files, and it is not the most effective to name them so similarly.

A hyphen (-), found on most keyboards, is not to be confused with a dash (—) or a minus sign (−).

For example, the following could all be be different files:
 * Kirby-Sword.png
 * Kirby - Sword.png
 * Kirby- Sword.png
 * Kirby -Sword.png

What's an NCR?
An NCR is a term I use to describe files that are almost identically named. Some examples would be:
 * Capitalization. (EX: File:KEY Dream Land.png and File:KEY dream land.png)
 * Extension difference. (EX: File:Marx being cool.jpg and File:Marx being cool.png)
 * Hyphens (EX: File:Meta Knight.png vs File:Meta-Knight.png vs File:Meta - Knight.png vs File:Meta- Knight.png vs File:Meta -Knight.png)

Why do you have symbols all over your sandbox?
I usually use them to be able to reference different types of images. Often, I will use the at sign @, dollar sign $, percent %, ampersand &, and dead key grave ` (and rarely asterism, usually for lists ⁂) to self categorize groups of images. For example, if I am going to need to fix the aboutfiles on a set of images, I might add % to them and do all of those images at the same time. Generally, they don't mean the same thing for the same section. Relatedly, symbols are added to edit summaries to avoid autofill taking up my screen space.

What are Smart Quotes? What are Smart Apostrophes?
Smart quotes and apostrophes are a type of quote that is not on a universal keyboard. They appear like this: (“|”|‘|’|’). They were essentially created to add style to the regular straight quotes (sometimes jokingly called dumb quotes) as seen here: ("|'). Since Smart Quotes do not appear on most keyboards as a standard, we try to avoid them the best we can. Some browsers/OS have automatic correction to smart quotes, especially apple products. These settings can be turned off in various settings pages. Notably, smart punctuation does not allow MediaWiki functions like italicize and bold to work.

Since some people may only be using smart quotes, pages that utilize quotations and apostrophes should have extra redirects made that utilize them.

Why do I keep seeing "Optimized" on files?
Image optimization is a LOSSLESS process in which an image has its metadata removed. Metadata is more text based, hidden information attached to files. Generally some metadata could include the date of capture, the file's dimensions, or type of camera used. While maybe useful for personal use, it's not necessary to have on the wiki. Hence, the emphasis on optimizing files.

There are a number of programs available to optimize files. The most popular are PNG Monstrous (formerly PNG Monster), which is universal in download and is extremely effective. Running command line optimizations, Zopfli and PNGOUT are very useful as well. The other is ImageOptim, which is generally a mashup of a bunch of optimizers. The pro to using ImageOptim is that it has support for four file types to be optimized: PNG, JPG, GIF, and SVG, with a con of being MacOS exclusive. An online alternative is EZGif, which is not the most effective method, but is a great "nothing else works" method.

Before uploading a new image or revision, images are encouraged to be optimized as it helps the user load the image more effectively and saves server space. Extremely frequently used icons and images, such as ones on high use templates, may also benefit from optimization to save on load time--though this is primarily for images that do not generate thumbnails.

As mentioned before, optimizing is a lossless process. Compression, which is sadly used interchangeably with optimizing, could mean either regular optimizing or the use of LOSSY compression. Lossy compression is where the image quality is reduced (by any varying amount) to make the file size smaller. LOSSY compression should not be used.

What's Gamma Brightening?
Gamma (Brightening) is a type of metadata stored on image files that change the way certain colors are displayed. Usually, it reduces the contrast amongst colors and is typically found on PNGs. While generally unwritten, the policy on gamma brightened photos is to optimize the file only if the original source does not use gamma brightening. If the source image contains gamma brightening metadata, it should not be optimized.

Why use OGA and OGV instead of OGG?
Way back yonder when the OGG format was introduced by Xiph.org, the only extension was .ogg; Since it became wildly much more popular in the later 2000s, they realized that the ability to have almost any type of file use OGG, they formally headlined the creation of different extensions such as OGA (Lossy Audio), OGV (Video), OGX (applications), and XFPF (weird code stuff that I don't understand). Per the creators suggestion, we should use the distinguished naming scheme.

Why can't I play this OGA/OGV file?
Unfortunately, while popular in the days of 2010, the global standard has dropped universal OGG support for reasons that have yet to really be explained. Some theorize it was because apple was trying to replace it with .mov and .m4a files, but this is conjecture. Generally, google chrome is a good browser to try and view this type of file on. If possible, it may be acceptable to re-rip as MP3 files.

I don't like the color difference for previously visited links
Weep no wider. Use the following custom CSS to revert back to all green links (this can be found under the "appearance" section of the preferences menu): a:link, a:hover, a:active, div#mw-panel a:link, div.vector-menu-content li a:link, div.vector-menu-content ul.vector-menu-content-list li.selected a:link, li a:hover { color: var(--link-internal, #378B00); }

/* Visited links' color */ a:visited, a:visited:hover, div#mw-panel a:visited, div.vector-menu-content li a:visited, div.vector-menu-content ul.vector-menu-content-list li.selected a:visited, li a:visited:hover { color: var(--link-visited, #378B00); } This change was ultimately performed for readers to meet standard web procedure, as well as helping the general editor base.

What makes a complete source?
A complete source on a file answers one question: Who is responsible for capturing or generating a file? There are almost exclusively three places a source will be taken from: you took the file yourself, in which case source=self is appropriate. Having the source be the game name, like |source=Splatoon 2, is not appropriate because that does not provide a name of a person or entity that we can give attribution to. Sourcing is about attribution—having the game name answers where the file might have come from, and is answered better in the |game and |description parameters. The second scenario for a complete source is a URL link to a website, such as Tumblr, Twitter, or the Spriters' Resource. The link needs to go directly to the page the image is used on. Simply saying "Twitter" or linking to the home page of Nintendo is not sufficient enough for a source. Clicking the link should take the reader directly to the same image, when possible. The third case would be for unreachable or print media, like SplatNet or The Art of Splatoon. These have direct variables in the |source= parameter, with a special message indicating that we cannot easily provide the source.

Why isn't the visual editor working?
If you are getting an error saying Parsoid/RESTBase server on a page: The visual editor does not work on pages with forward slashes (/). It's a known issue, but until then please use the source editor until then. If you need help with it, please feel free to ask here.

What's the difference between audio and music?
Audio is the larger circle that encompasses all sound that comes out of a given product. This includes music, sound effects, vocal lines, and anything else heard. Music is specifically just that—music. If given the choice between the two, music should be under music, anything else should be under audio.

How do I separate large sections on pages?
We've all been there. An image or an infobox sticks out of the way super weirdly and it needs to be broken up to some capacity. Consider using Template:Clr! All that is needed to be added is { {Clr}}. This will add a line break, splitting up content above and content below. Think of it similar to an invisible line that nothing is supposed to cross.

Why avoid sourcing FANDOM or subsidiaries?
The FANDOM company, broadly speaking, is not a good company. Despite the namesake, they are terribly anti-consumer with archaic and restrictive rules, and a focus more on SEO and advertising over accuracy and community. More specifically, the Splatoon Wiki hosted through FANDOM is notorious for outright stealing Inkipedia articles verbatim and posting it as their own content! We should not send traffic from our site to theirs, because leading members to an inferior product is generally an unethical practice, let alone to a competitor. Other notable subsidiaries (bought out by FANDOM) include GameSpot, GameFAQs, GiantBomb, TV Guide, Metacritic, Cord Cutter News, and Comic Vine. None of these outlets should be utilized unless absolutely necessary to do so.

Why avoid sourcing PidgiWiki
To cut to the chase, they do not appropriately source their own content, which could lead to fan-created materials being deemed official. Furthermore, without proper attribution, the wrong person could be listed as the source of a file. Most files typically taken from PidgiWiki are generally privately-issued press kit images—fortunately, I have access to both Nintendo and EA press kit materials. If you need me to look for something, ask!

What is StrategyWiki? Why do I keep seeing links to it?
StrategyWiki is a NIWA affiliate site that covers strategy guides for video games. Splatoon included! It hosts walkthroughs for the single player campaigns (Octo Valley, Octo Expansion, Return of the Mammalians, etc), which is better suited for that wiki than ours. As Inkipedia seeks to be an objective fact based site, a subjective walkthrough does not fit very well. Content can easily be transferred between the two via copypaste as long as a source is attributed via URL—both sites share a CC BY-SA 3.0 license for text.

StrategyWiki—also called ABXY—is also the web host of Inkipedia (and several other wikis), hence the purple button on the bottom of the page. There's plenty of guides to be written there, so if you're looking for a new project, why not consider giving it a look?

I've never used this template before
File is the primary image template Inkipedia uses to provide information on its File pages. This template does a lot in order to help organize files on your behalf, instead of you having to manually write a lot of things on your own. An example of the empty aboutfile template (which appears automatically in the summary box when uploading a new file) is as follows: Now, when actually filling out these parameters, you will almost certainly not need all of them, and many should be deleted when going through the template upon uploading. Lets look at each parameter and what they mean, and how each should be filled out.


 * |description=: This parameter is for writing a summary of what the file contains. A file description should be short and concise, requiring no more than one sentence to explain. For example, a piece of artwork of Judd from Splatoon 2 could simply be described as "Artwork of Judd from Splatoon 2."


 * |game=: This parameter is simple: Enter the name of the game or mode you are covering! Only one can be entered at a time, and files spanning multiple games should use the earliest chronological use. Enter the name exactly as displayed—the file will automatically link it for you!


 * |type= and |meta=: This parameter covers a lot of things at once. Primarily, this parameter is to indicate what type of file it is! The list of types is the following:
 * alternalog (Alterna Logs)
 * artwork (Artwork)
 * audio (Audio)
 * animated (Animated images)
 * music (Musics)
 * boxart (Box artwork)
 * barnsquid (Barnsquids)
 * brandlogo (Brand logos)
 * control (Controller buttons)
 * characterrender (Character renders)
 * characterart (Character artwork)
 * clothingicon (Clothing icons)
 * creditsartwork (Credits artwork)
 * diagram (Diagrams)
 * gearcloseup (Gear close-ups)
 * gearpromo (Gear promos)
 * headgearicon (Headgear icons)
 * icon (Icons)
 * logo (Logos)
 * lockericon (Locker icons)
 * line (LINE stickers)
 * map (Maps)
 * memcake (Mem cakes)
 * miiverse (Miiverse posts)
 * model (Models)
 * merch (Merchandise)
 * promotional (Promotional images)
 * photo (Real-world photos)
 * prerelease (Pre-release images)
 * pccu (Player customization close-ups)
 * rating (Rating icons)
 * render (Renders)
 * trailerscreenshot (Trailer screenshots)
 * screenshot (Screenshots)
 * shoeicon (Shoe icons)
 * stageicon (Stage icons)
 * stagemap (Stage maps)
 * sprite (Sprites)
 * splashtag (Splashtag banners)
 * sunkenscroll (Sunken scrolls)
 * splatfestart (Splatfest artwork)
 * splatfestwin (Splatfest win screens)
 * splatfestpromo (Splatfest promotional images)
 * system (System images)
 * user (User images)
 * video (Videos)
 * wallpaper (Wallpapers)
 * weaponrender (Weapon renders)
 * weaponartwork (Weapon artworks)
 * weaponicon (Weapon icons)
 * wiki (Inkipedia images)
 * Filling out this section is vital to help set up the automatic categorization. For all files that use |type=, they will be added into the entered game='s category. As an example, something with a |game=Splatoon 3 and a |type=shoeicon, the file will automatically be added to Category:Splatoon 3 shoe icons. Up to four types can be used, and should be separated with a comma. The |meta= category works similarly, only that that the types entered here will not look at the game for its category. For example, an image of a Nintendo Switch that needs to go with other systems will use |meta=System and be added into Category:System images. Files with no entered type will be added to a maintenance category.


 * |source=: This is a very important parameter. If you have a file that wasn't directly taken by yourself, it needs to be written or linked here. If you captured the file yourself, use |source=self. For images captured by other people, use |source=user and fill the next parameter below.


 * |user=: This parameter is unlikely to be used. It should only be filled with the name of the user for people that use |source=user or |type=user. For example, if Slate was the source of an image, you would enter |source=user and user=Slate.


 * |license=: This parameter is unlikely to be used. It is automatically filled in as fair use by default, and can usually be deleted. The only reason this parameter should be filled out is if a file should be licensed in any way other than fair use, such as public domain, creative commons, or something else. The options for this template are the following:
 * CC BY-SA 1.0
 * CC BY-SA 2.0
 * CC BY-SA 2.1
 * CC BY 2.5
 * CC BY-SA 2.5
 * CC BY 3.0
 * CC BY-SA 3.0
 * CC BY-SA 4.0
 * public domain (pd for someone else's work, pds if you release it)

I used File 1.0 before
The File 2.0 update brings a lot of new changes to the table, making the template a multi-use tool, where most components are controlled through the File template instead of the former system of File and Licensing templates and manually written categories.

The formatting to writing the template is the same, there are just new parameters from before.


 * |description= Still functions the exact same as before. Describe the file here.


 * |game=: This parameter is simple: Enter the name of the game or mode you are covering! Only one can be entered at a time, and files spanning multiple games should use the earliest chronological use. Enter the name exactly as displayed—the file will automatically link it for you!


 * |type= and |meta= This is the largest new addition to Aboutfile 2.0. This parameter replaces the former licensing templates like or  by integrating it directly into the template. Most of the names of the types are identical to the old licensing templates. This section should ALWAYS be filled out. If there is no type given, the file will be added to a maintenance category to be fixed as soon as possible. Primarily, this parameter is to indicate what type of file it is! The list of types is the following:
 * alternalog (Alterna Logs)
 * artwork (Artwork)
 * audio (Audio)
 * animated (Animated images)
 * music (Musics)
 * boxart (Box artwork)
 * barnsquid (Barnsquids)
 * brandlogo (Brand logos)
 * control (Controller buttons)
 * characterrender (Character renders)
 * characterart (Character artwork)
 * clothingicon (Clothing icons)
 * creditsartwork (Credits artwork)
 * diagram (Diagrams)
 * gearcloseup (Gear close-ups)
 * gearpromo (Gear promos)
 * headgearicon (Headgear icons)
 * icon (Icons)
 * logo (Logos)
 * lockericon (Locker icons)
 * line (LINE stickers)
 * map (Maps)
 * memcake (Mem cakes)
 * miiverse (Miiverse posts)
 * model (Models)
 * merch (Merchandise)
 * promotional (Promotional images)
 * photo (Real-world photos)
 * prerelease (Pre-release images)
 * pccu (Player customization close-ups)
 * rating (Rating icons)
 * render (Renders)
 * trailerscreenshot (Trailer screenshots)
 * screenshot (Screenshots)
 * shoeicon (Shoe icons)
 * stageicon (Stage icons)
 * stagemap (Stage maps)
 * sprite (Sprites)
 * splashtag (Splashtag banners)
 * sunkenscroll (Sunken scrolls)
 * splatfestart (Splatfest artwork)
 * splatfestwin (Splatfest win screens)
 * splatfestpromo (Splatfest promotional images)
 * system (System images)
 * user (User images)
 * video (Videos)
 * wallpaper (Wallpapers)
 * weaponrender (Weapon renders)
 * weaponartwork (Weapon artworks)
 * weaponicon (Weapon icons)
 * wiki (Inkipedia images)
 * Filling out this section is vital to help set up the automatic categorization. For all files that use |type=, they will be added into the entered game='s category. As an example, something with a |game=Splatoon 3 and a |type=shoeicon, the file will automatically be added to Category:Splatoon 3 shoe icons. Up to four types can be used, and should be separated with a comma. The |meta= category works similarly, only that that the types entered here will not look at the game for its category. For example, an image of a Nintendo Switch that needs to go with other systems will use |meta=System and be added into Category:System images.


 * |source= works the same way as before, with some new additions. For self-ripped or generated uploads, use |source=self. For files sourced from FANDOM, use |source=fandom (which will add to maintenance category). If there is no known source, leave this section blank! It will automatically be added to the unsourced files category. Lastly, if a user uploads a new revision of a file but isn't the source (IE optimizations or new re-takes of a file), utilize |source=user and read the following parameter.


 * |user= This is a somewhat rare and optional parameter that should only be used for |source=user sources, or for type=user files. This is how to indicate user images, in replacement of the former template.


 * |license is an optional parameter. In most circumstances, this will automatically be filled out as copyrighted fair use if anything is entered for the type= parameter. If a file needs a different type of license, such as Public Domain or Creative Commons, only then should this parameter be filled out. The options for this template are the following:
 * CC BY-SA 1.0
 * CC BY-SA 2.0
 * CC BY-SA 2.1
 * CC BY 2.5
 * CC BY-SA 2.5
 * CC BY 3.0
 * CC BY-SA 3.0
 * CC BY-SA 4.0
 * public domain (pd for someone else's work, pds if you release it)

Example
For example, let's observe this photo of Judd. This is an artwork of Judd from the original Splatoon game.

Description explains the point of the image. The game the image is from is the original Splatoon, so it is added with no modifications to the game parameter. The image itself is artwork of the character, so the type it is used for is artwork. The file came from the Squid Research lab, so it has been listed in the source parameter for where it came from.

Gallery of example images
Important to note: when using the

Other
''Additionally, please don't ask me about my personal life, I'd greatly appreciate it. I do make cool music for fun though''

Last seen doing: 

Today's fortune: