WMF has enough resources to put enough effort behind this, for things to be resolved. The last comments and this issue in general didn't get much of a response. Third, from the last few comments, it seems a current issue is with loading the data from OWID and I proposed two technical methods this could be solved. Could you please name the remaining issues here? To me it's unclear why exactly this hasn't been implemented by now / where the process is at right now.

This would be extremely useful and save a lot of time of many editors while keeping things more up-to-date and adding support to the interactive features that WP currently misses compared to OWID and which can be very useful.
Can't believe this is already possible to some degree and this issue hasn't gotten further in 2 years. Please add it asap and a small prompt asking the user to confirm to load data from OWID would be enough. Logged in users and app-users could have a setting "show charts embedded from OWID" or similar so they only need to confirm it once.
I think it may also be possible to mirror the interactive charts altogether and then embed the charts from there so that such prompts are not needed. Isn't that possible since the data is CCBY/CC0 and the tool OWID uses open source? Issues that are close to readily implementable that would bring this much of noticeable improvement to Wikipedia really are rare.

There could also be a widget to simply directly open the app's Places feature so one can quickly open it. A problem with the current implementation is that you need to return to the Home screen from any open Wikipedia articles. That not only makes it inconvenient to open the map and be a problem to some users due to privacy. Even better would be if one could configure which filters (see [[T360197]]) are applied when opening the Places via this widget.

@Jdlrobson This is not the same as the other issue. Maybe there are some similarities but this very different.

