User:Mgkrupa/Wikipedia Info and Help

Wikipedia policy

Reverting/Content removal

Wikipedia:Revert only when necessary
- "your bias should be toward keeping the entire edit."
- "It is usually preferable to make an edit that retains at least some elements of a prior edit than to revert the prior edit."
- "Reverting is reversing a prior edit, in whole or in part."
"When removing a section of an article, it is necessary that it at least be explained, and in some cases, discussed. Unexplained removal of content is when the reason for the removal is not obvious, and is open to being promptly reverted."
"When removing content from an article, whether it be a whole section or even just a single word, if the removal is likely to be opposed by one or more other editors, it is important to make sure there is clearly a consensus to remove the content." [...] "If you boldly make the removal, and it is then reverted by another editor, it is especially important that you discuss it prior to making a second removal."
"When information is unsourced, and it is doubtful any sources are available for the information, it can be boldly removed."
"Editors can remove information that they personally added, provided that it has not since been significantly changed or used to support other information in the article. Once it has been modified, or the text is valuable in supporting other information, it should not be removed without good reason. "

Links

When and when not to add links.

Wikipedia:Manual of Style/Linking AKA MOS:LINK

MOS:LINK: "Do not unnecessarily make a reader chase links: if a highly technical term can be simply explained with very few words, do so."

WP:NOTTEXTBOOK: "While wikilinks should be provided for advanced terms and concepts in that field, articles should be written on the assumption that the reader will not or cannot follow these links, instead attempting to infer their meaning from the text."

MOS:NOFORCELINK: "Do use a link wherever appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links."

MOS:Internal links: "Articles on technical subjects might demand a higher density of links than general-interest articles, because they are likely to contain more technical terms that general dictionaries are unlikely to explain in context."

MOS:LEADLINK: "In technical articles that use uncommon terms, a higher-than-usual link density in the lead section may be necessary. In such cases, try to provide an informal explanation in the lead, avoiding using too many technical terms until later in the article"

See also Wikipedia:Make technical articles understandable (AKA WP:TECHNICAL) and WP:NOTTEXTBOOK
MOS:REPEATLINK: "if helpful for readers, a link may be repeated in [...] the first occurrence after the lead"

MOS:REPEATLINK: "Generally, a link should appear only once in an article, but if helpful for readers, a link may be repeated in infoboxes, tables, image captions, footnotes, hatnotes, and at the first occurrence after the lead."

"Duplicate links in an article can be found using the duplinks-alt sidebar tool."

MOS:LINK: "Do not be afraid to create links to potential articles that do not yet exist (see § Red links)." See also MOS:REDLINKS

Wikipedia:What is an article?

Wikipedia manual of style

Technical

WP:OBVIOUS: "State facts that may be obvious to you, but are not necessarily obvious to the reader."
WP:NOTTEXTBOOK: "Academic language. Texts should be written for everyday readers, not just for academics. [...] Academic language in the text should be explained in lay terms."
MOS:JARGON:
- "Avoid excessive wikilinking (linking within Wikipedia) as a substitute for parenthetic explanations such as the one in this sentence."
- "When the notions named by jargon are too complex to explain concisely in a few parenthetical words, write one level down. For example, consider adding a brief background section with {{main}} tags pointing to the full treatment article(s) of the prerequisite notions; this approach is practical only when the prerequisite concepts are central to the exposition of the article's main topic and when such prerequisites are not too numerous."

Related templates

{{Explain}}, {{Explain-wrap}}, {{Clarify}}, {{Clarify span}}, {{Technical inline}}
{{Ambiguous}}, {{Definition}}, {{Definition needed}}
{{Example needed}}

Assumptions about the reader

It is safe to assume that a reader is familiar with the subjects of arithmetic, algebra, geometry"
- For articles that are on these subjects, or on simpler subjects, it can be assumed that the reader is not familiar with the aforementioned subjects."
- "Any topics outside of that scope or more advanced than them a reader can be assumed to be ignorant of."
the reader "may have heard of calculus, but are likely unfamiliar with it."
"'Write one level down": "consider the typical level where the topic is studied (for example, secondary, undergraduate, or postgraduate) and write the article for readers who are at the previous level.
- Thus articles on undergraduate topics can be aimed at a reader with a secondary school background, and articles on postgraduate topics can be aimed at readers with some undergraduate background.
- Writing one level down also supports our goal to provide a tertiary source on the topic, which readers can use before they begin to read other sources about it."
- The lead section should be particularly understandable, but the advice to write one level down can be applied to the entire article, increasing the overall accessibility.

