Thanks. One of the demos (the version on doc.wikimedia.org/oojs-ui) is working fine now.

It does appear in the list, but using the German name Formulare. Is it possible that you have overlooked this?

Settings on MediaWiki.org:

• Selected: Show me both editing tabs
• Enable the visual editor and the new wikitext mode in Structured Discussions (enabled)
• Enable the editing toolbar (enabled)

Thanks, that still doesn't work but you're right it's a new issue.

Ctrl-option-e (Mac), formerly used to edit or view the source of a page, is not working in Mozilla Firefox either, although it works in Chrome. Could that be due to a conflict with some feature native to the browser? Or is it a bug in MediaWiki?

I like the suggestions by @RobinHood70 and skizzerz about preserving linear parsing as part of a 'legacy' content model (which can then be adopted on the level of namespaces and wiki pages) and by @alex-mashin about the possibilities of forcing a preliminary step of linear parsing through a parser function. Especially since like @Megajoule and many others, I'm anxious about the future of my wikis and would be a little unhappy to see fifteen years of work go to waste.

Thank you all for moving the discussion forward. As a bit of 'power user' of Variables myself, in conjunction with other extensions (Parser Functions, Arrays, Semantic MediaWiki, etc.), I can certainly add to the list of use cases.

Sometimes double-clicking a token, with the intention of editing it, results in the removal of a token, which isn't really helpful.

Thanks @Bawolff for the explanation as well as the workaround - hardly something I would have thought of!

It makes sense to restrict the envisaged 'usedebugtoolbar' permission to sysops or bureaucrats by default. It would be a breaking change so that's why I made the suggestion but I'm fine with either approach.

I'm not sure how much discussion we still need. For a smooth transition, I'd say: if the toolbar is enabled, show it to all users by default (current situation) and offer a config setting to tie its visibility to specific user rights.

Speaking on behalf of a lot more people than just myself, this is certainly one of the most impactful and enduring issues that I've had to encounter since last year, although much has been improved.

Alright, thanks - it's a no-go then.

In 1.26 we are on line 1035 for this.

Could this be related to T153618 ?

okay, thanks for working on this

Experiencing the same issue following an upgrade to MW 1.28 (on a Windows machine). The version of SMW I'm using is recent, however (2.4.4).

FWIW, ICU's collation demo has a setting for numerical sorting: https://ssl.icu-project.org/icu-bin/collation.html

Shouldn't we wait until VPS hosting or cloud hosting is at least in a comparable price/budget range as shared hosting today? Not to put too fine a point on it, not being able to upgrade could be a personal disaster. I'm running a large and complex site with Semantic MediaWiki (my main reason for sticking with MediaWiki) and forty-odd extensions - Composer is used to install some of these locally before the files are transferred to the remove server. $10 a month is still an awful lot of money to me so the costs of relocating would be forbidding I'm afraid.

Task created: T86959

Thanks Cicalese for your speedy reply!

I'm using SF 3.0 (SMW 1.9, MW 1.22) and the mapping template still does not work with such input types as "combobox", "tokens" or "text with autocomplete". This may be due to certain issues with "combobox" and "tokens", because in some cases they autocomplete on the wrong category.