Yes, that's what I thought. On dewiki, I am not aware of other templates generally using sticky table headers, so "my" templates would be the most common, if not only use cases so far. Those tables all use the class charts-stickyhead (as documented here). I have no idea if other projects have done similar experiments, the Gadget on enwiki (@TheDJ) can probably be adapted to the Skin-specific differences. I think if this sticky header is deployed, the potential problem and its fix (eg, adding a certain standardized class) should be clearly documented somewhere for reference, then fixing any unwanted effects should be relatively easy. I will follow it closely in any case ;)

Hm, so you basically do not see the element mw-fr-category-oldreviewed. I thought logged-in users would see it generally, but since it comes from FlaggedRevs, I suppose you need reviewer rights in order to see it.

The linked page is still the relevant use case. To see the issue, you just need to be logged in and get rid of span.subpages {display: block;} in Minerva.css and Mobile.css, which is our temporary fix.

Yes, I was thinking of that. But would that have to be done for every template and gadget or would new Vector automatically modify top:0 in tables? In templates, it would of course be possible to target Vector and change the top attribute only there, but I don’t know how that would affect Vector Legacy. And much depends on the final version of the sticky site header: if it only appears on mouseover, it might not be necessary to change sticky table headers at all, as they would only be covered temporarily; otherwise, elements would have to move whenever the sticky site header appears. If the site header remains sticky all the time, the table headers need to remain visible all the time. And if the site header will be configurable through user preferences, the configuration would have to adapt accordingly.

True, I remember having tested to fix the VE toolbar in such situations, the overlap is very annoying. A page with several sticky table headers on dewiki is eg this discography (the template is of course used on thousands of pages). On enwiki, there is even a Gadget that can be activated for basically all tables.

I had already mentioned that on one of the feedback pages (can’t find it anymore), but I would like to point it out here as well: the feature should not clash with sticky headers of tables already used on pages. A sticky site header would overlap sticky table headers and make them useless. Maybe such situations have already been addressed in the meantime, just wanted to mention it again. I’m looking forward to the feature!

The blatant “who cares?” attitude shown on this task makes it hard for me to comment any further. But anyway, let’s wait until someone answers the obvious question on why this change was not announced the way it should have been. Then we might think about a local solution. Just further cluttering the common stylesheet of dewiki after every new bug should be avoided.

Yes, that could only be fixed via Common.css, but I would not touch that stylesheet only for a temporary fix.

Who is going to determine what are “important articles” and by which criteria? Without a replacement strategy, this change should have never been done in the first place. If it can’t be undone easily, I will propose a local replacement via Common.css on dewiki (at least for the row highlighting, which in my experience is the main reason why it is used). But I guess that cannot be a permanent solution.

Yeah, currently we are advised against using TemplateStyles that way. And as PerfektesChaos already pointed out, who is going to insert that template in more than 2,000 pages now?

I always liked using datatable on tables, and apparently I was not alone on dewiki: more than 2,000 pages there use the feature. The suggestion to work with TemplateStyles does not help, as we cannot simply make templates out of all the individual tables. Please bring back the functionality asap!

How far are we on this? The search suggestions footer still does not wrap correctly on Chrome, in any case.

In T97892#7281678, @Jdlrobson wrote:

This looks like a small unintentional mistake in T285492 that's easily rectifiable due to 2 conflicting but unrelated changes. No action is needed from editors.

In T97892#7281043, @XanonymusX wrote:

Are we supposed to fix this on dewiki directly via Monobook.css (easily doable) or will there actually be a central solution? I don’t really understand what the proposed “move to Monobook” of this task was trying to do.

For the record, this task was a refactor to make MonoBook more manageable that was done in July that has nothing to do with the current breakage. The current breakage occurred due to applying a patch that was written before the change and only recently merged. I've applied a temporary fix to MonoBook.css which I'll remove when this is dealt with.

Are we supposed to fix this on dewiki directly via Monobook.css (easily doable) or will there actually be a central solution? I don’t really understand what the proposed “move to Monobook” of this task was trying to do.

