Yeah, I just followed the label from the desktop version; as long as it’s just my personal gadget, I know what it means anyway. :D But I doubt that addPortletLink is ultimately the solution here; it means doubling all the links also in the desktop version (have to add it to common.js) and it gives no possibility to do anything about the formatting (as far as I know).

Actually, users can help themselves by simply using mw.util.addPortletLink. If added to the toolbox, the link will also appear in the overflow menu. Without icon, of course, but better than nothing. I will use that for the moment then ...

Have updated it, now both Android and iOS app are affected!

My question was whether there was a known interference of the new vector with position:fixed in table headers, not about a specific case.

I just noticed that apparently the tables with sticky headers I created on dewiki don’t work anymore if I activate the new Vector skin! How can the skin interfere with this effect? Noticed this on Chrome.

Just wanted to add: for dewiki (where navboxes have always been visible on mobile, but we certainly use them less frequently than enwiki does) I have created a responsive mobile version: examples. Should be live soon. Obviously this is just about the design, the problem of the heavy HTML remains.

Oh, I see! So it is not related to the TemplateStyles problem? In that case I can obviously work on fixing the infobox template (although it would be nice if the algorithm could cope with such cases, as the use of hidden links as an alternative to tracking categories is quite common in infoboxes on dewiki).

Has been noticed on dewiki as well. As we have deactivated the mobile "Welcome, USERNAME!", the "– Wikipedia" is displayed also for registered users. It seems like this happened only after last Thursday's update. Before then the title read "Wikipedia – Die freie Enzyklopädie". Please fix it, as it looks quite unprofessional!

As to limitations via class: there is always nomobile that can be used imo.

