Can we decline this, please, along with https://gerrit.wikimedia.org/r/355368? I mean, what is even the problem we are trying to solve here? array_map( function ( $x ) { return $this->format( $x ); }, $array ); is close to being unreadable. Enforcing it to be formatted as

array_map( function ( $x ) {
    return $this->format( $x );
}, $array );

or even

array_map(
    function ( $x ) {
        return $this->format( $x );
    },
    $array
);

is a really good thing, in my humble opinion.

Yea, sorry. Chromium. Version 71.0.3578.80 (Official Build) Built on Ubuntu , running on Ubuntu 18.04 (64-bit).

should we create the logs as we import each revision or should we create all the logs once at the end of the import process?

Just a mistake, sorry, @daniel. The one I wanted to point you at is T211473.

There is already a class:

:target .mw-cite-targeted-backlink {
	/* customizations go here */
}

While it might be possible to make an educated guess based on heuristics that might turn out to be true or not in the individual case (e.g. just assuming Windows-1251 will most certainly be correct in the vast majority of situations), no code can know what I meant when I manually type …?title=%86%96%96. It might even be EBCDIC and decode as "foo" then.

The issue with the statement "the conflict resolution screen already is a diff" is this: It's a diff the users are not familiar with. As a user I want a way to release myself from the limitations of the conflict resolution screen provided by the extension, and continue working in my familiar environment. I want a button to accept the current selections and continue editing in whatever wikitext editor I was using before. There I would then have access to a diff as usual.

I don't see what value a single, arbitrary "industry" example has. The user input is 100% wrong. There is no "right" way to make sense of it. Every "industry leader" I try does something different. GitHub does something different than https://www.google.com/search?q=a%01b, Google does something different than https://www.facebook.com/search/top/?q=a%01b, Facebook does something different than https://twitter.com/search?q=a%01b, …

Short answer: It's impossible to "guess" the "right 8-but character encoding". It would be wrong to assume anything.

An actual incident report (in addition to the Google doc) is published now: https://wikitech.wikimedia.org/wiki/Incident_documentation/20181107-TwoColConflict

I was very curious and found this is actually a core bug in the mw.Uri module. Unfortunately I wasn't able to find the correct Phabricator tag yet.

@Lea_WMDE, the problem is that all we currently have in the FileImporter configuration is a base name for the CommonsHelper2 configuration pages. In our specific setup this base name is Extension:FileImporter/Data/. We append the abbreviated domain name, e.g. en.wikipedia, and expect to find a page via https://www.mediawiki.org/w/api.php?action=query&titles=Extension:FileImporter/Data/en.wikipedia, which is then either found or not.

@zeljkofilipin, whoops. Thanks for the hint. I changed the access rights for the document. An incident report will follow.

Ah, thanks. For your information, on https://spenden.wikimedia.de/?skin=0 with the current Firefox the text is not selectable.

Either my original test was with a slightly older Chrome version, or the donation interface changed in the meantime. It had nothing to do with the cursor. It really was not possible to select the text. Unfortunately I can not test this any more because I have neither access to the older Chrome any more, nor to older versions of the interface.

I played around with a few styling options. The little "b" is what is relevant in the following examples.

.mw-cite-backlink a sup {
    padding: 0 0.3em;
}
.mw-cite-backlink a:target sup {
    background: rgba(0, 110, 255, 0.3);
    text-shadow: 0 0 1px #fff;
}

The idea is to apply the padding to all these small letters (they are barely clickable with the mouse anyway), and add the color to the relevant one.

The patch https://gerrit.wikimedia.org/r/474893 will have a few effects:

• The two messages "Jump up" and "Jump back up" will be visible to every user as a mouse hover tooltip, when hovering the up arrows. This was not the case before.
• Some up arrows will say "Jump up", some others will say "Jump back up".
• "Jump up" will be the tooltip for up arrows that are always visible (on references that are only used one time).
• "Jump back up" will appear dynamically on references that are used multiple times. For these, the up arrow will only become clickable (and this will include the tooltip) when the reference got highlighted.

We briefly discussed this today and we think:

• We definitely should not add aria-labels and keep the old "hidden spans" code the same time. This might lead to the situation that screen readers read the text twice, which is almost as bad as having no label.
• I checked and there is barely any code in core that uses aria-labels: https://codesearch.wmflabs.org/search/?q=aria-label%5Cb. Some extensions use it much more extensively. I, personally, think we should follow and start using it. Following a standard is just "the right thing" to do, isn't it?

I had a brief look at this and found this is, technically, not a Cite but a MediaWiki core issue.

Note that in the English language currency units are typically in front of the number (e.g. "€ 21.48"). This is different in the German language, where the unit must be after the number (e.g. "21,48 €").

That's sad. :-( But thanks a lot for replying so fast!