Thanks for recording this, we will think about the best way to implement this

Could you please prioritize work on this? As I wrote, amboxes have a critical role, impacting all users, not just editors. See also WP:THEYCANTHEARYOU.

Hello, I agree with the above comment of Tacsipacsi. Some of these boxes like Template:POV are very important for the user to be aware if an article respects the fundamental principle of Wikipedia WP:5P2 or not. Some of these boxes even can only be deleted with the consensus by voting from contributors. So this ticket should be at high priority.

Just want to acknowledge we are looking into the best implementation of this

Where is the link supposed to appear? I tested it on https://hu.wikipedia.org/wiki/MMS because https://en.wikipedia.org/wiki/Polar_bear doesn’t have any amboxes, but I couldn’t find the link even though I was specifically looking for it – which is far from being good, as the goal is that readers become aware of the amboxes without specifically looking for them. The app says it’s version 2.7.50443-alpha-2023-05-19, and my phone is set to Hungarian (which shouldn’t matter, but who knows).

@Dbrant could you post a screenshot here? The apk is expired and a screenshot enough for me to review.

This basically enables the Content Service to expose the "page issues" menu item for us, which is seen at the bottom of the article:

When tapped, we display the page issues in a popup dialog, similar to edit notices:

apk: https://github.com/wikimedia/apps-android-wikipedia/actions/runs/5212008678

So this is why I haven’t found it! All other platforms I know expose page issues at the top of the page. Since the main purpose of amboxes is to communicate information to users who don’t specifically look for it before they start reading the article (so that while reading the article, they already know how much they can trust it), hiding it at the bottom of the page fails to serve its purpose.

Hey @Tacsipacsi ! I'm the Product Manager for the apps that prioritized this task. I agreed it was important to use what Content Service provided us to show page issues (amboxes). When it came to placement, feature availability was prioritized over discovery (something that would require significant design thinking because it requires a holistic look at the architecture and user flow of the app). I drew inspiration from the iOS app where page issues already existed in the about this article section and had the engineers place it there since the iOS architecture is closer to that of Android.

This coming Fiscal Year (which starts in July), I am prioritizing a holistic review of our app's architecture to address the discovery challenges that exist. When the app was created it was intended to only support reading and serve as a limited feature reading app. This was a decision that has predated me. The Product Manager immediately before me started adding editing features such as suggested edits. When I left the Web teams (Growth, Editing and Web) and joined apps we started adding features that Wikipedians are accustomed to like Watchlist, Edit Notices and Article Talk pages. A lesson that I learned quickly was the importance of balancing what cross platform users expect with what long time app users expect. For example, when making notifications more prominent at all times for all people as requested by cross platform users we did not think about the architecture holistically, and a (few) reader(s) understandably pointed out that they will never edit and find the bell icon a distraction from their most used feature, tabs, something that doesn't exist on Web. For that reason we've tried to prioritize more customization of the experience by allowing people to place things like talk pages and edit history in their toolbar especially if editing features are more important to them than say the Share function. Majority of apps users engage with customizing their experience.

I say all of this to say, I can not in good faith simply place page issues in the exact same place it is on Web, especially because the format differs wiki to wiki and page issue to page issue. I've learned showing a condensed version and then linking it to another screen to be accommodate variation as well as users with small screens isn't a preferred solution by cross platform users based on the reaction of our implementation of talk page banners. Getting the architecture right is a top priority and something we are planning to do during this fiscal year. However, it is something that requires time and testing across multiple audiences. I am copying @ARamadan-WMF so she can ensure you are engaged in those conversations for this coming fiscal year, particularly for Android.

Hey @Tacsipacsi ,
I will follow up with you when we start working on this part during the next fiscal year, till then, you can be updated on our Wikipedia App newsletter from here.

Appears to be fixed on 2.7.50448-r-2023-07-18