Ups I added the wrong tag, thanks for correcting it. (Yes I meant the Android app; there is a Nearby map on web though, specifically the mobile view but it's not what I meant and seems deprecated now that this is featured properly in the app.)

The issue has been transferred to here: https://github.com/commons-app/apps-android-commons/issues/5624

The issue has been transferred to here: https://github.com/commons-app/apps-android-commons/issues/5623

The issue has been transferred to here: https://github.com/commons-app/apps-android-commons/issues/5622

The issue has been transferred to here: https://github.com/commons-app/apps-android-commons/issues/5621

Okay, I'll move it there along with the two other issues I just created. Would be nice if these two issue trackers and related repos were in sync.

Is this a duplicate of T358342 or related to it?

No, it's not a derivative work. You just don't get how prompts are being used. Naming some examples in the prompt can be helpful if the tool doesn't get the concept otherwise and the image didn't look like the term in the prompt at all. Ignorance is not strength.

I didn't say anything about that. Re your second sentence I explained why in rough terms. Here is one concrete example but there are also many other cases where people would probably assume the text in the prompt exactly matches what the prompter meant to illustrate/visualize; for example because my explanations in that DR have not even been understood.

We're not at all getting flooded by them. We're getting flooded with low-quality photographs of mundane things which we already have a thousand times over, not a handful of low-sized AI images that are usually among the first in their respective categories. An issue with requiring prompts is that people who have little experience with and apparently bias against AI images will delete (nominate or vote) them based on their flawed understanding of how these tools work in more sophisticated processes. And they're not necessarily easy to use if you a) have something specific in mind and b) that specific thing is not as simple as "a cat on a table". I'd be all for extensively encouraging prompts but that just leads to it getting nominated because it happens to have some objected or misunderstood term in it.

Having only one line for authors is also a problem when images from studies are uploaded where usually a relatively long list of study authors should be put there. Ultimately what would be more useful is a study images uploader tool where you just enter an URL (e.g. a nature.com study url or a DOI) and it checks if it's licensed adequately and if so prefills all the fields like the data and authors fields so you only need to edit file-titles and -descriptions etc.

@Pols12 Yes exactly, what I referred to is how to make the context menu show up on mobile where one can then copy the link. On Github readme this is also on mobile, if you test this. Maybe one can make the section link get copied automatically when one press-holds the section header on mobile but I meant showing the context menu of the section link.
Note that all of this should also be possible in the mobile app, not just in mobile Web browsers.

Press-and-hold tapping as described in step 3; edited.
A § appearing next to the section header that you can press and hold to copy the link (preferably on the left). This is implemented (since quite a few years) for readmes (markup language) on GitHub.

This is important and would be very useful. Could you please add this asap?

@ppelberg Seems like you're right:

While this would be most useful for tables, it could also be useful for lists (bullet-points). It would display the tag with some specified color and be interactive so that you can for example hide all list-items with one tag or only show list-items with specified tags. The filter-functionality interface could display when one clicks on one tag.

This refers to talk page posts on Wikipedia. For example it happened here.

I could log in again after checking "Keep me logged in". However, it should also work without checking that box and I think that box was previously checked (so I used to log in with that) but wasn't anymore.

The problem still exists with 102.3.0esr. The TOC is not readable, this should be fixed asap, albeit I don't know how many users are affected.

It is the latest in Debian, 91.13.0esr

Don't have that. But here's how it looks like when I change the Firefox preferences to Font size 16 where it used to be size 24:

(here's mine)

So the issue seems to occur only with a certain font-size (if it's supposed to look like in my screenshot). I thought the font-size 24 was the default but maybe it isn't or it's only the default for some configuration. Whether or not it's the default doesn't matter much as it should work with all reasonable font-size configs.

In T310893#8198740, @Jdlrobson wrote:

I can't replicate the issues with line heights in Firefox ESR 102.2.0.esr. What I see replicates the screenshot that Alex shared.

In T310893#8197991, @Aklapper wrote:

@Prototyperspective: Regarding F35496804, does the tense text also show on https://en.wikipedia.org/wiki/Restoration_ecology?safemode=1&useskin=vector-2022 ?

Maybe the 3rd screenshot that I just added makes it clearer just how incredibly bad it is. Now that the issue with it overflowing into the article text is fixed, this bug really should get fixed as well.

I don't remember changing the font-size and until recently this wasn't a problem. Moreover, in these settings I have "Allow pages to choose their own fonts, instead of your selections above" checked.

It happens with all widths and zoom levels that I tried with (earlier Firefox than 102) and also when I add ?safemode=1 to the url. Restarting the browser didn't help. I never had this problem until 22 July and it's very annoying as it hides parts of all articles. What did you change on 21/22 July?

No, wouldn't know which page would be more relevant than a VillagePump discussion, but after all it's in English Wikipedia's code so thought it would best go here. Also I'm not that worried about this issue, it simply should get fixed asap but it isn't particularly important or annoying to me personally. I wondered why nobody solved this yet and searched for discussions about it but found none.

In T310893#8013763, @Max.loh0424 wrote:

Providing an option to auto expand TOC (like the one in the tested version) would fix T307867 too.

In T310956#8013540, @Aklapper wrote:

Note that the image F35252843 in this ticket is restricted to the task author and cannot be seen by anyone else. Which piece of software is this about?

Filtering for "Automated contributions" (either "Bot" or "Human (not bot)" is already possible on Special:Watchlist.

I don't consider what I proposed simple, I only consider showing links to the categories at the bottom of the page relatively simple. These are plain HTML links and can be retrieved with the API afaik,

This has been authored in 2014 and has still not been implemented in 2022 even though it would be simple to show this information at least in a simple way. I'd just like to add that one could implement this by adding a category trees browser instead of a plain list of wikilinked categories.

Done. Also: this Wishlist proposal seems relevant to the issue and vice versa: Grouping watched pages.

Fair point and that's why I only raised this in a comment at that task. Most likely, it depends on some substantial core changes implemented first. But still this could become a Global Watchlist -only or -first feature instead of getting built into the current main Watchlist.

Yes, that's true – I should have made it clearer that it would be implemented so that it only loads these after pressing the button to show the watchlist (maybe it could preload and only show the first few items for each watchlist) ie per AJAX.

This could be built into the global watchlist (currently here).