I am well aware of how Vector 2010 works, but Vector 2022 is supposed to be an upgrade, just occupying space on the other side of the page is not an upgrade.

Agree with Jonesy95. This is not a feature if you have to scroll up to find it every time you want to use it.

@Tacsipacsi, thanks for the suggestion. I generally just create the new section title, add content until it goes wonky, save and continue editing using the regular editor which works fine

It may be the same bug but my experience differs in that it happens to me after a copy-paste and possibly differently after cut-paste of simple text from within the open edit window. When the cursor jumps it cannot be persuaded to stay in the right place for further editing if that editing includes a shift key as the first keystroke. I have to add the text at the top and later cut and paste it to where it should be. It is happening on Firefox with both windows 10 and 11. Once it has started, I have not found any way to make it stop other than cancelling the edit and starting again.
It happens with the new section tool (A new way to start topics...) and with the reply link.

I will check T302147 and report back

Is anything further likely to happen with this?

Am I correct in assuming that <policy domain="resource" name="width" value="32KP"/> is the one and max width is limited to 3200px? (similar for height), so I will have to manually resize and upload the image under another name if I need a larger image for zoom in details?
Misread that. 32KP =>32000px, so not a clue which default is limiting.

Thanks for the reference, but I do not know how to identify the relevant limits from that listing. I am trying to work out what maximum size of image I can specify that will return an image, so I can consider work-around options.

What are the default limits as set?

See also discussion on Commons at https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&oldid=634388957#Resolution.

Just to get a sense of perspective here, how many of those 20 000 edits were fixing problems caused by VE?

The generation of meaningless, easily confused ref names happens, it is a frustration to editors trying to maintain the integrity of sourcing, therefore it should be fixed. By all means pay someone to do it if the volunteers don't want to do it for whatever reason. This is one of the fundamental reasons for the WMF's existence, and the annual fundraising.

Who has the authority to upgrade or downgrade a priority?

What will happen if you want to use @ for another reason? Email addresses are the obvious example, but there could be others too.

As far as I can see no-one has answered RexxS's question. Is it likely that anyone here can actually do that?

Try suggesting a ref name based on the available parameters and requiring the editor to confirm that it is a reasonable choice or substitute their own choice. Start with "last1 year", add a, b c etc to disambiguate, use title if no author listed, then website, then ask editor, or just ask the editor to name it in the first place and disambiguate with a, b, c if necessary.

These names bother a lot of people who spend their time cleaning up the mess left by others using visual editor, which is a waste of editor time and generates resentment of visual editor. Is it really that difficult to generate a meaningful name and then check that it is unique in that article?

I agree with AfroThundr3007730 on the probable usefulness and scope of this request. Cheers, P

Fair enough.

If we were to add noreplace to all template inclusions, will it have any adverse effect. or should this wait until you are done?

Suddenly it is clear! Thanks for that explanation. Like a figure and ground problem, it depends on how you first look at it..

"if there is an invocation without noreplace, that takes precedence over the noreplace ones."
If I understand this correctly, we must add noreplace to any magic word that can be replaced, and leave it out for the one which must not be replaced, which is a bit counterintuitive based on the apparent meaning of the string.

I am happy to see some action here. Is there an explanation somewhere of how this will work, so we can plan ahead? cheers

This is worse if people use a bare magic word (not encased in the short description template), so the short description does not show using css as it has allocated class. The upside is that these have mostly been added at the bottom of articles, the downside is that this may not always be the case, which will require special searches to find them. This is already a maintenence problem. Who knows how many more hassles it will give us?

Sounds like it might work. I guess we will need different templates for manually added short description and auto added short description.

a) What side effect?
b) Confusing to whom? As it stands it is confusing to the people who have to use it, and may require complicated work-arounds to get it to work usefully. These will be a huge time-sink for the people who are writing the encyclopaedia.
c) This is the task for creating this magic word, and the task is not finished until it works effectively for its purpose.
c) How do you suggest we make this thing work?

The short description stored is the one from the last instance of the magic word SHORRTDESC found on the page. This is problematic and it would be preferable to store the first instance found on the page. This is a bug. Please fix

It does not look like I am going to get a reply, so will have to open a task to have it fixed without knowing how practicable it is

Fine, that is now clear to me. Thanks for clarifying
Is my question now sufficiently clear to get an answer?
(I dont know how {{DISPLAYTITLE}} and {{SORTKEY}} work, or what noerror and noreplace do)

OK, got it. So the problem is that the last one is stored, where it would be more useful if the first one was stored. It would seem that there is a routine that runs through the whole page, changing the value each time an instance is found, instead of stopping as soon as the first instance is found?

If there is more than one short description on the page the API call gets the last one. It would be far better if it got the first one, as there are a large number of pages where there is a default short description generated from a template or infobox, but for some of these a hand crafted short description would be better, which would be at the top of the page, so that is the one that should be used