Duplicate of T427698: VisualEditor doesn't show non-breakable space symbol, only HTML mnemonic?

In T427201#11953691, @Bugreporter2 wrote:

Was the failure to capitalise "English" and "French" in the report an attempt at irony?

In T426545#11929063, @kostajh wrote:

@KieranMcCann-WMF does this work Active blocks from all wikis: 1 (including on this wiki), or is it too wordy?

Would it make sense to run a bot to replace all on-wiki usages of tright and tleft? Are there edge cases to be mindful of?

Is there a limit to the number of TextMatchEditCheck that we can add?
On frwiki, we have https://fr.wikipedia.org/w/index.php?title=Wikipédia:Liste_de_fautes_d%27orthographe_courantes&useparsoid=0 which is a list of common typos and https://fr.wikipedia.org/wiki/Wikipédia:AutoWikiBrowser/Typos which is the setup page for corrections to automatically apply when using AutoWikiBrowser.
Both these pages are pretty long (about a thousand lines each), so would it cause issues to make TextMatchEditCheck for everything mentioned in them?

I think what would be easier to use, since categories are also added through templates, would be custom tags that behave like <nowiki> or <includeonly> tags in the outline page and these tags would then be automatically removed inside articles.

It hasn't happened for some time. I close as resolved.

As a user without abusefilter status, I still have the CodeEditor view of AbuseFilter. Is it the expected behavior?

I cannot get https://abstract.wikipedia.org/wiki/Q90 to properly load. I always see "Reached max retries. Try again later."

It is only true for JSON pages. Both JS and CSS pages can have categories from JS or CSS comments.

It currently isn't possible to find Orange when searching for Orange (color), so users currently always expect their input to be replaced with a matching item.

I would personally expect the title to be fully replaced with the title of the selected Wikidata item—either to complete or correct the input—while preserving any disambiguation written in parentheses.

Refreshing the page is often enough to make the page go back to normal:

I don't think that is consistent with the other task

No, I really feel like there has been a recent regression. It never happened before (MediWiki:Common.css was not served on mobile devices) but now it regularly happens.

As I wrote, this is a separate issue unrelated to useformat=mobile

It seems that there is still an issue in the case of many templates aggregated together including at least one template redirect, which causes Uncaugth (in promise) missing in ve.dm.MWTransclusionModel.prototype.callTemplateDataApi and makes the edit page unusable. Try editing the infobox of https://fr.wikipedia.org/wiki/Elfie_(téléfilm) for example.

In T421859#11784426, @ABreault-WMF wrote:

There is a minor issue though that the mw:DisplaySpace span in the .cdx-button gets a gap: 6px applied to it, making the space between the text and question mark unreasonable. It can probably be fixed by adding gap: 0px; to the inline style set in {{bouton cliquable}} but maybe there's a better option

In T419171#11766430, @Jdlrobson-WMF wrote:

I believe all the subsequent sections ARE editable. Am I missing something? The screenshot doesn't match with what I currently see in production...

In T421539#11760465, @Izno wrote:

Does it have to be someone else's subpage

Yes. You can just about always modify your own user space.

I cannot reproduce (diff and test), Does it have to be someone else's subpage, or CSS containing rules not allowed in sanitized CSS? Or maybe it works for me because, on frwiki, interface admins do have editcontentmodel right.

editcontentmodel is a sysop right, not an interface admin right.

In T384685#11720749, @ExE-Boss wrote:

In T384685#11676043, @Escargot_rouge wrote:

There isn't any templatedata for Template:Template link general, so there is nohing to expect to be loaded from templatedata for the redirect either.

Actually, there is: https://en.wikipedia.org/wiki/Template:Template_link_general#TemplateData

In T420323#11717649, @Bhsd wrote:

I guess this should be a feature request for Parsoid instead of CodeMirror? CodeMirror has no control of lint errors produced by Parsoid.

Preventing the editing of subscribers would likely prevent mentioning, since mentioning someone automatically adds them as a subscriber.

Is this really needed? It is already possible to set a default expiry using MediaWiki:Ipb-default-expiry, which is often set to infinite, MediaWiki:Ipb-default-expiry-ip and MediaWiki:Ipb-default-expiry-temporary-account. This also offers more granularity since what is wanted for temporary accounts is a 3 month expiry and not an indefinite one.

I find it confusing that it is only a prefixed search. I expected to easily find all items in my watchlist with titles containing "(film)" or "(20XX film)" by searching "film", but in fact it doesn't work and the search returned nothing.
It should be clearer in the UI that it is only a prefixed search.

It doesn't exist because it can be done by targeting any right that only logged-in users have, like viewmywatchlist.

In T413912#11697518, @Jdlrobson-WMF wrote:

A fix has been deployed. Menus seem to be working correctly now. let me know if that is not the case!

In T78171#11696250, @Tacsipacsi wrote:

In T78171#11688181, @Spartan.arbinger wrote:

frwiki rcu

What does “rcu” mean?

Advanced menu has been broken by this. It lost many of the additionnal links it offered like RecentChanges link.