As far as I can see, the same error is shown for links to redirects and for “red links” (thus links to ?action=edit of non-existing pages). For the former I would expect to be shown the preview of the page it redirects to, for the latter I would recommend a more specific error message, if possible (“read on Wikipedia” is a misleading description if it leads to editing a page).

I have tried to describe what the original problem was (and still is)

Oh, true, I checked with protected pages in ns-0 as well! Okay, new task then.

Just noticed this as well. Additionally, for pages in the Help and Template namespace, I do not see a “protect” option (while move and delete are present). I can’t think of a good reason to treat the various namespaces differently.

Yes, but why would you go for break-all now? That one is the worst option available, as lined out in T171726 (at least for text, not sure if it would make any difference for mere search results). It needs break-word (and yes, as a fallback for hyphenation). There is also some confusion around whether to use word-break, word-wrap or overflow-wrap (Chrome does some weird things there), but that will need some browser testing. Search results and footer should act in the same way in any case.

As long as it does not work in Chrome (the by far most widely used browser), it should not even be an option. And while in normal text it might be reasonable to use it, in the context of a diff (T171726) it does more harm than good, as readers won’t be able to distinguish between actual hyphens in the text and automatic hyphens. I guess in the search, hyphenation could be considered (but please consistently, not just in the footer), as users can directly see if they typed a hyphen themselves, but it needs word-break as fallback for Chrome and unsupported languages.

So, your observation is actually easily explainable: the browser apparently does not know any working hyphenation for Hebrew specifically, just tried it on Firefox. Other languages work fine. While Chrome apparently does not provide hyphenation in this context at all. That’s why I already questioned the use of hyphens:auto several times; just use word-break as anywhere else and we should be fine on all browsers and in all languages.

Hm, doesn’t seem like a satisfying explanation to me; I always have this happen on dewiki, where content language and interface language are both German!

Interesting. So this part is supposed to use hyphens instead of word-break? I would suggest to be consistent everywhere, but no idea if this is the root cause. For me it looks like in this screenshot; I use Chrome, there should be nothing else causing trouble.

Nice, seems to work! Now I found a new problem though (might also be caused by the change due to T280982): the search term is not wrapped and long ones are visible outside of the dropdown now. I do believe that was different before, but I wouldn’t bet on it, since I used custom CSS on the whole dropdown; might be a new issue entirely.

Just an observation: is it on purpose that unregistered users on mobile (Minerva) will not see any box/notification (that is the case now already, but the indicator area is of course no different)? From a dewiki perspective, I feel like this would be an important information for all users (similar to hatnote warnings etc.).

Okay, I have made some edits on beta today and received one notification (and one email) regarding Wikipedia Library! Will this be the only notification then?

I am pretty sure that the short description will work in the same way as the sort key does right now; thus we of course need to review the revision (in the wikitext), but the description the page uses will come from the latest revision, even if not reviewed. That is of course not the ideal behaviour (same for DEFAULTSORT), but with the current status of the FlaggedRevs extension it is to be expected.

In my eyes, it is only reasonable that WMF would try to treat communities/projects equally, even if indeed several years have passed. But anyway, since I am the initiator on dewiki, I will not allow for a premature termination to happen. Let’s continue the talks on dewiki!

In T279829#7028314, @MisterSynergy wrote:

The German Wikipedia community has not yet even discussed whether Wikidata descriptions should be dumped completely, or which milestone would be appropriate in case this should be done. Some remarks:

• In case this gets approved, there is a plan to add short descriptions from [[de:Vorlage:Personendaten]], which actually has systematic "short descriptions" for all biographies in German Wikipedia that would immediately qualify for use in SHORTDESC as well. With 870.000 transclusions, it alone would be sufficient to pass the proposed 850.000 requirement, leaving all non-biographies without descriptions.
• A couple of days ago, I queried the situation a bit. There were 2,56 million German Wikipedia articles (main namespace, no redirects), of which 2,13 million (83%) use a German description from Wikidata. This is considerably more than what we had three years ago for English Wikipedia.

