MarioWiki talk:Image use policy

Rule change

 * Images should be optimized and not exceed 5 megabytes in file size.
 * Images' dimensions should be in the original size and never exceed 5000 pixels in width or height.
 * Images cannot exceed an area of 12.5 million pixels or about 3500x3500 for a square image.

This rule should be changed because original, official artwork, namely, scenic artwork from recent games, such as this, this, this, this, this, this, this, and this must be resized according to that policy.

But I'm not sure why this rule is here. Is it for fair use or is it to prevent the wiki from carrying the burden of a large image? 14:23, 23 February 2014 (EST)
 * Maybe you can take this to the forums in the General Discussion topic? 16:06, 23 February 2014 (EST)
 * I think it would be very large. This wiki should only summarize the games, artworks are just an addition. PidgiWiki is an example of wikis that can contain any size of artworks.-- 15:43, 24 February 2014 (EST)


 * The rule is suspended until further notice. We might get serious on restrictions, but not necessarily those restrictions, and we don't want to have to resize everything twice. -- 16:21, 24 February 2014 (EST)
 * Ok, thanks, Steve! 19:28, 24 February 2014 (EST)

MediaWiki Headers
I think this project page can be better organized with the use of MediaWiki headers instead of four bullet points with sub-bulletpoints. Something to the effect below. -- 05:02, 8 February 2016 (EST)
 * This would make the page neater, it's fine by me. -- 22:08, 8 February 2016 (EST)
 * I think it's unnecessary. There's only four points, so it's pretty straightforward to find what you're looking for, and the screenshots and aboutfile points really don't seem substantial enough for full sections. The fact that the whole page is currently a (relatively) compact list is also a good thing, since people tend to not want to read long, multi-faceted policy pages. - 23:42, 8 February 2016 (EST)
 * The headers would make the rules more clear and faster to identify. Nobody likes walls of text. My suggestion was to make it more visually appealing or at least a less daunting read. The other MarioWiki pages use headers. -- 01:32, 9 February 2016 (EST)
 * I have decided to create a sandboxed version of this page to show what changes I am looking to implement: User:Wildgoosespeeder/MarioWiki:Image Use Policy -- 20:24, 9 July 2016 (EDT)

Cropping Letterboxing Mandated
and I have been talking about the quality of our image uploads and we are quite split if mandating cropping is a good idea. I suggest reading the talk page section (User talk:Porplemontage) to get an idea where our stances are with it. Thoughts? -- 03:30, 3 May 2016 (EDT)
 * How to cut this:
 * Koops shyness.png
 * I tried it with MS Paint and the resulting pic looks pretty "incomplete".  21:53, 5 May 2016 (EDT)
 * I'm not too keen on cropping screenshots as I said before but I can make exceptions if it is trying to zoom in on something, such as the Thorny Flower first picture. -- 23:07, 5 May 2016 (EDT)

1) Completely empty black border: crop out completely to the edge of the active image, every time (well, with the sole exception of "if the black border is part of the point' of uploading the image"). 2) Black border with text box impinging - case by case, but the general rule should be to crop roughly to the edge of the text box (not the text itself), including any black border visible against the active image.

So in the case of File:Koops shyness.png, this:
 * http://i.imgur.com/X6xKEKGs.jpg

