Basic math on the results from https://ordia.toolforge.org/language/Q7913 show about 57 lexemes with more than one form for Romanian. This likely includes ro-md and ro-X-..

Ah, yes. There was a single user in 2024 who was adding lexemes using this language tag. There was a long discussion on @Gikü 's talk page and IIRC they eventually resorted to using ro-x-Q8209 because the intent was to refer to 19th century Romanian. Can we check if there are any ro-md entries left on Wikidata? Sparql doesn't seem to be fit for this, maybe a direct check in the dB?

The 2 things are different IMHO:

1. Everything related to mo should be deprecated, as you suggested
2. The naming for ro-md (which I'm not sure where is used) should be put in accordance to the IETF rules.

@Nikerabbit can you elaborate a bit on what information you require? I believe the purpose of the task was to simply put the naming in accordance with IETF language tags rules

':' isn't valid in filenames.

Solved by 5bc404d476a7d2fc21e76bc49e02bc0635d7637e

Fixed in 517c2c975d6ff7d7a1881c05152d4323a59275af

I picked the bot because I was testing linking to the tool from Special:Contributions and it was easy to remember. If this is just a glitch in the data, I think we can simply close the bug.

@TheDJ @Mvolz I have a patch ready for this, I just want an OK from you on the feature.

FWIW, I updated the rowiki archive page - there was a single DYK missing.

The other solution doesn't work either if "Symbols" is not selected in a previous edit. Considering the docs, could this be a regression with the editor rather than a problem with the script?

As far as I understand, the docs say it should work. I'll try the other solution from that section as well.

This should be solved now: https://ro.wikipedia.org/w/index.php?title=MediaWiki%3AToolbar.js&diff=17752944&oldid=17689874

In T423676#11842022, @Jdlrobson-WMF wrote:

Okay we reverted the change.

I want to file a Bugzilla upstream patch against Mozilla before I close this out for completeness.

Also, can you reproduce it using ?useparsoid=0 vs ?useparsoid=1 outside of the migration tool? Just to try to see if this is a bug specific to the migration tool.

Yes:
?useparsoid=0

In the example I gave, the error was thrown for image names without the namespace, so for non-files.

I am wondering whether we should add back the edits that are reverts here.

I wonder if the fact that revisions are reverted based on the same model you're evaluating might skew the results.

@cchen can you explain how does the 0.8178 threshold on rowiki matches against the 1.7% error rate @ 0.95 on rowiki reported in [[T374698#11614851]]? Did you use a different definition of false positive?

Unless of course we formally offer it as a different editor!

May I ask why you prefer syntax highlighting for code, but not for wikitext?

In T418352#11671687, @MusikAnimal wrote:

But then what do we do with the CodeMirror sub-preferences for the individual features? Do they also get separated for wikitext and non-wikitext, or should they be shared? I suppose separate, too. I know for me at least, I like line wrapping in the mainspace and no line wrapping everywhere else.

@Albacore60 can you provide more details on how do you copy? What page are you on? Do you copy the address from the address bar or from a hyperlink in the page?

In T374698#11614466, @Tchanders wrote:

Are we removing bgwiki from the analysis, or would it be helpful to compare some data from August?

@Tchanders PSS9 hasn't run since August 2025.- I believe you'll need to choose a week when the local bot run in order to do the comparison.

In T374698#11601081, @Tchanders wrote:

I'm not sure how long calling the API will take (will need to fetch all the revision IDs for a month, then call the LiftWing API for revert risk scores for each one).

@Mvolz I followed your suggestion and created a new task. Perhaps you can help me to assign it to the correct team?

This also happens for access date, see: https://ro.wikipedia.org/w/index.php?title=Justi%C8%9Bie_capturat%C4%83&diff=prev&oldid=17303163

In T376845#11132545, @Jdlrobson-WMF wrote:

in short articles with big infoboxes, where the graphs end up on the left of the infobox in desktop view.

Thanks for the example. I assume in this resolution we'd want the chart to become full width? Not sure right now if this is a template issue or the chart itself. (Note getting the responsive behaviour right here is the main challenge)

In T397086#10940120, @bvibber wrote:

Note that the generic 'sans-serif' is used at present, so may vary significantly based on browser, operating system etc.

Right. I think it's in the spirit of the request to rephrase the last requirement as "abusefilter editors should have all the rights from the lines above". If you confirm that doesn't raises more issues, I can go with that to the community.

@Dragoniez, I think we're going into too much detail here and it becomes confusing. I'm pretty sure that all the users from the community that would actually understand such details are already cc'd.

Thank you! At this stage this is irrelevant for rowiki, so we can go with "No" for question number 3.

I agree with you on the first two: yes and no.

Per the discussion here, the community would like the following config:

• anons and non-autoconfirmed users cannot see anything
• autoconfirmed users can see public filters
• extendedconfirmed users can also see public filter logs (but without details)
• patrollers and admins can see filters, logs and details
• admins can see private filters and their logs
• abusefilter editors can have full control

@seanleong-WMDE yes, it's usually instant for me, see for instance this change today: rowiki, wikidata. I suspect it is somehow related to the user, but I don't have any proof.

That is a pity! Thanks all for your help, it was worth a shot. :) Maybe you'll find more active communities which would be interested in experimenting with this.

In T407978#11298546, @DLynch wrote:

It'd be fine to change it, but since it's been the way it is for over a decade it'd probably be good to make sure there's actually community consensus to do so.

I'm not sure how to write a reliable test for this, any suggestions are welcome.

It's an oversight, working on it.

I can confirm the issue with sources exist in Romanian as well

In T214998#11165163, @TheDJ wrote:

This should make that easier and not harder, so that should be nice.

In T376845#11129252, @Jdlrobson-WMF wrote:

I think it would be helpful if people could share example URLs to charts which are working around this or would benefit from this (particularly where the axis become unreadable on mobile devices). Having more test cases will be helpful for ultimately getting this addressed.

Awsome news, looking forward to the moment we can use Automoderator on rowiki as well.

I'm tagging @MusikAnimal since he is marked as the contact person for this task.

@Xqt , why did you choose to implement this directly in Page instead of ItemPage with a wrapper on top in Page? Is it OK if I move it?

Function already existing in class Page