The translation extension simply needs to review and update it's resources to target mobile. It's possible css changes/JS changes may be needed to support smaller browsers. We are not doing anything additional to blacklist this.

Word of caution the existing ui pattern of
See https://www.mediawiki.org/wiki/ResourceLoader/Writing_a_MobileFrontend_friendly_ResourceLoader_module

The translation extension simply needs to review and update it's resources to target mobile.

Do you have any reason to believe this is every going to happen? Who decided that it's not ok for mobile already?

We are not doing anything additional to blacklist this.

Irrelevant. If you add a general blacklist, you are responsible with handling the whitelist. If you don't want to whitelist functioning stuff, drop the unconditional blacklist.

You have raised a bug so you noticed.

I am happy with helping anyone optimise for mobile who understands this codebase.

So yes I think this will happen.

Even with the trivial one line change the experience remains broken so it does need work.

I've corrected the projects as this has nothing to do with MobileFrontend. I've kept reading web on to keep an eye on this. As I said I'm happy to help anyone who knows this extension.

If you want a sweeping change that's another bug with far more considerations and is unlikely to be fixed anytime soon.

You have raised a bug so you noticed.

No. I only filed the report of another user, who says Special:Translate works perfectly fine for them on a mobile phone but MobileFrontend intercepts the request bringing them to a place where nothing works.

Either way the process has started so thank you :)
Am hoping @Nikerabbit or someone can help us get this fixed.

please just redirect every Special:Translate URL from MobileFrontend to the desktop site.

ditto

A wiki administrator can always use the wgMFNoMobilePages configuration variable (set to Special:Translate) to blacklist a page.

Change 281377 had a related patch set uploaded (by Nemo bis):
Prevent MobileFrontend from destroying Special:Translate

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

In T102922#2148185, @Florian wrote:

A wiki administrator can always use the wgMFNoMobilePages configuration variable (set to Special:Translate) to blacklist a page.

A bit annoying for every Translate wiki to be forced to do this, but ok. Can you confirm the blacklist will work for non-Wikimedia wikis too?

In T102922#2176749, @Nemo_bis wrote:

Can you confirm the blacklist will work for non-Wikimedia wikis too?

?? What do you mean exactly? It will work as long as it's configured, it's a feature of MobileFrontend, so it shouldn't depend on a wmf-wiki or not :)

With regards to https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085277.html – I think we can just use this task.

Special:Translate uses lots of libraries:

• es5-shim
• ext.uls.buttons
• jquery.appear
• jquery.autosize
• jquery.makeCollapsible
• jquery.textSelection
• jquery.textchange
• jquery.tipsy
• jquery.ui.position
• jquery.uls.grid
• mediawiki.Uri
• mediawiki.api
• mediawiki.api.parse
• mediawiki.jqueryMsg
• mediawiki.user
• mediawiki.util

What does it mean to check that something is mobile friendly?

So the following modules have not got a target set so that they can run on mobile:
*jquery.appear
*ext.uls.buttons
*jquery.autosize
*jquery.textchange
*jquery.tipsy
*jquery.ui.position
*jquery.uls.grid

What does it mean to check that something is mobile friendly?

We'll need to review all the above libraries to work out if they make sense on mobile e.g. would introducing the library unnecessarily bloat the JS we ship to users by providing similar functionality to an existing library), whether they were written/tested on mobile (some libraries are not)

One thing we've commonly done when porting something to mobile is we've created a mobile entry point.
e.g. if we have a module ext.translate we have split it into ext.translate.desktop and ext.translate.mobile to allow us to explore this. Can Special:Translate function in a minimal way without these libraries if we were to refactor the code?

On the longer term, this would be a good opportunity to consolidate some libraries. For instance ext.uls.buttons looks like it could easily be swapped out for mediawiki.ui.button or oojs ui (which are already mobile friendly) to provide the same functionality. jquery.autosize looks like a bigger version of mobile.microAutoSize so we should have a look at these two libraries and what they do differently.

@Nikerabbit would you be interested in setting aside some time next week to have a look at this with me?

