Contributing to Wikipedia
(Tutorial)
Policies and guidelines
Introductions
How-to pages
Writing advice
Community
Directories and indexes
Interactive help

There are several advanced techniques to help improve the editing of Wikipedia articles. Most of the tips given here involve using typical browser settings and standard text-editors, such as those for side-by-side editing. While special software packages to allow customized editing do exist, they are typically not available when using other computers for wiki-editing.

Faster display[edit]

Setting user preferences

See also: Help:Section § Section editing

Skipping slow parts of articles

Side-by-side editing[edit]

The Wikipedia article edit window is not designed for side-by-side editing, due to the formatted article preview usually being on the top half of the page, and the edit buffer being typically far below (near the bottom of the page). By the time various issues have been noticed, the user might have forgotten where each of them occurred within the edit buffer. When using two browser windows for side-by-side editing, however, the text (or image) is noticed in one window and can be located and changed in the other window, thereby allowing numerous precise changes to be made much faster without forgetting the minor details. The second window could show an edit preview, a diff, or the history tab list. Compared with the productivity of using only one browser window, using two windows in this way can be an improvement.

Using an external editor

Many text editors which can perform a variety of functions are available on all major operating systems, some of which can be found at the List of text editors. Some text editors can only edit plain text; others can handle rich text and provide features which can assist with editing, such as syntax highlighting (including for MediaWiki) and spell checking. Alternatively, word processors (see also List of word processors) can be used and generally can perform many of the same functions that text editors can, including string substitutions like those described below; however, the text formatting may not transfer (especially when editing the source) and other complications may occur.

One method of allowing side-by-side editing is to copy the browser edit window into a text editor and change text in the external editor but copy, paste, and preview the results in the browser edit window buffer. This can be dangerous, however, as it's possible to forget which buffer has the recent changes.

To avoid losing unpublished changes, one can always edit in an external editor (especially one with autosave) and paste into the browser window to preview. The final save would be made in the browser window when publishing the edit, but only after a final careful edit preview. The latter is important because a careful preview could save time that might otherwise be spent later finding and re-editing the changes to the article. As the saying goes, "a stitch in time saves nine".

A safer technique is to edit in a sandbox and transfer the changes to the article for publication after they are finalized. By saving the sandbox frequently no matter whether the changes are final yet, one can minimize the chances of losing one's work if, for example, one's browser or system crashes.

Effects on copyediting and proofreading

See also: Wikipedia:Basic copyediting

Even when just copyediting or proofreading an article, the potential benefits of side-by-side editing can be significant. When initially viewing an article, a user might approach it with a "wait-and-see" attitude to whether there are enough issues to warrant editing it. A user in this situation may want to open the edit page for the article or section in a new window and then return to the article or section itself, for that way, the user will have the option of making changes in the second, edit window while retaining access to the current version of the article or section in the first.

With this set up, numerous improvements can be made that might have taken much longer if the edit window had not been available separately when first reading the page. This might seem like a trivial change, but sometimes significant time is taken up remembering and relocating the parts of an article one wants to alter; side-by-side editing can reduce this and accelerate the process.

Potential impact of side-by-side editing

The potential increase in productivity, using side-by-side as a new way of arranging edits, is almost a magical breakthrough in the ability to easily improve hundreds of scattered details. It is even more powerful than a WYSIWYG editor, for 4 reasons: (1) it allows users to see and edit underlying tables or infobox markup-language before becoming distracted by a wholly reformatted page; (2) the editing can continue while the preview-page is being formatted/displayed in the second window; (3) results do not demand verification; and (4) the diff-listing can remind users about all edits. Specifically:

  1. WYSIWYG editors have the drawback that they insist on live, instant transformations, which can seriously distract attention from myriad other details, when ongoing reformatting occurs. In effect, side-by-side editing allows both levels of attention: either change a few details and reformat to see results, or step-by-step-change almost all details (top to bottom), uninterrupted, and then wait for the massive reformatting afterward. Again, WYSIWYG-editing could be very distracting if adding a small change distorted the output and shocked attention away from numerous other small details.
  2. Because the edit-preview is processed in a second window, the user is able to continue editing in the first window while choosing to ignore the in-progress formatting of the display-page, if too distracting at the moment.
  3. It is an utter myth that all changes must be verified (instantly or not). When making 57 changes to a page, it can be better to hope for 54 (of 57) successes, and move on to another article, rather than to carefully babysit each change and lose time for the next article. Total "perfection" is not necessary in this level of writing, where an article can later be edited by anyone.
  4. During a side-by-side edit, a user can focus on changing the underlying markup language, so when it comes time to run a diff-listing (by pressing the "Show changes" button), the user is able to review each change (as before/after) and compare the text in the familiar markup style. New typos can appear as unexpected keystrokes in the diff-listing.

Quick editing is not just about fast edit and feedback, but about avoiding or limiting distractions and forced verification steps as well. In the long term, being quicker could depend on spotting edit-problems by using diff-listings in the second window while further editing continues in the first window.

Complex text substitutions[edit]

Even a simple text editor such as Microsoft Notepad can be used to handle some complex changes by using multiple text string substitutions. For example, to add double quotation marks around wikilinks, a user can perform the following steps:

  1. Use the search-and-replace function to change all [[ to "[[.
  2. Use the same function to change all ]] to ]]".
  3. For any wikilinks which already have double quotation marks, replace all "" with ".

Generally, however, any text editor or word processor can perform this function, as can the online rich-text editors already available on Wikipedia and most of its sister projects, which can be found under the "Advanced" section of the editor toolbar.

Avoiding accidental publication of an edit[edit]

Wikipedia has a user preferences setting found in the Editing section which, when implemented, warns the user about a blank edit summary line and requests confirmation before publishing. When nearing completion of an edit, however, a user might be tempted to begin composing the edit summary text, which can lead to an accidental publication of a partial edit with a permanent partial summary line. A way to avoid this would be to compose the edit summary line as the last line of the page, using HTML comment tags <!-- and --> to hide that line. For example:

(...text of article above here...)
<!--
31 changes: +2 sources; fixed 9 spellings; 8 convert ft/m; moved 6 images +commas
-->

Putting that comment line at the end of the page allows the user to see and revise the whole edit summary text without the risk of accidentally publishing it, since any attempt will be stopped by the edit summary field still being blank unless the user manually confirms to proceed with publication. When ready, the user can copy and paste that bottom line as the edit summary and if the user forgets to remove that bottom line, it is only a hidden comment, so it can wait until that user (or another) deletes that comment when making further changes to that page.

Few things make editing worse than saving a partial edit, where other users see the unfinished change and either complain or change the page again, causing an edit conflict when one tries to finish and submit the incomplete edit which was accidentally published. To avoid this, one may want to publish an entire edit to a specific article only once, or wait 20 minutes after submitting an incomplete edit, because other editors may be alerted (such as through their watchlists) and might embark on their own changes to the article.

Showing double-brace markup[edit]

Although articles rarely contain the double-brace markers (( and )), these braces are common in wiki-template documentation pages. To avoid activating templates (except inside tables), the double-brace markers can be encoded by adding one HTML numeric character reference equivalent:

When editing text inside of tables, then double numbers or nowiki tags should be used because tables look for a single left brace {. The double-number characters are simply &#123;&#123; for (( and &#125;&#125; for )).

Far future[edit]

Perhaps in the near future, a Wikipedia edit-window will have some type of side-by-side display with a scrolling area for formatted output. However, due to the complexity of simulating a formatted page in a scrolling region, it will probably be many years before such side-by-side editing can be implemented in a single browser page. It is being implemented for translations, though.

See also[edit]

Categories