Improve the New Translation dialog to easily find articles to translate
Closed, ResolvedPublic

Description

The "New translation" dialog provides the basics you need to start a new translation. You can select an article and start a new translation. However, it has limitations in terms of the information and control needed to find and article. Most of the time you need to know the article and the fact that it was missing in a given language in advance.

In order to improve the experience the following design goals are defined:

  • Make the experience of selecting an article more fluent. Going through less steps will encourage to start translating.
  • Anticipate relevant articles. Surface opportunities to translate.
  • Surface the information needed to make a decision. Language, quality and impact factors are often used to decide what to translate.
  • Provide options to explore the content. Checking information about the article before translating it requires currently to do a separate search.

A proposal to improve these aspects is described below.

Design details

  • Initially, just a search box is shown.
  • Clicking outside of the dialog, closes it.
  • The dialog is preferably shown in-place. That is, making other pieces of content move to make room for it, rather than appearing as a modal element.
  • Usually, the panel will be shown with the focus on the search field, so the first status visible will be the next one.

  • On focus, relevant articles are surfaced (in the example we used previously edited articles and those in user-specific collections such as nearby).
  • In addition, the source language (based on a smart default) is shown allowing the user to select a different one.
  • Articles without images will use the usual placeholder, a Base20 (#54595D) "article" icon (F8995301 F8995302) on a Base80 (#EAECF0) background.

  • When searching, matching articles are surfaced.
  • The number of languages in which they are available and whether they are available in the default target language is shown to facilitate the selection.
  • If the article is being translated by another user, we can indicate so (especially when we are blocking its creation, although it may be useful even if we do not).
  • Other quality assessments can be included too.

  • When selecting the article, the selection status is clearly differentiated from the search one (unlike it happens currently)
  • Users can change source and target languages. The fact that the article is selected allows to customise those selectors based on it: showing only source languages the article exists in, and highlight target languages where the article does not exist (we still want to allow, although in a less prominent way to overwrite existing articles).
  • Users can open the selected article by clicking on the title (which is announced with a small icon next to it).
  • Users can undo the selection by clicking on the "X" to search for a different one.
  • There are no options to set the target title. That will be done when starting the translation (we may need to work on an invitation for it).
  • This is the view where the user will land when the article is selected by an external entry point (such as suggestions).

You can check the idea in this prototype where you can start a translation for "Cupcake".

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Pginer-WMF updated the task description. (Show Details)Feb 24 2017, 2:10 PM
Pginer-WMF updated the task description. (Show Details)Feb 28 2017, 5:05 PM
Pginer-WMF raised the priority of this task from Normal to High.Jul 4 2017, 10:17 AM

Some questions:

  • Is it supposed to be the total number of languages, or the number of other languages? E.g., if an article is only available in English, should it be "文A1" or "文A0"?
  • Are you sure it's supposed to indicate "Missing" explicitly, and in green? Maybe it could be different? For example, yellow could show "already available in Spanish"? Whatever it is, it will be easy to implement, but I'm wondering what will be the clearest and most inviting for users.

Some questions:

  • Is it supposed to be the total number of languages, or the number of other languages? E.g., if an article is only available in English, should it be "文A1" or "文A0"?

We just want to communicate whether the topic is covered by lots of other languages or just a few. So I'm not very concerned with the specific metric. However, the total seems to be a figure easier to interpret, and avoids the "0 languages" case which can be confusing.

  • Are you sure it's supposed to indicate "Missing" explicitly, and in green? Maybe it could be different? For example, yellow could show "already available in Spanish"? Whatever it is, it will be easy to implement, but I'm wondering what will be the clearest and most inviting for users.

We want to signal in a positive way the opportunities for contribution. We can think on a more positive alternative to the "missing" label, but I think we should highlight those articles and do so in a positive color.
Drawing the attention to the articles users cannot translate requires users to make more mental steps: they focus on the articles they should not act to, in order to pay attention to the rest.

Pginer-WMF updated the task description. (Show Details)Aug 9 2017, 11:44 AM

Change 371473 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Improve the New Translation dialog

https://gerrit.wikimedia.org/r/371473

Change 372537 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Add article languages count

https://gerrit.wikimedia.org/r/372537

Change 372846 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/core@master] Support langlinkscount API

