@Aklapper Could this be some new form of hostile bots? All the accounts (@Hkrishr @nandhinibalaji311 and @Yashk2000) have zero other activity here as well as zero edits on all wikis.

Works for me too. Maybe browser specific? @Lea_WMDE You're testing on which browser?

I assume the confirmation-promt ist behind the fullscreen-plane. (Wrong z-index)

@Lea_WMDE: Not sure what you mean. I'm talking about the edit-mode. There the textarea is always 6 lines high:

Note: maybe this is already the case but just not for the simulation-page!?

@Pikne The communities are free to set up the configs as they want! This ticket is to make sure the new change is reflected in the configurations where the community has not yet started taking care of the configs.
The idea is also to remove GFDL from the list of "good"-templates, but not add it to the "bad"-templates. This way they can be still moved to commons if they are marked with any other "good"-template – so one could also have a template "Suitable for commons" (several wikis have this already) that if present allows to move the file but will be automatically removed from the wikitext by the fileimporter.

This has been deployed and is enabled in all Wikis. Please note that wikitext diffs are cached for up to 7 days. Therefore it might take a few days until old diffs get regenerated.

Maybe horizontal lines could mark the point where the diff is split?

So, the namespace does exist and it does contain entries.
But searching it seems not to work. Maybe this is the reason it's hidden in the default search?

I think this was fixed by:
https://www.wikidata.org/w/index.php?title=Template:Archive_index/text&diff=prev&oldid=718392127&diffmode=source

@Lea_WMDE There was an alternative suggestion from the community, to implement a fallback to using the configs of enwiki if none are found. The background is that a lot of (but not all) small wikis import the templates from enwiki as an start. link

@Lea_WMDE Can't reproduce it anymore, seems fixed.

here is another, clearer example of the change:
old & new

@Lea_WMDE You now closed this ticket as resolved but you also closed T196647 as duplicate of this ticket, it's content however is not fixed yet. Should we reopen it?

Note: I could reproduce this with several other files (in deed all files on dewiki I tried).

In T194505#4379057, @Pikne wrote:

Currently prefilled edit summary for this is in importer's interface language. I suppose wiki content language (English for Commons) would be preferrable instead.

@Tonina_Zhelyazkova_WMDE The situation is much better now but there is still a small bug:

So is this fixed now with T192019#4134117 ?

The box around the icon - does that also appear when syntax highlighting is off? i.e. when you click that button and it goes to the "off" state, do you still see it protruding outside the toolbar?

After further digging: The page isn't zoomed but my Chromium if set to "fontsize = big" in the settings. When setting back to normal it works. All other icons work however with all fontsize-settings.

@MichaelSchoenitzer_WMDE Is the page zoomed in or out beyond the standard zoom?

Chromium <s>& Firefox (both)</s>, Linux, Vector

@Lea_WMDE Not sure if this is a duplicate of T194644.

Edit-summaries may contain (a reduced set of) wikitext, including links. So the URL should be formated by:
[https://de.wikipedia.beta.wmflabs.org/wiki/Datei:Munich.png https://de.wikipedia.beta.wmflabs.org/wiki/Datei:Munich.png].

Screenshot of german Wikipedia:

I can confirm, it does not happen anymore on both devices. Probably fixed upstream or by accident due to some other changes? Closing.

When importing files from commons to test.wikimedia.beta.wmflabs.org this does not work. I don't get any link and the usernames are prefixed with imported>. Is this expected behavior?

The by far most interesting option is to search for a specific P31. For example to search for humans (P31=Q5). In the user interface there could be a parameter "instance of" with either a dropdown containing the most common values of P31 or a wikibase-entityselector allowing to search and select an arbitrary item.
If the user selects human the backend would then search for haswbstatement:P31=Q5.

Is there an estimation when this will deployed?

I also think the 'x' to remove the pills are to big in monobook.

@mforns Nice work – thank you for sharing! Another exception that should really be subtracted to avoid false-positives: If there is a P1889 (different from) linking two items. this will eliminate only a much lower number of false-positives – but a set of very important ones: items that also look identical to humans if not paying enough attention!

This is not a bug in Advanced search but in the search site in general – but it's probably getting more common and contraintuitive with advanced search.

Maybe a solution would be to move it to the right as on Vector-Skin?

The JS-Console shows an error:

Duplicate of T194590

Tested, seems to work as intended.

This is fixed.

This is the example I tested: [[ https://de.wikipedia.org/w/index.php?search=deepcategory%3A%22Friedhof+in+K%C3%B6ln%22+-deepcategory%3A%22J%C3%BCdische+Trauerhalle+in+Deutschland%22&title=Spezial:Suche&profile=advanced&fulltext=1&advancedSearch-current=%7B%22namespaces%22%3A%5B%220%22%5D%7D&ns0=1&searchToken=6yxr52xcaltx0i9yk1o39am2u | deepcategory:"Friedhof in Köln" -deepcategory:"Jüdische Trauerhalle in Deutschland" ]] (on dewiki).
It will find only the one page in both categories but none of the categories in all of the first but not the second category (should return 20 results).