Sun, Jul 8
Fri, Jul 6
That's it, I updated the desc. You directory link is fine!
Tue, Jul 3
Mon, Jul 2
I mean this is corrupt drawing not corrupt rendering. The curve handles on the both relevant nodes are fully switched at 180°. Fixed nodes:
This is an absolutely simple (idiotic) bug, which was introduced 2014 (before librsvg was correct). T68672 But nobody cares or recognize.
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.
Feb 12 2018
Feb 11 2018
Feb 9 2018
Jan 30 2018
Jan 27 2018
Jan 18 2018
Jan 13 2018
I propose to not fix, as this is proprietary code of an editor without standard. Actual browsers seems also not support this not understandable font-name systematic.
Jan 4 2018
After short test with Steinsplitter, the patch unfortunately still doesn't work.
Dec 26 2017
https://commons.wikimedia.org/wiki/File:SVG_mask_gradient_bug.svg renders correctly on Commons SVG Checker only, which declares running under librsvg 2.40.2. (as @JoKalliauer mentioned on a testcase)
Dec 17 2017
This is one of the lower bugs I know. As in the "Non-goals of librsvg" stays: "Implement every single SVG feature that is in the spec." On the other hand, even industrial-strength SVG rendering machinery in modern web browsers, don't supports this baseline-shift (as Firefox and Edge).
Dec 14 2017
I guess Test.svg is a really problem (limit) indicator, as this has the ongoing growing longest file history ever (+ already deletions).
I guess on Commons the module must be installed locally, as there are to much gadgets using this.
OK I see now, not blocked, because subtask T166601 is already done.
This is blocked by T88976: mw.toolbar.insertTags should be independent from mediawiki.toolbar module as (mw.toolbar is removed and) mw.toolbar.insertTags is used for the bottom edit tools (mw-editTools; which should not be removed!?).
Collides with T30856: Remove classic edit toolbar from core
I absolutely agree (for years, I just wanted to create this myself). On the one hand, it is absolutely annoying for editors if fonts get removed undocumented without any replacement/fallback.(rOMWC1616462ae03ad28fff9fdfc85203820c0bc25c1e)
The only information is https://noc.wikimedia.org/conf/fc-list (the whole page meta:SVG fonts is based on this).
Which seems neither complete nor trusty. We can see here the removed fonts are still present.
Examples (especially Nimbus Sans L fallback for Helvetica):
Dec 13 2017
Categories on Commons are really big stuff (many gadgets are there for maintenance). Such main change would be very critical, I'm very skeptical (but open for new technologies).
Dec 10 2017
@MarcoAurelio: Indeed, this should include an higher attention for the user. Special user right check and prompt (not as the common single one click).
Dec 5 2017
It is very strange, the bug report exists already since 2005 (also on T5909). It should be simple to fix.
I am in favor of keeping the link and converting him to what it is intended (like on Special:Log/move). (At the moment this problem got attention again on the DeWP Forum from experienced users: @NordNordWest, @Tsungam)
Nov 23 2017
I would support this. I've also local a rewritten fork from the Commons version for DeWiki. But there seems not really competent active tech admin anymore. The Commons version is indeed more modern and performant.
Oct 14 2017
Oct 8 2017
Is there a hint for replacement? The gadget on https://commons.wikimedia.org/wiki/Help:Watchlist_messages is not working anymore. That all seems are steps backward. Than I copy all the module also in to the script.
Oct 7 2017
@kaldari It seems your previous fix was the better one as you said:
@Tacsipacsi Anyway I tested with VE, your fix seems a bit pointless. HotCat is not intended to be active on edit-mode. So the simple solution would be to add a IF for the VE edit-mode.
@Tacsipacsi I got an error on the (from @Schnark) given test page: https://commons.wikimedia.org/w/index.php?title=File%3A1921_год_Доклад_о_состоянии_протезного_завода.pdf
Uncaught TypeError: Cannot read property 'insertBefore' of undefined
at CategoryEditor.initialize (<anonymous>:1347:22) at CategoryEditor (<anonymous>:1237:46) at createEditors (<anonymous>:2848:6) at setup (<anonymous>:2861:5) at Object.HotCat.start (<anonymous>:2985:56) at api.php?format=json&callback=HotCat.start&action=query&rawcontinue=&titles=File%3A1921_год_Доклад_о_состоянии_протезного_завода.pdf&prop=info|revisions&rvprop=content|timestamp|ids&meta=siteinfo&rvlimit=1&rvstartid=213817041:1