This indirectly caused issues in API sandbox, see T128054.

The hack comes from T74338: VisualEditor: [Regression pre-wmf5] Scroll bar is appearing while opening a link inspector and might no longer be needed. First, it seems that we no longer have anything with partial opacity in any inspectors (in neither of the current two themes). But even when I tried setting some opacities and removing this hack nothing seemed amiss. And I just ran into a superficially similar issue that has been fixed in Blink (https://gerrit.wikimedia.org/r/275676).

Works for me, on https://he.wikipedia.org/w/index.php?title=מלון_אורכידאה&action=submit&section=0 (random article).

There was, on Thursday, as usual. The following works for me now on the English Wikipedia:

I don't think that would be a requirement. (But if you want to take a stab, this is T117736.)

I was thinking of something like themeStyles, yes, although I guess making the theme name available as a Less variable would also work (there's a couple of ways in Less, involving mixins, to switch on variable value).

So… @IKhitron, how is it now?

(UploadWizard already doesn't work on IE 9, I just tested. You can't even choose a file (clicking the button does nothing) and when I fixed that, I got exceptions from somewhere deep inside. I didn't try debugging further than that because due to T49277, debug mode is broken on IE 9, and its debugger doesn't really work with minified scripts.)

Looking at https://developer.mozilla.org/en/docs/Web/API/File https://developer.mozilla.org/en/docs/Web/API/FileReader https://developer.mozilla.org/en/docs/Web/API/FormData – we'd be dropping IE 9 and maybe some mobile browsers.

Mehhh.

Yeah, I guess. There was a bug that caused VisualEditor to damage template syntax of infoboxes and similar templates. This bug is now fixed, but may still affect templates until they are purged.

Thursday has barely started in the US :) The deployment which should bring this change to Wikipedias should begin in a few minutes: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20160303T2000

This should be fixed by rECHIb2f7c4c507e5: Remove inline event handler js from charinsert (it's not live yet). Please reopen if this is still occuring after the 1.27.0-wmf.16 deployment next week (see https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap for dates).

This was done in b2f7c4c507e54dbcb1e629699ec5941ac7019660.

I'm not sure why this would come back, but I'm pretty sure it'll be fixed for good by the recently-merged rECHIb2f7c4c507e5: Remove inline event handler js from charinsert (it's not live yet). Please reopen if this is still occuring after the 1.27.0-wmf.16 deployment next week (see https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap for dates).

Backported to wmf.15 and will be deployed to Wikimedia wikis this week, per https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap.

No idea how/if we can fix the rule, but I went ahead and fixed the current violations in the affected files: https://gerrit.wikimedia.org/r/#/c/274478/

(Related: T89860: Buttons on login page are inconsistent with the policy of "only one primary button"; make the sign-up button non-primary [duplicate?])

Well, in that case, you can't make it non-primary without switching away from mediawiki.ui first (T85853: Convert MW core login/create account pages to OOUI (Special:UserLogin / Special:CreateAccount)).

I think the design has changed a lot since this task was filed, and it no longer applies. The page looks like this now:

Worth a user-notice too?

There's another patch at https://gerrit.wikimedia.org/r/#/c/272731/ which has a -1 right now.

I can't reproduce this issue. I was able to upload some files from https://www.flickr.com/photos/cogneon/albums/72157629426826348 locally. What's the actual file that was being uploaded? (Flickr URL please?)

I can't reproduce this problem. The given URL (https://www.flickr.com/photos/cogneon/albums/72157629426826348) correctly loads all images for me, locally and at https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard (I don't have the permissions for this at actual Commons).

I'm really not convinced that we'd want this, sorry. I think we'd want to teach new users that they have to fill in the author and source themselves, and not that it's prefilled. And for experienced users uploading many files you already only need to fill it in once.

Probably not. The text should match the "lang" attribute of the tag.

Reduced test case: https://jsfiddle.net/c9532md5/2/

UploadWizard only increments the last number present in the file name, that is not longer than 3 digits, appending one if there's none. So you could easily work around this by inputting "6 Nations 01" or "6 Nations 1" as your first file's name. I don't think we could implement any better logic for this (at least not without breaking somebody's workflow).

Vaguely related: https://gerrit.wikimedia.org/r/#/c/273980/

In T128380#2076265, @Sjoerddebruin wrote:

I think the same is happening on the image statement on this Wikidata-item, but it doesn't happen every time.

@ssastry Can you verify that the above is going to play well with Parsoid? I don't have the development version set up, and the APT one seems to be lagging behind.

So… TemplateData actually defaults to 'inline' if this parameter is not specified. (It's even documented: https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/Specification.md#316-format.) That's very wrong.

That change (which would make it work) is not live on Wikimedia wikis yet. It should be deployed this week with MediaWiki 1.27.0-wmf.15, according to the schedule at https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap.

What about this edit? https://pl.wikipedia.org/w/index.php?title=S%C5%82oneczny_patrol&diff=prev&oldid=45176454

This caused T128337 and T128319.

Not really, we're Editing/Multimedia, with stress on the Editing. Someone might overrule me, but this doesn't look like something that matches the team's purpose, and it doesn't look like something that anyone on the team has experience with.

In T121936#2072785, @Pginer-WMF wrote:

"Catalan Wikipedia" in this sentence means the actual Catalan Wikipedia. But "Easter Island" means the article about Easter Island, and not the actual Easter Island.

Another similar case was with usernames in messages like "Cronopio and 3 others left a message in your talk page". There usernames were representing users. Is there anything that was done in those cases that could be of help here?

Argh, we renamed that module…

MediaWiki code in Article::showRedirectedFromHeader() just does this:

I can't reproduce this issue locally. It must be some kind of a problem with Wikimedia wikis' configuration (messed up short URLs? :P).

The actual URL is produced by the PHP code in Article::showRedirectedFromHeader() (search for 'wgInternalRedirectTargetUrl') and it's wrong there. The JavaScript code in mediawiki.action.view.redirect.js just blindly uses it.

In T121936#2071580, @Pginer-WMF wrote:

First, I'd like to understand the details of the issue. Given the following two sentences:

• "More messages from Catalan Wikipedia and 3 other wikis."
• "Links were made from Easter Island and 3 other pages to Moai." Why the former is problematic but not the later (or similar ones we currently use in bundles)?
  
  Would mark the wiki names (in quotes or bold) for the sentence context help to make them more as literals that do not require to "blend" into the sentence grammar?