I'm sorry for the revert. It turns out I missed the fact this only affects pages that don't have a <references /> tag. These should indeed be rare. Not only that. I can not really think of a situation where a user was intentionally using this as a feature. The auto-generated <references /> was appended to the end of the page with no separation. This either does not have any effect, or causes bug, as explained in this ticket.

What's the state of these specific tools?

• Killing Phragile sounds iffy. Are we sure we never want to use it again?
• That commons-mass-upload tool sounds like something we gave to museums and such so they can quickly upload many files. Again, are we sure nobody at WMDE still refers to this?

Just to be sure I checked again. In the German Wikipedia the message doesn't talk about "Beta" any more. The correct message is used.

I changed the wrong message. More precisely: I changed only 1 of 2 messages. The other one is now fixed as well: https://translatewiki.net/wiki/MediaWiki:Twocolconflict-split-header-hint/de

• I changed the link in https://translatewiki.net/wiki/MediaWiki:Twocolconflict-split-header-hint-beta/de already. This should be rolled out on a daily basis, as far as I know.
• I don't understand how an English message can show up if the interface language is set to German. The translation already exists, as you can see above.

I don't say the change done in the patch https://gerrit.wikimedia.org/r/585003 is wrong. The test cases do indeed make a lot more sense with the patch applied. But: This will most probably change the output of thousands of pages. Have you been able to estimate how many pages will be affected? Is this communicated? Do you plan to mention this in, for example, TechNews? Do our user bases know how to fix templates and pages that look more broken now than before?

Personally, I veto this idea. The variable still exists in a ton of code: https://codesearch.wmflabs.org/search/?q=%5C%24wgUser%5Cb. Let's please give the developers some time to notice the deprecation warnings, before we make a sniff yell at them.

Oh dear. I believe our mistake in the patch https://gerrit.wikimedia.org/r/570090 (done as part of T242899) was that we only tested 1-line references. Thanks a lot for fixing this mistake!

There is indeed one file revision without a sha1 in this file's history:
https://nl.wikipedia.org/wiki/Speciaal:ApiSandbox#action=query&prop=imageinfo&titles=Bestand:Wiki.png&iiprop=timestamp%7Csha1&iilimit=500

For reference, the example from the commit message is here: https://gerrit.wikimedia.org/g/mediawiki/extensions/CodeReview/+/master/includes/backend/DiffHighlighter.php#219.

I feel violations are relatively rare, and barely have any impact. In my opinion this does not justify creating a sniff that potentially breaks code that does have a String class.

Yes, I believe so. Short answer: It's not Wikibase, it's MediaWiki.

The browser test is done. Should we consider this done, or is there a specific cleanup you still want to do?

The question was: A lot of time values in the Wikidata database name a year only. Does it even make sense to export these as xsd:dateTime? Shouldn't we export these as xsd:gYear?

Note it was just recently that we changed the color of <code> elements in error messages: https://gerrit.wikimedia.org/r/559714. Before, a <code> element would appear black on gray, in the middle of a red error message, which made it look like it is not part of the error message. If this change was a mistake and you believe <code> should look black again, please tell us.

Relevant data collection documents:

• Investigate on Featured Templates: https://docs.google.com/document/d/1Il8zgcVsRQkRNKWe2CsAgAqt255lH0AMFefOGQHSaMw
• Investigate on Template data enhancement in VE: https://docs.google.com/document/d/1UT3adZnYcuzRd6Fas5U7vts9_BDizS46Xp-i1W8yrQU
• Investigate on Template Better Labels and help messages: @Hanna_Petruschat_WMDE?

How I would do it:

if ( !$this->cache ) {
    $this->cache = $this->longCodeThatDefinesCache();
}

I don't know, but what is bad about being enforced to split something like

return $this->cache = $this->queryDatabase();

into

$this->cache = $this->queryDatabase();
return $this->cache;

In my opinion this is way more readable. It's way to easy to miss the = in the return line.