Assumptions about the reader (response about what can/can't be assumed)

We should [[Wikipedia:Make technical articles understandable]] and "[[MOS:MATH#TONE|as accessible as possible to readers not already familiar with the subject matter]]" who are presumed to be new to the subject.

Over time, I will try to make this article less technical. However, we first need to establish what assumptions can and can not be made about this article and its "typical" reader. According to Wikipedia:Manual of Style/Mathematics, and Wikipedia:Make technical articles understandable, and Wikipedia:Manual of Style this article should follow the following guidelines (as well as others not listed here). It should be be written "one level down", which means:

"consider the typical level where the topic is studied (for example, secondary, undergraduate, or postgraduate) and write the article for readers who are at the previous level." Also,
"articles on undergraduate topics can be aimed at a reader with a secondary school background, and articles on postgraduate topics can be aimed at readers with some undergraduate background."
"Articles should be as accessible as possible to readers not already familiar with the subject matter."
"When in doubt, articles should define the notation they use."
"If an article requires extensive notation, consider introducing the notation as a bulleted list or separating it into a "Notation" section."
"An article about a mathematical object should provide an exact definition of the object, perhaps in a "Definition" section after section(s) of motivation."
"Writing one level down also supports our goal to provide a tertiary source on the topic, which readers can use before they begin to read other sources about it."

I think that it is safe to assume that the reader has knowledge of calculus. But before we start editing this article to make it less technical, it's important to know what else we can assume about a "typical" reader of this article. This is important because, for example, whenever it is reasonable and possible to do so, then important terminology that a reader may not be completely familiar with (either entirely unfamiliar with it or just vaguely familiar with it) should be briefly defined/described within this article, instead of just having a link to the article about the term (this is because ideally, a "typical" reader should not have to go down a rabbit hole of Wikipedia links and search through various articles in order to understand something stated in this article; this may, for instance, be helpful with terms that have multiple meanings, e.g. "normal", or terms whose definition is found deep inside some article's body and not in the lead/introduction). So we need to agree on the following (non-exhaustive) list of assumptions before we can start rewriting this article:

Is it safe to assume that the reader is likely an advanced undergraduate or higher? (I personally think so).
Is it safe to assume that the reader is likely a graduate student or higher?
Is it safe to assume that the reader is likely a mathematics, physics, or engineering student?
Is it safe to assume that the reader has studied metric spaces? (I personally think that it is).
Is it safe to assume that the reader has knowledge of general topology (in particular, of non-metrizable topological spaces)?
Is it safe to assume that the reader has studied Banach spaces? (If not, then the Fréchet spaces and related notions that are used in this article will need more detailed explanations).
Is it safe to assume that the reader has studied Fréchet spaces? My guess is probably not and so the reader should not be assumed to know about Fréchet space. But if they are familiar with the basics of Banach spaces then the required knowledge for Fréchet spaces can be described using Banach space terminology.
Is it safe to assume that the reader has studied non-metrizable topological vector spaces? I think that this can not be assumed. However, unfortunately, neither the canonical LF topology nor the topology on the space of distributions is a sequential space so this topology can not be described using sequences (let along a metric). Suggestions about how to define and describe these topologies to readers who are not used to dealing with non-sequential (and also non-metrizable) spaces would be welcome. The current description of these topologies is (unfortunately) technical and I'd like for it to be less technical but I'm not sure how to make it less technical.

If it's sourced then explain why it should be removed. In general, if multiple authors who are experts in the article's subject matter thought that fact was important enough to include in their books/articles, then (assuming that it was added to the article) some justification should be given for its removal. In an ideal world, it should be discussed first on the talk page with notifications being given to major editors.

Writing guidelines

Punctuation

"authors should generally strike a balance between bare lists of facts and formulae, and relying too much on addressing the reader directly and referring to "we""

Layout/Organization

My relevant comments/discussions: Talk:Meagre set#About Mgkrupa's latest edit (June 2023)

Lead of article

See MOS:LEADELEMENTS for the structure/order of the lead.

