tided description up a bit. No reason for solution to be enwp specific.

This is unrelated to design.

it is enwp specific ... as other languages do not tend to have ft in ?

In T294707#7470243, @Aklapper wrote:

This task basically requests manipulating and replacing the text displayed on a page, in both directions. What to display when printing, when editing the page?
I'd say anyone is welcome to write a user script or gadget and try to maintain a list of regular expressions that potentially match and replace strings, and deal with its false positives and number formats etc, but this is not something to implement in MediaWiki core.

We do things like that with the gender magic word? Why can't something like that be introduced for measurements?

In T294707#7470245, @ThurnerRupert wrote:

it is enwp specific ... as other languages do not tend to have ft in ?

Only because it's mostly Americans who still use imperial and British for speed but that's a topic for somewhere else.

@RhinosF1: Hmm, is there a gender magic word in the actual content of main namespace wiki pages which alters the display for only some users and not for others?

@tstarling - as promised on facebook, here a task for measurements.

In T294707#7470249, @Aklapper wrote:

@RhinosF1: Hmm, is there a gender magic word in the actual content of main namespace wiki pages which alters the display for only some users and not for others?

Not in main namespace but it's used for varying content of a lot of notices to users. It's also used by a lot of i18n strings. (It may be more common in other languages so I'm not the best to give examples as English doesn't vary words based on a gender).

This is what bothers me here: It's the main namespace. :) If this was implemented, what's the canonical content to edit and why is there suddenly different text when editing the page compared to what I was viewing before? That's why it rather sounds like gadget territory to me...

In T294707#7470255, @Aklapper wrote:

This is what bothers me here: It's the main namespace. :) If this was implemented, what's the canonical content to edit and why is there suddenly different text when editing the page compared to what I was viewing before? That's why it rather sounds like gadget territory to me...

My theory in my head is that you'd have something like {{MEASURE|1ft|1m}} (yes, not accurate conversions). I would assume defaults would be set like any preference and someone would have to work out which is best (Research?). I'm not sure how we could do automatic conversions but {{MEASURE|ft=1}} could also work. We have numerous magic words that effect page content. My only concern would be increase in parsercache as you'd need a new variant to be saved.

Given @tstarling has supposedly asked for a task to be created in an offwiki discussion, maybe we should wait for further feedback?

This won't and shouldn't be done. It's basically equivalent to the auto-date formatting that was already removed a decade ago.

This can be resolved onwiki with some sort of user script or gadget.

I don't think it should be just declined. It's a reasonable request.

It's not simple, though. A quick way is probably to make a gadget, as @Izno suggests, but in the longer term, the best way to do it is actually an extension and not a gadget. Such an extension can include the functionality of the Convert template, which is one of the most frequently exported from the English Wikipedia to other languages, and user preferences to go with it.

In T294707#7470263, @Izno wrote:

This won't and shouldn't be done. It's basically equivalent to the auto-date formatting that was already removed a decade ago.

This can be resolved onwiki with some sort of user script or gadget.

tim mentioned his date formatting experience on facebook. i recall that i could not set my preferred format, and then turned it off again. i cannot even recall if i was too lazy to tell anybody why i turned it on and off. for height there is no one million possibilities, different case therefor.

OP was told at enwp WT:MOS that this was undesirable, a concept which has been rejected many times over decades. Articles always give quantities in multiple units simultaneously (usually SI and US Customary, plus other systems as well where appropriate), and the ONLY question is which unit gets pride of place by going first, and which follows in parentheses -- some articles do it one way, some the other. It's absolutely absurd to think that giving the user a way to switch which unit comes first is somehow useful.

There are real things that all wikis are waiting for developer time to be spent on, not this bikeshedding. If time is spent on this it will be a magnificent example of perverted priorities.

for height there is no one million possibilities

There are a bunch: https://en.wikipedia.org/wiki/Unit_of_length . Next preferences then could be Celsius vs Fahrenheit vs Kelvin, stones and pounds vs kilograms, lakhs and crores vs millions, etc. I don't think adding more such preferences outweighs the additional maintenance costs and code complexity for years to come.

One of the chief arguments against date autoformatting was that the only way to make it work was for the user to set a preference. Since the vast majority of readers were anonymous (not using an account) the change would only serve a small minority of readers. The main effect would be to conceal poor choices, which would be visible to most readers but invisible to the editors who would be in a position to fix the poor choices.

In T294707#7470311, @Aklapper wrote:

for height there is no one million possibilities

There are a bunch: https://en.wikipedia.org/wiki/Unit_of_length . Next preferences then could be Celsius vs Fahrenheit vs Kelvin, stones and pounds vs kilograms, lakhs and crores vs millions, etc. I don't think adding more such preferences outweighs the additional maintenance costs and code complexity for years to come.

true, @Aklapper , there are others. but popular ones are rare. therefor the suggestion to try with a simple one, and restricted reach, if it can be made so that it does not get in the way? where the default is UK height editors can choose to use a slightly different notation to let a property kick in in case the user sets it. if no preference set, display as before. pick 5-10 links where it could be tried, like michael jordan, mohamed salah, jordan pickford, manuel neuer.

In T294707#7470354, @Jc3s5h wrote:

One of the chief arguments against date autoformatting was that the only way to make it work was for the user to set a preference. Since the vast majority of readers were anonymous (not using an account) the change would only serve a small minority of readers. The main effect would be to conceal poor choices, which would be visible to most readers but invisible to the editors who would be in a position to fix the poor choices.

tim was so kind to provide the task to remove it: T31472. what i recall that i switched it on and off the personal preference for english language at that time. i set it to ISO and it was slightly too aggressive for my personal taste, but i cannot remember details. my personal software engineering view is that friction free date formatting in wikipedia is nightmarish. too many variants, exceptions, and preferences.

While changing a content page's content output directly based on a user preference could be problematic, components of the interface could still make use of this. For example, Special:Nearby currently only outputs in meters; but could leverage such a preference to provide this computed value in a localized unit of measure. (c.f. T53584)