Perhaps we should entirely remove the "info" icon, since the current symbol is indeed quite language-specific? We already have the "help" and "alert" icons (represented by a question mark and an exclamation mark), which are a lot more language-neutral, and which could probably replace it in most cases. A "hint" icon represented by the lightbulb could maybe be added, or perhaps a "guide" represented by a book or something.
I still think that the new wikitext editor should not try to handle formatted pastes at all. At least, "paste as plain text" should be the default, like in every code editor in existence ever.
I tried doing the revert today and it seems that T161177 is actually still fixed if we revert those.
Actually, the fix caused another issue: T178612: The label of FieldLayout aligned inline is misaligned when it has to be wrapped over multiple lines. For now I'm reverting it (https://gerrit.wikimedia.org/r/#/c/385226/); I'll look into this more carefully later.
Probably caused by rMW15adf03cba71: Fix changes list misaligned arrow. That was means to fix T176368: [minor-wmf.19] Watchlist 'Grouped by page' arrow should be aligned vertically though. Can you post screenshots of what exactly looks wrong?
This is difficult to work around in VE. Since this is fairly minor breakage, I suggest we just wait for the next OOjs UI release with the fix.
The issue was actually introduced in https://gerrit.wikimedia.org/r/#/c/381800/ (rGOJU7d6258a7043e: WikimediaUI theme: Simplify action toolbar buttons selectors), not 380546. I think we can safely revert that one. (Honestly we should stop trying to "simplify" > selectors. We previously did the same thing with rGOJUed185afb9167: ButtonElement: Decrease selector specificity, which was reverted before causing issues.)
@demon was grumbling about log spam, coming probably from this.
Wed, Oct 18
The display handling is the only concern, and that's what's causing this issue. But I don't suppose we can just delete that block and be done with it? The other styles probably already assume that .oo-ui-iconElement-icon will be hidden if there is no icon.
I've been thinking really hard about this and I'm convinced that the easiest course of action is to revert .oo-ui-iconElement/.oo-ui-indicatorElement styling to how it was in OOjs UI v0.23.3, that is, to revert commits 8e31b2f2, 6604d0f2 and e92c5f0f. This will fix this issue and return us to a known good (if imperfect) state.
Absolute positioning for ButtonElement icons/indicators seems to have been added in rGOJU99361c772c65: MediaWiki theme: Unify `padding` on ButtonElement (2017-04-06), only for the WikimediaUI theme (not Apex).
See T129521 examples of the results that never hiding dropdowns produces. This specifically:
For context, the light green area previously was not clickable and will be clickable now:
Tue, Oct 17
After the rewrite of how icons and indicators are styled (between v0.23.3 and v0.24, changes 8e31b2f2, 6604d0f2, e92c5f0f) widgets that mix in IconElement or IndicatorElement render incorrectly when nested (in the resulting DOM) three or more levels deep.
So, the root cause here is that $wgServer on Commons is set to "//commons.wikimedia.org" while arguably it should be "https://commons.wikimedia.org".
Looks like MultimediaViewer simply gets this data from the API and displays it as-is:
This will need to be backported to 1.31.0-wmf.4.
The "solid black icon" is a result of overlaying all the grey icons normally shown in the dialog on top of each other:
Same issue as T178336: In Apex theme, any iconless widget placed inside any iconed widget renders incorrectly (except with indicators instead of icons). The patch in OOUI there should fix it. You could also do a workaround in Echo like we did in VE with https://gerrit.wikimedia.org/r/384607, but the issue here is less glaring.
Mon, Oct 16
Might be, although the description there doesn't mention this specific issue. The patch there might apply to it too though. I filed T178336: In Apex theme, any iconless widget placed inside any iconed widget renders incorrectly.
That actually looks like a distinct issue, and a bug in OOjs UI itself rather than an interaction with our CSS. I'll file a separate task.
I suspect that on-wiki code which generates the pretty dropdown ends up somehow removing event handlers belonging to the CharInsert extension from the links, making them do nothing. (It's surprisingly easy to do.) It might not occur in debug mode or in other browsers depending on the order in which the two are executed (if dropdown generation runs before CharInsert, it's okay, otherwise it's not).
Fri, Oct 13
Wow, the way CiteThisPage makes this tag work is actually insane.
I often remove or edit the autogenerated section comment, e.g. when I am actually deleting the section, or inserting another section above it, or editing the last section in an article to tweak the navboxes.
You can use Shift+Enter to insert a newline without splitting the preformatted section. This is definitely a poor behavior though.
Thu, Oct 12
(And yes, this duplication sucks and it would be great to avoid it. It actually looks very doable to make the installer methods public and make the fallback skin use them, if you'd like to work on that.)
This feature is apparently implemented in two places:
- For the installer, it's in Installer::findExtensions() and LocalSettingsGenerator::getText().
- For the fallback skin, it's in SkinFallbackTemplate::findInstalledSkins() and getSnippetForSkin().
I think there has never been a bug here. I remember specifically testing this when working on the patch and it worked correctly. Now we've done exactly nothing to resolve this and it magically fixes itself?
Actually, this has already been implemented for many pages, by @Umherirrender and @PiRSquared17. For example, the change for Special:WhatLinksHere was rMW078ae9dbf5aa: Add autocomplete for WhatLinksHere subpages.
This was recently discussed on pl.wp at https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Wikinger_znowu_wszystkich_dyma.3F, I'll leave a comment there too when the change is deployed.
I scheduled the change for deployment today: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20171012T2300
The issue is also visible in our demos if you run them using PHP 5.5, which normally no one does:
Wed, Oct 11
Hmm, it seems we actually never use it at all, but that was my guess.
I've read older comments on this task again and it seems you pointed this out multiple times, and we apparently misunderstood you and thought the problem was with the edit summary field only rather than also its label. Sorry. The fix will be deployed to all wikis per the usual schedule next week (17-19 October).
Tue, Oct 10
Huh, indeed. The font my system ends up using is narrow enough for the issue not to be visible on cs.wp, but I can reproduce locally after making the text long enough. (Note that the edit summary field's width is not limited; only the label's width is.) It's weird if this changed now, I'm pretty sure we've not changed anything relevant to this. Should be easy to fix though.
I don't see the issue either. Can you take and upload another screenshot of what you're seeing now? Perhaps there's some subtle difference that would make the issue obvious to us.
As mentioned above, you can already get the desired result using formatnum:
The PHP code's behavior is apparently implemented by custom code in LanguagePl::commafy(). We don't have any such system in the JS code yet. It seems that the same code block is copy-pasted to a dozen other languages too. Perhaps there is a sensible way to generalize this.
I am not actively following the situation, but I believe we did that several times and got this person blacklisted in all major ISPs by now (although in some cases it took globally blocking all of the ISPs IP address space for a couple days before there was a reaction). Currently it seems he's using prepaid SIM cards (which can be bought anonymously) and editing via open proxies. Note that this has been going on since 2011 or so.
Mon, Oct 9
(Below is the query I used to get the numbers in last comment. Uncomment the various bits to query per-recipient vs general thanks, and blocked users vs not-blocked users.)
@TBolliger I appreciate that you're working on this but I honestly think we'd be just fine here with the simple solution of lowering the rate limit. And we probably should do that anyway while we discuss other options.
For reference, since the limitation was lifted on 3 October, I see two cases of thanks spam in the public logs (there might be more if they were oversighted)
- https://pl.wikipedia.org/wiki/Specjalna:Rejestr/thanks/TorquemadaCoteaz (14 thanks in 2 minutes before the user was blocked)
- https://pl.wikipedia.org/wiki/Specjalna:Rejestr/thanks/PanzerPapstKlanAvsran?limit=100 (57 thanks in 9 minutes before the user was blocked)
I think it's safe to say that the issue has not disappeared.
It seems to work fine now. This was probably fixed by @Perhelion in https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&diff=0&oldid=260137498.
I don't see the error anymore. This was probably fixed by @Perhelion in https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&diff=0&oldid=260137498.
Sun, Oct 8
Sat, Oct 7
Fri, Oct 6
A user account is "created automatically" when a user currently logged in on any Wikimedia wiki visits a specific Wikimedia wikis for the first time. For example, a user who has registered an account on de.wikipedia.org (and is logged in there) visits en.wikipedia.org for the first time (e.g. by clicking an interwiki link). This often explains the weird name (the names of accounts that are "created automatically" are probably in a different language than the wiki content).
This should be done not only for PopupWidget, but also for other dropdowny/popuppy things, e.g. DropdownWidget. (See comments on T107036)
I scheduled this change for deployment on Monday: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20171009T1300
Documented below is how the list of allowed file types is generated. Turns out that my "messy" and "a little annoying" were understatements and the configuration is in fact completely insane. This list may not be exhaustive, some of the entries listed below may be duplicated somewhere else (duplicates in the list of allowed extensions are ignored).
I'll figure out how to do it properly and do this one, so that it's easier for future deployers to change this setting for other wikis.