Page MenuHomePhabricator

Provide option to translate when searching for a missing language on mobile
Open, HighPublic

Description

On mobile, users have no clear way forward when the content is not available in their language. For example, a user trying to switch to the Bengali version of the Plants in Space article will get an empty list when searching for their language:

en.m.wikipedia.org_wiki_Plants_in_space(Pixel 2).png (1×1 px, 50 KB)

This ticket proposes to surface an option to translate the missing article using Section Translation. Surfacing an option to translate the page can be a meaningful next step that users in this context may be interested in.

This is proposed as a minimal intervention for the current language selector on mobile. Plans for the new language selector include additional possibilities to create missing content, but those may still take a while until it becomes the default selector on mobile.

The idea:

  • When searching for a language that (a) matches at least one valid language and (b) content is not available in such language(s), show an invite to translate. Note that it is possible that the search query for the user matches more than one language (e.g., "es" -> "esperanto", "español"). It is also possible that the search query does not correspond to a real language (e.g., "asdfasdf").
  • The invite will be only shown when searching for languages where Section Translation is enabled. Currently Section Translation is available on Bengali Wikipedia, which means it is possible to translate from any language into Bengali. The list of supported wikis will grow over time (T285842).
  • The invite will be presented as the empty state of the search results, as the user types and the above conditions are met.
  • The invite will link to Section translaiton in the corresponding wiki with the article and language parameters pre-filled (example link for the Moon article from English to Bengali)

Proposed design

The invite is presented as the empty state for search with a clear message about the language not being available and a follow-up encouragement to translate.

Up to two matching languages are shown as options to create the translation for, and a "more"(...) option is provided in case users want to translate into a different one.

mob-switch-search copy.png (562×375 px, 22 KB)

Messages:

Language not available
You can translate this page. It’s an easy way to create content in your language.

Event Timeline

Jdlrobson added a subscriber: Jdlrobson.

@Pginer-WMF is there any possibility we could merge the mobile version of the language selector with ULS as part of your planned rewrites?

@Pginer-WMF is there any possibility we could merge the mobile version of the language selector with ULS as part of your planned rewrites?

Yes. The idea for the new selector was to be responsive, so that it can be used in multiple context and hopefully replace the multiple controls used in different places across our products.

Change 708084 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/MobileFrontend@master] LanguageSearcher: Provide customisable empty state

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

@Jdlrobson In the WIP patch above I added a hook to fire when no results found and a placeholder for no-results. Screenshot:

image.png (281×403 px, 6 KB)

My plan is to add a RL module conditionally(based on target users for this entry point, wikis etc).

//  in ContentTranslation project
mw.hook( 'mobileFrontend.languageSearcher.noresults' ).add( function ( searchString ) {
 // Use searchString and handle it
} );

This will render custom actions to the mobile frontend noresults screen.

Do you think this is a good approach? Wanted to be less intrusive. Please let us know if there are better ways.

@alexhollender presumably we should have some kind of error message for the default behavior?

Screen Shot 2021-07-26 at 8.26.38 AM.png (912×1 px, 41 KB)

If so, perhaps @santhosh we add an empty state to this component and allow modification of the message via WikimediaMessages.

Note that this will require a new event_source value in the content_translation_event schema (T287403).

If so, perhaps @santhosh we add an empty state to this component and allow modification of the message via WikimediaMessages.

Overriding messages is not enough for this usecase. As you can see from the design, we need to add a message and then buttons that act as entry point to CX. They are dynamic too.

If so, perhaps @santhosh we add an empty state to this component and allow modification of the message via WikimediaMessages.

Overriding messages is not enough for this usecase. As you can see from the design, we need to add a message and then buttons that act as entry point to CX. They are dynamic too.

I asked a clarifying question around this on the ticket. The approach seems fine.

@Pginer-WMF I think it would be useful to have a mock for what this should look like without translation enabled.

@Pginer-WMF I think it would be useful to have a mock for what this should look like without translation enabled.

The messaging can follow what I proposed for the new language selector (T265585):

Overview Copy 30.png (768×1 px, 109 KB)

This is how the different cases would look like in this context:

Content not available in the language, with translation supportContent not available in the language, without translation supportSearching for a string which is not a language
mob-switch-search.png (800×375 px, 26 KB)
mob-switch-search-unavailable.png (800×375 px, 20 KB)
mob-switch-search-unrecognized.png (800×375 px, 24 KB)

I was not sure if we want to cover both (a) the general support for empty states and (b) the specific case of inviting to translate in the same ticket or have separate ones. So I kept the initial scope of the task about (b), but general empty result support would be a general improvement for the current selector too.

Okay got it! Let me know when you need some code review with a ping here and I'll happily help push this through!

@Pginer-WMF Identifying whether the search query is a language or not is not easy(Language not available vs language not recognized). You would need to search across autonyms of all known languages in our system, compensate for typos if we need. Also, the search query can be autonym, language name in current interface language or language code . I would recommend not to expand scope to that in this ticket. (a) and (b) can be good start.

@Pginer-WMF Identifying whether the search query is a language or not is not easy(Language not available vs language not recognized). You would need to search across autonyms of all known languages in our system, compensate for typos if we need. Also, the search query can be autonym, language name in current interface language or language code . I would recommend not to expand scope to that in this ticket. (a) and (b) can be good start.

Ok. If the distinction is complicated we can use the "Language not available" message in both cases. We can start with (b) and consider a simplified version of (a) as next step. Note that in this case both (b) and (simplified a) would show the same title for the message (in case this helps to implement b in a way that helps making the next step easier):

Content not available in the language, with translation supportOther cases where there is no match for the search query
mob-switch-search.png (800×375 px, 26 KB)
mob-switch-search-unavailable.png (800×375 px, 20 KB)

Test wiki created on Patch Demo by Jdlrobson using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/5700aec4e2/w/

Thanks for the live patchset. Looks good to me for the generic "no results found" state.

patchdemo.wmflabs.org_wikis_5700aec4e2_w_index.php_title=Valencia&mobileaction=toggle_view_mobile(iPhone 6_7_8).png (1×750 px, 47 KB)

A small nitpick I noticed is that the three text elements are not aligned to the same distance to the left edge. That would provide a clean scan line, but it is probably worth considering those adjustments for the new version of the selector. So I'd not consider it a blocker to proceed.

scanline.png (468×750 px, 34 KB)

Change 708084 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] LanguageSearcher: Provide customisable empty state

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

Change 709988 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] Add entrypoint to CX from mobile frontend language searcher

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

Screenshot_20210810-171344_Chrome.jpg (2×1 px, 193 KB)

I have suggested languages on my mobile device and I am now seeing a large area of whitespace above the new message. This didn't used to happen.

That is strange. I tested in my phone, Chrome browser and I see no issues

image.png (1×576 px, 82 KB)

Not seeing issue when accessed from desktop browser with mobile view either

image.png (435×526 px, 30 KB)

Change 709988 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Add entrypoint to CX from mobile frontend language searcher

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

That is strange. I tested in my phone, Chrome browser and I see no issues

image.png (1×576 px, 82 KB)

Not seeing issue when accessed from desktop browser with mobile view either

image.png (435×526 px, 30 KB)

Screenshot_20210811-062330_Chrome.jpg (2×1 px, 280 KB)