would be my default. Although this is a case where you can get away with cropping all the way to the edge of the active image and it looks okay (sometimes, there's text either right on the edge of the black border, or actually inside it). *previews, is surprised it actually embeds the imgur image, changes to linked thumbnail* - Reboot (talk) 23:23, 5 May 2016 (EDT)
 * But that crop just looks even more odd than cropping Paper Mario images. -- 00:20, 6 May 2016 (EDT)
 * PM Koopa Bros Toad.png (right) doesn't look odd to me.
 * Remember that the Paper Mario screen area was allowing for 10%ish overscan. The average player simply would not have seen most (or even all in some cases) of the black area. - Reboot (talk) 00:39, 6 May 2016 (EDT)
 * The case on the right: I'd like to see the remaining black border part made transparent.  01:05, 6 May 2016 (EDT)


 * I see the black border on my HDTV playing the game on real hardware through composite video. -- 15:08, 6 May 2016 (EDT)
 * Now try watching it on a 2000-era (say, bought in 1997 or 1998) CRT television. - Reboot (talk) 18:30, 6 May 2016 (EDT)
 * I'm not entirely sure we can rely on that because Nintendo did put in a "Screen Position" setting on the GameCube and Wii to correct any off-center screen positioning due to possible manufacturing defects of those CRT TVs. I know that has nothing to do with Paper Mario but it should shed light for CRT TVs. I had to use this setting to correct my old Toshiba CRT TV before I went to a Vizio HDTV. Also how a CRT TV processes input varies from TV to TV. With an HDTV, they are pretty consistent displaying correctly. -- 18:57, 6 May 2016 (EDT)
 * ...that lack of consistency and presence of overscan is the entire point I was making. Yes, LCD TVs are more consistent. With Paper Mario, they were playing to the lowest common denominator of 4:3 CRT viewable area (so did other games in terms of "safe" picture area. It was just that PM blacked out the "unsafe" area rather than putting non-essential graphics there). - Reboot (talk) 12:01, 8 May 2016 (EDT)

I'm good with cropping right across the top (1). Transparency is an interesting idea. -- 01:16, 6 May 2016 (EDT)
 * Like I said, you can get away with it with that image and it looks fine, but not in every case. The Paper Mario ones cut the dialogue too close to the top for that to look okay (note that the Battle HUD - File:PMBowserBattle1.png - has a 202-height active area as well). I've edited Koopa Bros. Toad.png (right) to have those two partially-surviving rows of black pixels be transparent - it looks fine, but it's more work to do. - Reboot (talk) 07:45, 6 May 2016 (EDT)

Well, if the screenshot is put on articles at the original size, that the transparent part by the top side of the picture will show as white. Since we have #f9f9f9 frames for pictures, If the picture has dark colors, this will make a "light gray--white--dark" contrast, which does not look good in my opinion. Thoughts? 11:27, 9 July 2016 (EDT)


 * We gotta keep thumb's background white so transparent character artwork looks good, so it's good. -- 18:12, 9 July 2016 (EDT)
 * Something I was wondering about the other day in relation to this sprite - is there an extension or something that would allow the background colour to be specified for an image? (A syntax something like file.ext .) - Reboot (talk) 18:20, 9 July 2016 (EDT)
 * Not that I know of, but I'll look into it. -- 18:29, 9 July 2016 (EDT)

Here is another issue: Super Paper Mario dialog boxes are the same black as the letterboxing and borders! -- 18:50, 26 May 2016 (EDT)
 * Only if you have your Wii set to narrowscreen/4:3. If you have it set to widescreen, there's no letterboxing. - Reboot (talk) 15:56, 28 May 2016 (EDT)
 * The image to the right needs to be recaptured anyways. That isn't my screenshot though. That's been there longer than I have been contributing (November 2015 even though I registered in 2010). Even with that said, I think the game controls the letterboxing on the top and bottom of the screens by inserting it when triggering a dialog sequence then makes it disappear when resuming control of the player character. The left and right letterboxing isn't supposed to be there. Bad cropping on the uploader's part. Here's what widescreen Super Paper Mario is supposed to look like: File:Hammer Whacker.PNG -- 15:59, 28 May 2016 (EDT)
 * ...that's not Super Paper Mario.
 * And I have Super Paper Mario running, on a Wii, right beside me. The game is not letterboxing, either in cutscenes or in gameplay. - Reboot (talk) 16:06, 28 May 2016 (EDT)
 * Unless I am thinking that Paper Mario: The Thousand-Year Door has that letterbox control. It's been a little while since I last played through the story and got the exact point the right picture is referencing. The image I linked to is from Super Paper Mario. It was taken from Flipside Arcade. -- 16:14, 28 May 2016 (EDT)
 * Okay, but it still isn't representative of the general UI/etc.
 * This is a photo, not a screenshot, but it shows what happens when you trigger a dialogue sequence with widescreen engaged. No borders (all the black is the actual bezel of the TV and beyond - I turned the light out to take the picture): http://imgur.com/j6W1TxX - Reboot (talk)
 * I think what I was trying to say about the Flipside Arcade image was what the widescreen mode looks like dimensionally so that way you can see if the game inserts letterboxing like I know Paper Mario: The Thousand-Year Door does. So would you require widescreen screenshots of Super Paper Mario so we don't have to put up with this odd cropping or transparency of screenshots? 4:3 screenshots are just as valid for this Wiki. -- 17:58, 29 May 2016 (EDT)
 * Require widescreen (which, since they don't waste a big chunk of the screen with empty black letterboxing, are automatically higher-resolution!). Besides, per the directive that started this discussion, the letterboxed ones *are* less valid than unletterboxed widescreen! (Direct comparisons notwtithstanding) - Reboot (talk) 18:51, 29 May 2016 (EDT)

Super Mario Galaxy dialogs for sure have an issue. The dialog box is translucent (alpha channel has a value somewhere between 0 and 255, which perfect transparency has a value of 255 for each pixel). Cropping would be wrong because it loses consistency with the rest of the dialog box and picture. Transparency is also wrong because part of the letterboxing is preserved caused by the overlapping translucent dialog box. How do we accommodate that? Also, we need to make sure we capture at native resolution (not always 854x480 or 640x480) because there is some filtering and blur applied to the rounded edges of the dialog box as well. Native resolution would likely not have this. Currently, that isn't accurate to take native resolution screenshots of Wii games at this current time. -- 01:59, 16 June 2016 (EDT)


 * Wildgoosespeeder: Border back but only for a few seconds. I still don't like the policy but I think if I upload two versions of the image, I won't have such a gripe with the policy.

...seriously?

No, I mean, SERIOUSLY?!? This coming from the PNG monster? - Reboot (talk) 17:39, 9 July 2016 (EDT)
 * No need to be disrespectful when addressing someone. Anyways, what does PNG Monster have to do with cropping screenshots? That's just a program to reduce file size of PNGs (doesn't affect the contents of the image). -- 18:04, 9 July 2016 (EDT)
 * Uploading an image twice is twice the size of a single upload. - Reboot (talk) 18:07, 9 July 2016 (EDT)
 * But only the current version of the image will be used. The other versions are archived. -- 19:31, 9 July 2016 (EDT)
 * I really didn't like the Paper Mario images due to the four large and uneven black borders. The Mario Galaxy images are fine, I'll update the policy so you can leave them as they are. -- 18:12, 9 July 2016 (EDT)


 * The rules you have decided months ago and updated moments ago don't really make a whole lot of sense to me. It's hard to come up with a uniform rule that fits each game nicely. That's why I have been questioning your decision. This is why I just upload an uncropped screenshot. Far easier. -- 18:35, 9 July 2016 (EDT)


 * It's pretty simple. The way that the Paper Mario images were cropped before your re-uploads was good. I didn't like the new black borders. The whole policy change was just a way to make those images look the way they used to, except of course with the better quality retained. Got it? -- 19:10, 9 July 2016 (EDT)
 * But why are you excusing Super Mario Galaxy from this rule? I'll just list the cons of cropping off the borders:


 * Not what real hardware produces, which is part of the image policy. The image is edited if cropped, so should reflect this change. If it is not mentioned, it's misleading. Then I will be OK with cropping.
 * This could make galleries in look kind of off when displaying screenshots. The title screen of Paper Mario is 320x237 while the game play screenshots are less than that. This can make pages using  look weird and off as well. -- 19:31, 9 July 2016 (EDT)


 * The general rule is that we don't crop, which Mario Galaxy follows. Think of Paper Mario as an exception to this rule, due to how terrible four large black and uneven borders look. It looks worse than your cited gallery problem, in my humble opinion. So note the crop in aboutfile line #4. -- 19:44, 9 July 2016 (EDT)

So note the crop in aboutfile line #4
 * Make it part of the policy? Then I will be much more satisfied with this policy change.

If the screenshot needs to be cropped to remove black borders or have transparency be added if a game element overlaps the black border, note it in, parameter 4. -- 19:52, 9 July 2016 (EDT)
 * I don't think it is necessary to mention cropping in #4, for the same reason Wikisource doesn't mention that it has "changed" the font or the layout of the original documents.  02:34, 17 July 2016 (EDT)
 * But it is a modification of the unaltered screenshot (or image that gets cropped). It should be documented if such an edit takes place. -- 02:44, 17 July 2016 (EDT)
 * It is a modification of the .png file output by the emulator, but what if you don't use the emulator's "screenshot" feature, but instead use the "Snipping Tool" that comes from Windows 7+? In the latter case, the borderless screenshot isn't modified at all.  03:49, 17 July 2016 (EDT)
 * You should be using the emulator's screenshot button. The reason is that it reads what the real output is (it's usually as close as possible to the real hardware's output). Only in odd cases should you use the snipping tool (or equivalent methods). I have had issues with MESSUI emulating CD-i using its screenshot button, but the screen resolution is always 384x280 for the Mario games we cover (including the letterboxing that should be cropped), so properly setting up MESS for the snipping tool fixes the issue. Other than that, just mention you use the snipping tool so that way if someone stumbles across your upload and it says so, they can compare with a non snipping tool screenshot of theirs to judge if a new upload tagging as cropped is required. Just out of curiosity, why do you use the snipping tool? Something wrong with BizHawk, similar to MESS? If so, show me a screenshot generated by BizHawk. -- 04:20, 17 July 2016 (EDT)
 * No, I don't use the snipping tool at all. But just as people have the freedom to choose what operating system to use to contribute to the encyclopedia -- Windows, Linux, Mac, etc. -- they should also have the freedom to choose how they take their screenshots, as long as they're of the same quality. What I'm worrying about is that snipping tool users will be compelled to act as if they were using the emulator method, even if they have done no modification at all. (Indeed, one of the great advantages of snipping tools is that you don't need to crop, if it's properly set up.)  09:31, 17 July 2016 (EDT)
 * [Note: I tried both methods of taking a Paper Mario screenshot and they're indeed of the same quality.  10:00, 17 July 2016 (EDT)]
 * [Another note: cropping is not editing the content of the screenshot. It isn't misleading either because the average readers of MarioWiki are players and look at screenshots to know what is on the screen, not how big the screen is or how much the screenshot differs from real hardware output.  12:36, 17 July 2016 (EDT)]
 * Real hardware doesn't crop. I trust the emulator screenshot button. I checked the NES, SNES, N64, GCN, and Wii and they relatively match. Therefore, cropping the image for MarioWiki is editing the screenshot. -- 15:18, 17 July 2016 (EDT)

I still don't agree. First, there isn't a rule in the image policy that says the hardware output is the only "correct" version of a screenshot and whatever disagrees with it is inauthentic. Second, the purpose of having screenshots on the wiki is to show the reader what is on the scene. It is only on a wiki like The Cutting Room Floor that being faithful to the hardware is important. 15:36, 17 July 2016 (EDT)
 * Hey, wait a minute -- it isn't my goal to argue whether cropping qualify as modification, and I was arguing over that like an idiot. All I ask is that people should be allowed to upload borderless Paper Mario screenshots without saying that they have "cropped" the picture in #4, since it is possible that they are honest.  15:53, 17 July 2016 (EDT)
 * I guess it is possible that there are people that don't know any better. My WIP screenshot guide is my attempt to better inform screenshot submitters the expected output of an emulator screenshot. If it matches, it's valid. Once validated, it can then be cropped, if necessary, as deemed by the policy. My WIP hasn't been modified to reflect the recent change in policy. Not sure of the best way to word it. -- 17:43, 17 July 2016 (EDT)
 * But what about snipping tool users? Why are you ignoring their feeling?  23:04, 17 July 2016 (EDT)
 * Another problem is that it compels the editors to think that cropping is modification, whether they agree or not.  23:30, 17 July 2016 (EDT)
 * Again, the intention of my WIP is to inform everyone submitting screenshots of expected outputs of emulator-taken screenshots, even snipping tool users. Snipping tool users should say they used the tool in the edit field. Doesn't matter if you agree cropping is editing. By definition alone, cropping is editing. It's like YouTubers video editing to zoom in or edit junk out of the raw footage or pictures they choose to include in their videos. -- 23:43, 17 July 2016 (EDT)
 * ''Snipping tool users should say they used the tool in the edit field.
 * OK, Now I feel better!  23:53, 17 July 2016 (EDT)
 * ↑ EDIT: mis-stated this sentence. My intention is to say that cropping doesn't affect the content of the screenshot. It _is_ a modification of the hardware output, though.  06:40, 19 July 2016 (EDT)

↑ 1 Aug 2016 update: Now hardware output has been explicitly mentioned in MW:UPLOAD. This should be no problem as long as people who use other methods are well informed of what the hardware output is. 23:39, 31 July 2016 (EDT)

First Time For a Certain User
I plan on uploading a screenshot I took of a Flying Roulette Block from Super Mario 3D Land, but I don't understand the policy completely and hope for no mistakes on my first try on uploading an image. I would appreciate some help to overcome this insecurity. 296lmn20 (talk) 11:09, 13 March 2017 (EDT)296lmn20


 * Hi there. In a nutshell, the policy on screenshots states that the resolution should ideally be close to the actual hardware (which is 400x240 for 3DS gameplay screenshots). If you're taking the screenshot from YouTube, the resolution would be affected (although it's still acceptable to upload). Another important thing is to give the file a meaningful name when uploading it: I'd suggest "SM3DL Shot - Flying Roulette Block". If you have any specific questions, don't hesitate to ask away.


 * 18:48, 13 March 2017 (EDT)


 * Thank you, but before I finalize this, I still have to ask about the summary. Do I just add what I need to input after the prompt sentence, or do I have to replace the prompt sentence with the information needed?296lmn20 (talk) 11:54, 14 March 2017 (EDT)296lmn20
 * Yes, you replace the prompt sentence with the information. If you make any mistakes, it is not a big problem as they are very easy to correct. -- 12:00, 14 March 2017 (EDT)
 * Note that you don't need to fill every section with some relevant information. If, for example, the image has no edits, you can simply remove the fourth section. Also keep in a mind that each image usually requires a relevant category as well, beyond the one added by the license. In this case, Category:Super Mario 3D Land Images should be included at the bottom of the summary. 12:45, 14 March 2017 (EDT)

Differences Between Formats Explained Better Than I Ever Could
Here's a video that explains the differences between formats and what image format is best for what situation, better than I ever could. Would it make a great link to refer to for this policy page? -- 19:28, 16 May 2017 (EDT)

Bitmap
Just curious, why is that format "forbidden?" Can the wiki just not render them properly? Doc von Schmeltwick (talk) 01:38, 21 October 2017 (EDT)
 * It's uncompressed. Converting to PNG is fine as the original BMP is preserved 100%. -- 01:53, 21 October 2017 (EDT)

Uploading
Why can't I upload an image? Starclimber the NightWing (message) 15:05, 12 May 2018 (EDT)
 * To be able upload images, you must be autoconfirmed. To become autoconfirmed, you must have your account for four days and make at least five edits. -- 15:09, 12 May 2018 (EDT)
 * This also relates to creating your user page, in response to your question on 's page. 15:10, 12 May 2018 (EDT)

Why do you have to be autoconfirmed to upload images?Starclimber the NightWing (message) 15:17, 12 May 2018 (EDT)
 * The restriction prevents vandals from being able to join and upload spam images. -- 15:20, 12 May 2018 (EDT)

Dashes
The dash (-) is easy enough to type on keyboards, so I don't see why it should be forbidden from filenames. 13:20, September 26, 2019 (EDT)
 * As I told Trig, I'm already working on this. 13:24, September 26, 2019 (EDT)

Screenshots
What about use Screenshot YouTube to take 1080p screenshots?


 * If you can't get native-resolution screenshots, YouTube screenshots are fine. The former are preferable, but not required. 21:07, October 31, 2019 (EDT)

On renaming files
Should the policy on renaming files be made stricter? The comments on this proposal indicated that this would be better suited to a discussion than a proposal, so that's why I'm starting the topic here.

My suggested changes to the policy on renaming files are as such:
 * Renaming files based simply on easy-to-type symbols (like hyphens, commas, and parentheses) should be discouraged.
 * The rule on renaming files that already describe the topic accurately should be enforced more strictly. (There are countless times when I've seen a reason to move the files back, but don't want to flood the Recent Changes with renames should I actually rename them all back.)

20:58, November 4, 2019 (EST)
 * So, I talked to the other admins about this about a month ago. That was the point behind this change and this change, for the respective bullet points. Files containing punctuation that is also used in the subject's name and files that are already clear enough should not be moved. Files with unnecessary punctuation should be moved to remove them, as it can be confusing when trying to find the file if a file is named "File:Mario-SM64-Artwork (2).png". I also understand consistency with file names, that is part of why we are requiring "png" over "PNG". But we aren't incredibly strict with file names because there isn't really a reason to do so, it kind of takes the fun out of it. Zelda Wiki and Fire Emblem Wiki use strict file name policies, and it's honestly a bit difficult for me to find "File:Ma 3ds02 adventurer vallite enemy.gif" (this is an actual file name) rather than "File:Vallite Adventurer 3DS Enemy Map Sprite.gif", for example. 01:36, November 5, 2019 (EST)
 * now I will get back to this when I actually have some spare time, but I would like to help make a guided list of acceptable punctuation (officially declared or not) and potentially devise a more effective plan for dealing with the many pre-existing file names. Again, if there is one specifically you would like to discuss, please tell me. Trig - 18:06, November 5, 2019 (EST)


 * Okay, to start I'd like to address why I most specifically address hyphens: They enable more duplicate or super similar names for files, and create quite a lot of confusion. As an example, simply the difference between using File:MP3-Star and File:MP3 Star is the difference between two different files in existance. Using a space for the hyphen makes it even worse, as I have seen a multitutde of games that use a combination of the following options;
 * File:MP3- Star
 * File:MP3 - Star
 * File:MP3 -Star
 * File:MP3 Star
 * Four different files could be virtually identically named, and that is not taking into consideration that the capitalization of file names (MP Star vs MP star vs Mp Star) also impacts file distinguishment. To fully disclose, unless there are two virtually identical named files with name capital differences, I do not move files just to change the capitalization of the file name itself, and when I do, I usually indicate when that is the case under NCR. To avoid using hypens that are not related to the file would limit the amount of confusing duplicated file names present in many games. This is not to say hyphens cannot be used, as such enemies like Cheep-Cheeps or other hyphenated terms exist, but it is to say that '''the amount of hyphens being used currently is excessive and not necessary.


 * Similar things can be said for various other punctuation symbols. Some of which are not as common as believed, but simply just overcomplicate the process involved. I have yet to encounter a single file name in which a parentheses set is required, and the use of periods in files is not always fantastic for coding purposes. Apostrophes are also interesting to note because there appears to be a variety of them available to use (as I mention [[User:Trig Jegman#Notes|here for Waluigi's Reign). While I believe apostrophes are are acceptable to use, it does lead the possibility of other alternate punctuation marks being available that other people use.


 * I do everything to be easy to understand first and organized second. I know I can harp on and on about the Game Abbreviation-Subject-File Type.extention format that I hold on to--which I did not make, but was rather about 55-60% of the norm and made the most linear sense--being used, but I do not apply to this to files that would only be formatted this way to be organized. File:Melty Molten Galaxy SMG early volcano.png is not in the aforementioned format, but it's name is appropriate and will not necessarily appear in another form (artwork/rendering) and hence I did not move it. The movement of File:World A-3LL.png to File:SMAS LL World A-3 Title Card.png was appropriate because the prior name did not mention it was a title card, and the extremely identical naming to the same level with File:World A-3.png and File:WorldA-3SMBTheLostLevels.png, it needed further distinguishment from the other two varieties (map and level screenshot). Placing it into the format made sense, as it was standardizing a chaotic assortment of files. Sometimes, a file that would be like SBLSBSMS, which would mean sirena beach legendary sand bird super mario sunshine, makes sense to change and expand out upon to reduce confusion.


 * In my opinion, as I have stated a many a time now, is that the image use policy should be rewritten more for the initial naming of files and should be extremely clear about what SHOULD be used, and what should NOT be used, as the current writing comes off as though it is an acceptable gray area. I do not think that any punctuation that is not an apostrophe, hyphen, or ampersand should be used for any file whatsoever, and the three mentioned should only be used when it applies to the file name (Mario's Glove in Luigi's Mansion) or the game series name (Game & Watch Gallery 2). I believe a SPLIT SECTION should be written for the renaming and movement of files (maybe using some of what I already have? about what specifically should be addressed in the movement and understanding the purpose of doing so. This section sould also include the full process of moving, replacing name on a page, and flagging redirects for deletion because it isn't really well demonstrated here.


 * Some other things to truly stress standardizing is the use of fully lowercase extentions, the use of jpg over jpeg, and splitting ogg to be the appropriate oga/ogv. Aboutfiles should exist on all pages (I have passed a few that did not have any).


 * on a smaller last note, I think we should dissuade the use of APNGs and rather suggest gifs to be used.


 * Thanks for hearing my input. Leave a talk page message if you need me. Trig Jegman (but it's mama luigi to you) - 19:24, November 5, 2019 (EST)

Typos

 * 1) "SVG is great alternative" -> "SVG is a great alternative".
 * 2) "i.e. Japanese kana or Greek letters" -> "e.g."
 * 3) "or apostrophes that is used" -> "or apostrophes that are used".

RickTommy (talk) 03:01, May 19, 2020 (EDT)
 * Fixed the first and last one. "i.e." is being used correctly. 23:16, May 1, 2021 (EDT)