Several activity phases are required to initially create an article, and to get from one release to the next.
For the sake of brevity in this article, the term manager indicates the master manager. While any manager can view the History and Article body pages while an article is being changed, only the current master manager has control of the process.
Phases are stages in the life-cycle of an article's contents, and control who has charge of the article and what they can do to it.
|#||Phase||Owner||Available target phases|
|3||Written||Manager||Master locale: Edit, Review, Done.|
Otherwise: Translate, Review, Done
|5||Translated||Manager||Edit, Review, Done|
|6||Updated||Manager||Edit, Review, Done|
|8||Edited||Manager||Edit, Review, Done|
|10||Reviewed||Manager||Edit, Review, Done|
|11||Done||Manager||Edit, Review, Translate (if master locale Done and locale has not been translated), Release (if all locales Done)|
The only phases that can be assigned are Write, Translate, Edit and Review, which when complete are marked as Written, Translated, Edited and Reviewed respectively, and control is returned to the manager. An assignee will need to convert the latest version to a draft to see what their available phases are. Done for a locale frees up dependent locales to be available for editing, but does not prevent re-editing the same locale. If other than to themselves, when the manager assigns a phase, an email is sent to the assignee informing them of the request.
The strict phase and locale sequencing only applies to articles that are Created, where there is no existing content for each locale so it makes sense to ensure that content is complete for each locale and its dependents. When articles are Updated, including those cloned from another article, there is no locale processing order applied as changes may not be needed across all locales.
|1||Note||Manager||Manager providing instructions to the assignee. Does not change assignee nor the effective phase|
|2||Query||Assignee||Assignee asking questions of the manager. Does not change assignee nor the effective phase|
|3||On hold||Manager||Manager taking back control|
The Note and Query phases allow written communications to the assignee and the manager respectively, making them part of the history of the changes. A Note is typically to point out new instructions for the assignee, of which they will be notified by email, though they will have to log in for details. A Query is for the assignee to seek clarification of issues found, though no email is sent to the manager. If there is a current Note or Query, a ✎ or ? respectively will appear after the Phase for the article in the In progress section of the Work list page.
Every phase for an assignee has a Note field for extra directions or clarifications. The On hold phase is for the manager to suspend the assignment and take back control, such as when serious issues with the content require an urgent reassessment of its structure or feasibility.
In general, other than when dealing with phases in general or particular phases, the term editing refers to an article when any of these phases is active, which may affect some functionality. For example, locales cannot be added or removed if there are any articles being edited.
Reviews are not required, but are recommended as a means of allowing another set of eyes to look over an article before publication.
A single-person operation will tend to want to write an article and immediately release it. Unfortunately, typos and other errors invariably occur along the way, no matter how experienced the writer. In large operations, like news sites, they used to have subeditors to check articles before publication, but competition and reduced revenues have forced many to release their subeditors and have their writers do their own proofing, resulting in a dramatic increase in typos, misspellings and even repeated blocks of text.
Therefore, get someone else to look over the article, or at least take a break long enough to let go of the trains of thought used to write the article, such as going for a walk or other activity that requires some concentration. This is akin to wine-tasters having a small piece of cheese between tastings so that they don't have the taste of the previous wine affecting the next.
The three types of review available are:
For a short article, all three can be done at once, but a long and involved article or set of articles may need an accuracy check done first. The rationale here is that there is no point in checking spelling if whole swathes of content might be deleted or changed because something was misunderstood. Those three types are three levels that start at the macro view and drill down into the details. Different skills apply to each type, where a subject matter expert will be best for accuracy checking, but a stickler for detail will be best for spelling. It all depends upon available skillsets.
If a review suggests some edits, the same writer or another person can do the edits, depending upon availability or whether different skillsets are required. When an article is released, all reviews are removed.
If an element has review notes, a red ʘ will be shown in its action bar. If only in its descendants, then it will be plain and smaller. If in its descendants and they are not listed within its element block, which ones have review notes will show a ʘ after their link in the children navigation bar, which can be clicked to jump to their hover button, which also has a ʘ. Click the hover button to open its element block, and repeat the process to drill down to the elements with their own review notes.
At any phase, only particular phases are available for the next phase, resulting in a limited set of sequences.
Every article begins with writing its master locale content.
For a newly created empty article, the Write phase is the only assignable phase available. Because this is for the master locale, the writer can modify not only the content but also the block structure freely. If the site has multiple locales, the same block structure is used by all locales. Only the internal structure of rich text blocks can be changed for each locale.
Ater writing, assigning a Review to someone else will allow a lot of errors to be caught. The reviewer can place review comments against any element in a draft. Once they mark it as Reviewed, if any changes are required, another Edit phase can be assigned to the original writer or someone else. Once Reviewed, it can be marked as Done to Release it, or assign it for a Translate if there are more locales.
Allowance for the differing sizes of text rendered in the other locales must be taken into consideration when selecting which structures to use. For example, if the master locale tends to be fairly compact, a table with several columns may be considered appropriate. However, if another locale uses 50% more space, or tends to have longer words, the table may not keep within page bounds, especially on a narrow mobile device. Another structure, or a simplified table might be better suited.
The translating sequence is done for each other locale after the writing of the master locale is completed.
The translation sequence has basically the same steps as for writing, except that assignment for Translate is from a Done phase. In addition, if a locale hierarchy is used, using the Next field for a locale instead of the master locale as default, all ancestor locales must have been completed with a Done phase.
Translators cannot change the article structure, except for the internal structure of rich text blocks, since different languages have different subject-verb-object, verb-adverb or adjective-noun ordering. These different orderings will not affect the monolithic structures of plain text fields, but embedded formatting tags in rich text blocks may be in different orders between locales.
Initially, there will be no content for non-master rich text blocks. The translator will have to clone the immediate ancestor locale content (as per the locale's Next field, or the master locale's) using the 🗗 button. Since the empty content for a locale for a block uses the nearest ancestor with non-blank content, there is no need to specify text for a locale if the text would be the same. For example, while there are many different spellings between US and UK English, a particular paragraph may not use any such words, and so can be left to fall-over to an ancestor.
As with writing, translation can benefit from a second opinion, making a Review by another translator of use. Review comments are stored by locale, so any for other locales will not be mixed in with those for the current locale.
The updating sequence is usually done to create a new release due to errors or required changes to content.
The updating sequence is like the writing sequence, but begins with an Updated phase, and occurs when a release needs modifications, or an article is cloned from another. The only assignable content-modifying phase is Edit. If a review requires changes to be made, the subsequent Edit phase is likely to be shorter than the first.
Once released, any previous releases can be purged, which completely removes the release and any drafts after the previous release. Only Purge if there is no requirement to keep content from previous versions.
Sometimes some content is not ready to be included a release but needs to be kept for a possible later release. For this, make the content into a draft as soon as this is realised. Any subsequent conversions of a WIP into a draft will not affect that required draft, but the release it led up to must not be purged. To avoid that risk, perhaps create another article and use spike 3 to transfer the wanted content to it.