Change 917391 merged by jenkins-bot:

[design/codex@main] docs: Add coded typography example

https://gerrit.wikimedia.org/r/917391

In T87001#8899987, @MusikAnimal wrote:

In T87001#8899655, @bd808 wrote:

Part of me knew that csp-report would end up being the most active tool, but I wasn't expecting it to be that much more used. Time for a new round of working with maintainers to find datasources that don't violate the Content-Security-Policy to bring that down I guess.

I don't know how this tool works, but I gather there's automation somewhere to POST to the /collect endpoint. Could that be where the traffic is coming from? https://csp-report.toolforge.org doesn't even load for me, but I see https://csp-report.toolforge.org/tools does.

In T87001#8899987, @MusikAnimal wrote:

In T87001#8899655, @bd808 wrote:

The current backend doesn't have any localization system setup, but that should be possible. I think we can get away without localization for an initial implementation if needed too.

Awesome! Do you know of any Python packages for MediaWiki localization, as in something akin to Intuition? There aren't a whole lot of messages but there is a need for proper pluralization rules, etc. I also wasn't going to consider this a blocker for the initial release, but I have a feeling we'll want localization in the longer-term.

Change 926547 had a related patch set uploaded (by Wfan; author: Wfan):

[mediawiki/extensions/DonationInterface@master] Make the submethods alphabetical

https://gerrit.wikimedia.org/r/926547

Sorry, we do not use "releases" on GitHub in the same way as other projects, which is probably why it's not compatible with "Obtainium". We only have one release called "latest" that represents the current Alpha build, and gets re-created with each merge to the repository. For production (stable) releases, we just use git tags.
If you really want to use the Alpha version of the app, you can just install the alpha APK from the "latest" release, and it will show you notifications about updates automatically.

Change 920801 merged by jenkins-bot:

[design/codex@main] TextArea: Add startIcon and endIcon props

https://gerrit.wikimedia.org/r/920801

@SimoneThisDot - currently (wmf.11) the related images have a hand pointer, but they are not clickable.
In betalabs it's not possible to check - related images are not loaded due to Failed to load resource: net::ERR_CERT_DATE_INVALID.

The task description now reflects the adjustments @nayoub see as being worthwhile to implement prior to sharing the prototype with volunteers for feedback.

It looks like there are over 1000 regexes doing something more complex than matching a single domain:

Thanks for that. it didn't give me any error when I ran it :/ There might be something logically broken there :(

Fixed these onwiki...

Just to contribute some post-deployment ideas, I recently made an accessory tool to ptwiki's SBL that provides some relevant information about the inclusion of an URL, mainly the timestamp, the author of the inclusion and a link to their edits on that day (sometimes the author's explanation is a bit hollow, while their before/after edits helps providing some context about that URL).

API call PRs (Part 1)

No errors have been recorded for wmf.11 - see logstash link. Last timestamp - Jun 1, 2023 @ 17:11:27.848 for group 2 wmf.10 wikis.

In T337700#8900003, @Ladsgroup wrote:

I meant it's on windows-1252, we run iconv('windows-1252, 'UTF-8//IGNORE', $text) on it (see moveToExternal::resolveLegacyEncoding)

One of them that's causing error is here:
https://sv.wikipedia.org/w/index.php?title=Diskussion:Bardhyl_Londo&action=edit

It looks interesting:

Parsing it is fataling.

I can ask for a backup to see what exactly was stored for these entries. I'll do that on Monday.

In T335972#8897405, @jwang wrote:

@KSarabia-WMF, Is it possible to prolong the AB test by an additional 3 or 4 days? This way, we would obtain a full two weeks of data once the edit button issue is resolved.

I meant it's on windows-1252, we run iconv('windows-1252, 'UTF-8//IGNORE', $text) on it (see moveToExternal::resolveLegacyEncoding)

I dont really understand. If the rows were legacy encoded as windows-1252, why would we convert UTF-8//IGNORE to UTF-8.

Weekly updates:

• Working on iterative feedback sessions on Human Rights Impact checklist. TODOs to help craft a few and potentially do a pilot implementation with some of Diego's models
• Put together some patches for plugin to help improve quality of internal Wikipedia Search Results in anticipation of doing some testing of how well it does. Early indications are that it does just fine as ChatGPT is generally passing a standard list of keywords as opposed to the raw user question

The answer to Q3, Q3.1, Q5 and Q6 of that is that they won't be implemented in the first iteration. Spamblacklist and this special page will co-exist until all of the edge cases have been addressed (and edge cases stay in the spam blacklist in the meantime). No software is 100% ready in the first launch, doubly so one made by volunteers.

The whole thing the script did was to run iconv() on the loaded string with 'UTF-8//IGNORE' and put it back as utf-8. Either these rows were incorrectly encoded as windows-1252 or the script took a utf-8 and assumed it's window-1252. Do you want to take a look @Bawolff ?

In T87001#8899655, @bd808 wrote:

Either linking in a UI repo as a submodule or adding the UI code directly into the existing backend repo is fine with me. If we do a submodule I would recommend that we make a https://gitlab.wikimedia.org/toolforge-repos/toolviews-ui repo via Striker to hold the code rather than a personal namespace repo. That should make it easier for the next set of maintainers to manage the code.

