[Wikitech-l] 🌱 Fresh 21.04 released!

[Krinkle]

This release updates Chromium to 73, and fixes a bug where containers could
sometimes keep running if you force-closed a terminal tab that still had an
open fresh-node prompt. If you found that certain Selenium tests didn't
pass locally after March 10th, this now fixed as well. [1]

Thanks to Kunal Mehta, Željko Filipin, and James Forrester for their help
with testing and finding bugs.

Install, update, or learn more; at:
https://gerrit.wikimedia.org/g/fresh#fresh-environment

Changelog:
https://gerrit.wikimedia.org/g/fresh/+/21.04.1/CHANGELOG.md

Fresh is a fast way to launch isolated dev environments from your terminal.
These can be used to more securely work with npm-based tooling such as for
ESLint, QUnit, Grunt, WebdriverIO, and Selenium. Example guides:
* https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing
*
https://www.mediawiki.org/wiki/Selenium/Getting_Started/Run_tests_using_Fresh
*
https://www.mediawiki.org/wiki/Selenium/How-to/Run_tests_targeting_MediaWiki-Docker-Dev

-- Timo

[1] Fresh directly uses WMF CI's Docker image for Node.js and browsers.
This means you should be able to reproduce any npm or Selenium test locally
and have it behave nearly-identical to CI. In March, WMF CI jobs were
slowly updated to use its newer image with Chromium 73. Some Selenium tests
started failing in CI after that, due to Chromium 73 changing how text
nodes normalize line breaks (example: change 666946
). After fixing
those, you may found  that those
same tests would now fail in Fresh. This was because I hadn't yet released
this update. They should now be in sync again!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Herald rules

[Krinkle]

Have we considered asking upstream Phabricator to e.g.  a non-blocking mode
for a Herald rule? These would e.g. be processed post-send in PHP or in
some other queued manner internally. It would likely need to be restricted
and (to avoid notification complexity) might also be automatically tied to
the action being "silent" like we do for these bots.

This might not replace the bot, but it would be a more widely useful and
beneficial investment perhaps.

-- Timo


On Thu, Apr 22, 2021 at 3:23 PM Amir Sarabadani  wrote:

> Hi,
> I'm really sorry for sending email to such a large venue but I couldn't
> find a better mailing list. Feel free to ignore this email if you don't do
> anything with Herald rules.
>
> Herald rules, a set of rules in phabricator to automate the work, are
> expensive and slowly making saving any change on phabricator slower and
> slower. You can take a look at this ticket.
> 
>
> As the result, we have been migrating these rules to maintenance bot
> . Which means
> changes won't be immediately applied anymore (and it'll take up to an hour
> and they will be post-change).
>
> If you see your Herald rule has been disabled, please don't enable it. If
> you want to change it, you can make a PR in the maintenance bot source
> code.  Please
> avoid introducing new Herald rules if there's a similar functionality
> supported by the bot. Just add it to the work list of the bot. An exception
> would be on time-sensitive tickets. Like handling UBN ones. They will stay
> as Herald rules.
>
> Any sort of change to improve documentation, code health, adding new
> functionality so we can migrate more Herald rules, or migrating existing
> ones would be greatly appreciated. If there are bugs, feel free to create a
> ticket for it
> .
>
> You can also create email filters to ignore emails triggered by
> maintenance bot (which its activity will increase).
>
> Best
> --
> Amir (he/him)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dynamically declaring parser functions?

[Krinkle]

It might be (more) feasible to use Lua (and Extension:Scribunto) for this,
or even just templates more generally, as this allows one to define on-wiki
mechanisms dynamically in a more flexible way.

