Improve the New Translation dialog to easily find articles to translate
Open, HighPublic

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
Amire80 triaged this task as Normal priority.Sep 4 2015, 8:57 AM
Amire80 set Security to None.
Amire80 moved this task from Backlog to CX7 on the ContentTranslation board.Sep 4 2015, 3:12 PM
Amire80 moved this task from CX7 to CX8 on the ContentTranslation board.Jan 24 2016, 10:30 PM
Amire80 moved this task from CX8 to CX9 candidates on the ContentTranslation board.
Pginer-WMF updated the task description. (Show Details)Feb 26 2016, 4:26 PM
Pginer-WMF updated the task description. (Show Details)Mar 9 2016, 11:27 AM
santhosh updated the task description. (Show Details)Nov 30 2016, 9:07 AM
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

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.EditedThu, Jan 4, 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.