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.

Is anything happening here? I have made a lot of unnecessary template edits already because of the lack of a preview function. If it is not introduced, I guess template pages should either use the CodeEditor or the old wikitext mode per default , otherwise template editing will never properly work.

Ah, I see. My earlier suggestion for a fix was indeed to leave the first line with the {| inside the template and create only the following parts through Lua. But apparently the <div>\n{| solves the problem! Thus I suppose that infoboxes should always be wrapped in a div to avoid such a behaviour.

I will look into this. But if it is not a Lua problem, what other change to the template could have been relevant for changing the behaviour? If you compare this article with the original template and the corresponding German article with the new Lua template, the difference is visible.

Yes, the problem is gone! :) Thanks to whoever solved it!

Oh no, seems like I overlooked something last night. :| The bug is still here, just reproduced it again. However I'd be glad if someone else could reproduce as well, otherwise I get the feeling I'm doing something wrong here, and I have no idea what that could be ...

Okay, it seems to be resolved, I can't reproduce it anymore!

I think this is related to T52407, about the larger need of a way to specify dependencies between parameters. There is indeed a lot of work still to be done in order to make sure that TemplateStyles can deal with any kind of templates. However, I doubt that “low priority” will ever get us there …

According to this help page, Templates are supposed to have subpages just like user or project pages. And indeed I also never noticed any different software treatment until recently with TemplateStyles.

Indeed, meanwhile articles mainly edited with VE are flooded with auto generated weblinks disguised as “cite book”, which will then also further spread with copy&paste by inexperienced users.

I hoped that resolving T185184 would fix this as well. But I can still reproduce the invisible wikitext parts at the beginning of any article that start with a template (infoboxes, usually). Just encountered another interesting case: initially, there were two different infoboxes at the beginning of the article, which I both deleted (by selecting single parts of them and overwriting the wikitext; it was this article: https://de.wikipedia.org/wiki/Zero_Assoluto). Then I used the backwards function of the editor, which eventually only brought back the first infobox. When using the preview, though, the other infobox was still there. Trying to reproduce it later, I managed to get various combinations of chaotic template wikitext, like

Okay, did some testing: I can always reproduce the problem in Firefox and Chrome, while in Edge it works fine (all browsers are updated to the latest version). Whether I am logged in or not does not matter; any time I paste a chunk of text (no difference between VE and NWE), there is an invisible character at the end of the line, which I can only get rid off by deleting it explicitly or by saving the page. OS is Win10, also latest version.

This sounds a lot like T171616 to me! There it has nothing to do with syntax highlighting, though. In any case I can still reproduce my problems, although I fortunately did not have another crash.

Yes, substituting within refs won't work if this bug is not resolved!

I am also thinking of templates with an unlimited number of unnamed parameters, which are not handled well in VE currently.

At least in German Wikipedia, the number of wrongly used cite book templates for websites is increasing quickly, as new users apparently just leave the formatting of the reference to VE. This produces a completely unnecessary workload when correcting the templates subsequently and also means that you will have to fill in everything manually if you want to have it correctly from the start. It’s definitely not of low priority!

Just encountered the problem again in a different setting (and with less severe consequences)!

To give a short summary of my usual steps (described in detail in German): it always happens when I want to delete an infobox at the beginning of an article which contains a photo. The moment I try to use the file name in a normal file embedding without the infobox code, the font changes and different problems can arise (there are some variations): sometimes the editor is completely blocked, one time making it even impossible to save (after a lot of editing in the article); sometimes it is not possible to write in some paragraphs (in those moments the Chrome console always warned about "Uncaught TypeError: Cannot read property 'getStore' of null" and similar); usually if I try to copy-paste some part of the source, I will not get back the part I have previously selected (mostly the code at the beginning of the article that I had previously deleted will always reappear somewhere). Looks like some deleted parts instead of vanishing are somehow hidden under other parts of the text.

I could reproduce it with Chromium as well, it’s apparently not limited to Firefox!

I noticed the problem today for the first time on my PC (Chromium), before I had experienced it only on the tablet. It happened with a user page on de.wiki that derived from meta, a similar case as the above mentioned.

Anything going on? It's high time that typography is corrected automatically; I don't get how you can classify this as lowest priority!

Well, I have another case: In German Wikipedia we have Template:Charteintrag, where not only such dependencies are required (eg if “POS_xy” then also “WO_xy”), but even the parameter names depend heavily on earlier added parameters. If I enter 1=x and 2=y, the possible parameters following are POS_x (with WO_x) and POS_y (with WO_y), but of course not eg POS_z! At the moment TemplateData is totally useless with this template, I fear.