Translation UX/Specification

List of messages


Summary. Messages are presented in a list using white background for messages requiring processing (untranslated messages but also messages that need some kind of revision) and gray for those that not require processing. Several filters are provided to restrict the messages to be displayed (see "Filters" section below).

Each element in the list is composed by the original message, the translated message (if any) de-emphasized using gray text, and a status label (more on this below).

Rationale Problems
 * Emphasize messages that require action. Message status should be obvious at a glimpse.
 * Facilitate scannability. Messages are represented in one line to achieve a regular vertical rhythm. As discussed below, other requirements (ease of proofreading) may conflict with this.
 * Truncating messages becomes a problem when translating and proofreading long messages (typically from page translations).
 * Although message codes are not normally required, some scenarios will require them.
 * Part of the scenarios can be solved by searching to a specific code, but not all of them.

Label system
Summary. Each message in the list may include a tag that indicates its status or pending actions.

Labels considered are:
 * Translated (gray with a tick mark). The message has a translation and requires no other action.
 * Outdated (clock icon with yellow background). The original message has been modified and there is no guarantee that the current translation is still valid.
 * To review (flag icon with yellow background). The message has a translation but it was requested to be verified.
 * Unsaved (pen icon with gray background). The user edited a translation but neither saved or cancelled the edit.

Labels indicating "warnings" are also shown when the messages are open, providing associated actions (See "Outdated translations" and "Request revision" sections below for examples).

Rationale
 * Present status in a clear, simple and consistent way:
 * Clear. Labels and icons seem to be intuitive for users during testings. Currently, the "fuzzy" mark as part of the message text is exposing inner complexities to the outside.
 * Simple. Only one label is shown for each message, being the precedence "Unsaved" > "To review" > "Outdated" > "Translated".
 * Consistent. All indicators follow the same icon + label pattern using background color for revision-related actions.

Translation dialog


 Summary. Messages from the list can be opened. Dialog is shown in-place as an expanded version of a message from the list providing controls and information needed for processing the message. The UI is divided in two zones:
 * Translation area: Includes the basic information (original and translation texts) and actions for providing or correcting a translation.

Rationale.
 * Provide a compact layout based on two columns.
 * Screens are getting wider.
 * Most messages are short.
 * Long messages lack suggestions, so they can use more horizontal space when needed.
 * Distribution is based on a 12 column layout where translation area uses 7 columns and the help area 5.
 * Make translation closer to the translated text.

Problems
 * Appropriate transition is required to make the open and going to next actions smooth (avoiding abrupt "jumps").

Buttons with contextual text
Summary. Buttons show a different label depending on the specific context. to better describe their action.

The main action button may present these labels:
 * Save translation. For new translations.
 * Update translation. When the translation exist and has been modified.
 * Confirm translation. If it was marked as "outdated" or "requires revision".
 * Delete translation. If the translation text is deleted. (in case that deleting translations is allowed).

Rationale
 * Avoid repetition. Saving a translation moves to the next message since it is usual to process messages in sequences.

Suggestions

 * When suggestions are available from several sources, a single selection is presented (indicating multiple sources).
 * Suggestions are highlighted when text matches the suggestion. When the user types a translation that matches the suggestion it becomes easier to identify.

Request revisions
Rationale
 * Make users gain confidence. Encourage users to provide translations despite not being completely sure that are perfect.
 * Improve quality. Provide a mechanism to identify translations that have different kinds of problems (e.g., style issues) that a uses can detect but not correct.

Problems
 * Users making systematic use of the feature. If messages are massively marked as a