Content translation/Product Definition/Mobile exploration

From MediaWiki.org
Jump to navigation Jump to search

Project goal: Facilitate the contribution of knowledge by transferring it from a different language while using mobile devices. We expect the volume and quality of contributions made on mobile to increase.

What mobile means[edit]

Opportunities[edit]

  • Lots of potential users. There are lots of mobile devices and mobile-only users.
  • Room to innovate. No existing support for translation. No similar app or site (almost). We have a blank page to get started.

Risks[edit]

  • Lack of knowledge about mobile language-related contribution. We don’t have much data about current and potential kinds of contributions, or the real constraints when consuming and contributing knowledge in the platform.
  • Inertia to just port what was done on desktop. With a translation tool available in desktop it may be tempting to just port the same experience. We need to identify the space of possibilities to evaluate those with more expected impact.

Users to target[edit]

  • Editors. Help them to “Make a contribution on mobile based on content from other languages”.
  • Active readers. Help them to “Access knowledge in the best way (and maybe become editors)”

The design space[edit]

Below we explore the factors that affect the mobile experience of our target users, and some possible directions to explore for each of them (examples are added to illustrate each factor, but they can take many different forms).

Experience for Editors[edit]

Kind of contribution[edit]

  • New content. Create a new article.
  • Improvements on existing content. Create a new paragraph on an existing article.
  • Reuse existing content. Easily reuse images and references from other languages while editing.
  • Quality assessment. Proofread translated content and surface issues.
  • Identify missing content. Connect red-links with existing articles in other languages. Mark missing sections in an article that exist in other languages.

Granularity of the contribution[edit]

  • Fully connected contribution. A whole article (challenge: manipulate big pieces of content).
  • Small pieces. A paragraph, word, sentence, image, section headings, etc. (challenge: lack of overall context).

Purpose of the contribution[edit]

  • to be read. Add content to the sum of human knowledge.
  • to inform other processes. Serve other editors/translators.

Added value (in which ways we can help?)[edit]

  • Automate steps. Let machines do (part of) the work.
  • Facilitate content display. Make it easy to move around and keep the needed info at hand.
  • Facilitate content manipulation. Make it easy to edit based on language info.
  • Facilitate user collaboration. Distribute the workload and help others.

Access[edit]

  • Part of the editing experience. Editing gets enhanced with language capabilities.
  • Separate experience. A specific tool for translation.

Motivation[edit]

  • Lack of other device. Mobile-only user, or just traveling in the bus.
  • Quick contribution. Not worth leaving the sofa and opening the laptop.
  • Personal progress. Advance as a translator (e.g., gamification).
  • Leverage mobile unique capabilities. Interaction (voice and gestures), context-awareness (nearby articles), integration with other apps (share on Twitter), etc.
  • Complement the desktop experience. Continue on desktop what you started on mobile, use as a second simultaneous screen, etc
  • Improve learning. Help users to learn new stuff as they translate (e.g., learn a language as with Duolingo, or learn about a topic…).
  • Impact on readers. Access to knowledge; visibility of how many people read what you wrote.

Experience for Readers[edit]

Purpose[edit]

  • Access to information. Provide information otherwise unavailable.
  • Get feedback on quality of translation.[1] Can be easy without having to type a lot.
  • Convert them into editors/translators.

Possible examples[edit]

The above parameters define the design space to explore. If we pick one option for each category we will be able to explore a whole set of possible solutions in a given direction. Below there are a set of examples just to illustrate how diverse solutions can be (picking the promising ones requires more exploration and evaluation):

  • Automatically-generated version for missing articles (based on Wikidata facts, Machine Translation, and images available in other languages). Readers can get an idea and have ways to provide feedback on the translation quality (informing translation suggestions system) and to fix/extend the automatic content (turning readers into contributors). In that way, the content can transition from automatic to curated one step at a time.

Integrate new content into existing translations. When an article gets updated, you can transfer that content to their translations by creating a translation and placing it in the right place in the article.

  • Organize and proofread translations. Identify which articles to translate next, organize them in lists to share with others, and proofread what others translate. Issues identified will inform translators as suggestions to improve.
  • Quick contributions. Based on your location and interests, small pieces of content are shown for translation: images for you to translate their captions, section names and short descriptions, and missing links to connect with their corresponding article. You can easily open the articles you discover to learn more about them. Translators will benefit from those small contributions.
  • Language-aware editing experience. The editing experience can be augmented to easily add content such images, links, references or sections from other languages the user knows. Furthermore, tools such as spell checkers can help with the process.
  • Create new articles from other languages. Create an initial version of a missing article by correcting an initial automatic translation and reusing content from another language.

Adding information to existing articles from corresponding articles in other languages, for example images that don’t yet appear in your current language.

Data that could be useful[edit]

The usual assumption is that people want to type as little as possible on mobile, but it would be nice to get details from existing data from Wikimedia, and hopefully other sites:

  • Twitter definitely works well, and they have very short sentences to type - up to 140 by definition.
  • Duolingo and Memrise definitely pretty well, and they usually have sentences that are even shorter than on Twitter.
    • Based on what Luis von Ahn said at his Wikimania talk, Duolingo mostly gave up on translation on the desktop site, and doesn’t even bother to do it on mobile.
  • Facebook definitely works well, although it’s hard to know how much text do people actually taptaptap through mobile.
    • Recently Facebook started trying to get translations for their UI on mobile - far from perfect.
  • Something similar is probably true for Tumblr and Quora - probably on a smaller scale, but usually with longer texts. Again, the Real data is probably secret.
  • WordPress.com may be similar, too, and they could be more open, so we could try to ask them for data.
  • Tatoeba is doing something similar to what we could do - translating sentences. But it doesn’t appear to have an app or a mobile-friendly site for contribution, just a usual desktop site.
  • Pootle and Transifex seem to have apps, but it doesn’t look like they are used much. OneSky, which is targeted at translating mobile apps, doesn’t have a mobile app itself.
  • Medium tried posts translation, but discontinued it (and it was desktop-only)

Inside Wikimedia:

  • Statistics about the screen resolution that people are using when they are browsing Wikipedia from mobile devices, and separately, statistics about the screen resolution that people are using when they are editing Wikipedia from a mobile device.
  • How long are mobile edits?‏ How many characters do people actually type when they edit wiki pages through mobile web and mobile apps? How many meaningful keystrokes? A simplistic way would be to measure the number of added characters, but that's not quite correct, because deleting a wrong letter and typing a correct one looks like zero added characters, but actually it's at least two meaningful keystrokes. By knowing the above two pieces of information, we may estimate what should be the length of the text units that we give people to translate.
  • Do people create articles through mobile interfaces these days?
  • People who do type information through mobile interfaces - do we have any reason to think that they took it from other languages?
  • From which geographical areas do people edit Wikimedia projects using mobile devices?[2]
  • Which articles are searched most and missing in language, that can feed our suggestion mechanism. It can be an explicit translation request by user or by automatically registering “missing article”.

Footnotes[edit]

  1. Facebook experiments with something similar for UI translation since mid-2015.
  2. More or less answered by Oliver Keyes - same places where people edit from desktop. That is, access to mobile editing does not by itself increase the likelihood of editing in new areas, at least not yet.