Please remember that WiKirby contains spoilers, which you read at your own risk! See our general disclaimer for details.

User:Trig Jegman: Difference between revisions

From WiKirby, your independent source of Kirby knowledge.
Jump to navigationJump to search
mNo edit summary
Tag: Reverted
m (Undo revision 332737 by Trig Jegman (talk) the spooky goblin is back)
Tag: Undo
Line 6: Line 6:
A user most known for file management. Founder and lead developer for Sourcemageddon. Currently placed in maintenance cyro-stasis due to having successfully cured all maintenance categories, and as such is only semi-active. <small>''See also: [[User talk:Trig Jegman|The talk page]], [[User talk:Trig Jegman/Sandbox|The sandbox]], [[Wikirby:Project Clean-Up|Project Clean-Up]], [https://discord.gg/r5EnGPpsyW Updates Discord].''</small>
A user most known for file management. Founder and lead developer for Sourcemageddon. Currently placed in maintenance cyro-stasis due to having successfully cured all maintenance categories, and as such is only semi-active. <small>''See also: [[User talk:Trig Jegman|The talk page]], [[User talk:Trig Jegman/Sandbox|The sandbox]], [[Wikirby:Project Clean-Up|Project Clean-Up]], [https://discord.gg/r5EnGPpsyW Updates Discord].''</small>


 
<!--
<div class="notice-template" style="display:flex;text-align:justify;background:#f88;margin:0.375em 2% 0.75em;padding:0 1em;border:1px solid #840;color:black;font-weight:bold">
<div class="notice-template" style="display:flex;text-align:justify;background:#f88;margin:0.375em 2% 0.75em;padding:0 1em;border:1px solid #840;color:black;font-weight:bold">
This user will not be online from ''May 8th'' to ''May 15th'' of the year ''2022''. Something must be seriously wrong if you need him, but he'll get back to you on his talk page ASAP.  
This user will not be online from '''' to '''' of the year ''''. Something must be seriously wrong if you need him, but he'll get back to you on his talk page ASAP.  
</div>  
</div> -->
__TOC__
__TOC__



Revision as of 11:14, 17 May 2022

It has been requested that this article be rewritten to be comprehensible to the human race.

A user most known for file management. Founder and lead developer for Sourcemageddon. Currently placed in maintenance cyro-stasis due to having successfully cured all maintenance categories, and as such is only semi-active. See also: The talk page, The sandbox, Project Clean-Up, Updates 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.
  • TR = Technical Rename - removing or changing things like punctuation, unnecessary numbers, or files with weird issues in them. Files should have no punctuation other than a sparingly used hyphen.
  • 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 <Gallery> 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.

Notes

If a note below has sufficiently been addressed, it can be removed. See also: My sandbox

General/Miscellaneous

  • Total edits (in thousands): 18.3 - 22:07, 27 January 2022 (UTC)
  • Any files starting in KMSC need optimized. Trust me on this one. - 00:54, 18 October 2021 (UTC)
  • Numerous files have very poor transparency that is likely only to be seen with a dark mode. This seems to be a very common trend for Moydow uploads, Anime artwork rips, and Moydow anime artwork rips. Some users may want to download and utilize the trial for NightEye or a similar dark mode service to help spot and flag more of these uploads. - 15:51, 25 October 2021 (UTC)

Trig How to Rename Files

While I have done the best I can to justify my reasoning, this section is almost entirely unofficial, so take it with a pillar of salt.

Please read these several official file help pages first. It is a much broader, official guide and is more likely to answer questions before I do. I will use the file File:Trig Demonstration Example File.png as an example in this demonstration.


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.

If you decide to preserve the user/user talk pages as well, open them up and do the same replacement if possible. Some user talk pages are protected, meaning the images are unable to be replaced. This is okay. This stuff happens. Not all images last forever, and that is why it is okay User pages don't need attention. If you can replace any images, edit ONLY the file name and nothing else. Indicate in the summary very clearly why a talk page or archive was edited. I use the term FNC, file name change, but as long as people understand why, it is acceptable.

Once all pages have been addressed, go to the created redirect and mark it with the {{delete}} 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.

How to use aboutfile

I've never used this template before

Aboutfile is the primary image template WiKirby 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:

{{aboutfile
|description=
|game=
|media=
|modified=
|type=
|type2=
|source=
|license=
}}

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 Kirby from Kirby Super Star Ultra could simply be described as "Artwork of Kirby from Kirby Super Star Ultra."
  • |game= and |media=: These two parameters are an either/or situation. Primarily, |game should be used for any single-game images. Only the direct American name of the game should be entered into this parameter (IE |game=Kirby Super Star) with no additional formatting. Entering a game into the |game= parameter will do two main things: An italicized link will be generated pointing to the game, and the file will be added to the appropriate game category. A file with "|game=Kirby & The Amazing Mirror" will display "Kirby & The Amazing Mirror" and it will be added to the Kirby & The Amazing Mirror images category. If a game is not the subject, multiple games are the subject, or automatic links won't work/aren't wanted, use the |media= parameter instead. Regardless of what parameter is selected, the other should be removed.
  • |modified=: This parameter is optional, and if not used should be deleted. This is primarily for files with significant edits or changes to them. Was a background removed? Is the image upscaled? Were arrows and numbers made for an informational diagram? If so, say so in this parameter. Filling this parameter will automatically place the file in the doctored images category.
  • |type= and |type2=: 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:
    • audio (For audio files)
    • photo (For real-world images)
    • sprite (For sprites)
    • screenshot (For user-generated screenshots for video games or web pages)
    • officialscreenshot (For officially released screenshots, usually promotional material)
    • officialmiiverse (For any Miiverse posts by official Kirby sources)
    • officialaudio (For any audio published by HAL or Nintendo)
    • map (For maps)
    • flag (For real-world country flags)
    • model (For 3-D Models)
    • artwork (For any artwork)
    • boxart (For any physical box art, or cover art that serves as a substitute–particularly for online-only games)
    • logo (For game or series logos)
    • user (For user images)
    • tv (For screenshots of television or video media, particularly of the Anime series)
    • scan (For scans of physical media or digital copies of printed work)
    • wiki (For images relating to Wikirby as a platform)
    • food (For real-world images involving Kirby Café)
    • ppp (For Channel PPP Twitter posts)
    • directory (For Dedede Directory Twitter posts)
    • gamereports (For all other Twitter posts)
    • rating (For real-world game ratings, such as ESRB or CERO)
Filling out this section will do several things in addition to specifying the file type. First, it will add the file into its respective category. A |type=screenshot will add the file to the Category:Screenshots. Additionally, filling out this parameter automatically gives the file a license, which is extremely important for fair use purposes. If two types are necessary, |type2= can be used. If not, |type2= can be deleted.
  • |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 Samwell was the source of an image, you would enter |source=user and user=Samwell.
  • |license=: This parameter is unlikely to be used. It is automatically filled in if the |type= parameter is filled out, 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.

I used Aboutfile 1.0 before

The Aboutfile 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 Aboutfile template instead of the former system of Aboutfile 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= and |media= function relatively the same, but have a critical change from before. Aboutfile 2.0 automatically will link and italicize a file written in the |game= parameter, as well as automatically categorize the file to the game written. |media will do none of these things and media/categories will need to be manually written.
  • |modified= Still the same as before, except that filling this parameter will now place the image automatically in the Doctored images category. Are there significant edits to the photo done? Add it here.
  • |type= and |type2= This is the largest new addition to Aboutfile 2.0. This parameter replaces the former licensing templates like {{game screenshot}} or {{artwork}} by integrating it directly into the template. Most of the names of the types are identical to the old licensing templates. |type=artwork is the same as {{artwork}}. Type will also automatically categorize the file based off of its type, so |type=artwork will add to Category:Artwork. In cases where a file might apply to two different types, type2= enables a second type+category to be added. There is no priority or hierarchy to the order types are entered (IE type= is not more important than |type2=). 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.
  • |source= works the same way as before, with some new additions. For self-ripped or generated uploads, use |source=self. For files sourced from Kirby Wiki 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, in lieu of using the old {{File Source}} template. 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 with a file search, in replacement of the former {{Personal Media}} 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.

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.

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 jpg, just to have a sense of uniformity and to avoid issues when auto-filling parameters.

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.

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.

Gallery of example images

Important to note: when using the <gallery> tag, the "File:" part does not need to be added.


Other

Bandana "Lady Slayer" Waddle Dee

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:

5 March 2024

Today's fortune: When in doubt, remove all the hyphens

User:Trig Jegman/Footer