Wikipedia:Advanced article editing

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

Faster display

Set user preferences

• Enable section editing – The top section of an article (&section=0) can be edited separately for much faster update of the intro text (right-click top option "My preferences", click tab "Editing" and click "Enable section editing" option).
• Hide edit-toolbar – Turning off the edit-toolbar can make a short edit-page appear 2x-4x faster (right-click top option "My preferences", click tab "Editing" and unclick "Show edit-toolbar" option).
• NOTE: Some article intro-sections do not contain all the top images, so sometimes, editing a whole article could be faster for adjusting the image placement.

Skip slow parts of articles

• After clicking "Show preview", all cumbersome tables or navboxes must be reformatted during the preview, but can be skipped by adding comments or #ifeq.
• Consider commenting-out those massive, gigantic bottom navboxes that typically double (or triple) the S-L-O-W-N-E-S-S of article previews: just put "<!--" and "-->" around the bottom navbox-template codings. (Even with high-speed Internet, large navboxes take a long time to load.)
• Consider conditional skip of text, using MediaWiki #ifeq-statements: using the markup language, surround omitted sections with "{{#if: skip |skip part 1|" and ending with "}}". Only "skip part 1" will show. Although HTML comments cannot be nested, the #ifeq-statements can be nested, as long as the spanned text does not upset the use of vertical-bar "|" or "}}" text.
• Consider copying troublesome sections of an article into a test-page for repeated changes & previews: edit as a user-space page (User:XXX/TestZZ) and copy/paste some text there for repeated changing/previewing. Perhaps have an "edit-TestZZ" window all the time.
• NOTE: For broader testing, the copied part of an article often spans 2 or 3 sections, rather than having just 1 section for editing. Be sure to copy enough sections for an accurate preview.

Side-by-side editing or diff

The Wikipedia article-edit window is not designed for side-by-side editing, due to the formatted preview-article usually being on the top-half of the page, while the edit-buffer is typically far below (near the page bottom). By the time various text-issues are noticed, the user often forgets where those occurred within the edit-buffer, far below. However, when using 2 browser windows for side-by-side editing, the text (or image) is noticed in one window and located/changed in the other window, thereby allowing numerous precise changes to be made 2x to 10x times (or more) faster, without forgetting the tedious details. The 2nd window could show an edit-preview, a diff, or history-tab list. Compare the lower productivity of 1 browser window, versus using 2 windows, and note how much faster all details are caught.

Use 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 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 to allow side-by-side editing is to copy the browser edit window into a text editor—such as Notepad in Microsoft Windows, TextEdit in MacOS, and gedit in compatible Linux systems—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 always edit in an external editor (especially one with autosave), but 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".

Double-copy the edit-window

• A quick method to allow side-by-side editing is to copy the browser edit-window, then change text in one window but copy/paste & preview the results in the 2nd window. However, this can be dangerous, as it's possible to forget which of the 2 windows has the most recent changes.
• NOTE: To avoid losing changes, perhaps always edit in the left-hand window (for example), but paste into the right-hand window to preview. The final save could be made in the left-hand window, perhaps after a final (one-time) preview of the left.
• A safer technique is to edit in a sandbox and save actual changes to the real article after they are finalized. By saving the sandbox frequently, you can minimize the chances of losing your work if your browser or system crashes, without any need for concern about whether the changes are final yet.

Even proofread alongside an edit-window

The increased speed of side-by-side editing can even be extended to a mere "proofreading" phase. When initially viewing an article, there might be a "wait-and-see attitude" as to whether there are enough trouble spots to warrant editing the article. Instead, consider first reading an article (with no intent to change it), but first click to "edit" in a new window, and then while reading (for the first time) make "possible edits" in the edit-window, while reading the formatted article page in the 1st window.

• Click "edit" open in new window (before first reading an article).

Often, within 10 minutes, numerous improvements could be made that might have taken another 20 minutes to re-locate and remember, if the edit-window had not been instantly available when first reading the page. It might seem like a trivial issue, but compare the results a few times to realize how much time is burned to re-locate and remember such changes.

However, beware the temptation to become a "copy-edit fanatic" when it is usually more important to add new text or new source footnotes to most articles.

Potential impact for side-by-side edit

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 even see/edit the 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 2nd 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 rapidly focusing on myriad other details, when such ongoing reformatting occurs. In effect, side-by-side editing allows both levels of attention: either change a few details & 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 2nd window, the user is able to continue more editing in the 1st 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 onto other articles, 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 articles are later hacked by anyone.
4. During the side-by-side edit, a user can focus on changing the underlying markup language, so when it comes time to run a diff-listing (button "Show changes"), 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/response feedback, but also about avoiding or limiting either distractions, or forced verification steps, as well. Being quicker, long-term, could depend on spotting edit-problems by using diff-listings in the 2nd window, while further editing continues in the 1st window.

Complex text substitutions

Even a simple text editor, such as Microsoft Notepad or gedit, can be used to handle some complex changes by using multiple text string substitutions. For example, two edit commands could be used to add quotation marks around wikilinks:

• Use the replace function to change all opening ' [[' to "[[.
• Use the replace function to change all closing ']] ' to become: ]]".

For any wikilinks which already had quotation marks, then replace all duplicated double quote patterns of "" with a single double quotation mark of ".

Avoiding accidental publication of an 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 is tempted to begin composing the edit summary text, which can thus 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 risk of accidentally publishing it, since any attempts would 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 that bottom line as the edit summary and if one forgets to remove that bottom line, it is only a hidden comment, so it can wait until one (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 rechange the page, 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 another 20 minutes, 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

Although articles rarely contain the double-brace markers {{ and }} those 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:

• the left double-brace {{ is {{, with bar | as |; and
• the right double-brace }} is }}.

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 {{ for {{ and }} for }}.

Far future

Perhaps in the near future, a Wikipedia edit-window will have some type of side-by-side display, allowing 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 currently though.

See also

• WP:Contributing to Wikipedia
• WP:Advanced footnote formatting
• WP:Advanced template coding
• WP:Advanced table formatting
• WP:Advanced text formatting