Since our goal is simply for fawiki to match the behavior of enwiki (so that the templates and modules we import work similarly), this can wait for T346052 to be resolved. If that resolution reverts enwiki's behavior to one in which subpages are not enabled in the Category namespace, then this task can be closed. If in the end it is decided that since some templates and modules on enwiki already assume this as enabled, it is better to leave it as "enabled", then this task will need to proceed too.

@Chuiimuii_ofc consensus was achieved.

In T398361#11411826, @IKhitron wrote:

In T398361#11411089, @Huji wrote:

@IKhitron as for the placement of ~, I wonder if using dir=ltr is the right solution. Specifically, I wonder if wrapping the element in <bdi> would be sufficient (and preferred).

Thank you for your help, @Huji. I've read some documentation about the bdi tag, and debugged some special pages. And I have a question. Wouldn't it be better to enclose any user name with bdi, not just temporary accounts? It is done in Special:Watchlist, and it prevents problems in names like User:John-, which is not forbidden in Mediawiki, as far as I could find the restrictions for special characters in usernames.

Same.

@IKhitron as for the placement of ~, I wonder if using dir=ltr is the right solution. Specifically, I wonder if wrapping the element in <bdi> would be sufficient (and preferred).

Reopening this task, as the issue (of sometimes not being able to proceed with an action (of marking edits as reviewed) even if having the right continues. Latest case is fawiki user Fotrus. I had to grant him "reviewer" right as a workaround,

@Chuiimuii_ofc I cannot understand where this is enabled for enwiki. The config file doesn't show it being enabled for Category namespace (14) for enwiki.

@Chuiimuii_ofc yes, and @Jeeputer is already soliciting consensus on that (link)

@STran I had also scheduled it for today, in an earlier time slot. It was just merged.

Gotcha. I can try to help with that.

It would be nice if we could get a code review on the patch, to hopefully be able to restore the September-ish timeline for next annual election at fawp

Local consensus has been achieved to move forward

Awesome!

@Xqt This would be a great chance to fix an old problem in constant names and documentation of pywikibot: 1, 2, 3 and so forth are not Latin digits, they are Arabic numerals. Latin numerls would be like X and I and D.

Persian (fa) is all set

In T396690#10920121, @Mooeypoo wrote:

I think it might be a reasonable assumption (and @Huji can let me know if that's also true for Farsi and Arabic?) that if the x-axis has labels in the RTL language, then the graph is USUALLY aligned RTL, and if it has mathematics/statistics intent, it USUALLY is aligned LTR -- but even that is non consistent in at least Hebrew and Arabic, and I suspect Farsi as well.

Already works

The change has been drafted. Discussion is ongoing on fawiki about the specifics, but so far it seems like the community is in agreement with using the same config as enwiki. I will mark the change as active for review once local consensus has been achieved.

I keep occasionally getting pinged about this general topic on fawiki. Various users there are envisioning a lot of value from having LLMs helped with translation, template editing, etc. Has there been any progress here? Has the OSI certified any of the open models?

Should this be closed given T194697 in core?

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Thanks for your followed up. I would argue that the phrase "The provided authentication token is either expired or invalid." does not mean "something went wrong with the redirect back to the local wiki" and so a separate message should be created and displayed in such circumstances.

The part I didn't know and Bugreporter educated me on was that deletion happens automatically after 40 days from archiving. So yes, all set here.

Thanks. Definitely reassuring.

There is a flaw with this proposal. Specifically, the part that says "if there's no edit conflict" cannot be asserted done in an automatic way.

I added myself to help with Persian. I also think the wrong Matej was tagged by @ppelberg above; @matej_suchanek is the on who should have been tagged.

That would still be an issue for larger pages. I ran a bunch of quick tests using a JS implementation and it can take several seconds to several minutes to simply compare two consecutive versions of some of our larger pages (I took some featured articles as examples). It is possibly that a PHP implementation running on Wikimedia cluster would be faster the running the JS implementation on my modern laptop, but even if it were to be 10 times faster, it would still be in the many seconds range which is not acceptable. Recall that AbuseFilters need to run completely before the page can be saved.

If someone decides to implement these (either Dice-Sørensen coefficient, or Levenstein distance, or something else) and is in need of some test cases, I have an idea for that: on Persian Wikipedia, we reglurly create redirects to articles where the redirect is only different in the use of certain characters. Specifically, the Persian standard keyboard uses ی yet non-standard keyboards may use the Arabic ي instead, and same goes for standard ک and non-standard ك so for a page with title یاک (مجارستان) you will also find a redirect titled ياك (مجارستان) created. If one runs edit distance or string similarity algorithms on fawiki article titles and main namespace redirects, they should be able to find those redirects quickly. One could even calculate performance metrics (sensitivity and specificity) for the implementation of the algorithm by assessing how many of the redirects it found, and how many other titles/redirects did it find and score highly that were not a correct redirect.

This is the second time I have seen issues related to deprecating mw.Uri and replacing it with the native URL(). May I propose that someone writes a guidance for it?

Temporarily elevating the priority, because many users across many wikis use that gadget and lost the functionality today. Please reduce priority once the issue I just reported is fixed.

@WikiBayer in this edit you broke a widely used gadget. Specifically, your edit on line 517 which changed var url = new mw.Uri(); to var url = new URL(); is causing an error, because the native URL API requires at least one parameter to be passed to its constructor.

The most extreme version of it happened today, when I made an edit and literally 10 minutes later, the wiki forced me to log in again. All I did was refresh the page in the tab that was open since my edits.

FYI it keeps happening every few days, at random times.

No. Thanks!

It happened again. And similar to last time, it resulted in me having to log in again. Duration of inactivity was around somewhere between 12 and 13 hours in both of these cases.

@Tgr it happened one again. This time, it didn't log me back in when I clicked on the login link. I had to properly login with my username and password. The duration of inactivity was only around 12 hours. I have updated P73705 accordingly.

In T386621#10596343, @Amire80 wrote:

In T386621#10595810, @Huji wrote:

For #4, I don't agree with Amire80's suggestion. What third example of such "technical names" exists that is neither a URL nor an email address?

Email addresses are probably the most common example by far, but there are other kinds of small pieces of code. In the MediaWiki world in particular, these can be API action and parameter names (in the API sandbox), parser functions, and configuration variables. In particular, the names of the latter two begin with # and $, and these characters "jump" to the wrong side of the word if explicit direction is not set.

Instead of mirroring, we could use "directional mirroring".

@MusikAnimal I need your help with tests/phpunit/unit/includes/watchlist/WatchedItemUnitTest.php which fails as a result of the change I proposed in the proposed patch. I cannot figure out how to modify the unit tests such that it would not expect the value to be provided as a direct parameter to the msg() function, but rather, as a parameter passed through the numParams() method.

Ah, it gets more complicated! Note that I was logged out when I refreshed the page. I clicked the login link, and instead of going to the login page, it logged me in! This is different from the last time I had this experience (that time, clicking on the login link took me to the login form).

@Tgr it happened again. I have provided some details in this private paste: P73705

Thank you for tagging this task with good first task for Wikimedia newcomers!

In T387061#10576766, @Tgr wrote:

Thanks for reporting! Are you willing to do some debugging around this? If you could provide the exact timestamp for the last logged-in request and the first not-logged-in request, I could check if the logs contain anything useful.

May I offer a different perspective? While it is pretty clear that we want "programs" run on WMCS to meet OSI requirements, it doesn't have to be the case that the AI model itself would run on WMCS. We are using other capabilities in Wikimedia projects that relies on external resources that are not OSI compatible. For instance, we use Google Images and TinEye to perform reverse images searches. The piece of code that refers the user to them is on WM projects (a JS in MediaWiki namespace on Commons) and meets OSI, but the underlying service doesn't.

@Amire80 this may be something you can quickly take care of. I am away from my development machine for a while.

@bd808 for posterity, a larger list is also available at https://github.com/eugeneyan/open-llms and maybe one of them is or at some point would be OSI compatible.

@Andrew you did not make a mistake, but we do have a problem. No matter which of the 4 OS choices I pick, the choices for the configuration only allow me to pick up to 8GB of RAM. The ones with higher RAM also have higher CPU cores, beyond the quota of this project.

I think that may address part of my issue and I will look into it. However, articles are indeed the majority of pages (and the largest volume) from that dump, so when it comes to the subsequent analyses I want to run, the RAM limitation may still apply. Even then, it is possible to run the analysis on a machine with less RAM and let the programming language handle it by use of page files/temp files; it will just be significantly slower.

In T381198#10383844, @Trizek-WMF wrote:

As I understand it, you want to move fa:ویکی‌پدیا:درخواست راهنمایی/Flow to fa:ویکی‌پدیا:درخواست راهنمایی. I want to make sure that you are not trying to revert the archiving process we applied to remove Flow from the wikis.

Thanks for this analysis. With this in mind, what is the next step? Should we add fawiki to $wmgFlowEnableOptInBetaFeature?

I am okay with being closed as dupe. It would be worth noticing here (and echoing in the other task) that the wikis involved where on two different server clusters (enwiki is on s1 and fawiki on s7). Shouldn't circuitbreaking issues only impact one server cluster?

I also think "start" and "end" is better than "inline-start" and "inline-end". After all, these are allowed values for the align parameter; align=center and align=start read well, and align=inline-start is too verbose with no real advantage.

I suspect CI is hitting a false positive here. The $wiki variable is effectively sanitized by the if/else statement above. That said, I'm not sure what the best path forward is.

Or it could be pivoted into a long format (one row for each property, as opposed to one column for each property).