Hi Aklapper,

This problem is not solved in MW 1.28.0. For what I know this is bug related to sitemap, which was not solved for at lest three years. Sitemap list all language varietals with same priority, which cause Google index them randomly.

The file with name [[File:クローサー-ザ-ザ-チェインスモーカーズは-ハルシー.ogg]] was not loaded during test. It was wrote there just for an example.
Most developer here, as a community heavily dominated by American/European, generally treat Asia/Middle East writing system together as "something they don't use". In most of bug that I found related to languages, bugs related to any single language of Chinese/Japanese/Korean will be problem for others. (The only exception is bug in the Traditional Chinese and Simplified Chinese conversion system.) Arabic might have problem as well. Germanic/Romance languages tend to have less incompatible, since most of developer master some of them expect English. Solving incompatible bugs related to languages generally don't need developer master those languages. Don't simply avoid language incompatible due to hardness of language itself or due to that language lack of global Influence. Instead, developer need to be aware of coding/transcoding with language they don't use.

Mediawiki 1.27.1

I can confirm this happens in my wiki after upgraded to MW 1.27.1.

This might be a bug related to the $wgForeignFileRepos ForeignDBRepo class incompatible, where MW randomly refuse to load some/all ogg file remotely (and mp3, mp4 file if $wgMediaHandlers['audio/mpeg'] = 'Mp4Handler';). However, I can't reproduce the exact sutation where only file with Japanese or Chinese file name can't be handle properly.

Cool, thank you @matmarex . --pages=existing,nonexisting work well. Hope the --pages=existing,nonexisting become the default value for refreshGlobalimagelinks.php, which will make life easier for everyone.

In T150165#2776487, @Aklapper wrote:

Is "Param pages required!" the literal output on the screen, or is that a translation to English for this bug report only?
I don't see any such message in the GlobalUsage code base...

With these two posts, I understand that this bug does not affect commons wikimedia (where all machine have access to files).

Ha, this is strange. I will test newer version MW with TimedMediaHandler. Problem might exist in php/Apache setting too.

By comment out the line 141 & 142
'zh-hans' => 'unidirectional',
'zh-hant' => 'unidirectional',

Is this bug really resolved?
I have tried with master/REL1_27 version of lockdown with master/1,28/1/27 version ApiParse.php under MW1.27.1.
Neither allow API edit in any combined case out of 6 possible combination.

@Arseny1992
All right, thank you for your clarification!
The problem were described here: https://www.mediawiki.org/wiki/Topic:T0mjz41gyrqntkrq