In particular, {{Short description}} is always at the very top of the article's source code.

Lead of article

"The lead should stand on its own as a concise overview of the article's topic."
"It [the lead] should identify the topic, establish context, explain why the topic is notable, and summarize the most important points, including any prominent controversies."
WP:BETTER/GRAF1 (i.e. Opening Paragraph):"Normally, the opening paragraph summarizes the most important points of the article. It should clearly explain the subject so that the reader is prepared for the greater level of detail that follows."
"Editors should avoid lengthy paragraphs and overly specific descriptions – greater detail is saved for the body of the article."
"In general, introduce useful abbreviations, but avoid difficult-to-understand terminology and symbols. Mathematical equations and formulas should be avoided when they conflict with the goal of making the lead section accessible to as broad an audience as possible. Where uncommon terms are essential, they should be placed in context, linked and briefly defined."

"the lead contains a quick summary of the topic's most important points, and each major subtopic is detailed in its own section of the article."
"A fuller treatment of any major subtopic should go in a separate article of its own."

"The lead section should include, when appropriate:

Historical motivation, including names and dates, especially if the article does not have a "History" section. The origin of the subject's name should be explained if it is not self-evident.
An informal introduction to the topic, without rigor, suitable for a general audience. The appropriate audience for the overview will vary by article, but it should be as basic as reasonable. The informal introduction should clearly state that it is informal, and that it is only stated to introduce the formal approach. Include a physical or geometric analogy or diagram if it can help introduce the topic.
Motivation or applications, which can illuminate the use of the topic and its connections to other areas of mathematics or other non-mathematical subjects."

First/Lead sentence

Lead sentence of article

"The first sentence should tell the nonspecialist reader what, or who, the subject is. It should be in plain English."
"The lead should, as much as possible, be accessible to a general reader, so specialized terminology and symbols should be avoided."
"the lead sentence should include the article title [...] in bold along with any alternate names, also in bold."
"The lead sentence should state that the article is about a topic in mathematics"
"The lead sentence should informally define or describe the subject."
"Be wary of cluttering the first sentence with a long parenthesis containing alternative spellings, pronunciations, etc., which can make the sentence difficult to actually read; this information can be placed elsewhere."
"If its subject is definable, then the first sentence should give a concise definition: where possible, one that puts the article in context for the nonspecialist. Similarly, if the title is a specialized term, provide the context as early as possible."

Related templates

{{Lead rewrite}}, {{Improve lead}}

Math guidelines

Proofs

Notation, definitions, and symbols

Writing sentences'

"generalization. [...] can be put under a "Generalizations" section"
"Articles should be as accessible as possible to readers not already familiar with the subject matter."
"sentences should not begin with a symbol."
"Add a concrete example"
Explain formulae in English
"avoid [...] abbreviations such as wrt (with respect to), wlog (without loss of generality), and iff (if and only if)"
- "avoid [...] quantifier symbols ∀ and ∃ instead of for all and there exists."
"avoid contentless clichés as Note that, It should be noted that, It must be mentioned that, It must be emphasized that, Consider that, and We see that."
- See also MOS:NOTED, MOS:PRESUME, Wikipedia:Manual of Style/Mathematics#Writing style in mathematics
MOS:MATH#TONE: "Avoid, as far as possible, useless phrases such as:
- It is easily seen that, Clearly, Obviously, Makes clear, Naturally, Of course, Note that, Observe that, Recall
"The reader might not find what you write obvious. Instead, try to hint why something must hold, such as:
- It follows directly from this definition that ...
- By a straightforward, if lengthy, algebraic calculation, ..."
MOS:PRESUME: "phrases such as of course, naturally, obviously, clearly, and actually make presumptions about readers' knowledge"

Italics/Boldface/Emphasis

MOS:EMPHASIS - "Other, non-emphasis, uses of italics on Wikipedia should use ''...'' markup, not  or {{em}} markup." Footnote reads: "In particular, words as words, including introduced terms of art, and foreign words and phrases, use normal typographic italics (''...'' or ... markup, when necessary). Do not use emphasis markup as an "escape" for italic markup. If you have a situation that would result in something like ''War and Peace'''s plot (in which the '' followed by a possessive apostrophe is apt to be parsed as turning on boldfacing instead of ending the italics), you can rewrite to avoid the possessive, or use a proper escape in various forms, including: ''War and Peace''<nowiki />'s plot, War and Peace's plot, or ''War and Peace''{{'}}s plot."

Definitions/Notation

"When in doubt, articles should define the notation they use."
"An article about a mathematical object should provide an exact definition of the object, perhaps in a "Definition" section after section(s) of motivation."
- "When the topic is a theorem, the article should provide a precise statement of the theorem."
- "it may be better to separate the statement into its own section"
Definition section should come after motivation section(s).
- "perhaps in a "Definition" section after section(s) of motivation."
"definitions should be highlighted with words such as "is defined by" in the text."
"In definitions, the symbol "=" is preferred over "≡" or ":="."
"If an article requires extensive notation, consider introducing the notation as a bulleted list or separating it into a "Notation" section."
"When defining a term, do not use the phrase "if and only if""
- "If it is reasonable to do so, rephrase the sentence to avoid the use of the word "if" entirely. For example, An even function is a function f such that f(−x) = f(x) for all x. instead of A function f is even if f(−x) = f(x) for all x."
"Whenever a variable or other symbol is defined by a formula, make sure to say this is a definition introducing a notation, not an equation involving a previously known object."
- Ex: "Write: Multiplying M by the vector u defined by u = v − v₀, ... and do not write Multiplying M by u = v − v₀, ..."
MOS:NOITALIC: "A technical or other jargon term being introduced is often being mentioned as a word rather than (or in addition to) playing its normal grammatical role; if so, it should be italicized or quoted, usually the former."
MOS:NOBOLD: "Avoid using boldface for introducing new terms. Instead, italics are preferred (see § Words as words)."

Displaying formulas and symbols

Symbols

the English words "for all", "exists", and "in" should be preferred to the corresponding symbols ∀, ∃, and ∈.
"In definitions, the symbol "=" is preferred over "≡" or ":="."
"Sets are usually written in upper case italic"
"Italicize lower-case Greek letters when they are variables or constants (in line with the general advice to italicize variables):"
"do not italicize capital Greek letters"
"An article may use either boldface type or blackboard bold for objects traditionally printed in boldface. As with all such choices, the article should be consistent with itself, and editors should not change articles from one choice of typeface to another except for consistency. Again, when there is dispute, follow MOS:STYLERET."
"it is ideal to use < when writing the less-than sign"

LaTeX/HTML

"For a formula on its own line the preferred formatting is the LaTeX markup,
- with a possible exception for simple strings of Latin letters, digits, common punctuation marks, and arithmetical operators."
"section headings, which should use HTML only"
- Can use either LaTeX or HTML for formulas.
"If an inline formula needs to be typeset in LaTeX, often better formatting can be achieved with the \textstyle LaTeX command. By default, LaTeX code is rendered as if it were a displayed equation (not inline), and this can frequently be too big. For example, the formula <math>\sum_{n=1}^\infty 1/n^2 = \pi^2/6</math>, which displays as $\sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$ , is too large to be used inline. \textstyle generates a smaller summation sign and moves the limits on the sum to the right side of the summation sign. The code for this is <math>\textstyle\sum_{n=1}^\infty 1/n^2 = \pi^2/6</math>, and it renders as the much more aesthetic $\textstyle \sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$ . However, the default font for \textstyle is larger than the surrounding text on many browsers."
"an article should be internally consistent. In an already consistent article, editors should refrain from changing one style to another."
"use the {{math}} template to display your HTML formula in serif [font] as well. Doing so will also ensure that the text within a formula will not line-wrap"

Accessibility

MOS:INDENTGAP and Wikipedia:Indentation - About using :
- Use <math display="block"></math> instead of :<math></math> (Discussed here)

Accessibility and Unicode characters

This is about changing LaTeX code (i.e. <math></math>) into Unicode. This is discouraged in Wikipedia for WP:ACCESSIBILITY reasons. Specifically, some readers may be using browsers that either don't render certain Unicode (such as arrows → or ∈ ) or don't render it correctly. In addition, some Unicode characters might not be interpreted correctly by some screen readers. Here are some relevant quotes:

