Page MenuHomePhabricator

[GOAL] Improve in-article language switching on mobile web I
Closed, ResolvedPublic


This task can be closed. Remaining work + additional work identified by user research is captured here: T137932

Definition Progress

The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item.

  • Summary
  • Rationale
  • Success Metrics
  • External Dependencies
  • Unknowns
  • Product Plan
    • Prototyping
    • MVP
    • User stories
    • User Story Phab Tickets
    • Metrics Implementation
    • Metrics Phab Tickets
    • Estimates
    • Delivery Date


This is intended to improve the reading experience of users who speak more than 1 language (almost everybody who didn't learn english as their first-language) and primarily for those users whose primary language has limited content. It is quite common for such a user to want to see if the article in another language has more content or if the can understand the content better in another language. This is particularly important for users whose primary lang

Goal Visibility

Is this goal a Readership Goal that is committed externally here:


The current language-switching button is buried at the bottom of the article and still gets more clicks than the hamburger menu see mobile report card (table name is 'page-ui-daily').

Success Metrics

Our current success metric is to increase language switching by 5% on mobile, but another success metric would be to achieve parity with desktop or Android language switching. We have not established those baselines.

External Dependencies

Unknown at this time.


The current best thinking here is to put the language switching in a sticky, floating footer bar that can house other article-level actions. This is being explored in the latest version of the iOS app (unreleased as of 12/18) and this ticket for web: T119658 However, early prototyping and design exploration might prove us wrong.

Product Plan


[WIP] Initial prototype

  • Create a sticky footer
  • Make it responsive
  • Open modal on tapping of the language button
  • change the language of article from language modal window

Usability testing

  • Create a protocol for usability testing
  • Define success criteria
  • Do the usability test


At a minimum, this requires that language switching within an article is not limited to the bottom of the article, provided that research does not disprove our hypothesis that the bottom of the article is not the optimal location for language switching.

User Stories

As a user I want to see what other languages an article is available in without scrolling to the bottom of the article.

Metrics Implementation

This will require:

  • Ability to roll feature out to subset of users.
  • Ability to measure language switching actions per pageview, session or user (only one is necessary, but pageview is compromised because every language switch generates another pageview..but on another project) on mobile web
  • Optional: Ability to measure language switching (per pageview, session, or user) on desktop and android

Timeline Estimate

List estimates below. These do not have to be exact. These are just used to validate proposed timelines and ship dates.

Prototyping0 weeks
User Testing2 weeks
Mockups2 weeks
Development2 weeks
Beta Testing and analysis2 weeks (most testing will be done on small % of users in stable)
Rollout to stable to small % of users2 weeks
Rollout to all users4 weeks

Delivery Estimate

End of February to 2% of stable users?

Related Objects

Resolved JKatzWMF
Resolved bmansurov
Resolved bmansurov
Resolved bmansurov
Declined Nirzar
Resolved bmansurov
Resolved bmansurov
Invalid bmansurov
Resolved Nirzar

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

You should probably reuse T66793 (maybe in the form of T104912), as a shorter list of languages is easier to place in a more prominent place.

The current Wikipedia Mobile app (v4.1.7) in the App Store has a persistent language picker, whereas the forthcoming version of the app (5.0.x) has an in-article mode where the language picker is displayed (i.e., no language switcher in discovery/feed, but easily accessible in article reading mode). I'm unsure if data are collected to explicitly gauge the level of engagement with the language switching button on v4.1.7 of Wikipedia Mobile.

One note about any potential analysis of use of the button: iOS platform app users are said to have a different geographic and multilingual concentration than, say, the mobile web at large.

Jhernandez renamed this task from [EPIC] Improve in-article language switching on mobile to [GOAL] Improve in-article language switching on mobile.Jan 12 2016, 1:11 AM
Jhernandez triaged this task as High priority.
Jhernandez removed a project: Epic.

@Nirzar @dr0ptp4kt What's up with the Usability testing section? Are we going to actually do it?

@Nirzar is there more designs to be done regarding the language modal or are we keeping it the same as it currently is (like on the prototype)

Jhernandez renamed this task from [GOAL] Improve in-article language switching on mobile to [GOAL] Improve in-article language switching on mobile web.Jan 12 2016, 1:33 AM

Hi @Nemo_bis, thanks for adding the blocking tasks. I've removed them since this is the goal task for the reading web team, and is related to the apps, not the web, and seems to have been superseeded by ULS-CompactLinks.

Jhernandez moved this task from Triaged but Future to Epics/Goals on the Web-Team-Backlog board.

Definitely. It has the Epic template on the description and a bunch of blocked tasks.

What's the status on this goal? It was listed in the last quarter goals and not on the current quarter goals but this epic is not resolved even if it says Done in last quarter goals.

We should get clarity on this and review the blocking tasks to remove them from blocking this one or resolve them so that we can close this goal.

@Jhernandez Thanks for flagging this. I will put together tasks/blockers for Q1. I am not sure if it should sit in this epic or not. The reason I am unsure is that design research and the work of the language team on desktop has uncovered some new add ons that were not part of this original epic. What do you think?

As to why the goal for Q2 was marked done, it because it was to ship to beta, which was accomplished. I am actually looking to see if we achieved the 5% lift now.

@JKatzWMF I'd favor having a new Epic as the new Q goal that mentions this one for reference, and inherits the new tasks from user research and the blockers of this one, with a new description with the plan.

That way we keep this one for history (data of what happened when this was a goal), and we can also resolve it ( i love closing tasks).

Let me know if I can help somehow.

JKatzWMF renamed this task from [GOAL] Improve in-article language switching on mobile web to [GOAL] Improve in-article language switching on mobile web I.Jun 15 2016, 11:30 PM
JKatzWMF updated the task description. (Show Details)
JKatzWMF claimed this task.

New epic captures remaining blockers and more for more accurate view of 2015-2016 Q1 Goals. Closing this one.