FWIW, I’ve read the comment and I disagree that my point above should be disregarded just because ‘it scales with bytes’. PEIS for example is not an objective measure, but a metric that is supposed to track the complexity of the templates on a page. The complexity of the templates on a page does not increase if I write in Russian instead of English, and Russian Wikipedia should not be punished by metrics that monolingual people came up with 15 years ago.

In T275319#9813756, @Ladsgroup wrote:

While non-Latin characters take twice as space, since Arabic and Hebrew scripts don't write short vowels (unless for children or disambiguation), the average letter per word is much lower than Latin scripts.

This is true but not all other languages have the same ‘advantage’. Russian routinely has bigger words and writes vowels. I don't think necessarily $wgMaxArticleSize is the thing to change though, since 2 MB pages are not really a useful need, but stuff like PEIS should definitely move to considering symbols and not bytes because that privileges Latin-based languages.

The biggest problem with that piece of code is that it is just unnecessary. There is no benefit to hiding the FlaggedRevs info into a popup that repeats the same info that the non-hidden notice already provides. It would be very good to have someone simplify that piece of code but I know that FlaggedRevs isn’t well-maintained. I can provide simplified redesign ideas if there’s any chance of them getting implemented.

In T364587#9813801, @Jdlrobson wrote:

It's floated - looks like you have a local style here: https://ru.wikipedia.org/wiki/MediaWiki:Common.css#L-195
that needs to be copied to MediaWiki:Minerva.css ?

