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?

@Escargot_rouge it might be challenge to use a bot as you'd need to be careful not to overcorrect. For example you wouldn't want to update "upright" in a paragraph of text that read "The train had 43 passengers onboard and remained upright when a lone car went off the track." For example you wouldn't want to update "outright" in a paragraph of text that read "Their house was destroyed outright by the fire"

Fixing instances like https://fr.wikipedia.org/w/index.php?search=insource%3A%2F%5C%3D%28tright%7Ctleft%29%2F&title=Sp%C3%A9cial%3ARecherche&profile=advanced&fulltext=1&ns10=1&ns828=1 would be more straightforward to do manually.

For a bot you'd need to carefully think about the right regex to run :-)

@Jdlrobson-WMF I have added an entry to tech news. Please check it out. Please add a line on what the impact of this change on people's workflow will be.

Should the same be applied to tnone? Used e.g. in Module:Multiple image.

In T426452#11942114, @STei-WMF wrote:

@Jdlrobson-WMF I have added an entry to tech news. Please check it out. Please add a line on what the impact of this change on people's workflow will be.

Adding this to tech news is nice. But it is very unnice that MediaWiki 1.47.0-wmf.3 including the change that has dropped these classes was rolled out before that issue of tech news could even be published. This, for example, broke many things in ruwiki without any warning.

In T426452#11927793, @Escargot_rouge wrote:

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?

Here's how you can do it using Pywikibot and AWB:

1. Download your wiki's dump on MediaWiki Content File Exports. For enWP in May 2026 it'd be those 19 files.
2. Use [^a-zA-Z0-9]t(?:right|left|none)[^a-zA-Z0-9] to find tright/tleft/tnone. Here's the full Pywikibot code that creates a list of such pages.
3. Filter the list. It shouldn't contain pages having e.g. 'Archive' in their titles, and AWB helps do that easily. It might be reasonable not to launch the bot in non-main namespaces automatically but to instead check every edit.
4. Use AWB to replace 'tright' with 'floatright': \bt(right|left|none)\b → float$1.

