Just came here to report the exact same bug. I just made a VE edit in en.wp and the related articles then came up appearing on top. This was the edit - https://en.wikipedia.org/w/index.php?title=Anu_Singh&type=revision&diff=700491912&oldid=686000746 See attached screenshot for how it appeared on my screen.

In T103082#1904529, @Alsee wrote:

I believe there will be little community support for the proposal described here. It's not useful. We're not looking for structured discussions, and we don't want to go to a Flow board to paste in an article title for deletion. Twinkle lets us nominate an article for deletion while at the article page.

My only position on this issue would be not to "reinvent the wheel'. I prefer if you choose "logged in" rather than "autoconfirmed" as the measurement of whether someone is sufficiently "interested" to warrant showing them more features - because it is the lower bar for entry and is also a feature that is a standard binary option across all wikis (whereas the level at which autoconfirmed is set can be adjusted on a per-wiki basis [I think]).

In T119337#1888695, @JKatzWMF wrote:

@Wittylama sure I had fought this originally, but given the conversation here: T118338, I think that's probably a better proxy for 'interest'.

Curious though--is this because anyone is complaining, because the principle is more sound, or because it's duping logic elsewhere.

As requested over on T116676, I've now added my various comments on the talkpage of the project: https://www.mediawiki.org/wiki/Talk:Reading/Web/Projects/Read_more

I've now added my various comments on that talkpage. Cheers.

As mentioned in: T116676#1877895

My mistake - didn't see that this feature was called "read more", was looking for "related articles" instead. Yes, the beta-features tool is working correctly. This is just user error (though, putting the phrase "related articles" in the beta feature description might help others who are similarly dim.

In T116676#1877903, @Jdlrobson wrote:

Confusingly the feature is listed as "read more" (only one of the extensions that powers it is called related articles). Can you confirm that shows up as I'm unable to replicate.

In T116676#1877887, @Wittylama wrote:

Second example (chosen by clicking 'random article'): https://en.wikipedia.org/wiki/Gabriels,_New_York gives me

• Hamlet

hi @bmansurov. I created T121402 specifically for this issue as I wasn't sure if this phabricator ticket was the correct place to put things. In it, I added some more detail (like that when I tried to see how it displayed for a different user I couldn't get it to load on ANY page.

I am now seeing "related articles" appear at the bottom of english Wikipedia articles.

In T117970#1858545, @Jdlrobson wrote:

We seem to be mixing bugs and this is getting confusing - apologies if I've missed anything.

This no longer seems to be a problem.
I can now create a statement AND add a reference for that statement at the same time.

Fair enough @Quiddity ;-) Cross-wiki notifications/watchlists is very important!

In T117970#1850701, @Jdlrobson wrote:

Note when comparing mobile to desktop it's important to recognise that studies show mobile behaviour is actually very different to desktop so we're always keen to test things out rather than assume just because X is here on desktop it should be in the same place on mobile.
...
Interestingly we moved the bar to the bottom of the page at the start of October and links to user profile dropped drastically but history links increased. Not sure how to interpret that :)

In T117970#1841890, @Wittylama wrote:

The only way that you'll know it's a link is if you click it by accident and, based on the feedback that you've been taken to an article history page, become aware of what you did and consciously learn that those words are secretly links.

In T76573#1851916, @TheDJ wrote:

I'm really happy however that there is time being spent on Flow right now, that can really help along this as well at some point.

There's a related discussion on MediaWiki.org about beta features: https://www.mediawiki.org/wiki/Topic:Ss54yq1w3twctqsj
TheDJ and Jdforrester are suggesting that the Beta Features system would need to be completely rebuilt to be able to scale anyway and that it wouldn't catch the kind of bugs I'm suggesting it ought to.

In T76573#1843206, @Quiddity wrote:

Hmm, that's probably a good idea, but just to devil's advocate... do you think a new newsletter is needed, or is an entry in Tech/News sufficient for the currently infrequent updates/releases/requests-for-feedback?
(Tangetially, I still hope that MediaWiki-extensions-Newsletter can be further developed and eventually deployed. :)

Thank you @CCogdill_WMF!

In T120214#1848456, @Ejegg wrote:

@Wittylama, do you know of any bad emails since then?

Probably pertinent to this discussion is the fact that a user who has opted in to the " Automatically enable all new beta features" mode will not know when a new Beta feature has been added to their interface. Equally, if a feature's behaviour has changed since it was enabled the user might not know either.

In T117970#1840115, @Jdlrobson wrote:

In T117970#1793588, @Fuzheado wrote:

