@Volker_E There is now a general problem in using the .messagebox class, as it can't easy centered anymore (due display: inline-block). E.g. as some main templates on Commons using this: https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Technical&oldid=367049139#Center_appearance_problem

@DannyS712 I just created (with proposal) https://commons.wikimedia.org/wiki/Special:AbuseFilter/220
Looks this ok?

In T232142#5469324, @Dbrant wrote:

To report an issue with the Commons app, please visit the project on GitHub: https://github.com/commons-app/apps-android-commons/issues

Phabricator is used by the Wikipedia app, not the Commons app.

Hey @Aklapper "working against": this was indeed only a not serious metaphor ("we can say", or this only my bad English :P).

It seems the bug was only on this day and is gone.

Adding the .CodeMirror class to the $currentFocused variable fixes this:

.on( 'focus', 'textarea, input:text, .CodeMirror', function () { ...

For me this task is nearly a duplicate of T36266 (same goal with only other approach) and I'm fully fine with Krinkles closing answer there T36266#4940650.
So for now the only adequate solution here is a separation of the dynamic headline text with a static anchor id, as common.
Technically the anchor id is already separated from the heading text (2 times, more/less encoded) and also not identically (e.q. get numbers attached).
So the question is, would this lead to other conflicts?

I guess PerfektesChaos is just right, I also don't see the real problem here.
@Iniquity so your request implies to rename any file which begins with "OOjs" or "OOUI" which get outdated/updated. This could be indeed impracticable. But I'm open for maintenance ideas, if Wikimedia takes the job (which also implies your request here, but I guess this is could be utopian too).

I applied the fix by Lupo himself. So this is probably fixed!?

The preview of SVGedit is also affected. I get a CORS fail:

Access to XMLHttpRequest at 'https://tools.wmflabs.org/convert/#conversionError' (redirected from 'https://tools.wmflabs.org/convert/svg2png.php') from origin 'https://commons.wikimedia.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The error seems from hyper precision in short form in the gradientTransform="matrix(2e-6 0 0 2e-6, which also Inkscape seems not to support (black rectangle). My Chrome simply ignore this element. So this seems not a SVG standard and so I suggest very low priority to fix. Interesting would be which tool the user had used.
Edit: I've never seen this problem before.

Is it not better to place this gadget on Meta!?

The file contains extensive feGaussianBlur filter usage, in which is librSVG not good. This filter has also only support recently.

This is a duplicate of T35245

I could swear I saw this bug long time before, as every style property with normal is ignored. PS: I found the report, as this is mentioned for years on https://commons.wikimedia.org/wiki/Help:SVG#Font-weight_value (without report). E.g. so font-style and font-stretch is affected too.

I reopened this task as this is not resolved on DeWiki, as there is still the deprecated mw.toolbar.insertTags used (on MediaWiki:Onlyifediting.js).

We don't want people to be able to globally rename from every wiki.

Why global renamers is not a global group??

In T205776#4627176, @satdeep_gill wrote:

Same is happening in https://commons.wikimedia.org/wiki/File:Sentence_Structure-pa.svg

The only sure workaround seems to try load twice (at the very end per window.onload), as shown in https://commons.wikimedia.org/wiki/MediaWiki:Edittools.js

We need simply a hook event. The trigger "wikiEditor-toolbar-doneInitialSections" is not suitable (which leads to such fixes rEVED889358f24c20dd326be341f170479334c136021a) also mentioned in T23692#260234 by @Mattflaschen-WMF

In T174145#4542977, @thiemowmde wrote:

Instead of bothering you with another duplicate of this ticket, I'm going to reopen it, because I find the icon heavily misleading and actually stressful.

Short question (not from me) the ltr icon https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_stripeToC-ltr.svg has now illogical rtl alignment.
Compare the old one (apex theme) is exact mirrored: https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_listBullet-ltr_apex.svg
Is this intended??

That would not be easily possible. There must be something like a "max-width" aka content area https://www.w3.org/TR/SVG2/text.html#TermContentArea value for the relevant text areas. I mean the same considerations were suggested with Flow-text, which comes not in the final SVG (1.1) specification.
If we would support SVG 2 it would indeed be easy, as it uses the "Auto-wrapped text" https://www.w3.org/TR/SVG2/text.html#TextLayoutAuto.

PS: It is hard to find a documentation for mw.toolbar replacement for this absolutely core function. It is also very hard to understand why Krinkle himself propagated the use of mw.toolbar just few days before this deprecation warning. https://www.mediawiki.org/w/index.php?title=Manual_talk:Custom_edit_buttons&diff=2750733&oldid=2730331&diffmode=source

Not that this is an important button, but the general problem is, the Wiki syntax is intended to be a tag language and HTML developing is going straight to favor CSS. And so Wikimedia don't want CSS in syntax: T37704

@Commons mw.toolbar should already be done on 2018-02-28 https://commons.wikimedia.org/wiki/Special:Diff/280636787/289473902?title=MediaWiki:Edittools.js

Sorry to be here for an live example, but I deleted https://commons.wikimedia.org/wiki/Template:Mozilla_Public_License/i18n (in fact ./en got deleted) to be able to move subpages per hand from https://commons.wikimedia.org/wiki/Special:PrefixIndex?prefix=MPL%2F&namespace=10 (which got not moved due the move bug by @Jarekt 2018-03-22) which seems a very bad idea from me.
As now (FuzzyBot) deleted all subpages without warning. And I restored all pages, but now the template is not translatable anymore.

In T168591#3375318, @Harej wrote:

Trying to get around this first by moving the subpage and then moving the parent page is a terrible idea, it turns out, since doing the former prevents the latter.

In T68672#4396191, @JoKalliauer wrote:

According to W3C-Validator with DTD 1.1 <style> needs "type" see:

That's it, I updated the desc. You directory link is fine!

I mean this is corrupt drawing not corrupt rendering. The curve handles on the both relevant nodes are fully switched at 180°. So I propose
WON'T FIX. Fixed nodes:

This is an absolutely simple (near idiotic) bug, which was introduced 2014 (before librsvg was correct). T68672

@CKoerner_WMF done