Wikipedia:Manual of Style/Mathematics#Special symbols - "Not all of the symbols in these lists are displayed correctly on all browsers (see Help:Special characters). Although the symbols that correspond to named entities are very likely to be displayed correctly, a significant number of viewers will have problems seeing all the characters listed at Mathematical operators and symbols in Unicode. One way to guarantee that an uncommon symbol is rendered correctly for all readers is to force the symbol to display as an image, using the <math> environment."
Wikipedia:Manual of Style/Accessibility#Links - "Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" cannot be reproduced into useful text by some screen readers."
MOS:BBB - "A particular concern for the use of blackboard bold on Wikipedia is that the Unicode symbols for blackboard bold characters are not supported by all systems, or that font substitution on browsers often render these symbols in discordant fonts. The use of Unicode characters for blackboard bold is discouraged in English Wikipedia. Instead, the LaTeX rendering (for example <math>\mathbb{Z}</math> or <math>\Z</math>) or the standard boldface must be used."
Wikipedia:Manual of Style/Mathematics#Fractions - "The use of Unicode precomposed fractions (such as ½) is discouraged entirely, for accessibility reasons" (Footnote) "Characters in ISO/IEC 8859-1 (¼, ½, and ¾) work with screen readers, but others, like ⅐, might not."
Help:Displaying a formula#Unicode characters - "Non-ASCII Unicode characters like $π$ work in MathML and MathJax but not in texvc so should currently be avoided."
MOS:FNOF

Other issues with Unicode characters are mentioned here: Wikipedia:Rendering math.

Here are some guidelines from Help:Displaying a formula#LaTeX vs. math template:

The disadvantages of {{math}} are the following: not all formulas can be displayed. While it is possible to render a complicated formula with {{math}}, it is often poorly rendered. Except for the most common ones, the rendering of non-alphanumeric Unicode symbols is often very poor and may depend on the browser configuration (misalignment, wrong size, ...). The spaces inside formulas are not managed automatically, and thus need some expertise for being rendered correctly. Except for short formulas, there are much more characters to type for entering a formula, and the source is more difficult to read.
Therefore, the common practice of most members of WikiProject mathematics is the following:

Use of {{mvar}} and {{math}} for isolated variables and very simple inline formulas

Use of LaTeX for displayed formulas and more complicated inline formulas

Use of LaTeX for formulas involving symbols that are not regularly rendered in Unicode (see MOS:BBB)

Avoid formulas in section headings, and when this is a problem, use raw HTML (see Finite field for an example)

And some more guidelines

MOS:FORMULA - "For a formula on its own line the preferred formatting is the LaTeX markup, with a possible exception for simple strings of Latin letters, digits, common punctuation marks, and arithmetical operators."
MOS:FORMULA - "Even for simple formulae the LaTeX markup might be preferred if required for uniformity within an article. For readability, it is also strongly preferred not to mix HTML and LaTeX markup in the same expression."
MOS:MATH#PUNC - "If the formula is written in LaTeX, that is, surrounded by the <math> and </math> tags, then the punctuation should also be inside the tags, because otherwise the punctuation could wrap to a new line if the formula is at the edge of the browser window."
MOS:NOTED - "avoid contentless clichés as Note that, It should be noted that, It must be mentioned that, It must be emphasized that, Consider that, and We see that." "Avoid, as far as possible, useless phrases such as: It is easily seen that ..., Clearly ..., Obviously ..."
MOS:MATH#TONE - "Articles should avoid common blackboard abbreviations such as wrt (with respect to), wlog (without loss of generality), and iff (if and only if), as well as quantifier symbols ∀ and ∃ instead of for all and there exists." Also avoid abbreviations like "iff", "i.e.", "e.g.", "resp." (spell them out instead: "if and only if", "that is", "for example", "respectively").

Wikipedia help

Help:Cheatsheet

Help:Advanced text formatting

Content translation

References

Wikipedia:Reliable sources/Perennial sources − "This is a non-exhaustive list of sources whose reliability and use on Wikipedia are frequently discussed. This list summarizes prior consensus and consolidates links to the most in-depth and recent discussions from the reliable sources noticeboard and elsewhere on Wikipedia."
For notation used in the article, "Articles should contain some references that support the given usage."

Order and content of Notes, Citations, and References sections. From Help:Explanatory notes

Examples from: Help:Explanatory notes#Shortened footnotes with separate explanatory notes:

Markup

Renders as