I recall once finding that "feature" by accident (clicking on one's edit-count), but haven't used it more than that because it's so obscure that I never remember how to get there. As you probably know from UX101, I revert to what's familiar and predictable vs hunting for obscure features even if the former is more complex.

I agree this experience is not ideal. If the button was more prominent do you think it would be logical to find?

In T118338#1840066, @Jdlrobson wrote:

Whilst I truly understand the motivation and desire to surface editor tools to edits I worry that this pushes new potential users away. My concern is the left menu is already becoming a dumping ground of links.

With regards to the phrase:

In T118338#1825689, @Tnegrin wrote:

I'd like to think of the two experiences as 80/20 rather than 100% either way.

This is quite relevant: https://medium.com/@ninanjira/taking-free-basics-in-kenya-for-a-spin-87d2a6e9e5a0#.9rhsvxu9e
In a discussion of free apps in Kenya, the author reviews the Wikipedia app and says:

This has the critical advantage of not pissing off the community because the overwhelming majority of readers of the site never leave namespace zero a.k.a. article space a.k.a. mainspace. Here's my 'smoking gun' image again, for what it's worth where the 'popup reminder' is showing over an Italian village pump discussion where a reader is screaming for the banners to stop ("basta!") and says that the text of the banners makes him feel blackmailed ("ricatto").

I think this is a broad discussion, and there's lots of potential elements...

Here's one image that demonstrates the issue nicely. It's showing the yellow "post it note" banner at the bottom of the screen. This was after clicking on a WP link from within the gmail app. I'm most definitely logged-in within Safari, but when clicking the a WP link from within this app (and equally other apps such as Facebook, Twitter, AlienBlue [Reddit]), it apparently does not remember that I've already seen the banners - many times.

Thanks Shani!

Thank you @Moushira for that diplomatic response. This is why WMF needs community liaisons - to help shield the community from 'because I don't like it' responses from developers. That is, nevertheless, the last time I try to get involved in discussions relating to mobile. Clearly the WMF has decided that it is sick of having no influence on design in the desktop environment (and it should have a lot more than it does), and instead has created a community-free-zone in mobile.

Trizek - that's why it's supposed to be only for the first time you use VE. Not every time.

If "knowledge engine" means what I think it means, then this is an attempt to b the all-singing-all-dancing solution to the Internet's problems. Surely the more 'domestic scale' issues like getting our own talkpages into the 21sr century, or Structued Data on Commoms, or even integrating Wikidata into Wikipedia infoboxes, are things that underpin any attempt to build a 'knowledge engine'? If we can't yet crawl, why are we trying to run?

By the way - I added some links today (on Meta) in VE and was shown a popup explaining linking.
However, a few hours later, still logged in, same browser, I received the same popup when I added another link.
So, it's working, but not "user's first use of VE" as this ticket's name suggests.

In T102136#1728045, @Lokal_Profil wrote:

I don't know if @Wittylama manually reverted the undesired changes, alternatively if someone else did.

For the name: Certainly, whatever you think makes the most sense.
Description: "for coordination of the Wikipedia article translation and Wikidata item improvement competitions associated with the Europeana 280 campaign"
[I can add a link to the project homepage when it's built]
How does that sound?

My use-case has been addressed by @Multichill using a bot here: https://www.wikidata.org/wiki/User:Multichill/Zandbak#Label
It's not replicable if you can't make your own bot (or convince someone else to run one for you) but it does show that the query is technically possible to query 'does this Wikidata item exist in <Wikipedia edition>' even if I'm still not sure how it's actually done!

With regards to the triaging that @Amire80 referred to above, I would suggest that, for this specific campaign, I NEED to have the ability to track which target articles exist, in which languages, updatable on a roughly daily basis. We're talking several thousand potential target articles so I can't check that manually.
Equally, because we'll be targeting the creation of articles where there could be several (or none!) potential source languages to translate from, it will NEED to be able to route a 'translate/create this' article via the Wikidata item rather than relying on a specific source language.

This might be dependent on T112769 - "Make it possible to query whether a Wikidata item exists on a particular Wikipedia language edition".

Thank you @Quiddity for adding me here! Since my suggestion on the wiki was auto-archived after several weeks with no response, I assumed the idea had 'sunk like a stone'. So, I'm very glad to see it's not just a valid idea but one that is being actively worked on!

Thanks indeed @Qgil :-) I'm delighted to hear that you're trying to emulate the 'GLAM approach', because we always set ourselves up to build a culture of decentralisation, local contacts, capacity development, every-project-is-different. [Quite the opposite approach to the way the Education program (now Wiki Ed Foundation) set themselves up, which was all about centralisation, formal structure, reporting hierarchy]

In T107625#1546707, @Wittylama wrote:

Just like the WMF doesn't negotiate image-donations for Commons, equally it shouldn't be negotiating metadata-donations for Wikidata. It should support "the community" to do that.

I'm still not sure what this means though....

In T107625#1545228, @Qgil wrote:>

@Wittylama has hinted to a page about Europeana at https://www.wikidata.org/wiki/Wikidata:Wiki_Loves_Open_Data#Organizations_interested

Thanks for creating this @Quiddity!
Perhaps this can be broken down to sub-tasks. For opt-in numbers on Beta-features:

• differentiate between those who chose this specific thing, and those who have opted to have all new features turned on automatically.
• List the 'retention rate' of each feature. That is - what proportion of people who have tested this feature are still using it! This is an excellent quantitative measure of whether it is a net-benefit to users.
• Indicate when the particular feature was made available in Beta-features, and the status of its development (e.g. 2-week turnaround for new feature iterations/no active development...)
• Indicate what target is expected for this feature to either 'graduate' or 'fail' the beta process. NOTHING should be there permanently. By comparison, Vector skin targeted 80% retention. Think of it like the way crowdfunding websites give you a limited time period to raise money - the campaigns don't get to run indefinitely.
• Indicate at the top of the page(?) how many active editors there are in total on the wiki, which gives the user a way to see if the number of users of a particular feature is actually a large number not. [Alternatively, indicate against each feature what proportion of the active editorship the usage number represents].

Thanks @santhosh

At the very least - the geocode information should not obscure the text of the article being translated - e.g.

Here's a video of the behaviour: