Sat, Sep 15
Fri, Sep 14
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
Thu, Sep 13
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
Wed, Sep 5
Sun, Aug 26
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 easy 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 where suggested with Flow-text, which comes not in the final SVG (1.1) specification.
If we would support SVG 2 it would be easy, as it uses "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 CSS. But the other main point is, Wikimedia don't want CSS in syntax: T37704
@Commons should 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.
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):