You must have a few suggested languages. The gap is bigger depending on how many (to get suggested languges you'll need to switch languages a few times)

Change 709988 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Add entrypoint to CX from mobile frontend language searcher

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

This added another two modules. Please remember to add new code to existing bundles instead, and conditionally executing it. Registering new bundles should be reserved as consious act with the intent to optimise performance ("module-splitting"), in which case one should quantify the end-user benefit and consider the bigger picture and user story (e.g. how likely it is that people will not interact with both parts of the code in a given week, the cost and delay of an extra network fetch to get the missing code when something could've been cached already from a previous page load, and the cost it adds to the registry for all users on all page loads).

CX currently registers 77 distict module bundles. Which after progress on T231326 is still the highest registry cost of any extension (and by count) on Wikipedia. I'm always available to help figure out an easy solution to improve module bundling, e.g. if you run into any difficult or awkward situations.

@Krinkle, in this case, we could not bundle it in existing RL modules as this is for mobile and targets mobilefrontend language selector. There is one init module which listen for hook fires from mobilefrontend language searcher and then another module which get loaded by init module for doing the actual work. Any suggestions to reduce this further?

CX currently registers 77 distict module bundles.

True. And more entrypoint features are coming to CX too. They are also similar to this case. I think we can further reduce this by combining more modules and removing many lazy load/on demand optimizations. But this is not trivial to do and require another full QA cycle and setting aside time from current activities. cc: @Pginer-WMF we will require another audit on this before we add more enty points as they need RL modules.

Change 716244 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] Language search entrypoint: Fill title and source language

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

One question about the way this is exposed only for Bengali. In the case we enable Section Translation in more languages, do we need any additional changes for those new languages to be considered by the entry point or does the component read form the same configuration in a single place where languages are added? (more context in T290302)

It need changes to the configuration variable ContentTranslationMFLanguageSearchEntrypointTargetLanguages. @KartikMistry FYI. The new language codes need to add there.

There is a configuration SectionTranslationTargetLanguage which takes only one language to restrict translation to that language. May be we can combine all of them to support multile (limited) language deployment

Change 716244 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Language search entrypoint: Fill title and source language

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

@santhosh I noticed that the entry point currently links to Content Translation, not the Section Translation version. Is that part of the last adjustments (to pre-select the article) or further changes are needed?

Current behaviour:

Notice the difference with the Section Translation dashboard (e.g., the notice on top):

bn.m.wikipedia.org_w_index.php_title=%E0%A6%AC%E0%A6%BF%E0%A6%B6%E0%A7%87%E0%A6%B7_%E0%A6%AC%E0%A6%BF%E0%A6%B7%E0%A6%AF%E0%A6%BC%E0%A6%AC%E0%A6%B8%E0%A7%8D%E0%A6%A4%E0%A7%81_%E0%A6%85%E0%A6%A8%E0%A7%81%E0%A6%AC%E0%A6%BE%E0%A6%A6&campaign=sp.png (1×640 px, 116 KB)

Yeah, pointing to section translation instead of Content translation was part of last patch (https://gerrit.wikimedia.org/r/716244) that got merged this week. It should get to the wikis next week. This week there is no train.

Yeah, pointing to section translation instead of Content translation was part of last patch (https://gerrit.wikimedia.org/r/716244) that got merged this week. It should get to the wikis next week. This week there is no train.

Perfect. Thanks Santhosh!

found something weird.
when we are on a slow network, the entry point message gets delayed and only shows when the call is finished.
when this happens, there should be a loading gif, what do you think @Pginer-WMF ?

delayMessageULS.gif (786×968 px, 1 MB)

QA notes:
test in production when deployed since only one language is available in test and beta wikis

This ticket represents a temporary intervention until the new language selector becomes available. If there is a relatively simple fix for this, we can consider it. But I'd need @santhosh input to understand the possibilities for improvements and their complexity.

If it is more complex, it may be worth spending the efforts on the new version.

The delay between no results and our entrypoint is the time it takes to load the code for showing the entrypoint. This code is lazy loaded when langauge selector from mobile frondend emits no-results event for the first time. Not lazy loading will imply our entrypoint code delivered to client devices unnecessarily. So it is a tradeoff.

In an ideal design and implementation, the language selector will know possible actions when no results are found. Currently that is not the case. Here the mobile frontend language selector broadcasts "look, a search with no results", and then " a small code snippet that is always loaded from CX codebase listens and load the actual code to show the entrypoint and handle click actions, evenlogging etc.

The delay between no results and our entrypoint is the time it takes to load the code for showing the entrypoint. This code is lazy loaded when langauge selector from mobile frondend emits no-results event for the first time. Not lazy loading will imply our entrypoint code delivered to client devices unnecessarily. So it is a tradeoff.

In an ideal design and implementation, the language selector will know possible actions when no results are found. Currently that is not the case. Here the mobile frontend language selector broadcasts "look, a search with no results", and then " a small code snippet that is always loaded from CX codebase listens and load the actual code to show the entrypoint and handle click actions, evenlogging etc.

Thanks for the details, Santhosh.
Given that Section Translation is not available in all languages, I think it is perfectly ok not to tax every user with additional code. Future user research may help to identify if this glitch is affecting the discovery of the tool, but for now we can keep this aspect as it is.