User:Mgkrupa/Wikipedia Info and Help

Reverting/Content removal

 * 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.
 * 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 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


 * What is an article?

Wikipedia manual of style

 * Manual of Style/Mathematics
 * Make technical articles understandable

Technical
 WP:OBVIOUS: "" 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" 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. 
 * 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."
 * 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)




 * 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 Manual of Style/Mathematics, and Make technical articles understandable, and 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."</li>
 * "If an article requires extensive notation, consider introducing the notation as a bulleted list or separating it into a "Notation" section."</li>
 * "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

<ol> <li>"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""</li> <li></li> </ol>

Layout/Organization

 * My relevant comments/discussions: Talk:Meagre set

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

<ol> <li></li> <li>"The lead should stand on its own as a concise overview of the article's topic."</li> <li>"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."</li> <li>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."</li> <li>"Editors should avoid lengthy paragraphs and overly specific descriptions – greater detail is saved for the body of the article."</li> <li>"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."</li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> </ol>

<ol> <li>"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."</li> <li>"A fuller treatment of any major subtopic should go in a separate article of its own."</li> </ol>

"The lead section should include, when appropriate: <ul> <li>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.</li> <li>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.</li> <li>Motivation or applications, which can illuminate the use of the topic and its connections to other areas of mathematics or other non-mathematical subjects."</li> <li></li> </ul>

First/Lead sentence
Lead sentence of article

<ol> <li>"The first sentence should tell the nonspecialist reader what, or who, the subject is. It should be in plain English."</li> <li>"The lead should, as much as possible, be accessible to a general reader, so specialized terminology and symbols should be avoided."</li> <li>"the lead sentence should include the article title [...] in bold along with any alternate names, also in bold."</li> <li>"The lead sentence should state that the article is about a topic in mathematics"</li> <li>"The lead sentence should informally define or describe the subject."</li> <li>"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."</li> <li>"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."</li> </ol>

Related templates



Math guidelines
Proofs

Notation, definitions, and symbols
Writing sentences'

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

Italics/Boldface/Emphasis

<ul> <li>MOS:EMPHASIS - "Other, non-emphasis, uses of italics on Wikipedia should use  markup,   or  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   (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: ,  , or  ."</li> </ul>

Definitions/Notation

<ol> <li>"When in doubt, articles should define the notation they use."</li> <li>"An article about a mathematical object should  provide an exact definition of the object , perhaps in a "Definition" section after section(s) of motivation." </li> <li>Definition section should come  after  motivation section(s). <li>"definitions should be highlighted with words such as "is defined by" in the text."</li> <li>"In definitions, the symbol "=" is preferred over "≡" or ":="."</li> <li>"If an article requires extensive notation, consider introducing the  notation as a bulleted list or separating it into a "Notation" section ."</li> <li>"When defining a term, do not use the phrase "if and only if"" <li>"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." <li>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."</li> <li>MOS:NOBOLD: "Avoid using boldface for introducing new terms. Instead, italics are preferred (see § Words as words)."</li> </ol>
 * "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"
 * "perhaps in a "Definition" section after section(s) of motivation."</li>
 * "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(&minus;x) = f(x) for all x. instead of  A function f is even if f(&minus;x) = f(x) for all x."</li>
 * Ex: "Write: Multiplying M by the vector u defined by u = v − v0, ... and do not write Multiplying M by u = v − v0, ..."</li>

Displaying formulas and symbols
Symbols

<ol> <li>the English words "for all", "exists", and "in" should be preferred to the corresponding symbols ∀, ∃, and ∈.</li> <li>"In definitions, the symbol "=" is preferred over "≡" or ":="."</li> <li>"Sets are usually written in upper case italic"</li> <li>"Italicize lower-case Greek letters when they are variables or constants (in line with the general advice to italicize variables):"</li> <li>"do  not  italicize capital Greek letters"</li> <li>"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."</li> <li>"it is ideal to use &lt; when writing the less-than sign"</li> </ol>

LaTeX/HTML

<ol> <li>"For a formula on its own line the preferred formatting is the LaTeX markup, <li>"section headings, which should use HTML only" <li>"If an inline formula needs to be typeset in LaTeX, often better formatting can be achieved with the  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 &lt;/math&gt;, which displays as $$\sum_{n=1}^\infty 1/n^2 = \pi^2/6$$, is too large to be used inline. 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 &lt;/math&gt;, and it renders as the much more aesthetic $$\textstyle\sum_{n=1}^\infty 1/n^2 = \pi^2/6$$. However, the default font for  is larger than the surrounding text on many browsers."</li> <li>"an article should be internally consistent. In an already consistent article, editors should refrain from changing one style to another."</li> <li>"use the  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"</li> <li></li> <li></li> </ol>
 * with a possible exception for simple strings of Latin letters, digits, common punctuation marks, and arithmetical operators."</li>
 * Can use either LaTeX or HTML for formulas.</li>

Accessibility

 * MOS:INDENTGAP and Indentation - About using
 * Use  instead of   (Discussed here)

This is about changing LaTeX code (i.e. ) 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:


 * Manual of Style/Mathematics - "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 &lt;math> environment."
 * Manual of Style/Accessibility - "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  or  ) or the standard boldface must be used."
 * Manual of Style/Mathematics - "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 - "Non-ASCII Unicode characters like $\pi$ work in MathML and MathJax but not in texvc so should currently be avoided."
 * MOS:FNOF

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

Here are some guidelines from Help:Displaying a formula:

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 - "If the formula is written in LaTeX, that is, surrounded by the  and   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 - "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

See also section
<ol> <li>"Editors should provide a brief annotation when a link's relevance is not immediately apparent, when the meaning of the term may not be generally known, or when the term is ambiguous." <li>"The links in the "See also" section should be relevant, should reflect the links that would be present in a comprehensive article on the topic, and should be limited to a reasonable number."</li> <li>"As a general rule, the "See also" section should repeat links that appear in the article's body. (The community has rejected past proposals to do away with this "rule". See, for example, this RfC.)"</li> <li>"Consider using or  if the list is lengthy."</li> <li>"The list should be sorted either logically (for example, by subject matter), chronologically, or alphabetically."</li> <li>" links are usually placed in this section."</li> <li></li> <li></li> </ol>
 * "If the linked article has a short description then you can use annotated link"</li>

Images/Galleries



 * multiple image


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


 * Galleries


 * Manual of Style for Images


 * WP:STACKING - "multiple pictures sometimes stack up vertically, particularly with large screens and wide images."
 * See also Extended image syntax

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

 * 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