There are also cases like t{{{align|right}}}. You can use the standard wiki-search to find them manually: insource:/t\{\{\{/. These should be changed to float{{{align|right}}}, which will work perfectly in the majority of cases.

In T426452#11933884, @Jdlrobson-WMF wrote:

@Escargot_rouge it might be challenge to use a bot as you'd need to be careful not to overcorrect. For example you wouldn't want to update "upright" in a paragraph of text that read "The train had 43 passengers onboard and remained upright when a lone car went off the track."

That concern is not really relevant here — in the example given, there isn't even a textual overlap with tright to worry about. And generally, doing a straightforward value substitution across a large wiki is quite manageable.

What @Escargot_rouge was asking about are the deeper implications. For instance, on frwiki I quickly noticed that {{Diagramme d'échecs}} (Module:Échiquier) receives tleft/tright values directly from articles and passes them through as-is. That said, this particular case is straightforward to fix — the conversion just needs to happen inside the module.

The deeper concern, though, is that limiting the search to the Template and Module namespaces is far from sufficient. Over time, these classes have made their way into many other places across wikis, and that is what makes cleanup genuinely painful when changes like this are made in MediaWiki.

This is reminiscent of the image markup change, where classes such as thumbinner, thumbimage, thumbcaption, and others were defined by the old MediaWiki markup — and over time, editors started using them directly in articles (which was incorrect). When the new markup was introduced, those editor-added classes were left in place across wikis but stopped working. Cleaning them up is largely manual, difficult, time-consuming work — and realistically, there is not enough manpower or motivation to do it thoroughly.

Apologies @MikhailRyazanov This was meant to go out a week before the change and there was a miscoordination. Apologies for not giving more of a heads up.

@Niepodkoloryzowany There should be no impact on tnone class.

@Od1n I corrected my example, thanks for flagging that. Regarding image markup, this is still supported. T318433: Templates (and extensions) that mimic parser media output need migration to new structure is the ticket for that. I understand it's slow time-consuming work, but these interfaces are not covered by the https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend and we need to balance this with evolving the codebase and user experience. As noted in the task description if you need more time you can copy these rules to MediaWiki:Vector-2022.css to achieve that goal.

This change has broken instant preview and regular preview. Go edit https://en.wikipedia.org/wiki/Template:Traffic_volume_top in code editor. The table has class=floatright, but the class is unknown to the browser and the table is shown on the left.
Edit https://en.wikipedia.org/w/index.php?title=Mississippi_Highway_69&action=edit&section=1, changing
{{tv-t|name=Mississippi Highway 69|align=left}}
to
{{tv-t|name=Mississippi Highway 69|align=right}}
No effect, both previews are broken.

Note: This change has probably broken the portal template on certain wikis. cf. discussion on zhwiki Village Pump.

In T426452#11957798, @Ponor wrote:

This change has broken instant preview and regular preview. Go edit https://en.wikipedia.org/wiki/Template:Traffic_volume_top in code editor. The table has class=floatright, but the class is unknown to the browser and the table is shown on the left.
Edit https://en.wikipedia.org/w/index.php?title=Mississippi_Highway_69&action=edit&section=1, changing
{{tv-t|name=Mississippi Highway 69|align=left}}
to
{{tv-t|name=Mississippi Highway 69|align=right}}
No effect, both previews are broken.

These tables are working fine for me in Preview, showing on the left and the right, respectively. I recommend you take this issue to WP:VPT on the English Wikipedia for troubleshooting.

@Jonesey95 That's strange, this is what I'm seeing in the preview output of https://en.wikipedia.org/wiki/Template:Traffic_volume_top:

The class floatright is there in <table>, but on the right Firefox does not seem to know about it.
What decides when the classes will be delivered to the preview?

This https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-ActivelyDisinterested-20260522161000-Odd_behaviour_of_multiple_images_template might be the same issue I'm having with the preview.

My editor is... ugh, after all these years I do not know what to call our editors (how sad!): it's the one that has instant preview on the right. And my browser is Firefox for Linux.

In T426452#11959617, @Ponor wrote:

The class floatright is there in <table>, but on the right Firefox does not seem to know about it.
What decides when the classes will be delivered to the preview?

I believe it's because the CSS is loaded conditionally (I8fd10c). If you request a "live preview" (whether that of 2010 or 2017 wikitext editor) and these specific styles have not been loaded on the current page, the CSS needs to be "attached" to the page so that the page displays correctly. Perhaps this is a general problem of the "live preview" feature.

@matej_suchanek That's what I thought, until:

Just now, I was logged in with my bot account in a separate "container tab", and https://en.wikipedia.org/w/index.php?title=Mississippi_Highway_69&action=submit&section=1&safemode=1 and "Show preview" (the button next to "Publish changes") had the table on the left side with text wrapped around; switching to align=right moved the table to the right.

With my main account, the table is on the left, with no text wrapping around – in Firefox for Linux, Firefox for Android (desktop view), and freshly installed Chromium.

I played with many settings, I used &safemode=1, but to no avail.

Same broser tab, "split view": my bot account on the left, my main account on the right

What do you see there?

I also can't replicate this @Ponor

It does sound like an issue with WikiEditor (2010) which I am not too familiar with. Since you can replicate could you open a bug and I'll try and find the right people to talk to about that. I suspect it might not be loading associated JS / CSS modules correctly somewhere in the pipeline.

@Jdlrobson-WMF I think I got it: I had the "Show preview without reloading the page" GLOBAL setting on. When I switched it off (Set a local exception for this global preference), the instant preview in the right-hand panel was still bad, but "Show preview" worked as it should, and that also fixed the instant preview. (I shut down my browser after changing the setting, not sure if that was necessary)

It'd be nice if someone here could confirm and tell me which component(s) to open a bug for. Both "Instant preview" and "Show preview without reloading the page" should load the associated CSS modules.

If you create the bug report with replication steps, subscribe me and tag WikiEditor (2010) and Realtime Preview I'll make sure it gets to the right place (sounds like the "Show preview without reloading the page" was important)