You propose to ignore 1,3 million existing descriptions from Wikidata. This is way too much, particularly considering that quite some editors have invested considerable time into adding Wikidata descriptions due to the way they have been used and exposed to readers in the past six years or so. It is also unclear at this point whether there is a desire to dump Wikidata descriptions entirely that is as strong as it was in English Wikipedia three years ago.

Perfect, thank you! As for step two, we are discussing that separately and might choose a different approach than English Wikipedia, but the procedure will show. We will continue our talks and then move forward with voting on the proposals soon.

Right, the same happens to other pages in the Wikipedia namespace that use class-styled h2 titles, like the Community portal.

@matmarex Seems so, yes. However, now the main page on dewiki looks completely broken when I have the tool activated (on all skins). Somehow TemplateStyles are no longer loaded, I believe. According to the HTML output, there is DiscussionTools involved. The dewiki main page is in the Wikipedia namespace, that must be the reason it is affected.

It also causes weird overflow issues with long titles, btw, took me a while to figure out what could be wrong.

As it probably is related: at the same time, all these sections are now suddenly expanded by default, without even the option to undo it (the arrows are gone). Have not yet encountered it on any ns-0 pages, but on project pages.

Thanks! There is no need to hurry, the current discussion is one of a series that went on for years, so we can wait a bit longer. I will not move on with the voting for now, as it is only fair to first provide the community with as much additional input as possible.

The move icon is a bit unexpected, but otherwise it looks promising!

How many projects actually use indicators for protection icons? I know it from enwiki, but eg dewiki has never tried to do that.

There is no point in re-discussing it; if a community wants to use it, they should be able to. And what exactly is the use of a German-language short description of a dewiki article for other projects?

Sure, but I repeat, this is deemed controversial for whatever reason, and I would like to have input on that beforehand, otherwise there con be no informed consensus by the community. Since the start of the procedure would have to be announced at least one week in advance anyway, there is enough time for the responsible people here on Phabricator to react; during the voting the task should of course be stalled. Let’s keep it open for now!

Ehm, the plan was to just do the opposite! As explained in the beginning, I will only go forward with the voting procedure if there is no “fundamental, well-founded reason to decline such a request”. I do not expect there to be one, but I would prefer to have some form of an official statement on this, due to its controversial nature.

In T279829#6988895, @Aklapper wrote:

In T279829#6988804, @XanonymusX wrote:

@Aklapper has referred me to filing a new request in the linked discussion

Errrm, well, I merely pointed to https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes and https://meta.wikimedia.org/wiki/Limits_to_configuration_changes for general info...

@Bugreporter I'm sorry, but this will not suffice. In that task they refer to a statement by @DannyH from 2018 (!), where he simply says that they will not enable the feature right now and without any reasons. It is 2021, @Aklapper has referred me to filing a new request in the linked discussion, and so I did. The dewiki community deserves a proper statement regarding this issue!

Another example for indicators: just saw that Dutch Wikipedia (nlwiki) puts the player for spoken articles in the indicator area (eg here), quite a stretch. At least it is also added to the end of the article (similar to dewiki, where the indicator icon only links to the footer with the player).

Well, there is a lot that has never been documented in MobileWeb as well … How should something like this be fixed by template editors? First of all, close to nobody uses the apps (especially among editors), so editors will not notice. Then, in the recommendations for mobile-friendly pages it says that such divs should use the infobox-container class. Would it still be removed in that case (as the class name contains infobox nonetheless)? Atm using that class doesn’t help though, as the current configuration of MoveLeadParagraph won’t recognise it anymore; and Mobile Web is more important than the apps. I recommend deleting that rule altogether.

Yeah, the latter point I thought about as well. So, I would summarise our “common” ideas:

Well, high time to track these discrepancies then! ;)

