1. History
History is the list of versions for an article, as well as the phases of an article while it is being edited.
See Editing phases for details of the phases and review types, and common phase sequences. See the Article lifecycle section of the Versioning article for details of the stages an article goes though.
Article lifecycle△
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.
| # | Stage | Description |
|---|---|---|
| 1 | WIP | Work in progress. Intermediate versions, each containing one editing change from the previous. Not publicly viewable |
| 2 | Draft | Version for review or candidate for release. Not publicly viewable |
| 3 | Release | Approved version that is available for public viewing |
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.
Locale hierarchy△
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 Strict 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 Strict Done may just give a chance to think about them.
Navigation bar△
Descriptions of the navigation bar items.
| # | Area | Description |
|---|---|---|
| a | Owner path | Version owner hierarchy as jumps to their listing in the Access section of the Work list page, except for Article which jumps to the Article head page |
| b | Phase details | Various details of the current phase. Only shown if the article is being edited |
Owner path△
The article body navigation bar provide jumps to the pages for it and its hierarchy of owners.
| # | Name | Description |
|---|---|---|
| 1 | Subsite | Owning subsite identifier as a jump to its entry in the Access section in the Work list page, with its category list expanded |
| 2 | Category | Owning category identifier as a jump to its entry in the Access section in the Work list page, with its article list expanded |
| 3 | Article | Article identifier as a jump to the History button in the Versions row of the Details section in the Article head page |
Phase details△
The article body navigation bar holds the details of the current phase.
| # | Name | Description |
|---|---|---|
| 1 | Phase | Current editing phase as a jump to the Phase column of the article's entry in the In progress section of the Work list page |
| 2 | Locale | Locale being processed by the current phase. Only shown if an editing or review phase |
| 3 | User ID | User identifier of the person assigned the current phase. If not an editing or review phase, Manager is shown |
| 4 | Due | Duration in which the task is expected to be completed. Only shown if an editing or review phase. The format is as described in Durations, though if expired, they will be shown like [3w] |
Phase selection△
A master manager can assign managers or writers to editing or review tasks.
| # | Criterion | Description |
|---|---|---|
| 1 | Locale | Presented within the hierarchy of fall-through dependencies, master locale first. Locales without a Next will be placed last under the master locale |
| 2 | Phase | Dependent upon the locale. Review is always available. If never released, always Write for the master locale, and Translate for the others. Thereafter, only ever Edit |
| 3 | User | Those managers or writers allowed to edit or review for the locale. All are assumed suitable for the master locale. If only one user, they are selected |
| 4 | Review types | Types of review to be performed. Only for Review phase. See Reviews for details |
| 5 | Due | Duration in which the task is expected to be completed. 4 weeks is selected by default |
| 6 | Notes | Notes for the phase. Required for the Note, Query and On hold phases. Embedded characters can be used |
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.
Version list△
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.
| # | Name | Description |
|---|---|---|
| 1 | Age | Rough duration since the version or phase created. – if the same as the row above |
| 2 | Date-Time | Date-time identifier |
| 3 | Stage|Phase | For versions, the stage in the article lifecycle. For phases, the phase in the editing lifecycle |
| 4 | Locale … | For versions, actions available. For phases, details and types of review. Click the Note label or its checkbox to view the text of a Note or Query |
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.
| # | Stage | Action | Description |
|---|---|---|---|
| 1 | WIP | Draft | Make the version into a draft, deleting all previous WIPs |
| 2 | Draft | Abandon | Delete all phases and any WIPs or other drafts back to the previous release. Only available for the latest version and if there is a previous release |
| 3 | Draft | Delete | Delete the version. Only available if not the only draft after the latest release |
| 4 | Release | Purge | Delete the release and all drafts back to the previous release or the start. For when previous releases are not required. Only available if not the latest release. Otherwise, delete the article in the Details section of the Article head page |
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.