Huh. First time I’m seeing that code. But I would argue that the screenshots above should still display correctly on the default FlaggedRevs setup. Even if some local overrides are missing (I will move them to https://ru.wikipedia.org/wiki/MediaWiki:Gadget-common-site.css now but I would argue this still needs a fix).

Yeah, sorry (links should be viewed logged-in):

• https://ru.m.wikipedia.org/wiki/Википедия
• https://ru.m.wikipedia.org/wiki/Русская_Википедия
• https://ru.m.wikipedia.org/wiki/Вашадзе,_Георгий

Actually, this means that Minerva places the FlaggedRevs notice in a different place from before. Previously it was just under the heading, now it’s under the buttons. @Jdlrobson can I ask you to take a look and/or clarify the difference?

Another problem a person reports with the new styles in https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Не_баг,_а_фича!

In T363337#9811366, @Aklapper wrote:

It would mean that only members of Trusted-Contributors, WMF-NDA acl*sre-team or acl*security can change the Priority field value.

I hope this would mean that addition to Trusted-Contributors would be more active then because this would effectively hinder ability of many less active Phabricator contributors to report the urgent tasks.

Would this mean that people like me couldn’t put Unbreak Now! priority to the tasks that require it?

Why is displaying a hover-only element with no context in hover-less environment in any way better than not displaying it like it was before? I am baffled by this. OK, I will add the necessary code to hide it completely from Minerva.

What do you mean? This is in scope: the colour that you added fails basic contrast requirements, part of the interface (– icon below the smaller notice) is not hidden even though it was before.

Does not LGTM:
https://ru.m.wikipedia.org/wiki/Сказочная_тайга

Removing this styling entirely instead of replacing it with list-style: disc will make it worse to read the bullets in sublists, e. g.:

It’s good to see MediaViewer getting improved, especially since for some reason it is still different on mobile and on desktop (it shouldn’t be). I just hope that the issues with the new code mentioned by me above will also be resolved soon.

Finally 🎉

In this case it is https://ru.wikipedia.org/wiki/Шаблон:Неоднозначность (a template) generating this.

Would be great to redesign that module entirely tbh. It is very incoherently designed right now. Let me demonstrate with a screenshot:

OK, that answers my question I think. Hopefully the use of ellipsis will be as minimal as possible.

Why was that decided for all contexts, and not just for contexts where there is no other possible solution? I’d like to remind that there are no tooltips on mobile, for example.

What seems to be another regression after this update is that the buttons are not aligned correctly horizontally (both issues in Firefox):

Seems like icon buttons in the top right corner became noticeably smaller after this task’s changes were merged, is that really intended? For me https://en.wikipedia.org/wiki/Assassination_of_Luis_Carrero_Blanco#/media/File:Placa_Carrero_Blanco.jpg displays buttons at 20×20 when the recommended minimal size even in Codex library is 44×44 per https://doc.wikimedia.org/codex/latest/components/demos/button.html

Seems like @Jdlrobson in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1020418 while fixing T361671.

This work seems to be underway in T356532 and related tasks. I’ll do the patch.

Also, hyphens: auto (maybe wrapped in @supports for entire block with widths) would’ve been preferred to word-break since the latter breaks the words pretty badly (I see EventStreamConfi/g and ElectronPdfServic/e now)

There is a weird <table class="wikitable plainlinks" id="sv-skin"></table> on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Version now, @matmarex can you take a look?

In T363657#9765380, @Jack_who_built_the_house wrote:

Content styles are not necessarily used for user-generated content, e.g. on https://en.wikipedia.org/wiki/Special:Version there are content styles and .mw-body-content, but no user-generated content and .mw-parser-output.

Those cases can be pretty easily fixed if it becomes a problem. I don’t necessarily see it as an issue (especially since .wikitable is not currently scoped to anything for example; maybe that should also be the case here).

Would be good to just rescope all of these to .mw-parser-output IMO. That should indicate by default that whatever you put into it should be styled like page content does. And that class is pretty much stable, given that it is used in various parts of interface and in multiple extensions.

Seems like tag markers are still displayed without parentheses, @Jdlrobson are you sure it is resolved?

Btw, I meant that there should be a ‘Recent additions’ option for every group, not just a link to all recent additions. The latter would indeed be quite useless. But linking to all the messages in the group is also quite useless. There should be an option to display all the messages in the group in the order of their last edit (or something like that).

Another thing that is missing in the task desc: https://en.wikipedia.org/w/index.php?title=Kazan&action=info has a self-made ToC (generated by https://en.wikipedia.org/wiki/MediaWiki:Pageinfo-header). Other wikis might’ve copied this. This would also cease to be needed if this was implemented.

This needed to be fixed via removing the icon point-blank from that message, not via just always loading the icon. The entire box there is misaligned and the icon just contributes to a worse-looking design:

Given that this happens second time already, something needs to be done to ensure this doesn’t happen in another year.

This is a bad hack that should not be supported. A sensible code that does this pattern looks like this:

| a = {{#if: {{{condition|}}} | one outcome | two outcome }}
| b = {{#if: {{{condition|}}} | three outcome | four outcome }}

Your example doesn’t work with duplicate parameter warning and does not work rightly. Wikitext is not supposed to be used like that, passing differing arguments into a #switch is hacky as it is, but what you want to do is even more hacky. This task can and should be declined.

This bug has resurfaced again, given that it is exactly the same, I am re-opening the task:

In T361299#9730812, @JScherer-WMF wrote:

Thanks for this. Just so I understand, is there potential tech debt or complications that we would incur if we kept the smaller margin? Ideally, the block quote would be inset from both sides of the main paragraph, including the vertical stroke that demarcates it from the other sections.

There is no potential tech debt, but I would argue that mobile format should use as much space as is allowed. Tablet+ can obviously have margins. I just don’t think it necessarily makes sense for a mobile layout (especially since not everyone has big smartphones).

In T362747#9727635, @matmarex wrote:

@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

I think in that case it was also what you described: new module not propagating to the HTML. It wasn’t browser-side cache because I also checked it without any cache in Firefox Focus etc. But, to be frank, I don’t think it is the same in the desktop version: I use Wikipedia anonymously extensively and I’ve both added and removed gadgets before and the change propagation on desktop is not the same as it is on mobile. I don’t exactly know the reason for it, but it doesn’t take week or two to add a new gadget module to desktop views, for instance. If anything, the changes in default modules get reflected on pages much quicker than it was with Minerva.

While this bug is the most apparent, it would be also good to explore in general what causes this problem in Minerva / mobile version in particular. I don't think the expectation of a style change should be any different on Minerva than it is on other skins. If an update is done, it should be properly propagated no matter the skin. Currently that is only the case with async CSS loaded by MobileFrontend’s JS.

I experienced this while trying to do the work on making a common site styles module in Russian Wikipedia.

@Volker_E please comment on the patch if you can. I need to drop https://ru.wikipedia.org/wiki/MediaWiki:Gadget-wikibugs.css#L-21 already :-)

In T361299#9723798, @JScherer-WMF wrote:

Would you mind letting me know the device / viewport width with which that screenshot was taken so I can replicate it on our end?

This is also related to T356532. Even without the block quote styling, the new large text setting can create less optimal character per line numbers, especially in languages with longer words.

This was just my Android device. Obviously the most glaring problems would be seen on 360px, this is somewhere like 480px width and 720px height.

In T316670#9179471, @matmarex wrote:

I think that this could be resolved with min-width on the headings, rather than clear: both. We did that for headings modified by DiscussionTools, which also adds a bunch of extra items to the heading: T335823.

Since this is not getting fixed for such a long time and continues to cause issues, I added min-width: 10em locally (= 240px) in https://ru.wikipedia.org/wiki/MediaWiki:Minerva.css#L-6

What you are describing are deficiencies in Translate extension, not in VE. Same would probably happen if I use https://en.wikipedia.org/wiki/User:BrandonXLF/QuickEdit if the handling of !!FUZZY!! is really so fragile. That should be fixed instead of trying to break VE support for no reason.

@matmarex replying here instead of onwiki: this is this code in jquery.makeCollapsible styles —
https://gerrit.wikimedia.org/g/mediawiki/core/+/67f80e68bf5534d5de317c4ee892707d18760ade/resources/src/jquery/jquery.makeCollapsible.styles.less#46

Interesting. Updated https://ru.wikipedia.org/wiki/Шаблон:Оригинальный_текст to use it, seems to function as intended. I guess this covers all the cases then.

Another option for ruWP might be to turn on the ‘basic’ experience by default since we don't seem to show the ‘advanced’ version to IP users and I would argue ‘advanced’ option is pretty, for the lack of the technical term, shit for everyone else as well. That whole interface really needs a redesign, but in the case of Russian Wikipedia, I think switching it off might be a proper solution as well.

From my own lookup of what causes this, this seems to be caused by the following code in OOUI itself:
https://gerrit.wikimedia.org/g/oojs/ui/+/8e4947086a62a6516df6f2eb125a02d440ebb94b/php/mixins/ButtonElement.php#44

‘At least as visibly as in the wikitext editor’, or... not so much :-) I don’t see why the deficiencies of Translate extension in that department should preclude from fixing this task.

Another argument in favour of putting everything above the input (with an example that is valid for Wikipedia, ‘Stjn’ is not required to be here, it can also just be ‘Manage passwords’ on its own):

Regarding !!FUZZY!!, I think this is a more general issue with Translate extension. See for example this edit: https://translatewiki.net/?diff=12345686 — I think !!FUZZY!! was there at some point and I only ended up seeing it because I went into source code mode afterwards to edit yet again, but nothing was shown upon saving. There might be some other cases where that’s true.

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

This continuously causes issues with user scripts after any rename, I am asking someone from Security-Team to take time to review the patch provided.

Why do I have visual editor buttons on translatewiki.net in those namespaces then? (And what would be the problem with keeping it?)

This task should really be declined. Most languages do not have machine translations that are well-translated in comparison to original, especially with technical terms, especially in such a narrow field like Wiki(p/m)edia. Trying to engineer a solution that would at any point involve machine translation in interface messages is just plain wrong. In Russian we are frequently having to remove the results of low-effort machine translations from people who simply press some buttons to translate without knowing both languages full well. WMF should not contribute to this. If you want your tools to be translated to different languages, pay Wikimedians to translate them.

In T361940#9695592, @Ladsgroup wrote:

Doing this will address the problem for everyone regarding that issue: T359529#9684005

This is a massive change in how autoreview was handled though, if intended. Having one or multiple unreviewed templates on a page shouldn’t lead to requiring to review every single edit on a page.

@Zache please comment the same on the other task since this one was closed as a duplicate of T361940: Imports, moves and protections are not autoreviewed

In T361934#9692567, @cscott wrote:

EDIT: actually I think I misunderstood the meaning of "guaranteed invalid" in the spec (https://www.w3.org/TR/css-variables-1/#invalid-variables) and the inheritance won't actually work the way I expected it would. Can someone else double-check my logic and figure out whether this can be done in another way without requiring more custom-property syntax?

Copying the comment: unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var() in case --skin-specific is undefined.

@Mabualruz unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var() in case --skin-specific is undefined.

I had to fix margins yesterday on the main page of Russian Wikipedia because I opened it in new Vector and it had a bunch of spacing problems because of the paddings. I think having only margins to space elements is a reasonable expectation in newer skins (Monobook also has paddings, but, hey) that was broken by the changes described in the task.

By going to https://en.m.wikipedia.org/wiki/Martin_Luther_King_Jr.#/languages I get this:

Fixing this would also fix T309489: Main Page history is not full width

Somewhat of an opinion that <pre lang=""> and <code lang=""> should just function as synonyms to <syntaxhighlight> if the extension is installed. Or something similar to them (language or hlang to differ from HTML lang?). Yes, it is not ‘correct HTML’, but so what? As long as wikitext doesn’t insert the attribute into HTML, we’re fine, I’d say. And <syntaxhighlight> without any lang should be considered an error. (<source> to me is bad since it doesn’t say anything about what the tag does, even if it is less verbose.)

The last note is the result of T282999: Enable Reference Previews on all wikis using the Popups extension, on Nov 21 to which you are privy. We never asked to have ext.cite.referencePreviews enabled, it was done without the community opt-in on an explicit promise that it should not add JS when the project doesn’t want to use it.

In T345960#9680099, @Jdlrobson wrote:

It's already a thing for WMF developers: https://phabricator.wikimedia.org/T360590

Are there any metrics showing what contributes the most to the JS payload? I tried to look into that issue in Russian Wikipedia as a result of the T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip task, but we ended up with an impression that default gadgets contribute far less into the JS size than the default modules did.

Small comment: if this becomes a thing, this should also become a thing for WMF developers, since (from the looks of it for me) most of the JS payload on Wikimedia websites comes not from gadgets, but from various default JS modules loaded without any possibility to opt-out. Focusing on gadgets then becomes trying to push the blame onto the gadget developers even though they are not the main contributors to JS payload.

In T358071#9679085, @Jdlrobson wrote:

I can't see ambox in https://en.m.wikipedia.org/wiki/Crocus_City_Hall_attack ?

See for example in https://en.m.wikipedia.org/?oldid=1215029134

Keep in mind btw that since T280531: Enable partial action blocks on all Wikimedia production wikis and in MediaWiki by default local sysops already can block users from (re)uploading files and that doesn’t require having a user group (via https://www.mediawiki.org/wiki/Anti-Harassment_Tools/Action_Blocks). I see that the proposal removes autopromotion entirely, but just want to make sure that the decision-makers in the community are aware of this opportunity.

See https://www.mediawiki.org/wiki/Figure_migration / T314318: Disable wgParserEnableLegacyMediaDOM on all wikis

Changed by MusikAnimal after my request.

(I would like to amend the previous comment: I too consider the patch and the merge good for the project, I just think that given the constraints of the current system there should’ve been some amendment that would make possible to use category names with commas in them.)

In T359894#9663983, @Izno wrote:

This is how it was until T280766. That was enough writing on the wall to ditch the name.

Oof. Maybe if Jdlrobson pinky-promises to not touch that class again, you can use error with cs1-specific class?

There is no specific template adding a category, it is added via heuristics. So no, it still requires a gadget while Lua support for categories is not there.

Another alternative is for .cs1-visible-error to implement itself via standard error class while resetting some of its properties.

Encountered another instance where setting a variable on the class level would be beneficial to simpler CSS writing:
https://ru.wikipedia.org/?diff=136900868

Other options would rarely contain categories, but this option is very likely to do so in many languages. I think making this change without considering this was bad.