If there was a workable proposal for generally showing indicators in Minerva, sure; but since 2014 there hasn’t been any, as far as I can see. My WD-based proposal is relatively easy to configure, as the same is done for generating the short description on most projects, so I have more hope that it could be done quickly. And people seem to agree that those quality badges are the most important/relevant types of indicators, so giving them a special treatment seems to be in line with what has been discussed about the general problem. Oh, and just like with the short description, a way to locally overwrite it (with a categorised indicator as proposed?) could be implemented as well. The rare discrepancy between WD and local indicator (which at least on dewiki is tracked and quickly fixed) is still an improvement over not having any indicators shown.

Lovely. That’s the issue with mixing structural global semantics and local decoration (as already criticised in T262093) …

Well, but why does it use this class then in the first place? Navboxes on dewiki are visible because we never used the class, there is absolutely no need for it.

But mobile web of enwiki does have a tagline, it is just empty. And I stand corrected, the same holds true for Minerva on desktop generally, so the tagline should indeed be the preferred position for the indicators. My proposal:

No idea about the apps, but what do you mean by m.wikipedia.org? That is not a project. My screenshots above are from de.m.wikipedia.org, in case that wasn’t clear. However, I have come to realise that this task is actually about the Minerva skin, not specifically about mobile web, there we indeed do not have a default tagline. But as already said, it can just float within the page-heading, a tagline is not a necessity.

In T75299#6932946, @Sdkb wrote:

@XanonymusX I don't think the tagline is shown on most mobile displays for most wikis.

I can confirm that it still looks like this, yes!

I would go along with giving good/featured a special treatment (as I said, I would then just directly take that information from WD and ideally display the small badges to the right of the short description), which should be prioritised, and offering a dropdown for anything else users might have added to the indicator area (unless specifically marked as nomobile).

Honestly, in order to do that, we don’t even need to resolve this task at all. The information on good/featured is already in Wikidata and could be quite easily displayed directly from there, like the short description (maybe even using the same small badges used on WD). Tooltips on tap would have to be added, but it seems fairly easy to me. Any comments on that approach? Could be filed in another task.

In T171726#3475223, @Jdlrobson wrote:

This was intentional. Why is the word wrap problematic? What would be preferred?

This assumes that the class names will remain like this, with all the styling issues that have been pointed out already. As already explained, I would have to use hatnote both for disambiguation notes and for message boxes on dewiki due to incompatibilities of the ambox class, which would not be in line with the logic of the linked recommendations.

I would also add that the icons for protected status are not that widely used across projects, there is no such thing on dewiki, for example.

It’s not really a bug, as it is to be expected that a nowrap will cause overflow. But since mobile web and the app hide overflow, it needs to be forced to wrap. In the four screenshots I show lines with nowrap (the page numbers in footnotes 268 and 271; it’s part of the citation templates on dewiki); only the reference preview in the iOS app manages to wrap the line.

Yeah, I just experimented with the ambox class and must say that it is absolutely incompatible with related templates on dewiki. Which means that we would have to use hatnote on all of them (not really what the class was designed for) or just leave them in the middle of the text if this change were to become permanent. Apart from potential clashes with local CSS because of poor naming, as pointed out by @PerfektesChaos, the biggest issue is that these classes all have very specific styling attached to them, which has caused me quite some headache with infobox already; now with hatnote there comes a grey text-colour and a tiny font size, which is not in line with standard styling on dewiki.

I remember similar problems on dewiki with the IPA template, which uses templatestyles and had previously broken the moving of the first paragraph. That had been fixed (last year?), can’t remember which task that was.

For dewiki, I have now added hatnote to some of the most common templates. Luckily I have admin rights, since many of these templates are protected. But this can indeed not be the solution; as long as the recommendations linked above are not followed by a substantial percentage of the projects, such an enwiki-centric change disrupts a huge number of projects. Just saying, I am one of the main forces behind mobile-friendly optimisations on dewiki, but I had never even seen this page with recommendations before. I will be happy to promote them on dewiki, but there would be a lot more to do in other projects. Revert by Monday sounds reasonable for now.

As explained in T277258, dewiki for example uses class="navigation-not-searchable" on the disambiguation notice. There are absolutely no standard classes for whatever elements of a page across projects (the infobox class is still not standard on dewiki, and I think on itwiki it had never even been used).

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 …