🚂🌈Summary of 1.39.0-wmf.14 train deployment
This email is a summary of the Wikimedia production deployment of
1.39.0-wmf.14
- Conductor: Jeena Huneidi
- Backup Conductor: Ahmon Dancy
- Blocker Task: T308067 <https://phabricator.wikimedia.org/T308067>
- Current Status <https://versions.toolforge.org>
🔢 Stats
Sparklines comparing with the last 5 trains.
- 259 Patches ▂▁█▆▄
- 0 Rollbacks ▁█▁▁▁
- 0 Days of delay ▁█▁▁▁
- 4 Blockers ▁█▃▂▂
🎉 Trainbow Love 🎉 Thanks to folks who reported or resolved blockers:
- Derk-Jan Hartman
- Amir Sarabadani
- Samuel
- Lucas Werkmeister (WMDE)
- Jon Robson
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
Hi folks -
*TL;DNR:* Can MediaWiki encode URL fragments in its API responses?
The iOS team noticed the MediaWiki Notifications API
<https://www.mediawiki.org/wiki/Notifications/API> returns partially
encoded URLs - the paths look to be encoded, but the fragments are not.
This causes issues with user talk page notifications with topic title
fragments in certain languages:
...
"legacyPrimary": {
"url": "//
ar.wikipedia.org/wiki/%D9%86%D9%82%D8%A7%D8%B4_%D8%A7%D9%84%D9%85%D8%B3%D8%…
غير_جيد",
"label": "اعرض الرسالة"
}
...
Our Swift URLs (which are based on RFC 1808) fail to instantiate with these
unencoded fragments. This led to some cross-team discussion on T307603
<https://phabricator.wikimedia.org/T307603> about where and how to fix
this. Does this seem like something that could (or should) be fixed deeper
within MediaWiki? Can we encode the fragments of urls in the response of
any MediaWiki API?
@matmarex did some excellent investigation in this comment
<https://phabricator.wikimedia.org/T307603#7955104>, and it sounds like the
original Chrome bug that led to this unencoded fragment need within
MediaWiki is no longer an issue. We're open to fixing it client-side if
this proposal is a no-go, but I wanted to make sure we weren't putting in a
client-side workaround for a server-side workaround that is no longer
needed. I appreciate any thoughts!
*Toni Sevener*
iOS Software Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi,
I've recently discovered that namespace names may have an ambiguity with
interlanguage links: If a namespace name is the same as a language code,
using it in wikitext poses all kinds of challenges.
Actual example: In the Tyap language (code kcg), the Wikipedia in which was
created a few days ago, the Category namespace is called "Sa:", which is
also the language code and, hence, the interlanguage link code for Sanskrit.
So, "Sa" is usable in wikitext, but has all kinds of little issues. For
example, old-style non-Wikidata interlanguage links to Sanskrit from the
Tyap Wikipedia are probably impossible. They are not very likely to be
inserted into articles, but still, it's somewhat conceivable. I also
noticed that it confuses Pywikibot in some ways. And I can imagine other
subtle bugs that it will cause.
I've asked Tyap speakers whether it's possible to change the word for
"Category" to something else. No—they want to use "Sa". It's legitimate not
to want to change the word for a technical reason.
So what can be done?
The editors there told me that it's OK for them to use "[[Category:" in
wikitext, but they would like to see "Sa:" in the title of category pages.
I'm not sure that it's possible: as far as I know, the namespace name
definition in MessagesKcg.php will be used for both things, and if Visual
editor is used to add categories, it will add "[[Sa:". Bots or gadgets can
be used to replace it to "Category", but is looks like an ugly hack.
Does anyone have better ideas for a robust, comprehensive solution?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.36 as of today, Friday June 3, 2022.
This means that MediaWiki 1.36 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade either to MediaWiki 1.37, which will be
supported until November 2022 or to 1.38 (released yesterday), which will
be supported until June 2023.
Thanks!
Sam Reed
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hello,
For the last few hours we had random CI build issues affecting MediaWiki
repositories. The symptom looks like:
[UnexpectedValueException (-1)]
'/workspace/src/vendor/./composer/tmp-xxxxx'
is a corrupted zip archive (0 bytes), try again.
After looking at the whole CI stack, I highly suspect it was a transient
issue on GitHub infrastructure which would serve some Zip assets as zero
bytes archives. The dependencies affected seem to have been:
wmde/hamcrest-html-matchers:v1.0.0
phpdocumentor/type-resolver:1.6.1
I don't see build failures anymore I am thus assuming the issue has been
solved by GitHub.
For any change in Gerrit that was affected, you can comment "recheck" in
Gerrit to trigger a rebuild.
If you have approved a patch with Code-Review +2, you would need to
remove your Code-Review +2 vote and apply again. If someone else
approved a change, you can Code-Review +2 it to trigger the test and
merge cycle.
The task:
https://phabricator.wikimedia.org/T309764
--
Antoine "hashar" Musso
Wikimedia Release Engineering