https://gerrit.wikimedia.org/r/372846

Change 371473 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Improve the New Translation dialog

https://gerrit.wikimedia.org/r/371473

Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 6:48 AM

Change 372537 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Add article languages count

https://gerrit.wikimedia.org/r/372537

Change 374425 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Show only relevant languages in New translation

https://gerrit.wikimedia.org/r/374425

Change 374425 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Show only relevant languages in New translation

https://gerrit.wikimedia.org/r/374425

Volker_E added a subscriber: Volker_E.EditedSep 6 2017, 9:41 PM

It'd be great to work on the animation part after clicking “New translation” (speed up the animation a bit) and out again (when the button reappears). It's pretty jarring currently.
My action points:

  • Speed up expand animation
  • Make collapse animation not jarring, as in speeding up & make transitions more fluent
  • Clean up animation code for x-browser compatibility and consistency

@Petar.petkovic, here are the SVG and PNG version of the "new window" icon:

Change 378252 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Add pageviews info to New translation dialog

https://gerrit.wikimedia.org/r/378252

@Pginer-WMF, here is screenshot for you to check:

@Pginer-WMF, here is screenshot for you to check:

The screenshot looks good in general, but I'd recommend increasing the space between the language selector and the closing "X", in order to make more clear that the X affects the whole element. Increasing from the current 8px to 16px should work well.

All our 'x' icons are in the upper right corner in normal dialogs and cards. From the screenshot above, it seems that the image increased, so would there be space to put the translation language filter below?

All our 'x' icons are in the upper right corner in normal dialogs and cards. From the screenshot above, it seems that the image increased, so would there be space to put the translation language filter below?