In T337700#8899829, @Ladsgroup wrote:

When I checked for that page that got deleted in svwiktatiory, they were indeed moved by me. My guess is that they were invalid legacy encoding which would have not caused an error but when moved to utf-8, the check became strict which is fine in some cases but not all. I looked for any mediawiki page in nlwiki to make sure I won't break the wiki: T128154#8899826 I'll go and manually edit those 10 pages to fix their encoding.

Yup, I ran

echo '' | mwscript edit.php --wiki=svwiktionary --user Ladsgroup --summary '[[phab:T337700]]' 'MediaWiki:Loginprompt'

In T337700#8899938, @Ladsgroup wrote:

I just learned logging in is still broken on dawiktionary and svwiktionary. Okay, I try to figure out what's going on. First I need to unblock the logging in in these wikis

Random note:
The latest version looks weird but it doesn't error when I try to load it:

> $blob = \MediaWiki\MediaWikiServices::getInstance()->getBlobStore()->getBlob( 'tt:9469' );

> var_dump( $blob );
string(56) "Du �r nu inloggad p� wiktionary med anv�ndarnamnet "$1"."

Some more questions:

Mentioned in SAL (#wikimedia-releng) [2023-06-02T21:44:09Z] <mutante> based on T336427#8890714 pending a response, everything already copied to gerrit1003, and extra paths being added to Bacule... shell access to gerrit1001 will be removed next week

I am testing only the Second test as noted above:

based on T336427#8890714 shell access to gerrit1001 will be removed next week

I can do the patch, but I'll wait a bit for some sysadmins opinions, per this page. Thanks.

Change 926632 had a related patch set uploaded (by Superpes15; author: Superpes15):

[operations/mediawiki-config@master] [ruwiki] Add an editautoreviewprotected level protecion

https://gerrit.wikimedia.org/r/926632

I just learned logging in is still broken on dawiktionary and svwiktionary. Okay, I try to figure out what's going on. First I need to unblock the logging in in these wikis

In T338055#8899817, @bd808 wrote:

I think it would be interesting to run some comparisons using python client code to see how timings vary if we move the result sorting to the client side rather than asking ToolsDB to do the necessary file sort in its shared RAM.

which in this case is request_day ascending, tool ascending thanks to the primary key of (request_day, tool)

Hi @Kyykaarme. FTR The following groups have the autoreview flag on fiwiki: autoreview, bot, editor, reviewer and sysop, so I'll add them to the allowed usergroups. Thanks!

So I guess:

Change 926628 had a related patch set uploaded (by Superpes15; author: Superpes15):

[operations/mediawiki-config@master] [fiwiki] Limitate the use of the ContentTranslation tool

https://gerrit.wikimedia.org/r/926628

Note that MW_CONFIG_FILE shipped in MW 1.38. Per the above, individual setups are free to assign variables in LocalSettings.php from any source, including environment variables.

Based on all the info you've gathered, and comments in T325315, I think we can avoid committing a link_target entity schema for now, and just use page info fields in a redirect_target_page as described in T325315#8898609.

@Lucas_Werkmeister_WMDE Regarding SelectQueryBuilder, I believe the signature of SelectQueryBuilder::where() should already prevent use of null from passing static validation, is that right? If I understand correctly, fetchRowCount() and SelectQueryBuilder already work correctly in your example when skipping where.

@Vgutierrez Three years later, have you experienced these?

The svwiktionary rows are:

mysql:research@s3-analytics-replica.eqiad.wmnet [svwiktionary]> select * from text where old_id in (956, 1279, 4946, 5462, 9469);
+--------+-----------------------+---------------------+
| old_id | old_text              | old_flags           |
+--------+-----------------------+---------------------+
|    956 | DB://cluster27/265098 | gzip,external       |
|   1279 | DB://cluster27/265766 | gzip,utf-8,external |
|   4946 | DB://cluster27/269404 | utf-8,gzip,external |
|   5462 | DB://cluster27/269918 | utf-8,gzip,external |
|   9469 | DB://cluster27/273899 | utf-8,gzip,external |
+--------+-----------------------+---------------------+
5 rows in set (0.002 sec)

Got it thanks.

In T338069#8899884, @Pereibri wrote:

The free api worked great until now, is there an alternative if we can’t use this any longer?

Just to give some additional insight: Emails sent to emergency@ are routed into our Zendesk system and, from there, to our PagerDuty system. This ensures data consistency and (when issues like these aren't happening) that someone from the team is paged to the issue.

In T331514#8899555, @Ottomata wrote:

IIUC EventLogging does already have soft/optional dependencies […]

dancy merged https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/24

dancy opened https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/24

Change 908973 abandoned by Superpes15:

[operations/mediawiki-config@master] [ruwiki] Add 'sboverride' right to the bots

Reason:

Granted by default to the bots everywhere per T313107

https://gerrit.wikimedia.org/r/908973

+1, thank you @Pcoombe for holding down the banner fort as only you can.