Help: Edit summary
It's good practice to fill in the Edit Summary field, or add to it in the case of section editing, as it helps everyone to understand what is changed, such as when perusing the history of the page. It's a good idea to set your user preferences (under Editing) to "Prompt me when entering a blank edit summary". (If you really want to keep it empty, you can just confirm the message or enter a blank space to avoid the message.)
In the case of applying substitution, providing the line of wikitext containing "subst:" in the edit summary is especially useful, because otherwise substitution does not show up as such in the page history.
The edit summary box can hold one line of 800 characters, with a size no more than 1000 octets (the latter restriction never has an effect on 7-bit-ASCII-text, but in UTF-8, any non-ASCII character occupies 2 to 4 octets). If you attempt to type or paste more, only the first 800 characters will be displayed and the rest will be disregarded. For example, attempting to add 10 new characters at any location within a summary already containing 795 characters will result in the truncation of all text after the 800th character.
In edit summaries, internal links work with some limitations, see below.
Other wikitext code is not interpreted:
- Variables, templates, and parser functions are not expanded.
- External links do not work.
- HTML tags do not work.
- Italics, bold, etc, do not work (edit summaries are rendered in italics by default).
<nowiki>tags do not work; thus e.g. [[a]] cannot be displayed (it will be rendered as <nowiki>a</nowiki>). One could use [[a]] (with a zero-width space between the brackets on the left) or [ [a] ] instead.
When pressing preview, a preview of the edit summary is displayed, along with a preview of the edited page. While the summary may be too long to be seen in the input box without scrolling, it will be displayed in its entirety on the history page.
Pressing Enter in the edit summary box has the same effect as pressing "Publish changes". Be careful not to do this by accident while typing the edit summary, because the unfinished edit summary may not make sense and cannot be changed. A subsequent dummy edit such as adding an extra space somewhere which does not change the rendered page, gives the opportunity to supply a correct edit summary for the previous edit.
Linking to a section
An anchor name enclosed between /* and */ produces a right arrow linking to a specified anchor on the page, followed by the anchor name with CSS class "autocomment": → Anchor text. It is similar to the wikitext "<span class="autocomment">[[#Anchor name|→]] Anchor text</span>"".
Separators are automatically provided when needed (i.e. between /* */ syntax and text in either order). For example, the edit summary:
/* Foo */ test /* Bar */ test
is rendered as:
For more flexibility these special anchor links can be replaced by ordinary links to pages redirecting to the desired anchors; see also below.
When editing an existing section, the section title is inserted at the beginning of the edit summary, enclosed with /* and */ marks, for example /* External links */.
If the section name is changed it is useful to change it in the edit summary accordingly, so that the section link still works as such (until the name of the section is changed again, as the links do not change retroactively).
If you create a new section before or after an existing section by clicking a section "edit" link, change or delete the text between /* and */ marks, to avoid confusion.
Details of the edit should be added after this text. In the case that you provide a long summary yourself you can consider deleting the section title in order to stay within the limit of 800 characters, depending on what is more important.
In the case of using the pipe trick, the pipe is ignored (but the link works).
The links can be checked in the preview of the edit summary.
What links here does not list links in edit summaries.
If a link target contains a %-sign followed by two hexadecimal digits the link does not work, and the link label shows up as plain text without brackets; in the case of a piped link the info what the link target is, is lost.
Thus, while in the wikitext of the page itself [[DCCWiki:Village_pump_%28technical%29#Abc]] and [[DCCWiki:Village pump (technical)#Abc]] are equivalent, giving DCCWiki:Village_pump_(technical)#Abc and DCCWiki:Village pump (technical)#Abc, only the latter works in an edit summary.
In a URL, all characters other than [[-:/.]], the digits 0-9, and the plain letters A-Z, a-z, are coded with once or twice a %-sign followed by two hexadecimal digits (follow the link to confirm that these four characters are not affected).
The codes occur in practice when a page name contains special characters (characters other than those mentioned), and a link to a section of that page is made by copying part of the URL to that section, which in turn is produced by a TOC link. This is not the case if only the section name contains special characters, because in a URL they are coded with a point followed by the hexadecimal digits. So the anchor itself does not give problems, the fact that there is an anchor makes it convenient to use the URL, which gives this problem.
Workarounds to get a working link in the edit summary include:
- use the URL, but replace the codes by the characters concerned by hand (this is not convenient in languages where many characters are coded)
- apply a redirect to arrive at the page, e.g. w:WP:VPT,
- apply the TOC link, get the part of the URL from the page name, if applicable add the interwiki prefix again, and use the result as link target in the page as well as in the edit summary
- assemble the combination pagename, #, section name oneself; the page name can be copied from the page header, or, if it has a short redirect, the pagename can also easily be typed: we get w:WP:VPT#Abc where the anchor is typically easier to copy (being longer than here), but the rest is just typed.
Since edit summaries cannot be edited after saving the page, moving the contents of a link target can be a problem, and this frequently happens: the move to an archive is often even predictable.
- In the case of a page move a redirect is created; however, when the old name is needed for a new page, the link is not targeted correctly anymore.
- In the case of a link to a section, when the name of the section is changed, an anchor can be made with the old name of the section.
- In the case of a link to a section, if content is moved to another section, the link will still target the old section.
- In the case of a link to an explicitly put anchor, the anchor can be moved with the content, provided that other links to the anchor need to target the other position too.
Anticipating these problems one can do the following:
- make a link to a page with a name that accurately and unambiguously describes the required target
- if this page does not exist, create a redirect to the desired page, possibly with an anchor.
While the edit summary remains the same indefinitely, the redirect can be changed whenever needed.
This method is also useful for replacing the automatic section link: It provides flexibility with regard to renaming of sections.
"Post a comment" feature
When starting a new thread on a Talk page or page with __NEWSECTIONLINK__, the "Post a comment" feature can be used. Click the plus sign next to the Edit link (MonoBook skin). A box labelled "Subject/headline" appears before the main editing box and the "Edit Summary" text box will not appear. Text typed into the subject field becomes both the edit summary and a new heading (which is added to the end of the page), and text entered into the main edit box is inserted below this heading.
See also help about adding a section at the end.
In certain circumstances, an automatic summary is generated when an edit is saved without one. This is slightly different from the summary added when editing a section, as that can be modified by the user before saving.
|Creating or replacing a page with a redirect
('$1' is replaced with the target of the redirect)
|MediaWiki:Autoredircomment||Redirected page to [[$1]]|
|Removing all text from a page||MediaWiki:Autosumm-blank||Blanked the page|
|Removing most of the text from a page, or editing a short page
('$1' is replaced with the page text)
|MediaWiki:Autosumm-replace||Replaced content with "$1"|
|Creating a new page ($1 is replaced with the page text)||MediaWiki:Autosumm-new||Created page with "$1"|
With the exception of the automatic summary when creating a redirect, which usually says all that needs to be said, these are not a substitute for a proper edit summary – you should always leave a meaningful summary, even in the above cases. They are, however, useful in providing some context for edits made by inexperienced users who are not aware of the importance of edit summaries, and for spotting vandalism.
For some kind of edits, the software adds a special tag, like "⧼tag-mobile_edit⧽" or "Manual revert".
Places where the edit summary appears
The edit summary appears in black italics in the following places:
- Page history - list of edits of a specified page; also shows the size of the wikitext in bytes, for edits from 19 April 2007 (for Wikimedia wikis).
- User contributions - list of edits by a specified user
Temporarily (see MediaWiki manual about $wgRCMaxAge):
- Watchlist - list of recent changes to watched pages (logged-in users only); also shows the change in size of the wikitext in bytes; use the enhanced watchlist to see all recent changes in the watched pages, not just the last change in each page
- diff page - shows the difference between two edits
- Recent changes / enhanced recent changes - list of all recent edits; also shows the change in size of the wikitext in bytes
- Related changes - list of recent changes to pages linked to a specified page; also shows the change in size of the wikitext in bytes
- List of new pages - shows the edit summary of the creation; also shows the current size of the wikitext in bytes
The edit summary also appears in the e-mail received in the case of e-mail notification.
See also help about change tracking.
File upload summary
When uploading an image one can supply an upload summary. This serves multiple purposes:
- as the second part of the automatically created edit summary of the upload log (the first part giving the file name)
- as text in the entry of the image history
- in the case that the file name of the image is new:
- as the edit summary for the creation of the image page
- as wikitext for the editable part of the image page, which includes the following possibilities:
- briefly describe the image
- provide internal or external links
- call templates
- specify one or more categories the image is in
The capacity of the upload summary is one line of 250 characters; In the upload log the last part may fall off, because this can contain 255 characters, including "uploaded "filename"".
Note that there is no preview function to check the code for the links, template calls and category tags, but of course, if needed one can edit the image page after uploading, to correct errors and also to extend the text.
See also help about image page.
Changing an edit summary
Changing an edit summary is cumbersome and requires importing (hence this has to be enabled on the wiki and the user needs to have that user right): export the page with history, delete the page, make the change in the xml file, and import it again. To change the edit summary of the current revision one can also export the page without history, delete the page, restore it except the last revision, make the change in the xml file, and import it again.
The import log shows the import of the page, with user name, date, time, and number of revisions. The deletion log shows the deletion and, if applicable, restoration, with user name, date, and time. The "View and restore deleted pages" feature shows deleted revisions. There is no easy way (like a diff) to see what changes were made. In the case of multiple deletions and imports or restorations it is not recorded which revisions existed when in the regular page history, so it is not possible at all to know what was changed in the last delete/import operation.
The Wikimedia search function cannot search edit summaries, and they are not indexed by external search engines.
Always fill in the summary field. This is considered an important guideline. Even a short summary is better than no summary. An edit summary is even more important if you delete any text; otherwise, people may question your motives for the edit. Also, mentioning one change but not another can be misleading to someone who finds the other one more important; add "and misc." to cover the other change(s).
Accurate summaries help people decide whether it is worthwhile for them to check a change. We've found that summaries often pique the interest of contributors with expertise in the area. This may not be as necessary for minor edits, but "fixed spelling" would be nice even then.
In the case of a small addition to an article, it is recommended to copy the first one or two sentences of this addition to the summary field, giving a maximum of information with a minimum of effort. Put ft in front, as an abbreviation of "full text" (see the Abbreviations section for other abbreviations). This way, readers of the summary will be unlikely to check the page itself as they already know the extent of the edit. It also makes it easy for color-blind or visually impaired readers to see punctuation and other tiny changes that may be difficult to discern (this was especially true before the new diff view in MediaWiki 1.20). It also helps users to check recent changes, page history and user contributions (see below) very efficiently, and reduces the load on the servers.
For longer additions, you should write a short summary of the changes you have introduced into the article. For an addition of, say, 800 characters you can also save time by simply copying that into the summary field.
Unfortunately you can copy only one line of text from the edit box into the edit summary box. The contents of further lines can be pasted at the end of the line. Thus, for example, a bulleted "see also" list is cumbersome to put in the edit summary box. One possible workaround for a new list is putting the list on one line, separated by the asterisks for the bullets, copying it to the edit summary box, and then, in the main edit box, inserting line breaks before the asterisks.
In addition to a summary of the change itself, the summary field may also contain an explanation of the change; note that if the reason for an edit is not clear, it is more likely to be reverted, especially if you have deleted some text. To give a longer explanation, use the Talk page and put in the edit summary "see Talk".
After saving the page, the summary cannot be edited — another reason to avoid spelling errors.
In the case of important omissions or errors in the edit summary, you can make a dummy edit just to put the correction in the edit summary.
Experienced users, especially those with many edits to make, will often use abbreviations in edit summaries (as well as log entries), in order to save time; for example, "rv" for "revert". These should be used with care, as they can be confusing for inexperienced users, but they are generally fine for small edits such as formatting and grammar changes. See Edit summary legend for a list of commonly used abbreviations in edit summaries.
Protection or move actions also generate entries in page the history. This entry is also limited to 1000 octets, and consists of action descriptions and user provided comments.
Action descriptions, such as "moved XX to YY", is created from current system messages in site language. As a result, it is not localized by changing user interface language.
User comments, if long enough, can be truncated by the system. Then its longer version, which doesn't have to share 1000 octets with action summary, can be found in protection/move logs.