I would love to be able to force people to do something. But this is not how people work, any it is especially not how a community of volunteers works. Sorry, but there is no way this can happen.

Finally, PM and I had a chance to talk. We decided to continue with the decision previously made (that is selecting the right side by default, as done by patch https://gerrit.wikimedia.org/r/578516), collect user input during the small default phase, and possibly change the decision before the feature becomes the default for all wikis. Main motivation for this way forward is that we want to collect user feedback for the "your side selected" solution right now, and possibly collect more user input for the "nothing selected" solution later.

Yea, please go for Phan. A PHPCS sniff for this will most probably be tremendously complicated, and still miss many places. For example, how should PHPCS know when $this->logger actually is a LoggerInterface, and not something else? How should it check the $context array in $this->logger->info( '…', $context );?

Which of the action APIs is causing this? Is it even a specific one, or all of them?

I do not know the involved CachingKartographerEmbeddingHandler class in Wikibase very well. But according to what I see in https://codesearch.wmflabs.org/search/?q=wgKartographerLiveData I suspect that:

1. I believe this is not a serious issue. Just a notice. The missing variable is cast to an empty array. From there, I believe all following code is fine with an empty array.
2. The root cause appears to be a mismatch between the code in the Kartographer extension where the variable is created, and the code in Wikibase that consumes it. Note that the variable is only created under specific circumstances, but Wikibase always expects it.

When someone is able and willing to identify the original issue, we can undo code changes that are not needed any more then. As long as this is not the case let us please, please unblock people from working on these codebases.

We also decided that for now, the default of pre-selecting the "other" side should be switch to the "your" side […]

For whitespace, we should minimize it as much as possible and add it via CSS where needed, that provides us best flexibility and lowest image data.

I wrote a longer mail about template categorization. Summary: I suggest to use the existing category tree for templates that's already maintained by the communities:

• https://de.wikipedia.org/wiki/Kategorie:Vorlage:
• https://en.wikipedia.org/wiki/Category:Wikipedia_templates

These trees might miss a lot of templates, but I believe it's safe to assume that:

• The good templates we are interested in are already categorized.
• The community will add more categories the moment they become more visible in a "featured templates" interface.

Without knowing much about the project, I would like to suggest:

• Drop the globe from all .svg images and make it a separate file.
• Don't try to crop any of the images. Leave all of them as is, including the globe, and just position the two on top of each other using CSS.

Third-parties can just not install the extension.

@JStrodt_WMDE and @Hanna_Petruschat_WMDE, personally I would prefer to turn the option around, while still using a positive wording. I find it problematic to give users an option they can use to express their dissatisfaction. ("Why is this enabled by default? I never asked for this.")

Done: https://gerrit.wikimedia.org/r/575988

Answers, in order:

The discussion mentions basetimestamp and starttimestamp. While working on Two-Column-Edit-Conflict-Merge I just learned that relying on timestamps is an outdated mechanism. It will especially fail if two edits happen the same second. Instead, I found parentRevId and editRevId, which correspond to the two parameters mentioned above, but are revision IDs instead.

Template documentation we (can) have according to the TemplateData specification:

• Plain text description of a template
• Machine-readable information which template parameters belong together
• For each parameter:
  • Label
  • Description
  • A single example for the parameter value
  • Documentation of the default behavior a parameter will have if it's not filled
  • If a UI should suggest the parameter to be filled

Note: VisualEditor on the Beta cluster is broken right now, so we failed to demo this today. I suggest a demo on Adams computer.

In the past, I liked PHP's empty() exactly because it is so relaxed. Whenever I saw something like if ( !empty( $var ) ), I was sure no unwanted empty or empty-ish value can make it to my code.

Another user reporting the same issue: https://www.mediawiki.org/wiki/Topic:Vhm2enq0u01a86i0

Sorry, I don't get what you are proposing. First, we can clearly argue that the "issue" is not an issue, but an intentional browser feature. Second, the same happens in the old conflict interface.

Current colors for comparison:

TL;DR: The description in the commit message describes a browser feature we can not change.