Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/mobile/cards/1187

This one is a bit tricky to fix, since MediaWiki doesn't actually have any concept of a "Terms of Use" link. It isn't a standard footer link like "Privacy policy", "Disclaimers", etc. Should non-Wikimedia wikis even have a "Terms of Use" footer link in the mobile view? There is no equivalent in the desktop view. Should we introduce such a footer link in the desktop view as well? How should the wiki owner configure this link? Through the installer? In LocalSettings.php? By specifying a MediaWiki message on-wiki? Also, we'll need to override the link for Wikimedia wikis, probably through the WikimediaMessages extension so that they point to the wikimediafoundation.org page instead of a local page.

We'll need to answer some of these questions before we can more forward on a solution.

Are these questions getting answered?

Speaking for MediaWiki + MobileFrontend out of the box, without Wikimedia customization...

(In reply to comment #2)

Should non-Wikimedia wikis even have a "Terms of
Use" footer link in the mobile view? There is no equivalent in the desktop
view.

MobileFrontend shouldn't add legal options not available in the desktop view.

Contact, Privacy, About and Disclaimers are already enforced in MobileFrontend. This already exceeds the needs for legalese of most MediaWikis.

Er... sorry, but why an enhancement request? This actually looks like a serious problem to me (as serious as Wikimedia legal texts are, that is).

Currently all the independent MediaWikis out there using MobileFrontend are claiming that their own "Terms of Use" are http://wikimediafoundation.org/wiki/Terms_of_use?useformat=mobile

There you find a Wikimedia logo, "Part of our mission is to:"...

Kenan - thoughts?

Low priority + Enhancement... Right. :)

Ok, my last argument on this report: MobileFrontend seems to be installed in about hundred non-WMF sites, all of them linking to WMF terms of use:

http://wikiapiary.com/wiki/Extension:MobileFrontend

Popular wikis (according to the number of pages and editors) include:

https://wiki.openstack.org/w/index.php?title=Main_Page&mobileaction=toggle_view_mobile

http://www.droidwiki.de/index.php?title=Hauptseite&mobileaction=toggle_view_mobile

http://www.pokepedia.fr/index.php?title=Accueil&mobileaction=toggle_view_mobile

And even

http://m.yoursexwiki.com/wiki/Main_Page (warning: explicit content)

I've poked Kenan several times. I will ask him again today to look into this.

The only reason I marked as an enhancement is after install it is easy to set redefine the message 'mobile-frontend-terms-use-text' to override it although since you pointed out a lot of people keep defaults and that doesn't have ideal results.

I guess this is not obvious but I'm not sure how we can do this in a nicer way at the moment. Obviously that changes alot if Kenan or Luis let me know we need to change it asap because of legal issue heres...

Copying from Luis:"Medium priority? It's not an emergency, because it doesn't obligate us to anything, but it is still pretty misleading to mediawiki users, so we would like to get it fixed.

Not terribly specific, I know - let me know if you want to discuss further."

For what it's worth: third-party wikis often use the "disclaimers" stuff (MediaWiki:Disclaimers & MediaWiki:Disclaimerpage) to prove a "Terms of Use" link.

My $0.02: create a system message for MobileFrontend ToU link; check the existence and act accordingly (i.e. if it has some content other than "-", treat it as a link; otherwise don't show it in the footer at all).

kwang wrote:

I'm going to look at getting this into the next iteration.

Change 92994 had a related patch set uploaded by MaxSem:
Don't force WMF terms of use upon everyone

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

Note that the mobile edit preview page also includes a hardcoded link to the Terms of Use.

Change 92994 merged by jenkins-bot:
Don't force WMF terms of use upon everyone

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

Quim, there is a separate bug for that particular issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=56639

Marking this as resolved now that patches are merged. Changes should start showing up with the deployment train.