Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.mediawiki.org/wiki/Translation_UX/Specification below:

Translation UX/Specification - MediaWiki

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.

The sign-up workflow covers the path of a new translator from his first visit to translatewiki.net to his first translation.

Design goals:

• Start earlier. Allow users to start translating as soon as possible.
• Start easy. Guide and simplify first translations.

New translator sign-up and account activation

1. Using the signup form to enter user account information and translation language
2. An example translation is presented to the user to get familiar with the basics.
3. Use first translations to determine whether to assign translation permission to the user.

Interactive prototype

Summary The landing page is the first point of contact for a potential translator to the translation platform. It is necessary that the visual communication is effective for a first time visitor to identify the purpose of the platform and how he can use it. Poor communication will result in users not understanding the platform and will result in a loss of a potential translator.

Rationale

• A prominent image that represents people and culture helps provide some context even to a random visitor
• Images are visually appealing and can help retain a visitor on the page longer
• A clear and concise one line definition of the platform can help someone understand how he can contribute

Summary A simple and visible sign up form can convert accidental visitors into translators using a favorable user experience. All the information required for creating an account must be information that is already known to the user. This combined with an effective call for action can significantly lower the barrier required to register as a translator

Rationale

• The heading 'Translate a free project in your language today' is an immediate call for action to the user
• The most probable user language auto detected from locale reduced the effort required to select a language from a list
• The 'native speaker' setting communicates to the user that it is related to the language proficiency.
• Confirm password field has been dropped to reduce the user effort required to sign up. [1]
  • Users can retrieve their passwords using e-mail, and change the e-mail using the password. So both act as security alternatives to one another.

Summary. The user is presented an example translation which is an easy translation to get started with. The translation can be obtained from a set of pre-defined translations or from the real translation list (selecting a short message with available suggestions and description). The UI for translation is a simplified version of the one they will use later.

Rationale.

• The learning curve is reduced if the user start with an easy translation and do not get confused with advanced features.
• This step is optional. Users can go directly to a project if they want to.
• A thank you message is included to indicate the account has been created.
• 'Try another' button allows the user to try a different message to translate if required
• Options are provided for the user to select the appropriate translation. This reduces the effort of typing a custom translation

Summary. New translators can start translating from the beginning but only for a limited number of translations that will be used to determine whether to provide translator rights or not. 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.

• New users can make only a limited number of translations, these translations do not become transferred to the software product until reviewed. When reviewed positively, users become full-right translators.
• If users try to exceed the translation limit, a dialog is shown to them explaining the situation.
• 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

• Spambots will be able to create accounts and pollute the sandbox with spam messages.
  • The example translation can be used as a captcha by providing an easy translation with one valid and many invalid options as suggestions.
• 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).

This section describes features to make the translation process more fluent. Additional notes on the visual style and interaction details are available.

Most of these features are illustrated in the following prototypes:

• an interactive message prototype.
• interactive HTML prototype for full-page translation and proofreading.

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

• 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.

Problems

• Truncating messages becomes a problem when translating and proofreading long messages (typically from page translations). A specific solution for proofreading has been defined to solve these issues.
• 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.

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.

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).

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.

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 [2] 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.

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.

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.

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.
• An 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.

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 stripe is shown above the translation text area when 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.

Summary. Users may mark translations for revision. A "Requires revision" label is used in the message list and a warning stripe 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 stripe 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).

Summary. A full-page view is provided to make it easy to compare and verify original and translated texts. The view is focused on content:

• Labels are turn into icon markers located at the side (left for actions, right for proofreading marks).
  • The tick mark indicates a verified translation".
• Content should be shown in a representation as close as possible to the final form (e.g., render headings and links).
• When proofreading, keyboard shortcut is supported. An active marker can be checked and moved to the next by pressing enter.

Users can mark translations as verified (the tick mark).

• On hover, non-verified marks will appear to allow users to mark messages as checked without opening the translation dialog. In proofreading mode, marks appear without the need for hover.
• When the dialog box is open for a non-verified message, it presents the main action as "confirm translation".

Additional aids are provided at fixed-located header and footer:

• Header includes:
  • Back to message list link to return to the list of messages.
  • View selector to change between original, compare (default) and translated.
• Footer includes:
  • Indicator of progression. Should indicate proofreaded, translated,
  • Quick access to previous and next messages. Next message allows to customize the kind of messages the user moves to (next to translate, next to review, etc.).

Autocompletion of small parts.

Rationale

• Emphasize content.
• Support continuous content.

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).

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.

The languages of interest for a user can be obtained in different ways:

1. Recent contributions to languages
2. Babel template based
3. Babel extension based
4. TranslationNotifications extension preferences.
5. Meta translator templates
6. Translate assistant language preferences

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.

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.

Summary The translation search workflow covers the path of a translator looking for a message, project or translation to an action with the target item. The mediawiki search interface currently used on translatewiki allows the user to define advanced search filters and criteria but is currently cluttered leaving a lot of room for improvement[3]

1. Fixing an incorrect translation on a specific project
   1. Using the mediawiki search to lookup an incorrect message
   2. Using project or language filters to drill down to the required message in case of multiple results
   3. Using an action link to load the target message into the translation workflow

1. Fixing a common typo in a particular language
   1. Using the mediawiki search to lookup an incorrect word
   2. Using project or language filters to drill down to the required message
   3. Using an action link to load the target message into the translation workflow

Interactive prototype

Summary The search mode allows a user to decide on the type of search he is performing. The default mediawiki search behavior is to list all the results grouped serially. The user has to currently navigate through a large list of filter in the advanced options to limit his search to only certain types of results. Having tabs to switch the search mode can greatly improve user experience and make searching more seamless.

Rationale

• The overview mode gives a summary of the results to the user. This serves a starting point for the user to drill down to a more specific search result.

Summary Faceted search filters allow a user to easily drill own to his target item by filtering the search results using relevant links. At each step, results from groups that are not relevant is discarded [4]

Rationale

• The filters are grouped into three categories: Language, Projects and Message status. These were chosen because they are the main properties of each translation or message on translatewiki.
• The language filters are shown first because it is the smallest list and is easy for the user since he readily knows this information.
• The project filters is a relatively longer list. Subgroups of projects are indented.
• The status filters allows a user to limit his search to only certain type of messages.
• The number next to the filter indicates the number of results for that filter and helps the user make an appropriate choice of filters to apply
• The advanced search option allows the user to access the default mediawiki options as a fallback mechanism.

Summary The search result list provides the results of the user's search query and combination of search filters

Rationale

• Translation and source message results have a translate/review link to enable a user to directly perform an action from the search page
• The text that matches the search keyword is displayed in bold to highlight the match for the user.
• For messages, links to the message group or project is provided to allow the user to access the project page.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4