1. History

The body of an article is versioned, and since it can involve significant effort by multiple people throughout its lifetime, it can progress through several stages.

Quite a lot of WIP files can be generated when creating or editing an article, especially if using a diagram element or sequence element which can generate hundreds due to the number of placement adjustments of their child elements required. Periodically converting a WIP to a draft will delete all previous WIPS, which can help reduce archive file sizes. If not needed, previous releases can be purged to further reduce archive sizes.

To get to a release, the latest WIP is converted into a draft, then that draft is converted into a release. Technically, only the file name is changed, meaning that the release update timestamp is the timestamp of that latest WIP, not the time when made into the release.

See the Article lifecycle section of the Versioning article for more details.

Locales can be defined to be in a fall-through hierarchy, which affects viewing but also the translation sequencing. Not relevant if only one locale.

While the fall-through hierarchy defines what is shown if no text exists for the text in the current locale when viewing an article, the hierarchy also defines when non-master locales are available for translation.

By default, all non-master locales fall-through to the master locale for viewing, but also allows them to be translated directly from the master once it is Done. However, if a locale has a [non-master] locale selected for its Next field on the Locale page, it is both used as the fall-through locale for viewing and the locale that must be Done first for translation. It is also used as the source for a rich text element when ⧉ is clicked in the action bar of its element block in a non-master locale.

This hierarchical arrangement is especially useful if translating for different scripts for the same language for a rich text element where the translation is done by editing the text of the cloned content inserted by clicking the ⧉ in the action bar of its element block. For example, if the master locale is English (World) [en-001] and other locales include Uzbek (Latin, Uzbekistan) [uz-latn-uz] and Uzbek (Cyrillic, Uzbekistan) [uz-cyrl-uz], making uz-latn-uz the Next locale for uz-cyrl-uz allows the latter to be translated using text from the former rather than the master locale.

While eliminating a second translation of the master locale content, this should also result in far less rearrangement of inline elements for the second of such locale pairs than using the master locale as the source. Which order such pairs are placed in the locale hierarchy depends upon which the first of them has for its Next locale.

The expected process is to translate each locale according to the hierarchy, mark it as done, then release the article once all locales have been translated. If not wanting to translate all locales before release, Done could just be clicked for the locales to skip. By default, when it comes time to make edits, there is an All done button to bypass clicking each Done for the locales that don't need any edits. Note that non-master locales must be enabled in the Locales row of the Details section of the Article head page for their translations to be shown publicly.

However, if wanting to mitigate against rushing to All done before considering if perhaps some other locales may also need edits, the Strictly Done flag can be checked in the Access section of the Settings page to hide it. While clicking Done for each of a multitude of locales for online help can be tedious, for those who want to ensure that due process is followed so associated edits are not missed, forcing that via Strictly Done may just give a chance to think about them.

Descriptions of the navigation bar items.

ab

A master manager can assign managers or writers to editing or review tasks.

Locale, Phase, User and Due are only used for the Write, Translate, Review and Edit phases. See Editing phases for details and typical sequences. The locale and Phases text are in a different colour, and the borders are thicker for each locale level, so in a multi-locale scenario, the phases selections can be readily identified with their owning locale, and not confused with following child locales that may appear at the same level in the visual hierarchy.

The version list contains all versions of an article, plus any phases for a current editing cycle, in reverse chronological order.

Clicking the Latest button on the introduction line jumps to the Article body page, for the phase's locale if assigned.

Each Date-Time will usually be unique to maintain the correct reverse chronological order, but if for a multi-locale scenario the All done button is clicked, all Done phase entries will have the same value, except for the last locale which will be a second later to ensure that its Done button is at the top of the list.

If not wanting to keep previous releases, click the Purge button for them. Otherwise, keep those that have content that might be reused in future.

The phases and stages are designed for maintaining an orderly production schedule rather than as a historical archive, which is why versions can be deleted. For those strict working environments where each complete release must be retained, save the rendered page for that release as a single file that includes all embedded images and files. Chromium-based browsers offer that option with a .mhtml extension. Store that file in your organisation's secure document repository that prevents the records of document changes from being edited.

There are some keyboard shortcuts that help speed up common tasks.

Most buttons, after completing their actions, jump to a button above, but close to, buttons or other controls that are likely to be used next, so that keyboard users can quickly tab to them.