(I've not fully read the thread, apologies if this is incompatible with a
requirement, I thought I'd mention it as it seemed likely to be of use.)

On Sun, Apr 18, 2021 at 2:40 PM FreedomFighterSparrow <
freedomfighterspar...@gmail.com> wrote:

> My use case is this:
>
> I have three alternative access points to the wiki, where some things
> are not allowed - e.g. videos. Each access point has different
> extensions disabled, and then tags and parser functions show "as is" on
> screen, which looks bad.
>
> My goal is to hide those, obviously.
>
> I'm upgrading MW from 1.29 to 1.35; My previous solution is here:
> https://github.com/kolzchut/mediawiki-extensions-NoopTags
>
> Basically I hooked ParserFirstCallInitHook and LanguageGetMagic to
> dynamically declare empty stubs for those missing function parsers and
> tags, using global variables $wgNoopTagsFunctionBlacklist and
> $wgNoopTagsBlacklist.
>
>
> This doesn't work in MW 1.35, because LanguageGetMagic was removed. I
> tried bypassing the issue by hooking GetMagicVariableIDsHook, but
> apparently that's only for "variables" ({{variable}}), and not parser
> functions.
>
> Is there a way to achieve my goal? Either by fixing my extension or
> doing something completely different which I haven't thought about?
>
> Thanks in advance
> Dror
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki 1.36.0-rc.0 is ready for testing

[Tyler Cipriani]

I'm pleased to announce the immediate availability of MediaWiki 1.36.0-rc.0,
the first release candidate for 1.36.x. Download links are at the end of the
e-mail. The tag has been signed and pushed to Git.

Please note that MediaWiki 1.36 now requires the PHP internationalization
extension, commonly referred to as Intl, ext-intl, or php-intl.

This is not a final release, and should not be used for production websites.
Known issues are tracked in Phabricator on the release workboard [1].

As always, please try out the release candidate in a test environment and do
report any issues that you discover. Please use the #MW-1.36-Release [2] tag
in Phabricator when reporting issues specific to this release, to make sure
that we find them as quickly as possible.

It is expected that MediaWiki 1.36 will become final in May 2021, though the
date may slip if blockers are identified.

Preliminary release notes:
https://gerrit.wikimedia.org/g/mediawiki/core/+/REL1_36/RELEASE-NOTES-1.36
https://www.mediawiki.org/wiki/Release_notes/1.36

Public keys:
https://www.mediawiki.org/keys/keys.html

Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/3386/

Bug report form:
[2] 
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.36-Release

**
Download:
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.0-rc.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.0-rc.0.zip

Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-core-1.36.0-rc.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-core-1.36.0-rc.0.zip

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-core-1.36.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-core-1.36.0-rc.0.zip.sig
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.0-rc.0.zip.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Next datacenter switchover planned for week of June 28th

[Kunal Mehta]

Hi,

The next datacenter switchover is scheduled for the week of June 28th. 
If you're not familiar with why we do this, I'd suggest reading [1].


Starting next week I'll be reaching out to service owners/maintainers to 
finalize the list of services that we will be switching over, checking 
what work/improvements need to be made from what we learned in the last 
switchover.


One notable change this time is that we are still planning to run the 
MediaWiki deployment train. This both mimics a real unplanned switchover 
situation where the train is running, as well as avoiding the situation 
of having three weeks worth of code go out in one train because of other 
scheduled train disruptions[2].


The tracking task for this is .

[1] https://diff.wikimedia.org/2017/04/18/codfw-temporary-editing-pause/
[2] https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar

-- Kunal

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Language Extension Bundle 2021.04 release

[Kartik Mistry]

Hello all,

I would like to announce the release of MediaWiki Language Extension
Bundle 2021.04. This bundle is compatible with MediaWiki 1.34 or above
and requires PHP 7.2 or above.

Next MLEB is expected to be released in 3 months. If there are very
important bug fixes, we will do an intermediate release. Please give
us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].

* Download: 
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.04.tar.bz2
* sha256sum: 652b7838b4c87fba80ca46ebd15a106bf3fd4e9cc202417de6ee3ad33d2a8048
* Signature: 
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.04.tar.bz2.asc

Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode

Release notes for each extension are below.

-- Kartik Mistry

== Babel ==
* Fixed Mediawiki requirement. Requires >= 1.34.0.
* Maintenance and localization updates.

== cldr, CleanChanges and LocalisationUpdate ==
* Maintenance and localization updates only.

== Translate ==
* Consider translated optional messages towards meeting the export
threshold ({{Phab|T159122}})
* Do not lock pages indefinitely during translatable page moves
({{Gerrit|661125}})
* Support new HTML-y translation variable syntax ({{Phab|T274881}})
* Limit pages that can be moved from the UI to 500 by default.
({{Phab|T277431}})
** This can be modified by updating the configuration:
$wgTranslatePageMoveLimit
* Add moveTranslatablePage script that can move any number of pages
({{Phab|T275109}})
* Rename Special:SupportedLanguages to Special:ActiveLanguages
externally ({{Gerrit|673007}})
* Add description/summary to Special:PagePreparation ({{Phab|T276911}})
* Add help link to Special:PageMigration | ({{Phab|T277031}})
* (MW >= 1.36) Enable "opt-in" translation aware transclusion for
templates ({{Phab|T47096}})
** This has to be manually enabled for existing translatable pages but
is enabled by default for new pages.
* Add script to cleanup obsolete rows from translate_groupstats
({{Gerrit|673261}})
* Fix metadata handling for translatable page moves and deletions
({{Gerrit|666357}})
* Namespace for classes under the src/ folder has been
changed to: MediaWiki\Extension\Translate instead of:
MediaWiki\Extensions\Translate. class_alias
has been used to ensure existing functionality and cached data does
not break. The alias will be removed in the next MLEB release.

== UniversalLanguageSelector ==
* Ensure ULS supports modern Vector ({{Phab|T273232}},{{Phab|T273928}})
* Maintenance and localization updates.

=== Fonts ===
* Update Junicode to 1.002 ({{Phab|T173573}})

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l