this is by design so not a bug

as mobile editing is still new and we don't have enough data about editing to make an informed decision we started with registered users only.

I'd suggest raising the issue on village pump to see if a project wants it to take this forward.

The visual editor is new, but the regular editing isn't.

At least the message Mobile-frontend-editor-cta should say something about it: instead of "You must be logged in to edit pages on mobile.", it should say "Mobile editing for anonymous users is disabled. Either log in or use the desktop version to edit the page".

Thank you for filing this bug, Eran Roz.

(In reply to comment #1)

this is by design so not a bug

as mobile editing is still new and we don't have enough data about editing to
make an informed decision we started with registered users only.

As documented at https://meta.wikimedia.org/w/index.php?title=Founding_principles&oldid=46234, the "ability of anyone to edit articles without registering" is a founding principle of Wikimedia wikis.

Any software (MobileFrontend or otherwise) that inhibits the ability of users to freely edit unquestionably has a valid bug. A design decision by a small development team cannot simply discard core principles.

Re-opening this bug.

While being a major issue, it's not high priority IMHO. The mobile team has been cautious about expanding access to contribution tools because they have their limitations and the community has often reacted bad (see Commons about the mobile uploads) – this is my understanding.

I don't know whether this has been trialed before and there are stats, but we (community) could start collecting blocking bugs/requirements for this request. The mobile team, at some point, could make clear that a wiki, if the consensus wants so, can get anonymous mobile editing enabled on the understanding that (presumably) there are no resources for bug fixing but we'd just be in "learning mode". Etc.

There are many ways to handle this request and none of the extremes (all on / all of – now and forever) makes much sense IMHO.

it should be high priority because it tells anonymous editors they aren't allowed to edit and aren't welcomed.
The message should be:
Mobile editing for anonymous users is BROKEN ;( Either log in OR USE THE DESKTOP VERSION TO EDIT THE PAGE

(In reply to comment #5)

it should be high priority because it tells anonymous editors they aren't
allowed to edit and aren't welcomed.
The message should be:
Mobile editing for anonymous users is BROKEN ;( Either log in OR USE THE
DESKTOP VERSION TO EDIT THE PAGE

Yes, I was confused by the message myself a few days ago. That part should not be too hard to fix.

updated here:
http://translatewiki.net/w/i.php?title=MediaWiki:Mobile-frontend-editor-cta/en&diff=4900413&oldid=4795855

this isn't a solution but a workaround. (it is just justification to Low priority, but the bug should be major severity)

(In reply to comment #7)

updated here:
http://translatewiki.net/w/i.php?title=MediaWiki:Mobile-frontend-editor-cta/
en&diff=4900413&oldid=4795855

this isn't a solution but a workaround. (it is just justification to Low
priority, but the bug should be major severity)

You can't edit messages on TWN.
https://translatewiki.net/wiki/FAQ#Improving_the_English_source_message
You can submit a patch, or I will try to.

There seems to be two bugs here.

1. The message
2. A valid enhancement request to enable editing on mobile.

1. The current message says "You must be logged in to edit pages on mobile.". The statement is correct as currently the editor doesn't work on mobile for anonymous users. It doesn't say you need an account to edit Wikipedia it says /mobile/ wikipedia.

If there is a better way to explain this in a single sentence please suggest one.
We also don't say the editor needs JavaScript.. should it say that as well?

2. As stated this is by design. I'd suggest raising this discussion on a Village pump to see if there is demand. We should experiment with anonymous editing on mobile and see what the revert rate is like and if it is useful or not.

(In reply to comment #9)

2. As stated this is by design. I'd suggest raising this discussion on a

Village pump to see if there is demand. We should experiment with anonymous
editing on mobile and see what the revert rate is like and if it is useful or
not.

Again, you're missing the point: this isn't something that the mobile team can simply disable and then try to require users to find consensus to re-enable. Being able to edit without registering is a fundamental, non-negotiable principle.

it is not a topic for discussion in village pump - it isn't specific to any wikipedia or specific project. by default things should work for anonymous as they work for logged in users as MZMcBride pointed out - it violates the principle of free encyplopedia. If specific project wants to disable editing - than it should go through village pump.

(In reply to comment #9)

The statement is correct as currently the editor doesn't work on mobile for
anonymous users.

No. What you're saying here on Bugzilla is nearly malicious.

"The editor doesn't work on mobile"? Is there any reason that anonymous editing "doesn't work" other than $wgMFAnonymousEditing being set to false in MobileFrontend.php?

Saying that anonymous editing doesn't work is _not_ the same as saying that you've intentionally disabled anonymous editing. If there are actual issues with anonymous editing in the MobileFrontend extension, please point to filed bugs in Bugzilla explaining these issues so that they can be addressed.

Otherwise, please immediately stop saying anonymous editing "doesn't work."

Well it is actually not a technical bug but politics bug ;)
Should be assigned to @erik Moeller ;)

It's not quite so simple as a permissions change. Longer explanation below, but the tl;dr is that there's a lot of design and development work that needs to be done before we can just flip the switch.

First and most importantly: editing a wiki "anonymously" means leaving a permanent, searchable trace of your IP address in connection with your edits; this is actually a non-trivial and in many cases highly sensitive piece of metadata. As a bare minimum requirement to ensure the safety and privacy of our users, we would need to build an educational system into the mobile editor that alerted users of their logged out status, made them understand the implications of this (e.g. if they're in a country where their edits could put them in danger, make sure they're aware that they're basically geo-targeting themselves by editing without an account), and let them login/signup before saving their edit. On desktop, we do this with a series of templates and mediawiki messages, but mobile has a very different, radically constrained UI, and solving this problem in a way that doesn't hinder the ability to actually make an edit and gets people to read and understand the disclaimer isn't easy or straightforward. In addition to this bare minimum requirement, there are a host of other social, UX-related, and technical challenges to opening up an anonymous editing funnel on mobile:

1. Mobile devices are quite different from desktop in that it's much easier to fat-finger and accidentally do something you didn't intend to do. A highly motivated IP editor on desktop who accidentally (or as a test) blanks a page might discover the page history and the undo button – that's much harder to do on mobile, where the history view is currently so tiny and cluttered that undo is barely enough of a target to tap on, let alone see. Until we have a nice, clean, mobile-friendly history view and revert actions (something the team is going to be working on sometime this year), you'll get a lot of first-time users messing up or messing around with no way to clean up the mess.

2. On desktop, it's not as huge a break from your workflow to leave what you're editing, log in, and keep editing; on mobile, where everything is so focused and zoomed-in, that feels like a huge break. Unless we made it obvious *why* an account is beneficial, it's doubtful most anon editors would go through the trouble of creating an account to fix a typo -- but that means they're missing out on important features like a watchlist and a notification system (see point 4).

3. The abuse filter is already a huge problem for mobile, since on many wikis it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed users adding links, adding/removing large chunks of text, or, on projects like Portuguese Wikipedia, making edits of any kind), which in turn causes the mobile editor to throw an error. Right now the error rate is hovering at an alarming 48% across all projects; making editing available to anons would guarantee that the error rate would skyrocket. Until we build a replacement for the abusefilter CAPTCHA (again, a tricky engineering problem on mobile), we'd knowingly be showing anons a broken and unusable edit button most of the time.

4. A lot of the features we're building on desktop to keep people in the loop about what's happening to their edits (like email and Echo notifications) are for logged in users only, and those become extra critical communication mechanisms on mobile, where it's harder (and, again, a bigger break from your workflow) to find and check your talk page. I'm not sure how we'd build a notification system for mobile IP editors without unnecessarily spamming a huge swath of mobile readers with notifications about user warnings that don't involve them. This is already a problem on desktop, but it becomes exponentially more problematic with the wildly fluctuating IPs of most mobile devices.

For all these reasons and more, letting IPs edit on mobile is (for now) not a great idea, so I'm closing this as WONTFIX -- however, the mobile dev team will be working on many of the associated issues here, and it's certainly not outside the realm of possibility for anon mobile editing to happen sometime in the future. For now, we can fulfill our ideological obligations to a free and open wiki by showing the edit button and a login/signup CTA everywhere and making it as quick and easy as possible to login or sign up. To reiterate my first point: "anonymous" editing is actually less anonymous than signing up for a free user account that requires no personal information, not even an email; to claim otherwise is simply demagoguery.

Maryana Pinchuk, thanks for your detailed explanations. You convinced me.

The only problem that I see in the current situation is wrong impression from the message that tells anonymous editors "You must be logged in to edit pages on mobile". I think the edit button shouldn't be displayed for anonymous at all if they don't have right to use it (to be consistent with permissions, as in the case of "create" article in enwiki for anonymous), or at least should tell users are welcomed to use desktop version. Maybe you should ask Jorm will have a better idea...

(In reply to comment #9)

2. As stated this is by design. I'd suggest raising this discussion on a

Village pump to see if there is demand. We should experiment with anonymous
editing on mobile and see what the revert rate is like and if it is useful or
not.

My reply to this probably should not have been comment 10, though I was and am annoyed that anonymous editing was disabled. I should have just filed a separate tracking bug, which I've now done at bug 53069.

(In reply to comment #15)

Maryana Pinchuk, thanks for your detailed explanations. You convinced me.

My thanks as well. I've split this explanation out to bug 53069. Parts of it should have tracking bugs. Other parts need discussion. :-)

(In reply to comment #15)

The only problem that I see in the current situation is wrong impression from
the message that tells anonymous editors "You must be logged in to edit pages
on mobile". I think the edit button shouldn't be displayed for anonymous at
all if they don't have right to use it (to be consistent with permissions, as
in the case of "create" article in enwiki for anonymous), or at least should
tell users are welcomed to use desktop version. Maybe you should ask Jorm will
have a better idea...

Yes, I think the wording could use improvement. Jon seems to agree (or is at least willing to consider patches for better language; cf. comment 9) and comment 14 seemed to focus exclusively on the issue that I've now split out to bug 53069 (obstacles to enabling anonymous editing via MobileFrontend).

Re-opening this bug with a better summary for the labeling issue (i.e., tweaking the wording of "You must be logged in to edit pages on mobile" message to be clearer). I think there's general agreement that the current wording could be better, though of course speak up if you disagree and would like to keep the current wording ("You must be logged in to edit pages on mobile"). I think even a simple change such as switching to "You currently" would help. We can't give the impression that we think it's okay to lock out anonymous users. While individual developers and project managers may disagree with this, it's a community matter ([[m:Founding principles]]).

(There's also the question of what the general expectation is with the extension and whether the current default in MobileFrontend.php is correct. Filed as bug 53076 now.)

I've also filed a separate issue for bug 52442 comment 15 (re-examining the user experience when an anonymous user doesn't have permission to edit). This is now bug 53073.

Thanks Maryana for explaining better than me and thanks MZ for splitting this out into multiple bugs and yes MZ I do agree the wording could be better.

I do wonder if the message change should be a separate bug as when combined with the above conversation it is less clear on the purpose of the bug. Thoughts?

(In reply to comment #17)

I do wonder if the message change should be a separate bug as when combined
with the above conversation it is less clear on the purpose of the bug.
Thoughts?

I think that would be fine. I didn't really feel like seeing this bug completely thrown away, so I went for the salvage route. But if you think it'd be clearer to split it out, sure.

Forking to bug 53107 which references this bug so this bug doesn't get confusing and is more clearly actionable for any new readers.

• This bug has been marked as a duplicate of bug 53107 ***