Feb 28 2019
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.
Feb 25 2019
Feb 16 2019
Feb 2 2019
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.
Nov 11 2018
Oct 29 2018
Is it not better to place this gadget on Meta!?
Oct 28 2018
The file contains extensive feGaussianBlur filter usage, in which is librSVG not good. This filter has also only support recently.
Oct 20 2018
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.
Oct 12 2018
We don't want people to be able to globally rename from every wiki.
Why global renamers is not a global group??
Oct 5 2018
Oct 3 2018
Sep 26 2018
Sep 21 2018
Sep 15 2018
Sep 14 2018
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
Sep 13 2018
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
Sep 5 2018
Aug 26 2018
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
Aug 8 2018
Aug 5 2018
Jul 28 2018
Jul 26 2018
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.
Jul 8 2018
Jul 6 2018
That's it, I updated the desc. You directory link is fine!
Jul 3 2018
Jul 2 2018
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
Jun 11 2018
Jun 9 2018
I don't see the real usefulness of removing modules. (It leads to exporting and separating the modules again for script makers.) Makes this not the term module pointless!?
Jun 5 2018
@MusikAnimal: Yes I still see the error. In addition I have to say that it only occurs when the classic toolbar (which will be removed soon from core) is used or the Wikieditor is disabled.
May 21 2018
Hello everywhere, excuse me for my late contribution here, that I was a long time unannounced inactive.
Mar 6 2018
There is now https://commons.wikimedia.org/wiki/MediaWiki:Gadget-LargerGallery.js on Commons. But I don't know for sure if the task is fulfilled with that.
Mar 3 2018
Downgrading discussions also on deWiki:
Mar 2 2018
The current implementation is somewhat of awful. The long size should be depending on what (and maybe how) is something inserted. The edit summary is, in general, a short notice what was done. Some people c&p they fully edit text in there what should definitely never the goal of this feature. Or also classic Uploads got the full file-page as the summary.
E.q. useful for:
Feb 23 2018
Appears in Chrome 63 and Firefox 57 on Windows 7 x64. On all projects (tested also different Acc.)
- Only on Replace all
Feb 21 2018
This bug was due T131382, so I do close.
Feb 19 2018
It seems we can use "iiprop": "metadata" or "iiprop": "dimension" for testing probable valid thumb info.
I reopened the task, as this is not an expectable behavior of the API (and it is also not SVG related). If we have a query list with a bunch of file titles, the whole query fails, and then we must retry the query again and again until we have all errors? There is no other method to test the imageinfo query is valid or not.
I created a fallback case in the general fail function (with empty thumb dummy) after hinting by zhuyifei1999. (Curiously someone deleted immediately all corrupt files from the case above after I deployed the fix.)
Feb 18 2018
Feb 16 2018
Unfortunately no, for me all the taggings are false.
The relevant (local) abuse filter (61) seems still imperfect and in the beginners' phase: https://fi.wikipedia.org/wiki/Toiminnot:V%C3%A4%C3%A4rink%C3%A4ytt%C3%B6suodatin/61 @Zache
The markup for "invalid wikicode" seems very buggy, as I just checked very few recent edits.
Feb 15 2018
@zhuyifei1999 Then open the other task again. It is on the first glance indeed a VFC problem. I've not looked deeper in the VFC code what information concrete are needed. But yes, anyway we need a fallback function here.
Feb 14 2018
Feb 13 2018
This seems not an SVG code problem (alone?), rather a MediaWiki parser problem. It would be new to me if the Wiki parser checks SVG code.