When I first experimented with “global modules”, I used separate data tables on Commons for the template parameters (https://commons.m.wikimedia.org/wiki/Data:Module:Music_charts/parameters.tab) and the text output (https://commons.m.wikimedia.org/wiki/Data:Module:Music_charts/labels.tab), among others; these were called by the central module, which eventually outputs the template code. This method would actually work fine for my needs, but the performance is terrible, so I never implemented it outside of testwiki …

Another friendly reminder: I'm still drowning in WP Library emails every day. Please do something about it!

Today I found the class mw-sticky-header being automatically applied to some tables on enwiki. As far as I can see, it only works in Safari and only on desktop. Does somebody know more about this?

In T254287#6298486, @hgzh wrote:

dewiki has made the change today. I think we found a clean and sustainable solution.

In T256297#6292174, @Majavah wrote:

Is it sent via MediaWiki's "email this user" or in some other way? If it is, which account are they coming from? I can block that account from sending e-mail

The new dewiki main page is now live (https://de.m.wikipedia.org/wiki/Wikipedia:Hauptseite). If I’m not mistaken, there is still a larger margin on top, shouldn’t it be gone by now?

I'm still drowning in WP Library emails every day! I have now deactivated wikimail there, I hope that at least will stop them, but could someone please fix this? I doesn't help the cause if it is spammed like this.

Well, some output did not work two days ago, but it does now. Caching problems, I guess, different users are reporting different errors (and the error category is also just shown in some cases). I will keep the warning then as long as this task is open.

Has this been fixed? It looks like the errors are gone now and Score is working again.

Yep, however it looks like the message needs to be blanked for every language separately! Is that what is expected? Right now we have done it for de, en and it, but we cannot do that for any language a user might have set in their preferences.

Since I posted this, I got three more emails, one in German (as usual) and two in English; probably because I visited (no edit!) some other projects from the Beta cluster.

Ah, I forgot to mention: I have never seen an echo notification about this.

Right now, T231160 would probably cause some trouble if we were to call such a class nomobile-narrow. But I hope that will be fixed in the near future...

@PerfektesChaos: FYI. Thanks for the quick solution, the new main page is coming soon, so this will definitely be taken into consideration for the mobile layout!

Gonna try it on Beta, thanks! I guess it could also be formatted differently this way?

Hm, the thing is: the main reason why people use the NWE (in my experience) is exactly the functionality that is broken now. So switching back to the old editor does not solve anything in this regard (while switching to VE does, oddly enough). Right now I have to start off with VE, insert templates and references, then switch to NWE and copypaste everything in place. Very unfortunate, but I get that the number of users affected is indeed pretty low.

So, that basically means that we won't be able to edit properly until next week?

Have you checked out Flagged Revisions yet?

I have now opened T254518 for the remaining issue. Good, I guess this task is resolved then, kudos to everyone involved, it's very appreciated!

Fair enough, it should be a relatively rare use case anyway. But the cursor losing focus when clicking the editnotice seems like a general bug to me; if fixing that problem made charinsert work in NWE as well (I have no idea about whether the two things are related at all, just as an idea), great, otherwise there is little need to work on this any further, I agree.

Has this been fixed all of a sudden? Today for the first time templates with TemplateStyles did not look broken anymore when checking the preview. Great!

This is basically the same as T241933.

I have added an example (but it's obviously a general problem, since the overlays container simply does not contain the mw-parser-output class)

Oh, I see, that works, yeah! If that is the preferred solution, I guess it won't be necessary to keep this task open. Thanks for the explanation!

Ah, that would make sense, yes! But as long as edit notices may contain templates, TemplateStyles must be applied there as well.

This came up these days during talks with German public broadcast. There is definitely the expectation from users to be able to jump between videos, especially if they are collected inside a gallery. Having an empty screen after finishing watching one video in the current player is also pretty dissuasive. Even though I myself hardly ever use the MediaViewer, I would expect this to be a very positive development for readers.

Was the change related to T237246?

Well, calling something a template when it’s not does look wrong to me. Plus, if it can’t be edited, giving users an edit dialogue is very misleading as well. Sure, there are several templates without parameters; but at least with page transclusions from other namespaces that should be obvious enough to be treated differently by the VE. I would expect a dialogue that just says something like “This content is generated by ‘page name’. You can edit it directly on that page.” (with proper linking, obviously). Or leave it as it is and let the “edit” button directly open the other page in a new tab? Something like that, I would think. Page transclusions can never have a “description”, so that note is also very misleading. Since this way of transcluding pages in discographies is standard on deWP, it’s not a small issue; and as far as I know, there are many lists and disambiguations that are composed of transcluded parts as well.

Hm, fair enough. Sounds a bit English-centered, but I get that the number of potentially supported/affected languages is a fact that should not be overlooked. I am indeed using Schnark’s tool and it works fine overall (except for single quotation marks, but even MS Word still can’t deal with those, so I guess there is no proper solution), also for other languages than German. As always with such tools, I just do believe that they would be most useful for new editors, and like this there is a only a small chance that they would find out about and start using it by themselves. That leaves us once again with lots of unnecessary corrections all over the articles. Furthermore, with every year that passes, the chance that some wikis might want to start “enforcing” proper typography is diminishing; I had a long discussion on itWP years ago about the issue and it was clear that without a generally available autocorrect function nobody would be willing to change the typography rules. I guess with autocorrect available from the beginning, even the (to say the least: debatable) MoS rule on enWP would not exist in this form.

We have several user scripts that do exactly what is requested here. Maybe take some ideas from them? The feature should be available for everyone and would prevent a lot of unnecessary typographical corrections.

Anything happening here? Lately I find myself always switching editors whenever I have to work with templates. That slows down the workflow quite a bit.

Update: I still haven't found the JS that fixes the problem on the mobile version; but I just noticed that the WP iOS app apparently does not follow the example, there the tooltips are still sticky. I would expect at least the iOS app to be specially designed for dealing with such known iOS bugs. Very confusing, but it shouldn't be impossible to fix this for all versions and devices.

Problem still there. Very annoying on large pages. Anything happening?

Alright then. Would be lovely if there was a FlaggedRevs maintainer, otherwise I see various similar problems arising with future layout changes. I will ask for a local solution on German WP now; in the meantime I got rid of the box via my common.css for mobile screens only, so I can continue to use the watchlist without seeing the same old warning every time.

If I understood @Zache correctly though, it's the same for Finnish (thus not German WP exclusive)?! Anyway, it looks like the current design has been discussed extensively, but obviously without mobile-specific considerations.

Stumbled across this problem when I tried to load localised data from a Data Table on Commons and in the console I never got the data I expected to get. I agree that the current state is not at all user-friendly.

Oh, I see, looks like the box is limited to non-English messages. With English as my user language I also just see the one-line note. Not sure why, where is the localised version of the message stored?

In T237246#5738156, @Jdlrobson wrote:

I'm seeing this now, but it's not hideable, so I'm guessing this is a gadget that's not been made compatible on mobile.. is that possible cc @XanonymusX,?

Ideally, the bar should be formatted similarly to the "active filters" one; right now it even causes some overflow in the desktop version (when there are other banners on top).

Well, you won't be able to reproduce it unless you actually have pending flagged revisions on your watchlist. You can try watching https://de.wikipedia.org/wiki/Parlamentswahl_in_Norwegen_2017 , as an example.

Well, the iPod touch is supposed to be 1136*640 px (per https://www.apple.com/lae/ipod-touch/specs/ ); as I said, it is indeed the smallest screen size available to me, and I usually test everything on it.

Yeah, in my case there were some very long web links in summaries. But even if I get rid of those, the initial buttons are still way too large (at least in German) for the screen size. I’m using iOS and testing it now on the smallest screen possible (I guess), on the iPod touch.

After this change, my watchlist is more than double the width of my screen! Apparently neither the size of the buttons nor the length of edit summaries can fit the screen size. Should I open a new task for that? It needs to be fixed asap, the watchlist is barely usable like this.

Alright, I have now added a warning to the German WP project pages. In my case I have simply renamed the class in hidemobile for the moment.

This is incredibly annoying; even Wikipedians most critical about VE have always admitted that it is a good way to work with tables. Now not even that works anymore, it's so frustrating! At the moment apparently I have no way to copy and paste table columns.

So I created this testing environment, using only the tooltip-related styles: http://danu-talis.bplaced.net/tooltip-test.html (first with the styles I use on testwiki, then with the ones I use on German WP). You are right, it behaves exactly like it does in MediaWiki environment. Btw, I also found out that when using Firefox on iOS, the sticky tooltips problem is resolved, but the caption still jumps.

In T212610#4845272, @matmarex wrote:

I don't know, but I would guess that these sites have implemented something that makes it work, either intentionally or accidentally. Maybe they have a global click event handler for some reason, making everything "clickable", or maybe they override something about scrolling that accidentally changes what tapping does.

If you want to prove it's a MediaWiki problem, please create a small stand-alone .html file that implements the same feature and does not have the problems.

Thanks for looking into it! Well, if it is a general iOS problem, why doesn’t it happen on the external website and why only in WP desktop version and not in mobile version? Otherwise I wouldn’t have asked it here. And the caption jumping is definitely not a Safari bug, since it also happens in Chrome; furthermore, I would expect to find trace of such a bug on some other support/discussion site if it were a general one (probably captions are not that often used, but still). So I’m not convinced that there is nothing to do on the side of MediaWiki.

On iOS usually with Safari, but I also tried Chrome (same behaviour).

Well, as described above, the exact same HTML/CSS apparently works fine on the external website I have linked, the problems are only visible in MediaWiki (I have tested German WP and Testwiki). I can also try it on my personal website, if further testing is required, but the different behaviour on the website that presents the code explicitly as a generally applicable demo seems proof enough to me.