I'm not sure if this suggestion would be a good idea. The fundamental problem is that VE currently cannot tell the difference between responsive="" and responsive. From Parsoid's and VisualEditor's perspective both look the same. The suggestion might make one situation slightly better (responsive doesn't become responsive="" any more but responsive="1") but at the same time make other situations worse (responsive="" would also become responsive="1", causing more dirty diffs).

We talked about this in a larger round and decided to make it behave the same as when saving the page, i.e. nothing is inserted. This is necessary because there is usually no content to insert in place of the […] placeholder.

We talked about this in a larger round and decided to do this in two steps:

1. We change the button so it replaces the entire ref, as discussed above.
2. Later we will learn if and which edge cases exist for replacing only the sub-ref and how to solve these problems. This is out of scope for this ticket here.

I'm not sure I understand the issue. When I'm specifically editing the sub-ref, why shouldn't the replace button replace the sub-ref? As far as I'm concerned it works entirely as expected at the moment.

I was able to reproduce the underscore bug locally. When I do any edit the content of my example reference gets re-serialized as <ref>[[a_b]]</ref> in wikitext, with underscores instead of spaces. I can confirm it is caused by https://gerrit.wikimedia.org/r/1208418 and the linked Parsoid patch https://gerrit.wikimedia.org/r/1208139. Temporarily marking as "unbreak now" for the Content-Transform-Team to have a look.

It looks like only the first 10 have coordinates. I tried to strip the query down to demonstrate the effect better.
https://en.wikivoyage.org/w/api.php?action=query&generator=geosearch&ggscoord=41.8967068%7C12.4822025&ggsradius=20000&ggslimit=11&prop=coordinates

I just realized that the idea to use only the reference group + name to identify it on a page doesn't work, not even with T409909 fixed. Here, this is a valid document, split into two independent sections, both with a [1] reference.

<ref name="a">Test</ref>
<references />
<ref name="a">Something else</ref>
<references />

This is used on help pages. The only way to distinguish these is the global id, which is global per document and not reset between such reference sections.

Steps to reproduce:

• Create a minimal document with e.g. <ref details="p2" name="b">Book</ref>. Nothing else needed.
• Start VE with &debug=true in the URL.
• Show the model and enable "Update on changes" if you prefer.
• Notice that the model contains 2 internalItem for the sub-ref and the main ref, as expected.
• Now copy and paste the ref by highlighting the footnote number, Ctrl+C and Ctrl+V one or more times.
• Pick one of the duplicates and edit the sub-ref. Change it and uncheck the "edit all uses" checkbox.
• Now the model contains way to many internalItem. Multiple copies of the main ref as well as multiple copies of the original sub-ref.

In Logstash we can see that there is a nonsensical …&duration=6048009776799 URL parameter passed to the special page. I can't tell what this value is supposed to represent or where it comes from. It's neither a Unix timestamp nor a relative duration. It would be great to find the source and fix it.

This appears to be specific to sub-refs. When I try the same with main refs I get totally expected treeOps with e.g. 60 operations.

Something is duplicated internally and goes up in a logarithmic fashion. The more I play around with my example document (doing trivial things that should be linear) I can see that ve.dm.TreeModifier.static.applyTreeOperations is called with more and more treeOps. After a while there are 10000 in the array, then 20000, 40000, and so on.

During story time we decided that we need more data. The idea is to use the scraper to scan for pages with conflicting reference names.

• We are only interested in the main namespace (better: in content namespaces).
• This can only happen on pages with more than 1 reference.
• It can only happen if there are at least 2 references with names that contain spaces of underscores.
• If such a candidate page is found, the scraper should normalize spaces and underscores and then see if the list of reference names collapses to less elements than before.
• The result should be a list of wiki + page name where such a conflict is found. That should be enough. The reference names or counts don't need to be recorded.

I'm not sure what we would do to solve this other than rolling out the change in two stages: First change the consumer to be fine with the array key missing, then change the other half of the code.

This looks like old code from before https://gerrit.wikimedia.org/r/1201327 getting hit with new data. I'm not sure what to do about this. This should resolve itself when all code is updated.

@STei-WMF, yes, this is ready. Maybe something like this?

@cscott, I tried to describe the issue in my comment T384204#10488178. The problem is that the Parsoid renderer is not compatible with the legacy renderer in case the up-arrow in front of a reference list item is plain text. It appears like this was a decision made in 2015 by the parsing team (see https://gerrit.wikimedia.org/r/170936 where the createTextNode call was removed in favor of some CSS-only :before).

I'll flag Advanced-Search whenever cirrus is ready

@dcausse I'm not sure what the question is, sorry. Please feel free to close this as a duplicate of T40403 if you think it is one. Unless this is not implemented in CirrusSearch there is nothing we can do in the Advanced-Search codebase. An extra Advanced-Search ticket for something that's currently technically impossible is not useful.

(moved to T407471)

@Volker_E, can you help us here with a hint? We wonder if we are allowed to use modern ::marker CSS for the <ol> in reference and sub-reference lists? When we check CodeSearch it's still exceptionally rar (the one in Cite was even introduced by us). When we compare our compatibility matrix with https://caniuse.com/mdn-css_properties_marker it appears like it should be fine, but we are not entirely sure. Which team would be able to make that decision or help us making one?

Personally as well as in my role as an interface designer I believe the current collapsing behavior is actually good. Note that this only happens when the screen is extremely narrow. But in this situation we want as much room as possible for the content. The symbols are not so important to begin with.

Here is a minimal example you can try on Wikivoyage to see the problem:

<maplink latitude=10 longitude=20 zoom=13>[
{
	"type": "Feature",
	"geometry": {
		"type": "Point",
		"coordinates": [-122, 37]
	},
	"properties": {
		"marker-symbol": "-letter",
		"marker-color": "#ee0"
	}
}
]</maplink>

In this demo the marker is almost invisible because it is white on yellow.

I think we should propose something for the TechNews. It should say something like: On Wikivoyage wikis (the feature doesn't exist anywhere else) colored <maplink> in the article will be shown with their correct text color, instead of only their background color. The community can remove local TemplateStyles and such that currently work around the problem. However, it might be better to do this 1 month later after the relevant caches expired.

Question: Where does this …&prefix=… feature come from? Since when does it exist? How often is it used? I think I have never seen it before. I'm aware of the prefix: keyword in the CirrusSearch syntax, but this is probably something entirely different.

I'm sorry to decline this, but this is unfortunately not going to happen as presented here. Unfortunately this ticket jumps straight into presenting a solution without really explaining the issue. What are you trying to achieve? What happens when you try to use the new interface for what you want to do? What exactly are the problems, and where?

I know this is not a full solution, just to make sure this is mentioned here: https://phabricator.wikimedia.org/diffusion/EASR/browse/master/docs/adding_fields.md?as=remarkup describes how a local interface administrators can add custom fields to the interface.

Is this the same as T223694: Misleading namespace input in Advanced Search when searching with a prefix?

I can still reproduce this. It does not happen when I try to publish, but really only when switching editors.

Isn't this long solved with the Advanced-Search interface? There are predefined sets of namespaces (e.g. all talk namespaces) as well as a quick search feature. That even accepts numeric namespace ids as well as canonical English namespace names on non-English wikis.