The Sun is pretty big.<ref name=Foot01/><ref group=Note name=Note01/> But the Moon<ref group=Note name=Note02/> is not so big.<ref name=Foot02/><ref group=Note name=Note03/> The Sun is also quite hot.<ref name=Foot03/>

==Notes==
{{reflist|group=Note|refs=
<ref name=Note01>But Miller points out that the Sun is not as large as some other stars.</ref>
<ref name=Note02>The Moon goes by other names, such as Selena - see, for example Jones, ''The Solar System'', MacMillan, 2005, p 623.</ref>
<ref name=Note03>Historically the Moon was not always considered to be large, see, for example, Peterson, ''Astronomy'', MacMillan, 2005, p 623.</ref>
}}

==Citations==
{{reflist|refs=
<ref name=Foot01>Miller, p. 23</ref>
<ref name=Foot02>Brown, p. 46</ref>
<ref name=Foot03>Smith, p. 334</ref>
}}

==References==
{{refbegin}}
* Brown, ''The Moon'', Penguin. 2001.
* Miller, ''The Sun'', Oxford, 2005.
* Smith, ''The Universe'', Random House, 2005.
{{refend}}

The Sun is pretty big.^[1]^{[Note 1]} But the Moon^{[Note 2]} is not so big.^[2]^{[Note 3]} The Sun is also quite hot.^[3]

Notes

^ But Miller points out that the Sun is not as large as some other stars.
^ The Moon goes by other names, such as Selena - see, for example Jones, The Solar System, MacMillan, 2005, p 623.
^ Historically the Moon was not always considered to be large, see, for example, Peterson, Astronomy, MacMillan, 2005, p 623.

Citations

^ Miller, p. 23
^ Brown, p. 46
^ Smith, p. 334

References

Brown, The Moon, Penguin. 2001.
Miller, The Sun, Oxford, 2005.
Smith, The Universe, Random House, 2005.

Footnotes

Help:Shortened footnotes = WP:SRF: "Explanatory or content notes are used to add explanations, comments or other additional information relating to the main content. One of the reasons they may be used is to avoid making the text too long or awkward to read."
"Some or all of the footnotes can also be defined within the reference section/list, and invoked in the page content. This keeps those citations in one central location for easier maintenance and avoids cluttering the text."
- See example here WP:LDR
"For the basic reference list, add {{reflist}}"
- "<references /> may be seen instead of {{reflist}}. This is valid,
- but <references /> does not offer the advanced features of {{reflist}}."
"The main reference list is placed in a separate section, usually titled "References", "Notes" or the like."
"using {{reflist}}, the list can be split into columns. {{reflist|xxem}} where xx is the column width in em. By setting the width in em, the number of columns will automatically be adjusted to the width of the display. It should be used only when necessary, as the template has built-in auto-formatting capabilities providing a useful display in most scenarios by itself."
- "{{reflist|30em}}: Where there are many footnotes plus a page-width Bibliography subsection"

{{Notelist}} and {{efn}}

{{notelist}} can be used in place of {{reflist|group=note}}.
{{efn}} can be used in place of <ref group=note>.

Sentence.{{efn|Footnote 1}} Sentence.{{efn|Footnote 2}} 
Sentence.{{efn|Footnote 3}}

== Notes ==
{{notelist}}

Images/Galleries

[[File:Flag of France.svg|link=|link=France|thumb|frame|frameless|border|left/right/center/none|upright (or upright=0.56)|x60px|120px|120x60px|baseline|alt=TextForReadersBrowsingWithImagesOff|TextThatGoesBelowTheImage]]

{{multiple image}}

{{clear}} - "As a final resort, you can force the browser to insert a break, making all text and pictures appear below"

Galleries

<gallery>
File:Wiki.png|Caption 1
File:Wiki.png|Caption 2
</gallery>

Manual of Style for Images

WP:STACKING - "multiple pictures sometimes stack up vertically, particularly with large screens and wide images."
- See also Wikipedia:Extended image syntax#The many-floating-objects problem

Tools for finding images/videos

Meta-Wiki:Free image resources – where to find free images for use in Wikipedia
- Meta-Wiki:Free image resource#Search Enginess
  - search.creativecommons.org (Openverse) − Search for Creative Commons-licensed and public domain content.
- Wikimedia:Free image resource#General collections
Commons:Free media resources

