To main heading

Smallsite Design

Online management help

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.

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.

The stages of an article's lifecycle are:
#StageDescription
1WIPWork in progress. Intermediate versions, each containing one editing change from the previous. Not publicly viewable
2DraftVersion for review or candidate for release. Not publicly viewable
3ReleaseApproved 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.

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.

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 ʘ?ʘ 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 ʘ?ʘ 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.

The areas of a history navigation bar are:
History page navigation barab
where:
#AreaDescription
aOwner pathVersion 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
bPhase detailsVarious details of the current phase. Only shown if the article is being edited

The article body navigation bar provide jumps to the pages for it and its hierarchy of owners.

The navigation bar items are:
#NameDescription
1SubsiteOwning subsite identifier as a jump to its entry in the Access section in the Work list page, with its category list expanded
2CategoryOwning category identifier as a jump to its entry in the Access section in the Work list page, with its article list expanded
3ArticleArticle identifier as a jump to the History button in the Versions row of the Details section in the Article head page

The article body navigation bar holds the details of the current phase.

The phase details are:
#NameDescription
1PhaseCurrent editing phase as a jump to the Phase column of the article's entry in the In progress section of the Work list page
2LocaleLocale being processed by the current phase. Only shown if an editing or review phase
3User IDUser identifier of the person assigned the current phase. If not an editing or review phase, Manager is shown
4DueDuration 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.

The selection criteria for task assignment by the master manager are:
#CriterionDescription
1LocalePresented within the hierarchy of fall-through dependencies, master locale first. Locales without a Next will be placed last under the master locale
2PhaseDependent 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
3UserThose managers or writers allowed to edit or review for the locale. All are assumed suitable for the master locale. The current or last master manager is selected by default
4Review
types
Types of review to be performed. Only for Review phase. See Reviews for details
5DueDuration in which the task is expected to be completed. 4 weeks is selected by default
6NotesNotes 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.

The columns for the version list are:
#NameDescription
1AgeRough duration since the version or phase created. if the same as the row above
2Date-TimeDate-time identifier
3Stage|PhaseFor versions, the stage in the article lifecycle. For phases, the phase in the editing lifecycle
4Locale …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.

The available actions for versions are:
#StageActionDescription
1WIPDraftMake the version into a draft, deleting all previous WIPs
2DraftAbandonDelete 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
3DraftDeleteDelete the version. Only available if not the only draft after the latest release
4ReleasePurgeDelete 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.

Keyboard shortcuts

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

The keyboard shortcuts active in this page are:
#KeyDescription
a\Opens the Work list page
b~Safely refreshes the current management page
c&Activates the Latest button to jump to the Article body page for the latest version
d@If the Update button is displayed, activates it to allow a task to be assigned
e@If the latest version is a WIP, activates the Draft button of its row to make it a draft
f@If one of a Written, Translated, Edited or Reviewed buttons is displayed, activates it to go to that phase
g@If the All done button is displayed, activates it to allow release
h@If no All done button is displayed, but any Done buttons are, activates the first to mark its locale as complete. Repeat as required
i@If the Release button is displayed, activates it to release the article
j#If any Purge buttons are displayed, activates the latest to delete that release and any drafts that led up to it. Repeat as required

The @ shortcut makes for a fast keyboard-driven release process if only editing a single locale in the session:

  1. 1.Make the latest WIP into a draft.
  2. 2.Complete the editing task.
  3. 3.Mark all locales as done, otherwise the first locale as done.
  4. 4.Release the article.

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.

  • Files
  • Banners
  • Links
  • Contact   Glossary   Policies
  • Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design©Patanjali Sokaris