Change 512526 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [tests] Use werkzeug != 0.15.2, != 0.15.3 in dev-requirements.txt

When the fallback is set shy and shy-latn will be essentially be the same. As a follow-up shy-latn can be hidden from users, but that is more difficult to do.

I'm not sure if that can be sorted out. There seems to be lots of politics and possible conflicts of interests involved, none really related to the simple issue at hand.

OK, just to be sure:

I don't want to rename language codes in translatewiki.net - it's too much effort and there is no tooling for that. Just move MessageShy-latn.php to MessagesShy.php and add $fallback = 'shy' and entry to Names.php. I think that is sufficient with the language-data changes you propose.

Makes sense to me.

non-canonical query continuation

Looking at e.g. https://translatewiki.net/w/i.php?title=Pywikibot:Checkimages-doubles-talk-comment/de&action=history some seen to have been recreated rather than backported. But that might also be a race condition between Fuzzybot and the human editor.

Pywikibot:Checkimages-doubles-talk-comment/de was never be backported to twn, see: https://phabricator.wikimedia.org/rPWIN644dc6c7f517a3c48a47834ee488970be6cf7557#change-ad9qMwWHf5x1

In T220178#5211250, @Xqt wrote:

[...] I don’t see any reason to block the patch for untranslations messages.

Since merging it would drop translations which had yet to be backported I would say blocking it on that makes sense.

The remaining two messages where recovered in i18n repository (https://gerrit.wikimedia.org/r/#/c/pywikibot/i18n/+/512465/1/checkimages/sr.json). We always have fallback enabled on i18n and these messages aren't L10N that is always needed for the script. Cannot follow this conclusion. See also T224331 for the underlying problem.

Also happens for edits on Items:

Change 512524 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [tests] Skip TestPwb.test_one_similar_script with Python 2

I suggest sorting out T165648 first to avoid having to change things later.

@hoo any reasons we didn't take that setting into account?

@alaa_wmde and @WMDE-leszek: Can you have a look?

Change 511960 merged by jenkins-bot:
[mediawiki/extensions/ConfirmEdit@master] Fix bug in Captcha::confirmEditMerged which breaks the $wgCaptchaRegex check

I am not sure at which point we can prohibit this. Because I assume we wouldn't want to prevent someone from entering two references, starting both with the same snaks and only then adding the differentiating snaks.

This is done in the extension and the Android app itself, too :)

In T220178#5211279, @Xqt wrote:

BTW They where backported, see https://translatewiki.net/w/i.php?title=Pywikibot:Checkimages-doubles-talk-comment/it&action=history for example

Looking at e.g. https://translatewiki.net/w/i.php?title=Pywikibot:Checkimages-doubles-talk-comment/de&action=history some seen to have been recreated rather than backported. But that might also be a race condition between Fuzzybot and the human editor.

High resolution thumbnails from the file, like:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/%D0%9F%D1%83%D1%88%D0%BA%D0%B8%D0%BD._%D0%95%D0%B2%D0%B3%D0%B5%D0%BD%D0%B8%D0%B9_%D0%9E%D0%BD%D0%B5%D0%B3%D0%B8%D0%BD_(1837).pdf/page7-1834px-%D0%9F%D1%83%D1%88%D0%BA%D0%B8%D0%BD._%D0%95%D0%B2%D0%B3%D0%B5%D0%BD%D0%B8%D0%B9_%D0%9E%D0%BD%D0%B5%D0%B3%D0%B8%D0%BD_(1837).pdf.jpg
look poor and exhibit artifacts likely resulting from scalling-up jpg image with lossy compression

Please reopen if the problem appears again.

Change 512520 had a related patch set uploaded (by 星耀晨曦; owner: 星耀晨曦):
[mediawiki/extensions/DonationInterface@master] Use break instead of continue in a switch block

In T224355#5212764, @Tpt wrote:

Has the first page of the PDF a smaller size orresolution than the other ones?

Yes.
This PDF: the first page 347x524 (22,4 kB), others about 377x529 (42,3 kB)
This PDF: the first page 163x253 (2,49 kB), others about 166x255 (3,90 kB)
Title page usually has smaller size, because there's not so many text.

Change 512519 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[mediawiki/core@master] Remove redundant closure for all modules with packageFiles

@Aklapper @Mglaser @80686
I have a few questions regarding this task:

Wird bearbeitet von einem/r unbekannten Autor*in.

Can you clarify what you mean by "duplicate reference definitions"? In the first diff you linked, IABot expanded shortened URLs to their full form, and in the second diff, it added {{webarchive}} to two links.

IABot only edits links in references. The link you tried to have fixed is part of the main article text.

Change 509396 abandoned by 星耀晨曦:
Checks the autocomment whether is empty in Linker::formatAutocomments()

@Ebe123 OK! When you're ready, feel free to go to https://phabricator.wikimedia.org/tag/user-notice/ and drag this ticket from "Not ready to announce" to "Announce in next Tech/News" and ping me here, and we'll make sure the communities get to know what's happening. (:

Change 512516 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/extensions/UrlShortener@master] Purge CDN after creating a new shortcode

Mentioned in SAL (#wikimedia-operations) [2019-05-26T08:01:10Z] <mobrovac> decommission restbase1012-a - T223976

Currently, I don't think the constraint system allows to limit a constraint scope to items only.

Indeed for the second point, it is indicated on P443 (Constrain section) that the lexeme has to be excluded (it makes sense). So Lingua Libre Bot should not add P407. That's said, it is not clear why the exclamation mark appears in Strom.

The IPA statement on Q102090 isn't really a sample to follow.

I don't think the wdtn triples are needed. I'd just add the "wikibase:identifier" ones.

You're right, never mind. Tag freely!

In T224357#5212762, @cscott wrote:

I have one more patch outstanding I was going to merge ( https://gerrit.wikimedia.org/r/508037 ) but I can do that in a subsequent point release. Note that wikipeg is a dual JS/PHP package now, you should probably release to both npm and composer. That involves bumping the version in package.json before tagging a commit. I can do this Tuesday if that's easier.

It is maybe related to T184867. Has the first page of the PDF a smaller size orresolution than the other ones?

I have one more patch outstanding I was going to merge ( https://gerrit.wikimedia.org/r/508037 ) but I can do that in a subsequent point release. Note that wikipeg is a dual JS/PHP package now, you should probably release to both npm and composer. That involves bumping the version in package.json before tagging a commit. I can do this Tuesday if that's easier.

@Johan: I wouldn't have much of a timeline for this... I'll try adding tests and making sure mp3 transcoding works well (as it differs from MediaWiki-extensions-Score 's way)