Auto-linking is also not available in 2017 editor, as written in https://www.mediawiki.org/wiki/Extension:CodeMirror, but I'm not sure if it's in the scope of this task.

In T419187#11683296, @AlexisJazz wrote:

• Use a form of FlaggedRevs for .js pages in MediaWiki: namespace that requires any edit to be approved by someone else. The "someone else" doesn't have to be an interface admin, just any other user who is considered trustworthy.

Logs could still be useful in revert mode when a community is debating changing the cautiousness level.

I don't see what prevents User:CompromisedInterfaceAdmin from updating your common.js so that it downloads their version of a gadget after they infected it.
For this to be useful, you need more assumptions about what interface admins are allowed to do on users common.js.

This is a regression that started yesterday after MediaWiki update.

In T414395#11676159, @MusikAnimal wrote:

In T414395#11676131, @Escargot_rouge wrote:

Ideally, I'd want to be able to enter the wish directly in English and in my own language, without having to wait for an admin (I'm not sure what right exactly is required) to make it translatable.

It doesn't ever need to be made translatable, per se. We even have automatic translation now :)

You can write your wish in whatever language you want, and whether or not it is set up for human translation is irrelevant. Translation administration is a complicated process requiring human intervention. For end users, it's not something you need to be concerned about.

Ideally, I'd want to be able to enter the wish directly in both English and my own language, without having to wait for an admin (admin or some other status, I'm not sure what right is required here) to make it translatable.

There isn't any templatedata for Template:Template link general, so there is nohing to expect to be loaded from templatedata for the redirect either.

Removing Tag DiscussionTools as it just happens to be triggering a refresh and the issues lies in VE code.
https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/b01e9b000c5ae5680501e5dbd51302aefa2cebc9/modules/ve-mw/preinit/ve.init.mw.DesktopArticleTarget.init.js#907 is clear about it.

In T418352#11672138, @Bhsd wrote:

In T418352#11672058, @Escargot_rouge wrote:

The current situation is already odd. It is not obvious at all that if you want linting in wikitext, you have to enable syntax highlighting.

This works exactly like CodeEditor. Ace syntax highlighting is required for linting.

In T418352#11671687, @MusikAnimal wrote:

For example, the preferences dialog in CodeMirror is called "Syntax highlighting preferences", and one of those preferences would be "Syntax highlighting" itself. And heck, the button itself in WikiEditor says "Syntax". I think it might seem odd to turn that on and it not provide syntax highlighting (though the user would have to configure it that way themselves, so maybe it's okay?).

In T402598#11660321, @Pppery wrote:

I don't like the idea of this. First off I've never seen the point of non-admin iadmins, but also this has absolutely nothing to do with the core responsibility of interface admins (editing CSS and JavaScript)

Might be the same kind of issue as in T247241: In VisualEditor, creating unpiped hyperlinks then italicising or bolding them forces a piped link.

You have to click the "Syntax" button to activate CodeMirror.

In T417733#11626295, @VedHades wrote:

A simple right rotate icon svg.

The option should be called something like "hide transclusions" rather than "hide templates". The latter formulation suggests that the option is limited to concealing template pages themselves, whereas the actual functionality the wish asks for is about filtering out any page for which all links to a given page are transcluded through a template.

It would be more convenient if {{#isredirect}} is an alias of {{#isredirect:boolean}} instead of an alias of {{#isredirect:local}}, since the main use case would be inside an {{#if:}} statement and {{#if:{{#isredirect}}||}} feels more natural than {{#ifeq:{{#isredirect}}|true||}}.

The resize bar appears on mobile, but it doesn't seem to do anything. Dragging the bar just scrolls up and down as it would with any non-interactive content.

To be clear, I don't think I will ever want to change the size of the edit window on mobile. I personally would prefer it to be removed than to have it actually resize the window.

This happens when a discussion takes place outside of a talk namespace and without __NEWSECTIONLINK__ magic word. This isn't the result of a recent change, it has been this way since the release of the new version of the reply button.

This is normal lua behavior. pairs is not expected to keep the order unlike ipairs.

This task was resolved by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1213958

I noticed that bracket matching is incorrect inside regex: escaped brackets are matched with unescaped brackets. I do not know if it should be corrected or if bracket matching should be disabled inside regex.

In T201233#11551573, @Wellverywell wrote:

@Jdlrobson-WMF user @Bezik on Russian Wikipedia has reported that this is actually a breaking change.
In any theme (MinervaNeue, Timeless, Vector-2022), any browser (Firefox, Vivaldi), without user CSS, when increasing browser scale/decreasing window width any punctuation marks after formulas go on the next line. Example on this page:

I've investigated this issue and pinned down that it's due to commit https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1154054. What I think is happening is when window width goes below @max-width-breakpoint-tablet, width: 100% is activated even for .mwe-math-element-inline elements, which makes them non-inline, and the punctuation mark goes off. In my opinion that style should not be applied to .mwe-math-element-inline elements.

In T415206#11544198, @Bhsd wrote:

Some templates can have custom parameters, so it is difficult to recognize "non-existent" parameters from TemplateData.