Translation UX/Specification

This page describes some of the features proposed to improve the user experience for the Translate extension.

'''These features are not final since a process of testing and discussing them has just begun. Feel free to provide feedback at the discussion page.'''

Translate workflow features


This section describes features to make the translation process more fluent. Most of these features are illustrated in an interactive prototype.

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 (optionally) a label indicating status (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.

Project and language navigation
Summary. Indicators for the current message group and language are provided. The message group indicator is presented as breadcrumbs where the user can modify the current location at different levels (e.g., change to a different project or a different message group in the same project).

Rationale
 * Facilitate navigation. Users will be able to recognize their current location and jump to related groups of messages (e.g., messages in the same project, same messages in a different language).

Filtering
Summary. Different kinds of filters are provided to show specific messages. The header of the message list includes filters by category and binary filters. Search-based filtering is also included to show only messages containing specific text.

Category filters include:
 * Untranslated
 * All messages
 * Outdated
 * Pending revision

Binary filters include:
 * Optional messages. Include/exclude messages that are considered optional.
 * Messages without suggestions. Include/exclude messages for which there is no suggestion available.

Rationale
 * Flexibility. Allow users to reduce the number of messages to a minimal set of messages of interest.

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.
 * Help area: Provides description, suggestions, examples in other languages (spoken by the user) and access to message-related support questions.

Rationale.
 * Organize related elements together. Translation is closer to the translated text, and suggestions are close to the text area they fill.
 * Provide a compact and clean layout.
 * Screens are getting wider making line-length too long when a single column approach is used.
 * Most messages are short.
 * Long messages lack suggestions, so they can use more horizontal space when needed.
 * Emphasize the text to translate.
 * Distribution is based on a 12 column layout where translation area uses 7 columns and the help area 5.
 * Help area is presented as a contextual help on how to fill the text area.

Problems
 * Appropriate transition is required to make the open and going to next actions smooth (avoiding abrupt "jumps").
 * More testing with translation messages (common and extreme cases)is required to properly adjust sizes of UI elements.

Buttons with contextual text
Summary. Buttons show a different label describing their specific action on different contexts.

The main action (blue button) may presented as:
 * 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).

The skip button may be presented as:
 * Skip to next. Label used most of the time.
 * Cancel. When a message is edited in a different language, to allow users to go back.

Rationale
 * Avoid repetition. Saving a translation moves to the next message since it is usual to process messages in sequences.
 * Simplify the workflow. Instead of providing multiple options to choose from, a simple approach based on "Do" or "Skip" is used but information scent is provided by descriptive labels.

Suggestions
Summary. Users can select a suggested translation, and have a notion of its source and the number of times it has been used in similar situations. Suggestions are presented next to the translation text area and clicking on them will populate the text area with the suggestion text.

Rationale.
 * Emphasize the suggestions by summarizing the source information.
 * Detailed information of the specific messages that used a suggestion is hidden behind the "used X times".
 * When suggestions are available from several sources, a single selection is presented (indicating multiple sources).
 * Allow checking suggestion match. Suggestions are highlighted when the user typed text matches the suggestion.

Adapting to long messages


Summary. Messages and the help area have a variable length. The size of the dialog is determined by the translation area. In case that the help area exceeds this size, scrollbars on the help area will appear.

Apart from this general behavior some additional mechanisms are used:
 * A smaller font size is used for long messages.
 * A expand/collapse icon is shown in the translation area (next to the close icon) to make the translation area to use the full screen width.
 * Long descriptions are cropped and a "read more" link is provided to access the whole content.

Rationale.
 * Adapt to the variability in size of the data.

Problems.
 * Specific thresholds for determining when a message or description is considered to be long are still pending.

Outdated translations


Summary. Translations for which the original message has been changed are presented as outdated translations. An "outdated" label is used in the message list and a warning strip is shown above the translation text area hen the message is opened.

The original message is shown and message diff marks are used to indicate the added and removed pieces of text.

Main action is presented as "Confirm translation" and it will remove the outdated label (making the message appear as translated). If the message is edited, the main action is presented as "update translation".

Rationale.
 * Facilitate compare and confirm process.

Problems.
 * The usefulness of the diff approach for all kind of modifications is still pending validation.

Request revisions


Summary. Users may mark translations for revision. A "Requires revision" label is used in the message list and a warning strip is shown above the translation text area when the message is opened.

The "requires revision" link from the translation dialog allow users to mark a translation for revision. When this is done, the warning strip appears with an "undo" option and the main action becomes inactive.

When the user opens a translation marked for revision, the main action is presented as "Confirm translation" and it will remove the "requires revision" label. If the message is edited, the main action is presented as "update translation".

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 user can detect but not correct.

Problems
 * Although the feature has been well received by users during test, it is difficult to anticipate the real use that will be done.
 * Users making systematic use of the feature. If messages are massively marked as requiring revision, the feature becomes less useful.
 * No specific mechanism has been defined for product or language community admins to be aware of translations being flagged (apart than filtering those messages explicitly).

Translation limit for new users


Summary. New translators can participate in the translation workflow from the beginning but provide only a few translations that will be used to determine whether to provide translator rights or not (more detail on the Sign-up process). Ideally the verification will be made before the user arrives to the limit, but a dialog is shown to explain the situation in case the user reaches the limit.

Rationale.
 * Present translation limit in a positive way. The message emphasizes the fact the user is evolving from a new translator to a more experienced one.

Problems
 * Users considered that the message may be a bit frustrating but consider it to be "a good compromise".
 * The number of messages allowed for translation needs to be adjusted so that users get informed of the account upgrade (positive) without showing them the limit message (negative).

Cross-language translation


Summary. Users speaking more than one language are provided shortcuts to easily provide translations for the same message in their languages.

This is achieved by:
 * Provide a text indication for the previously translated message in case translation is lacking for one or more of the user speaks.
 * When a translated message is opened, the help area includes an indication.
 * Both cases make the in-place editor to request the translation for the new language (a label is added to indicate this explicitly) and the "skip" button is presented as "Cancel" to provide a way to go back.

Rationale.
 * Once used made the effort of understanding the context for a translation it becomes easy to translate to several languages.

Problems
 * Users translating to many languages are not a common case. That is why the feature is not emphasized in the UI.

Integrated comments


Summary. Users are able to ask for more information about a message and read questions and answered by others to try to get more context about the message to translate.

Rationale.
 * Made the conversation bout a message in context. This will avoid users to switch between windows.

Problems
 * Demanding in terms of space.