Related to this, I think it would work better as a continuous element. In that regard, I'd recommend doing the following size adjustments:

  • Reduce the article image size to 48px, and the distance between the image and the text to be close to 8px.
  • Reduce the article name font size to 18px
  • Reduce the language indicator font size to 14px and color to Base30 (#72777D)
  • Reduce the min-height instructions to make the top text to align with the top of the image and the bottom text with the bottom of it.
  • As mentioned above, increase the distance between the X and the language selector

I applied the changes locally in the browser and made a before/after comparison:

BeforeAfter

Change 378252 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Add pageviews info to New translation dialog

https://gerrit.wikimedia.org/r/378252

I give this a try in production, and I noticed a couple of aspects that may require some polishing as follow-up tasks:

Those are not breaking the main user workflows, but it may be worth polishing while we are focusing on this dialog.

Change 372846 abandoned by Petar.petkovic:
Support langlinkscount API

https://gerrit.wikimedia.org/r/372846

Change 381246 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Embed New translation search results

https://gerrit.wikimedia.org/r/381246

When we are surfacing previous articles but there are none we can use the empty state to encourage users in their choice:

  • Font uses 16px font size and Base30 (#72777D) as color.

Using the message "Think of any topic of your interest. You don’t need to be an expert to create a great translation." we emphasise the idea that you don't need to be an expert to contribute, which is one of the barriers identified by the research on new editors.

Change 381495 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Add Recent edited pages to New translation

https://gerrit.wikimedia.org/r/381495

Change 381246 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Embed New translation search results

https://gerrit.wikimedia.org/r/381246

Change 381495 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Add Recent edited pages to New translation

https://gerrit.wikimedia.org/r/381495

I took a look to the current version in production (which probably does not include changes from latest patchsets):

There are some small details that may be worth adjusting:

  • The text placeholder for the search field says "Search for source page". The "source page" concept does not seem very intuitive, especially now that we are not asking for a "target page" for users to understand the contrast. We can change it to be "Search for a page to translate".
  • The empty state message ("Think of any topic of your interest...") seems a bit crowded we can consider using the following adjustments:
    • Using a smaller font (14px)
    • Using a higher line height (1.5em)
    • Making the text area a bit wider if possible, although the previous adjustments should avoid the text to break too early.

Change 384182 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Change New translation input placeholder

https://gerrit.wikimedia.org/r/384182

Change 384182 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Change New translation input placeholder

https://gerrit.wikimedia.org/r/384182

Arrbee moved this task from Bugs to Oct-Dec 2017 on the ContentTranslation board.

Change 400266 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Add nearby suggestions

https://gerrit.wikimedia.org/r/400266

The mock up shows basic idea behind suggesting nearby pages to the user:

To implement a feature of suggesting nearby pages, we need to determine user's current geolocation. We have option to use browser native geolocation API or cookies we already have in our ecosystem. The browser API displays the dialog when user opens CX page asking for permissions to use geolocation services. I'm not even sure if we can communicate why we want the user to enable us to track his location. That is the main drawback of that method, which needs inputs from PM.

@Amire80, what should we do about this one?

Here are some comparison arguments from the top of my head:

Browser APIGeolocation Cookies
- Browser automatically displays confirmation dialog for user to allow usage of geolocation+ No confirmation dialog displayed
+ Higher accuracy. Possibility of using high precision mobile device GPS+We already have cookies which we can utilize
- Might be significantly slower, but we can control some parts- Possibly very poor accuracy
- Only available in secure contexts (HTTPS), meaning it won't be available in testing environments
Pginer-WMF added a comment.EditedJan 4 2018, 11:08 AM

From my perspective a confirmation dialog will break the fluency of the experience in this context (getting in the way of users that may be already about to search for a specific article to translate). I don't expect we need much accuracy (we are just filling the initial empty state with content that may be connected to the user in some way), so the geolocation cookies seems a good approach.

One question about the browser API, would it be possible to show the nearby articles if the permission was granted by the user before (in other parts of our site), but not show the content and don't ask explicitly for it otherwise?

Yes, I'm also very reluctant about using the Browser API. This may also have some privacy implications; I'm not sure that such a thing would be covered by our privacy policy (I am not a lawyer). If we reuse already-available information, it should be covered.

What is poor accuracy? information do we have exactly? What ULS has is usually not much more than a country. The mobile version's Nearby feature is more precise; does it use the Browser API?

What is poor accuracy? information do we have exactly? What ULS has is usually not much more than a country. The mobile version's Nearby feature is more precise; does it use the Browser API?

From what I remember while testing, inside WMF we have GeoIP cookie, which has acceptable accuracy. It shows my location as near city center, which is approx 5km off from my physical location.
Outside WMF, we have ULSGeo cookie, which stores geolocation info. It uses freegeoip service and is always blocked by my browsers extensions. Visiting the service website, I remember it showing 80km apart city as my location. Using it right now, seems not to display decimal point accuracy for latitude and longitude, but shows my location more precise, with maybe 15km error.

What is poor accuracy?

Results that range from a right region of a city to a wrong continent (planet should be correct most of the time, for now).

What ULS has is usually not much more than a country.

We are querying for nearby articles which have coordinates. The accuracy of data in ULS does not matter. Only the accuracy of the geolocation API.

The mobile version's Nearby feature is more precise; does it use the Browser API?

Yes it does use the browser geolocation api.

Change 400266 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Add nearby suggestions

https://gerrit.wikimedia.org/r/400266

Petar.petkovic removed a project: Patch-For-Review.
Petar.petkovic moved this task from Incoming to Done on the Design board.
Petar.petkovic removed a subscriber: gerritbot.

Checked in cx-translation - all specs from the task and the discussion seem to be in place:

  • the layout looks compact (I am using the example with 'Albert Einstein' since it's used in the task):

  • the text was corrected - instead "Search for source page" - "Search for a page to translate". And the text "Think of any topic..." looks cleaner now.

However, there are few of relatively small issues that could be a separate tickets or they may be declined. Since they are not exactly the bugs, @Pginer-WMF, @Amire80 can you please triage them? I'll write follow-up(s) tickets if needed.

(1) no vertical scrolling after clicking on 'New translation'

(2) The button to start a new translation has the label 'Start a new translation' in mockup, but everywhere else the label is 'New translation'

(3) Is it satisfactory to have long article titles to be displayed like this?

(4) More interesting problem: 'Nearby` feature shows articles that have been already translated.

When it's ok to display articles that already exist in the target wiki when a user types, displaying already translated articles in 'Nearby' list of suggestions does not feel right.

(5) Why redirects are displayed in the suggestion list?

Etonkovidova moved this task from QA to Done on the Language-2018-Jan-Mar board.Jan 30 2018, 1:16 AM

(1) no vertical scrolling after clicking on 'New translation'

Ideally we want not to block the scroll while keeping the new translation panel floating on top. However, I think w can live with the current state for now.

(2) The button to start a new translation has the label 'Start a new translation' in mockup, but everywhere else the label is 'New translation'

This is ok. A shorter label helps in small screens.

(3) Is it satisfactory to have long article titles to be displayed like this?

Not the best, but considering the complexity of applying ellipsis to multi-line elements, I think we can leave it as it is since it is expected to work well for most articles.

(4) More interesting problem: 'Nearby` feature shows articles that have been already translated.

This is an issue. We should be proposing articles that are missing for users to create.

(5) Why redirects are displayed in the suggestion list?

Redirects act as an alias, an alternative way in which a given topic is known. For example "Tomato" and "solanum lycopersicum" are alternative names for the same concept. Regardless of which one is the real article and which is the redirect, it is ok for users to search for either to start the translaiton. Selecting the "solanum lycopersicum" redirect should lead to translate the "Tomato" page.


I also reported an issue related to keyboard use: T186195: Better keyboard support for the New translation dialog

Petar.petkovic closed this task as Resolved.Feb 2 2018, 4:53 PM

Resolving the ticket as it is moved to "Done" column.

@Pginer-WMF already provided some insights, but I'll give my take on last two comments.

(1) no vertical scrolling after clicking on 'New translation'

Ideally we want not to block the scroll while keeping the new translation panel floating on top. However, I think we can live with the current state for now.

I have provided a patch that removes no scroll effect on "New translation" dialog. Since list of results is clippable, we can have some jumpiness when scrolling on mobile, but that's more acceptable than being stuck with no scrolling, where some UI elements can be unreachable after certain sequences of actions.

(2) The button to start a new translation has the label 'Start a new translation' in mockup, but everywhere else the label is 'New translation'

This is ok. A shorter label helps in small screens.

The label was shortened from "Start a new translation" to "New translation" as part of T160067. The mock ups continued to use old label.

(3) Is it satisfactory to have long article titles to be displayed like this?

Not the best, but considering the complexity of applying ellipsis to multi-line elements, I think we can leave it as it is since it is expected to work well for most articles.

Long article titles were subject of T181701.

(4) More interesting problem: 'Nearby` feature shows articles that have been already translated.

This is an issue. We should be proposing articles that are missing for users to create.

This was actually done on purpose. After some conversations with @Pginer-WMF, I have made "Recently edited by you" list showing already translated pages, behaving the same as "Nearby" list is behaving now. I have created new ticket to track this suggestion - T186331.

(5) Why redirects are displayed in the suggestion list?

Redirects act as an alias, an alternative way in which a given topic is known. For example "Tomato" and "solanum lycopersicum" are alternative names for the same concept. Regardless of which one is the real article and which is the redirect, it is ok for users to search for either to start the translaiton. Selecting the "solanum lycopersicum" redirect should lead to translate the "Tomato" page.

I had in plan to deal with redirects and @Pginer-WMF gave much better guidance how redirects should behave in "New translation" dialog.

I also reported an issue related to keyboard use: T186195: Better keyboard support for the New translation dialog

Thank you for creating this ticket. I had some keyboard accessibility points on my TODO list, but public ticket is always better.