In T102922#2230019, @Jdlrobson wrote:

So the following modules have not got a target set so that they can run on mobile:

And whole of TUX code I assume? I only included the dependent libraries on the list above.

Can Special:Translate function in a minimal way without these libraries if we were to refactor the code?

TUX (nickname for the new UI) does not work without JavaScript all. That's why I was looking feedback for completely separate minimal, low maintenance interface which does not require JavaScript.

On the longer term, this would be a good opportunity to consolidate some libraries. For instance ext.uls.buttons looks like it could easily be swapped out for mediawiki.ui.button or oojs ui (which are already mobile friendly) to provide the same functionality. jquery.autosize looks like a bigger version of mobile.microAutoSize so we should have a look at these two libraries and what they do differently.

I agree, ext.uls.buttons has been on the kill list for long time, just not done yet. Happy to look into autosize as well.

@Nikerabbit would you be interested in setting aside some time next week to have a look at this with me?

Yes but I am on a vacation next week. Is after that okay?

In T102922#2230031, @Nikerabbit wrote:

In T102922#2230019, @Jdlrobson wrote:

So the following modules have not got a target set so that they can run on mobile:

And whole of TUX code I assume? I only included the dependent libraries on the list above.

Yup.

Can Special:Translate function in a minimal way without these libraries if we were to refactor the code?

TUX (nickname for the new UI) does not work without JavaScript all. That's why I was looking feedback for completely separate minimal, low maintenance interface which does not require JavaScript.

Note this is not as scary as it seems. Provided the JavaScript only runs on a special page many of the translate extension specific code can be enabled after some simple testing, it's just a good opportunity to audit it and test it on some real mobile devices and make use of already available libraries where possible to make it as streamlined as possible.

On the longer term, this would be a good opportunity to consolidate some libraries. For instance ext.uls.buttons looks like it could easily be swapped out for mediawiki.ui.button or oojs ui (which are already mobile friendly) to provide the same functionality. jquery.autosize looks like a bigger version of mobile.microAutoSize so we should have a look at these two libraries and what they do differently.

I agree, ext.uls.buttons has been on the kill list for long time, just not done yet. Happy to look into autosize as well.

@Nikerabbit would you be interested in setting aside some time next week to have a look at this with me?

Yes but I am on a vacation next week. Is after that okay?

Yup I'm at a team offsite first week of May so let's aim for 8th onwards to kick this work off. I'll send out a meeting invite.

The above isn't especially interesting to me or the users on behalf of which I filed this report. These users only asked to reach Special:Translate, which works perfectly for them (so they said). Let's do that as first thing.

Change 288251 had a related patch set uploaded (by Jdlrobson):
Enable Translate extension modules on mobile

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

Change 288321 had a related patch set uploaded (by Jdlrobson):
Enable UniversalLanguageSelector modules for mobile

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

Change 288322 had a related patch set uploaded (by Jdlrobson):
Add translate styles via addModuleStyles

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

The above patches take care of 2-4 of the things I said I'd do. I'll look at jquery.appear, jquery.tipsy and jquery.ui.position soon.

Change 288322 merged by jenkins-bot:
Add translate styles via addModuleStyles

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

So far what has been merged is to get rid of ext.uls.buttons and there is work in progress marking the Translate and ULS resource loader modules for mobile use.

Still todo is improving look/grid for smaller screens and looking at those jquery library dependencies.

@Nikerabbit I will take a lot at those libraries today. Would be great if you could review the ULS patch.

I am holding the ULS patch a bit to avoid too many changes going out with next deployment train. Will look into it soon.

jquery.ui.position

Makes no sense on mobile. Given you are usually thinking in terms of a viewport on mobile and do not have a mouse cursor in a traditional sense I'd recommend removing.

jquery.tipsy

I think this one's okay. It's not great for mobile - you have to click to view things which is not obvious. It's 11kb unzipped (1.64kb gzipped). I think we can set its target to mobile.

jquery.appear

