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

In T286645#7212411, @Jdlrobson wrote:

@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:

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?

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).

In T286645#7236626, @Jdlrobson wrote:

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.

In T286645#7238507, @santhosh wrote:

In T286645#7236626, @Jdlrobson wrote:

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.

In T286645#7239764, @Jdlrobson wrote:

@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):

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

Content not available in the language, with translation support	Content not available in the language, without translation support	Searching for a string which is not a language

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.

In T286645#7245463, @santhosh wrote:

@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 support	Other cases where there is no match for the search query

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

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

@alexhollender @Pginer-WMF just looking for a quick design review on https://patchdemo.wmflabs.org/wikis/5700aec4e2/w/index.php?title=Valencia&mobileaction=toggle_view_mobile before I merge @santhosh patch.

In T286645#7246434, @Jdlrobson wrote:

@alexhollender @Pginer-WMF just looking for a quick design review on https://patchdemo.wmflabs.org/wikis/5700aec4e2/w/index.php?title=Valencia&mobileaction=toggle_view_mobile before I merge @santhosh patch.

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

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.

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

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

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

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

In T286645#7274564, @santhosh wrote:

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

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

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)

In T286645#7275195, @gerritbot wrote:

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

Test tip: Go to https://en.m.wikipedia.org/wiki/Coraciidae search for bn in language search

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

I created/updated a few follow-up tickets for instrumentation, performance and deployment:

• T290428: Instrument the mobile language selector entry point to Section Translation
• T290431: Explore reducing Resource Loader modules further
• T290302: Confirm Section Translation can support the new set of languages

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):

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.

In T286645#7341354, @santhosh wrote:

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 ?

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.

In T286645#7351512, @santhosh wrote:

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.

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

[mediawiki/extensions/ContentTranslation@master] Mobile Frontend Language search entry point: Redirect to target wiki

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

Change 723425 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Mobile Frontend Language search entry point: Redirect to target wiki

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

I tried the entry point on a group 1 wiki, and most of the issues seem fixed. However, there is still an unexpected behaviour: the link opens in a new tab, where it should be a regular navigation.
Can this be easily fixed or a separate ticket may be needed?

Related to the previous glitch, when testing on desktop the mobile version, the ".m." part of the domain gets lost as part of this navigation. Maybe this is related to the previous issue. In any case, it would be preferred for the mobile domain to remain so those accessing the mobile version on desktop keep a consistent experience.

@Amire80 pointed out that the entry point is only visible right now when the user has enabled the Content Translation beta feature in a given wiki. This adds an unnecessary barrier since (a) beta features are not easily accessible on mobile, and (b) the entry point is only surfaced when users search for a specific language (not intrusive to consider the beta feature limitation). Thus, exposing the entry point regardless of the activation of the beta feature would be preferred in this case.

waiting for issues to be fixed

In T286645#7398145, @Jpita wrote:

waiting for issues to be fixed

Compiled pending issues in a separate ticket: T292828: Language selector entry point to Section Translation needs adjustment

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

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