Misc

Wikipedia:Keyboard shortcuts

common.js at en.wikipedia
global.js at metawiki
vector.js - Preferences for popup menu and other such things at en.wikipedia
vector.css - Skin and Wikipedia preferences at en.wikipedia

[Note01-2] But Miller points out that the Sun is not as large as some other stars.

[Note02-3] The Moon goes by other names, such as Selena - see, for example Jones, The Solar System, MacMillan, 2005, p 623.

[Note03-5] Historically the Moon was not always considered to be large, see, for example, Peterson, Astronomy, MacMillan, 2005, p 623.

[Foot01-1] Miller, p. 23

[Foot02-4] Brown, p. 46

[Foot03-6] Smith, p. 334

[1]

[Note 1]

[Note 2]

[2]

[Note 3]

[3]

v t e Wikipedia technical help
Get personal technical help at the Teahouse, help desk, village pump (technical), talk pages or IRC.
General technical help	Browser notes Bypass cache Keyboard shortcuts Editing CharInsert Edit conflict Edit toolbar Reverting How to create a page IRC Tutorial Mobile access Multilingual support Page history Page information Page name Help Printing Software notices Editnotice Special Characters Entering User access levels VisualEditor Help
Special page-related	Special page help AllPages Edit filter Emailing users Logging in Reset passwords Logs Moving a page History merging Non-admin and admin-only page moves Notifications/Echo FAQ Page Curation Page import Pending changes Random pages Recent changes Related changes Searching Linksearch Tags User contributions Watchlist What links here
Wikitext	Wikitext Cheatsheet Columns Line-break handling Lists Magic words For beginners Conditional expressions Switch parser function Time function Redirects Sections and TOCs Tables Introduction Basics Advanced table formatting Collapsing Conditional tables Sortable tables Using colours
Links and diffs	Links Interlanguage Interwiki Permanent Diffs Simplest diff guide Simple diff and link guide Complete diff and link guide Colon trick Link color Pipe trick URLs
Media files: images, videos and sounds	Media help Files Creation and usage Moving files to Commons Images Introduction to images Picture tutorial Preparing images for upload Uploading images Options to hide an image Extended image syntax SVG help Gallery tag Graphics tutorials Basic bitmap image editing How to improve image quality Graphics Lab resources Sound file markup Visual file markup
Other graphics	Family trees Graphs and charts How to create Barcharts To scale charts Math formulas Math symbols Musical scores Musical symbols Timeline EasyTimeline syntax WikiHiero syntax
Templates and Lua modules	Templates Advanced template coding Template documentation Template index Template limits Template sandbox and test cases Citation templates Lua help Lua project Resources To do Substitution Purge Job queue Transclusion Labeled section Costs and benefits Guide to Scribbling
Data structure	Namespaces Main/Article Category Draft File File description page Help Portal Project/Wikipedia Talk Archiving Simple Template User User page design MediaWiki Bug reports and feature requests TimedMediaHandler extension Module Special
HTML and CSS	Cascading Style Sheets HTML in wikitext Catalogue of CSS classes Common.js and common.css User CSS for monospaced coding font Classes in microformats Markup validation Span tags Useful styles
Customisation and tools	Preferences Gadgets Skins Citation tools Cleaning up vandalism tools Customizing watchlists Hide pages IRC Scripts User scripts Guide List Techniques User style Tools Alternative browsing Browser tools Editing tools Navigation shortcuts Optimum tool set Wikimedia Cloud Services Beta Features at MediaWiki
Automated editing	AfC helper script AntiVandal AutoWikiBrowser Bots Creating history HotCat Huggle Navigation popups RedWarn Twinkle Ultraviolet WPCleaner Inactive igloo STiki
See also: Category:Wikipedia how-to Category:Wikipedia information pages Further navigation at: Help pages Administrators Accessibility Accounts Bots Referencing Citation metadata Templates User scripts

Wikipedia policy

Reverting/Content removal

Links

Wikipedia manual of style

Technical

Assumptions about the reader

Writing guidelines

Layout/Organization

Lead of article

First/Lead sentence

Math guidelines

Notation, definitions, and symbols

Displaying formulas and symbols

Accessibility

Wikipedia help

See also section

References

Footnotes

Images/Galleries

Tools for finding images/videos

Misc