This library concerns me a little as for every call of appear it sets up a scroll and resize event (undebounced). I'd recommend you instead take care of this yourself using the mediawiki.viewport ResourceLoader module which is already written to work on mobile.

@Krinkle usually has good thoughts around this sort of thing so am curious if he has anything to add. @Nikerabbit does moving away from the other 2 libraries seem feasible?

In T102922#2323300, @Jdlrobson wrote:

jquery.ui.position

Makes no sense on mobile. Given you are usually thinking in terms of a viewport on mobile and do not have a mouse cursor in a traditional sense I'd recommend removing.

Not sure I understand this comment. We use it in one place to position absolutely placed element (menu) in relation to another element (trigger).

Change 281377 abandoned by Nikerabbit:
Prevent MobileFrontend from destroying Special:Translate

Reason:
We are working on a different approach.

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

Change 292136 had a related patch set uploaded (by Nikerabbit):
Stop using jquery.appear which is not enabled for mobile.

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

Change 292298 had a related patch set uploaded (by Jdlrobson):
Remove jquery.tipsy from UniversalLanguageSelector

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

@Nikerabbit I just noticed T117720 exists and on reflection given there is only one use of it I would advise we move away from tipsy rather than add it to mobile. I've written a patch to do that. Let's discuss any concerns you have around doing that on T119417

Gave some feedback on your patch! FYI I'm off on vacation today. My whereabouts is in my calendar but I won't be available for a bit. I am glad to see progress here! :)

If we get rid of tipsy in ULS then we can do the same in Translate.

https://meta.m.wikimedia.org/wiki/Special:Translate is still unusable. It would be nice to redirect the user to a functioning Special:Translate URL in the meanwhile.

Change 292298 merged by jenkins-bot:
Remove jquery.tipsy from UniversalLanguageSelector

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

Change 288321 merged by jenkins-bot:
Enable UniversalLanguageSelector modules for mobile

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

Change 305195 had a related patch set uploaded (by Nikerabbit):
Replace jquery.tipsy with OO.ui.PopupWidget

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

Change 305195 merged by jenkins-bot:
Replace jquery.tipsy with OO.ui.PopupWidget

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

Change 292136 merged by jenkins-bot:
Stop using jquery.appear which is not enabled for mobile.

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

I think that I reviewed everything, but https://gerrit.wikimedia.org/r/#/c/288251/ says:

08:31:52 1) ResourcesTest::testUnsatisfiableDependencies
08:31:52 The module 'ext.translate.multiselectautocomplete' must not have target 'mobile' because its dependency 'jquery.ui.autocomplete' does not have it
08:31:52 Failed asserting that an array contains 'mobile'.

Can ext.translate.multiselectautocomplete be easily ported to use OO.ui.LookupElement ?

Perhaps, but it is not used in Special:Translate.

Change 288251 merged by jenkins-bot:
Enable Translate extension resource loader modules on mobile

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

OK, so now all the known patches are merged or abandoned.

I checked some items from the task description that appear to be resolved.

Some questions:

• Is "Remove use of jquery.ui.position" resolved? It's not checked at the top, and it still seems to be used in ext.translate.groupselector.js (.position()?), but I might be misreading the code.
• Is "Review grid system and get it working < 600px" resolved? As far as I can see, it isn't, but I might be wrong. Should there be a separate task for it?

In T102922#2632328, @Amire80 wrote:

• Is "Remove use of jquery.ui.position" resolved? It's not checked at the top, and it still seems to be used in ext.translate.groupselector.js (.position()?), but I might be misreading the code.

It's still in use, see T144131: Replacement for jquery.ui.position in Translate

• Is "Review grid system and get it working < 600px" resolved? As far as I can see, it isn't, but I might be wrong. Should there be a separate task for it?

I have done some tweaks, but the truth is this is just the first step. Now the work can continue on making the page work well on mobile, which was kind of hard before when it did not work at all.

Also, since wmf.19 is rolled back, it will take some more time before this fix is visible there.

VERIFIED FIXED by visiting https://meta.wikimedia.org/wiki/Special:Translate from an Android browser:

Added the Verified task per @Nemo_bis.