We had a similar situation with Minerva.For the Minerva skin we have useskin=minerva but the skin name is Minerva Neue.

This would be a lot of work and I'm not sure worth that work given the limited audience that is intended for useskin (primarily developers). I also think it might create more confusion than the status quo.

Currently, skin keys right act as IDs so making useskin=vector-legacy work suggests that we would need to add aliases for this to work and that in turn would likely need changes in ResourceLoader and various other places which might lead to more confusion - for example someone might expect MediaWiki:Vector legacy.css to apply CSS to the legacy Vector page if useskin=vector-legacy works or to be able to add skin=vector-legacy to a ResourceLoader URL.

I could see value in this if skins are intended to be translated but currently they are not.

I am not (currently) convinced that this is worth the effort it would entail.

I'm not suggesting aliases. I'm suggesting that if you have MonoBook in preferences then any invalid value in useskin= should display in MonoBook. useskin=vector-legacy was just an example of an invalid value. It could also have been something random like useskin=hippopotamus.

Ah I see. Thanks for clarifying. I guess it could also render an error?

An error message seems too drastic to me unless it's just added at the top and the rest of the page still displays. But an error message sounds like more work, especially if there are translations. I would be satisfied with invalid useskin just being ignored. Without knowing the code, that sounds simple to me.

By the way, uselang behaves similar to useskin: If the value is invalid then it falls back to English and not the user preference.
If you for example select "es - español" at https://en.wikipedia.org/wiki/Special:Preferences then https://en.wikipedia.org/wiki/Example?uselang=hippopotamus displays with English interface and not Spanish.
The fallback is also English in non-English wikis. If you for example select "es - español" at https://de.wikipedia.org/wiki/Special:Preferences then https://de.wikipedia.org/wiki/Example?uselang=hippopotamus has English interface, not Spanish and not German. I think the fallback for invalid values should be the user preference for registered users and the wiki default for unregistered users, meaning an invalid uselang is just ignored.

This doesn't appear to be related to ResourceLoader or a compontent currently stewarded by MediaWiki Platform.

The uselang parameter is interpreted by MediaWiki's RequestContext class, and from there passed to Skin, OutputPage, ResourceLoader, and various other components.

The default of "site default" means that when you share a permalink, the parameters you set have a deterministic behaviour. If I share /wiki/Banana is uses your personal language and skin choice. If I share /wiki/Banana?lang=x&skin=y it will instruct the system to try to use X and Y. Whatever the result is, you'll get the same when I share it.

It also means that interpretation of these variables does not involve a cross-dependency to the user database and user preferences system, which seems desirable for making the system easier to reason about unless and until there's a value-add from approaching it differently. When making such choices you always give up other choices, it isn't "free".

I appreciate that when first trying something random in an unknown system, the result may not be as you expected. However, there is no way to meet that expectation for everyone as not everyone will have the same initial reference frame and expectation. I don't see any particular reason why, when providing an invalid value, a default of "user preference" is any more or less intuitive or expected, than a default of "site default".

Either of those seem sensible expectations. I imagine most will never know because they won't enter an invalid value. If you do, it becomes self-apparant quite quickly as indeed the task author learned as well before writing this task.

I'm leaning towards declining this as I don't see a problem or benefit from changing this. My general stance is that, when changing something and it becomes equally likely for someone to file the opposite request tomorrow, it may be better to decline it.

With regards to knowing the correct value, I think you make a good observation that these are hard to discover. we want to make these IDs easier to discover, perhaps we could list the IDs like vector, vector-2022, minerva on Special:Version or something like that.

In T370144#10268504, @Krinkle wrote:

With regards to knowing the correct value, I think you make a good observation that these are hard to discover. we want to make these IDs easier to discover, perhaps we could list the IDs like vector, vector-2022, minerva on Special:Version or something like that.

You can go to the skin selector on Special:Preferences and click on the preview links. Not sure if that qualifies as easy to discover; still better than Special:Version though.

In T370144#10268504, @Krinkle wrote:

If I share /wiki/Banana?lang=x&skin=y it will instruct the system to try to use X and Y. Whatever the result is, you'll get the same when I share it.

If somebody shares a link with useskin= or uselang= then they problably tested the value is valid. Invalid values are more likely to come from users typing a url for themselves and then it doesn't matter whether others will see the same. If they do share something invalid then maybe it's the parameter name which was invalid like your lang=x which will render in the user preference language because it didn't say uselang.

I don't see any particular reason why, when providing an invalid value, a default of "user preference" is any more or less intuitive or expected, than a default of "site default".

I think the normal software reactions to invalid input are error, ignore, or "random" if the software isn't coded to detect it's invalid and react. Expectations may differ but this looks like "random" to me, especially when uselang= doesn't actually fall back to the site default but to English as my earlier example showed.

But the whole thing is not a big deal when invalid values are probably rare and most users probably detect something is wrong and fix it. Thanks for commenting.