User Details
- User Since
- Dec 2 2014, 11:15 AM (510 w, 1 d)
- Availability
- Available
- IRC Nick
- Perhelion
- LDAP User
- Perhelion
- MediaWiki User
- Perhelion [ Global Accounts ]
Jun 18 2020
Mar 17 2020
Mar 9 2020
Sep 19 2019
@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
Sep 17 2019
Sep 16 2019
@DannyS712 I just created (with proposal) https://commons.wikimedia.org/wiki/Special:AbuseFilter/220
Looks this ok?
Sep 5 2019
Aug 26 2019
Aug 22 2019
Aug 21 2019
Hey @Aklapper "working against": this was indeed only a not serious metaphor ("we can say", or this only my bad English :P).
Aug 16 2019
It seems the bug was only on this day and is gone.
Aug 15 2019
Adding the .CodeMirror class to the $currentFocused variable fixes this:
.on( 'focus', 'textarea, input:text, .CodeMirror', function () { ...
Aug 11 2019
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?
Aug 10 2019
Aug 8 2019
Aug 3 2019
Aug 2 2019
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).
Jul 30 2019
I applied the fix by Lupo himself. So this is probably fixed!?
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.
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).
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
@CKoerner_WMF done