bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1297

This is currently by design. Red links are currently disabled on mobile until there is a better article creation workflow.

Note, you can currently view red links in the alpha mode of the site.

(In reply to comment #2)

This is currently by design. Red links are currently disabled on mobile until
there is a better article creation workflow.

Note, you can currently view red links in the alpha mode of the site.

No. This bug is not about red link not being displayed as links, but about other formatting (subscript ) getting lost in red links.

https://zh.m.wikipedia.org/wiki/User:Liangent/sub

Actual:

<div><ul><li><a href="/wiki/">blue _link</a></li>
<li><span class="new" title="Special:Nonexistentpage（页面不存在）">red link</span></li>
</ul></div>

Expected:

<div><ul><li><a href="/wiki/">blue _link</a></li>
<li><span class="new" title="Special:Nonexistentpage（页面不存在）">red _link</span></li>
</ul></div>

Yes I understand. The code that scrubs red links is very crude and does not take into account child nodes. If said hacky code is removed this bug will go away :)

(To elaborate - I think we shouldn't waste time on trying to fix a hacky piece of code and instead remove the need for it all together)

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1424

Now that enwiki has drafts on a new page we could simply make the edit button load the editor for the draft version of the page and in the content link to the draft / show some indication of draft status.

What think you Jared? What would this look like?

I think we don't have drafts quite yet. we want to reevaluate what happens to red links sitewide when a draft exists. I'd prefer to hold off changes till then, adding steven and Pau.

• Bug 54241 has been marked as a duplicate of this bug. ***

• Bug 60228 has been marked as a duplicate of this bug. ***

I've updated the bug summary to hopefully be more accurate.

swalling wrote:

(In reply to comment #11)

I've updated the bug summary to hopefully be more accurate.

I've updated the bug summary to remove your crude and intentional use of unnecessary adjectives.

The solution we want is to enable red links in MobileFrontEnd. Making that the bug summary makes sense.

(In reply to comment #12)

(In reply to comment #11)

I've updated the bug summary to hopefully be more accurate.

I've updated the bug summary to remove your crude and intentional use of
unnecessary adjectives.

I guess you didn't like the word "crude", except Jon was the one who first used that in comment 4...

The solution we want is to enable red links in MobileFrontEnd. Making that
the
bug summary makes sense.

No, that's not what this bug is about. Did you view the test cases in comment 0? This bug is about <sub> and child nodes being stripped.

I dont really care what the bug name is to be honest. To fix all the issues related to this whether it be for recent changes or sup links the real way to fix it is to enable red links and stop the hacky formatter stuff that has been there since before editing. Whether you want to create a new bug or not I dont really care but what there should only be one bug for this and arguing about it to be honest is counterproductive for all involved. What would be really useful is if someone would help write a plan for enabling them in such a way that we dont end up with new pages that instantly get deleted and gives users bad first experiences and that doesnt generate spam. Any help with that is much appreciated.

(In reply to comment #5)

(To elaborate - I think we shouldn't waste time on trying to fix a hacky
piece of code and instead remove the need for it all together)

Yes, I agree.

Reading through the comments on this bug report, I believe there's general consensus to kill this red link-related code.

Let's simply remove the red link-related code and we'll deal with the fallout (e.g., additional anonymous page creations, if any) as necessary and appropriate. We have lots and lots of options for dealing with any harmful effects of there being red links in MobileFrontend, in my opinion. We've survived much longer with red links in the desktop (non-MobileFrontend) user interface.

I'm marking this bug with the "easy" keyword accordingly. This usually gets attention to the bug much faster, which is what I think everyone is looking for here.

Since new page creation is enabled in (just no red links) it would be a good idea to check if any pages have been created via mobile so far and if so run some checks to see if they were any good / did they get reverted. We have data so it would be good to get a feel for what will happen when we make this more widely available. Also currently new page creation templates are nasty on mobile... someone will have to perfect this before enabling red links - this task is not simply a case of flicking a switch.

There is also an opportunity here to build for the future... I wonder if redirecting new page edits to drafts or making it easy to turn them into drafts might be a clever idea... writing on a mobile phone is a pain (I'm doing so now so can testify that) and may be better suited for draft creation e.g. jotting down shorthand notes

(In reply to comment #15)

Let's simply remove the red link-related code and we'll deal with the fallout
(e.g., additional anonymous page creations, if any) as necessary and
appropriate.

"We" being the Wikipedia editors? Are they aware about this possibility? I think it would be good to contact the big communities (tech-ambassadors?) and get them involved just in case. For reference, the Commons community wasn't happy at all about mobile uploads being "simply enabled", and image uploading on desktop was a feature existing in desktop just like page creation.

While uploading good pictures from you mobile device is perfectly possible, creating good articles from scratch from your mobile device is objectively a complex task. I personally agree that a plan a bit more elaborated needs to be in place: templates looking good on mobile, new articles assigned to a specific category automatically? in a specific namespace other than Main?

While not extremely complex, all this doesn't sound to me "EASY" as to recommend newcomers to pick this task. I would remove the tag.

(In reply to comment #16)

I wonder if
redirecting new page edits to drafts or making it easy to turn them into
drafts
might be a clever idea... writing on a mobile phone is a pain (I'm doing so
now
so can testify that) and may be better suited for draft creation e.g. jotting
down shorthand notes

Sounds like a good idea, as long as the wiki has a Drafts namespace or equivalent. I guess this means that MobileFrontend should have a parameter to define the namespace where new mobile articles are created, defaulting to Main.

"We" being the Wikipedia editors? Are they aware about this possibility? I
think it would be good to contact the big communities (tech-ambassadors?) and
get them involved just in case. For reference, the Commons community wasn't
happy at all about mobile uploads being "simply enabled", and image uploading
on desktop was a feature existing in desktop just like page creation.

I respectfully suggest that the backlash to mobile upload was due to poor design decisions (ie encouraging new users to go against community norms) rather than a desktop feature suddenly being enabled on mobile. I dont think redlinks suffers from this, so i dont think this will suffer the same fate. That said more communication is always better.

(In reply to comment #17)

"We" being the Wikipedia editors? Are they aware about this possibility? I
think it would be good to contact the big communities (tech-ambassadors?) and
get them involved just in case. For reference, the Commons community wasn't
happy at all about mobile uploads being "simply enabled", and image uploading
on desktop was a feature existing in desktop just like page creation.

There's some light discussion of the Commons mobile upload fiasco at [[mw:Talk:Mobile wikitext editing]]. I don't believe it's an analogous situation.

While not extremely complex, all this doesn't sound to me "EASY" as to
recommend newcomers to pick this task. I would remove the tag.

I think you're needlessly overcomplicating the matter. The technical changes required to resolve this bug are trivial, I believe. If this notion is mistaken, please feel free to remove the "easy" keyword from this bug report.

Sounds like a good idea, as long as the wiki has a Drafts namespace or
equivalent. I guess this means that MobileFrontend should have a parameter to
define the namespace where new mobile articles are created, defaulting to
Main.

I'm not sure this is necessary. I think we should match desktop behavior.

Is the desktop behaviour correct? I'm not so sure... otherwise why create drafts?

What's the rush? If someone clicks a red link and then tries to create an article on mobile and has a bad experience will that user ever try creating one again?

An experienced user can start their own page on mobile simply by navigating to the appropriate URL e.g. https://en.m.wikipedia.org/wiki/I_am_a_brand_new_page_that_doesn%27t_exist

I really would challenge us to think outside the box here. First experiences are sooooo important yet we seem to forget this in this piece of software.

I really would challenge us to think outside the box here. First experiences
are sooooo important yet we seem to forget this in this piece of software.

Having text like "click here to do X" where click here is not a link because it would be a red link, is a great first impression. (Yes i've actually encountered things like that when browsering mobile site)

"click here to do X" is so 1990s web. We should be moving away from that too. Link labels should be more meaningful dont you think?

(In reply to comment #20)

What's the rush? If someone clicks a red link and then tries to create an
article on mobile and has a bad experience will that user ever try creating
one again?

If there's any rush, it's to restore behavior that's existed since the dawn of Wikipedia. :-) Red links are a pretty crucial part of the site interface.

The user experience that you've implemented in MobileFrontend doesn't allow the user to create a draft article at all. Red links are munged into black text. If you want to discuss first impressions, let's discuss implementing a mobile site that pretends as though user registration is a hard requirement and that creates the illusion that incompleteness (i.e., red links) are a scourge?

I really would challenge us to think outside the box here. First experiences
are sooooo important yet we seem to forget this in this piece of software.

This isn't about thinking outside of the box, in my opinion. It's about having sensible behavior on mobile. I'm pretty sure everyone here agrees that the red link stripping is bad ("very crude") and anti-wiki. So... why not kill it?

(In reply to comment #22)

"click here to do X" is so 1990s web. We should be moving away from that too.
Link labels should be more meaningful dont you think?

Oh i certainly dont disagree. However that doesnt change the fact that such constructions exist, and having text that should be a link not be a link is very very confusing.

swalling wrote:

(In reply to comment #23)

If there's any rush, it's to restore behavior that's existed since the dawn
of
Wikipedia. :-) Red links are a pretty crucial part of the site interface.

The user experience that you've implemented in MobileFrontend doesn't allow
the
user to create a draft article at all. Red links are munged into black text.
If
you want to discuss first impressions, let's discuss implementing a mobile
site
that pretends as though user registration is a hard requirement and that
creates the illusion that incompleteness (i.e., red links) are a scourge?

Lack of anonymous editing and red links is _temporary thing_ not a permanent design choice. You're right that it sucks that we don't have redlinks, because it does make an impression on readers that we're not the encyclopedia anyone can edit.

We are most definitely going to add anonymous editing and article creation workflows to mobile. The question is not "Should we?", it's "When and how?" We don't have a choice, considering how much of our registrations and traffic is being driven by mobile. It's more and more all the time.

However, Jon is the voice of reason here when he says that we need to figure out a good experience for mobile. Just enabling red links and calling it a day is not good enough. Please trust me when I say that everyone here wants mobile to have red links as much as you do. Let's help the mobile team figure how to do it right, not bicker about timelines.

I say we should move this discussion to mediawiki.org, and start proposing/discussing specifications to implement. Having design discussions on Bugzilla about the interface copy and workflows really stinks. Perhaps on a subpage of https://www.mediawiki.org/wiki/Mobile_wikitext_editing ?

This is another report where a MediaWiki functionality (in this case MobileFrontend functionality) is conditioned by a Wikimedia-specific situation. Quick reverts for page creation and the Drafts namespace are factors that most MobileFrontend users don't need to consider.

Is it worth detaching both use cases (Wikimedia, rest of MediaWiki)? If a configuration would exist in MobileFrontend allowing sysadmins to enable/disable red links, then each site would be able to choose their preferred setup at any point. Wikis welcoming any input (the big majority) would be happy with this, while sites with special needs like en.wiki could still work on additional steps if needed.

Such configuration is probably a good idea anyway, since it might be that mobile page creation doesn't make much sense for some sites. It might be also useful to deploy this feature with a quick way to step back if some kind of problem arises.

I think you mean [en] wikipedia. Most of wikimedia does not use drafts.

(In reply to comment #27)

I think you mean [en] wikipedia. Most of wikimedia does not use drafts.

I know, but more Wikimedia wikis share the circumstance of high rates of new pages being deleted, causing frustration among newcomers. This is the main argument for being careful when enabling red links, but this is not a concern in most non-Wikimedia MediaWikis (and probably not even in many Wikimedia sites).

A patch that adds a global to enable red links and defaults it to true would be much appreciated for the 3rd party use case. Wikimedia wiki's can override this to false while we explore this more at Steven suggests.

To give background they were originally disabled because of the fact there was no editor in mobile so this code has been around since day 1. Although crude and hacky it has got the job done.

I would personally love to see red links dong get me wrong but I echo the thoughts of the wise Dr Ian Malcolm
http://sustainableman.org/wp-content/uploads/2013/07/DrIanMalcom.jpg

FYI once a Wikimedia wiki or any wiki with caching enables such a setting there is no going back. The red links will stay until the cache clears.

I don't understand why this bug includes a huge discussion on whether or not we should turn on red links in stable. We have an established workflow for experimental features on mobile:

1. Design the experiment, hopefully including criteria for success/failure.
2. Implement the experiment on alpha and see if it has any significant technical problems.
3. If there are no technical issues, promote the feature to beta and let it run for long enough to get some useful data.
4. Evaluate the results and decide whether the experiment was successful or not.
5. If the experiment was successful, turn it on in stable.

Where are we at right now? Do we have any useful results yet?

Please do not use Bugzilla as a debate forum. That's what we have wikis for.

Redirect to: https://m.mediawiki.org/wiki/Mobile_Web/New_page_creation

(In reply to comment #31)

Where are we at right now?

I have my mobile browser in Experimental mode, and this morning I saw a red link for the first time ever. I clicked, and the mobile editor opened with a blank page.

So at least we are there.

The bug originally reported should actually be fixed.
Enabling red links is on the current timeline so marking as assigned (to mobile team)

The original issue with sup elements is fixed. The conversation and title are a little confusing, hence why this was closed.

Tracking bug would be more useful (I think one already exists but I can't find it)

I've reopened because the problem still persist. The most evident proof is the comparison of the links in the firt post. But I've noticed this morning also in https://it.wikivoyage.org/wiki/Speciale:UltimeModifiche and I notice it each time a new user register on the site.

the problem still persist

Yeah, because the main function to remove redlinks from mobile sites still exists :) Maybe we can rethink this?

I hope that it would be rethink. In my opinion all the red links should be shown by default. In case, through a specific gadget, who doesn't won't to deal with red link would be able to transform them into plain text. That's how it should work in my opinion.

I'm going to close this, since the conversation is a bit hard to follow and the original problem raised by Liagent is fixed and I can't find a tracking bug (so what I said in #c35 is not true)

See bug 66534 which hopefully tells a clearer story.