URL to logo is also incorrect.

Deployed!

Deployed!

This issue also occurs with MediaWiki 1.39, so it should be reflected in that version as well, since it is still supported.

In T406424#11245724, @Ladsgroup wrote:

Biggest point would be what to do with log rows. I thought we had something since FR has been undeployed from many wikis before but I can't find anything.

This looks much better now.
{F65719446}

Finally completed!

In T399450#11001915, @Umherirrender wrote:

In T399450#10999969, @A_smart_kitten wrote:

Possibly a regression from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1132176? /cc @Umherirrender

The return type is correct when looking at the documented return type of LocalFIle::getUpgraded, but that function returns null instead of false. Init LocalFile::$upgraded with false can do the same job.

In T399450#10999746, @gerritbot wrote:

Change #1169076 had a related patch set uploaded (by Zoranzoki21; author: Zoranzoki21):

[mediawiki/core@master] rebuildImages.php: Update imageCallback return type

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

In T398737#10976143, @BlankEclair wrote:

If you configure it such thta only logged-in users can read it, then alllwing previews would leak its contents for logged-out users, no?

Of course, why not.

Deployed

In T396102#10886901, @lihaohong wrote:

It probably has to do with the following js. It doesn't do anything with client-darkmode if the user is anonymous. @Kizule would it be fine to execute the if ( darkMode ) statement for both anonymous and logged-in users? This change works on my local testing environment, but I'm not sure if the code is the way it is for some other reasons.

if ( mw.user.isAnon() ) {
        // If the user is anonymous (not logged in) write a cookie
        mw.user.clientPrefs.set( 'skin-theme', darkMode ? 'night' : 'day' );
} else {
        // If the user is logged in write with API to user settings
        new mw.Api().saveOption( 'darkmode', darkMode ? '1' : '0' );
        if ( darkMode ) {
                docClassList.add( 'skin-theme-clientpref-night' );
                docClassList.add( 'client-darkmode' );
                docClassList.remove( 'skin-theme-clientpref-day' );
        } else {
                docClassList.add( 'skin-theme-clientpref-day' );
                docClassList.remove( 'client-darkmode' );
                docClassList.remove( 'skin-theme-clientpref-night' );
        }
}

In T395257#10856830, @A_smart_kitten wrote:

At a glance, looks like the same issue as T394052: Unable to create a patch demo wiki that includes the Chart extension: `npm run build` fails with "missing script", which was merged into T372083: Add Chart extension config to PatchDemo (Charts doesn't work on patchdemo)

In T394739#10842617, @Nikerabbit wrote:

Latest version of the patch:

In T394739#10837891, @Nikerabbit wrote:

The file is incorrectly formatted, so server side import would give the same error. Here is the full error:

exception.ERROR: [b35af8a474f9e65a2f9e2cea] /wiki/Special:ImportTranslations   RuntimeException: Unable to parse msgstr:

msgctxt "s_project_delete_msg"
msgid "Are you sure you want to delete project \"%1$s\"?<br>This will also delete %2$s attached issue reports."
msgstr Da li ste sigurni da želite da obrišete projekat \"%1$s\"?<br>Ovim će biti obrisano %2$s prijavljenih problema na njemu."

Side note: I recommend against moving things to columns, as we triage from the backlog and may miss tickets that have been moved already.

In T393402#10833560, @Nikerabbit wrote:

Executed

php maintenance/run.php ./extensions/Translate/scripts/poimport.php --file ~/mediawiki_sr-el.po --user KizuleBot --really | tee ~/T393402.txt

Here is the output for review:

T393402.txt781 KBDownload

Here are the changes:

• https://translatewiki.net/wiki/Special:Contributions/KizuleBot

In T393402#10826104, @Nikerabbit wrote:

twn:/www/translatewiki.net/docroot/static/temp$ sudo /srv/mediawiki/workdir/maintenance/run /srv/mediawiki/workdir/extensions/Translate/scripts/export.php --group=mediawiki --offline-gettext-format="%GROUPID%_%CODE%.po" --lang=sr-ec,sr-el --target=. 
Exporting group mediawiki
twn:/www/translatewiki.net/docroot/static/temp$ ls -lah
total 25M
drwxrwxr-x 2 betawiki users 4.0K May 15 14:58 ./
drwxrwxr-x 7 betawiki users 4.0K Feb  5 15:58 ../
-rw-r--r-- 1 root     root   13M May 15 14:58 mediawiki_sr-ec.po
-rw-r--r-- 1 root     root   13M May 15 14:58 mediawiki_sr-el.po

You can download from https://translatewiki.net/static/temp/mediawiki_sr-ec.po

In T392745#10771086, @Djido wrote:

Message clearly says "100% of text is not translated". At least, there is a bug to imply that there is no translation at all. It does not say "100% of paragraphs are not translated".

All paragraphs are marked as _not translated_, even if they have no English words. Actually, all yellow-marked paragraphs are _all_ translated. There is no chance that tool can judge _quality_ of translation. Why they are all marked as "untranslated" when they do not contain a single English word?

This is not a bug. The message doesn't mean that everything is not translated (the whole page), but paragraphs marked with a yellow line.

I still believe we should move forward with this. We already have Special:BrokenRedirects and Special:DoubleRedirects, so adding Special:UnusedRedirects would round out the redirect‑management suite and eliminate the need to maintain a standalone ~188‑line extension.

I didn't know much back in 2017, so I'm making things right in 2025.

Feedback would be very welcome, as it seems that I did something wrong, and at the moment I'm unsure what exactly.

In an effort to fix these deprecation warnings:

(Moving assignee to the author of another patch), @Aklapper, please correct me if I'm wrong. Thanks!

It's not archived. It just has to be added back to translatewiki.net and that's it.

I don't see why not. :)

Let me try this (thanks @adrelanos for giving me an inspiration).

Not happening

No longer happening + MediaWiki 1.35 is EoL.

I forgot to assign this to myself, sorry.

Also, the default is the correct one, so I guess in case this gets done, we'll be able to move users' preferences to the correct format just by dropping the date rows in the user_properties table.

I'm reclosing this task, as it looks like that this is working now.

https://cxserver.wikimedia.org/v2/translate/mk/sr/Google shows Cannot GET /v2/translate/mk/sr/Google.

I'm facing the same issue again, but with mk to sr. But this time Yandex and others are working, just not Google (which provides better translations than the others).

Uh, oh, it looks like this is happening for nearly all logs.

This is ready now.

In T374778#10212890, @MGChecker wrote:

I just took care of it.

(ping for @hashar or someone else to take a look at my last comment)

It looks like that this is solved in T368594: CVE-2024-47845: Extension:CSS uses CSS sanitizer incorrectly, and is easily bypassed.

I'm going to handle this.

Yup, it's working now. Thanks!