Wikipedia:Advanced article editing

Contributing to Wikipedia
Protocols
Editing policy (Content policies) Etiquette guide (Dispute resolution) Simple rule-set Simple style-manual
Introductions
About Wikipedia How to contribute Tutorial Newcomer training Newcomers primer Plain & simple The Wikipedia Adventure
How-to pages
Creating an account How to edit Starting an article (Article wizard) Talk pages (BOLD, revert, discuss) Referencing Renaming Deletion Media Lists Tables Templates Copying text Style-tips Wiki markup
Writing advice
Article development Basic copyediting Layouts Avoiding mistakes Writing better Perfect article Advanced editing Writing about women
Community
Community portal Dashboard Backlog Maintenance WikiProjects
Directories
FAQs Help hub Help index
Interactive help
Teahouse Help desk

This essay, Wikipedia:Advanced article editing describes some techniques to improve 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 exist, to allow customized editing, they are typically not available when travelling to 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

• During show-preview, all cumbersome tables or navboxes must be reformatted for the preview, but could 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).
• 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 just 1 section as typically being edited. 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 beside edit-window

• A good method to allow side-by-side editing is to copy the browser edit-window into a text-editor (such as Notepad in Windows or TextEdit in Mac OS X), then change text in the external editor but copy/paste & preview the results in the browser edit-window buffer. However, this can be dangerous when forgetting which buffer has the recent changes.
• The nearby editor can allow powerful editing, such as search-and-replace, or perhaps some spell-checker functions.
• NOTE: To avoid losing changes, perhaps always edit in the external editor, but paste/preview into the browser window. The final save would be made in the browser window, but perhaps only after a final, careful edit-preview. Remember a careful preview could save perhaps an hour of (later) finding & re-editing a half-changed article. Recall the adage: "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 when forgetting 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/preview into the right-hand window. The final save could be made in the left-hand window, perhaps after a final (one-time) preview on 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 chance of losing your work if your browser or system crashes, without any need for concern about whether the change 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, can be used to handle some complex changes, by using multiple text string-substitutions. For example, 2 edit-commands could be used to add quotation marks around wikilinks:

• Use Notepad edit-replace to change all opening ' [[' (to become: "[[ ).
• Use Notepad edit-replace to change all closing ']] ' (to become: ]]" ).

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

For several years, there has been a free text-editor, called "NoteTab", which allows using highly complex regular expressions to find, replace or swap multiple text-patterns on each line of a page. The free version of NoteTab is a simplified version of the commercial-product version, and allows many sophisticated features, without having to buy the full-feature version. NoteTab can also be used to count words or particular phrases within a page. For more, see the features described in essay: "WP:NoteTab".

Avoiding accidental save of edit

Wikipedia has a user-preferences setting to warn about a blank edit-summary line, and then request confirmation before saving. However, when nearing completion of changing a page, a user is tempted to start composing the edit-summary text, which thus opens the door of accidental SAVE of a partial edit, with a permanent partial summary line. Instead of accidents, 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 seeing (& revising) the whole edit-summary text, without risk of accidental SAVE (stopped by the edit-summary field still blank). When ready, copy that bottom line as the edit-summary, and if you forget to remove that bottom line, it is only a hidden comment, so it can wait until you (or another user) deletes that comment when making further changes to that page, after a few hours or days.

Few things make editing worse than saving a partial edit, where other users see the half-baked change, and either complain or re-change the page, causing "edit-conflict" when you try to finish the incomplete edit which was accidentally saved. In general, try to SAVE an entire edit to a specific article only once, or wait another 20 minutes, because other editors will be alerted and might embark on their own changes to the awakened 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 1 HTML character-number code:

• the left double-brace "{{" is "{&#123;", with bar "|" as &#124;
• the right double-brace "}}" is "&#125;}".

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

Perhaps in the close 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 would probably be many years before such, side-by-side, editing could 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