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.
<https://phabricator.wikimedia.org/T108586>
As the result, we have been migrating these rules to maintenance bot
<https://phabricator.wikimedia.org/p/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.
<https://github.com/Ladsgroup/Phabricator-maintenance-bot> 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
<https://phabricator.wikimedia.org/tag/phabricator_maintenance_bot/>.
You can also create email filters to ignore emails triggered by maintenance
bot (which its activity will increase).
Best
--
Amir (he/him)
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
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 <https://phabricator.wikimedia.org/T281515>.
[1] https://diff.wikimedia.org/2017/04/18/codfw-temporary-editing-pause/
[2] https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
-- Kunal
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…
* sha256sum: 652b7838b4c87fba80ca46ebd15a106bf3fd4e9cc202417de6ee3ad33d2a8048
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2021.04.tar…
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:
<code>$wgTranslatePageMoveLimit</code>
* 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 <code>src/</code> folder has been
changed to: <code>MediaWiki\Extension\Translate</code> instead of:
<code>MediaWiki\Extensions\Translate</code>. <code>class_alias</code>
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
The 1.37.0-wmf.3 version of MediaWiki is blocked[0].
The new version is deployed to {group(s){0,1,2}}[1], but can proceed no
further until these issues are resolved:
* T281361 TypeError: Argument 2 passed to
Wikibase\Client\DataAccess\Scribunto\WikibaseLanguageIndependentLuaBindings::trackUsageForSitelink()
must be an instance of Wikibase\DataModel\Entity\ItemId, instance of
Wikibase\MediaInfo\DataMo
<https://phabricator.wikimedia.org/T281361>
Once these issues are resolved train can resume. If these issues are
resolved on a Friday the train will resume Monday.
Thank you for your help resolving these issues!
-- Your humble train toiler
[0]. <https://phabricator.wikimedia.org/T278347>
[1]. <https://versions.toolforge.org/>
--
WMF release engineering team | he/him or they/them
"Imagine a world in which every single human being can freely share in
the sum of all knowledge."
// apologies for cross-posting
Hello!
A new type of preview will soon be part of the MediaWiki software:
Reference Previews.[1] This feature shows you a reference in a small pop-up
when you hover over the reference number in square brackets. This way, you
can look up a reference without jumping down to the bottom of the page.
What’s more is that Reference Previews can offer a quicker way to evaluate
the trustworthiness of the cited source by displaying the reference type
(book, web, news, journal, note) in the pop-up’s header. Thus, they can
help increase trust in the article itself. These types can be applied by
using citation templates, or by manually entering a class into the ref tag.
Reference Previews will be combined with Page Previews[2], a feature
showing previews for linked articles. Both perform essentially the same
function: previewing content before deciding to dig deeper, and easily
providing more information while reading. Because of their similarities in
design and behavior, both Page Previews and Reference Previews will be
controlled by a single user setting. This means, all users who currently
have Page Previews activated, will also get Reference Previews. Also, all
readers, anonymous contributors and new users will see Reference Previews
per default if they haven’t disabled Page Previews.
On several wikis, the Navigation-Popups gadget and the Reference Tooltips
gadget already offer previews for references. If you want to use them
instead, you can: If you have one of these gadgets enabled, you’ll see them
instead of Reference Previews. Although these gadgets exist, this feature
was built into a MediaWiki extension in order to make it available for all
Wikipedias, just as Page Previews is.
The original request for this came from the Technical Wishes survey on
German Wikipedia in 2017, where it was the number 1 wish. The Technical
Wishes team from Wikimedia Germany has been working on it in cooperation
with the WMF’s Reading Web team. Reference Previews have been a beta
feature for several months on all Wikipedias and some other wikis, with
more than 830,000 beta testers. During the beta phase, lots of feedback was
collected, and several changes were made as a result.[3] Now, we plan to
deploy it to a first group of wikis as a default feature on March 17. We’re
still looking for wikis who want to have the default feature early, so if
you’re interested, please let us know! [4] [5]
More information about this feature, including frequently asked questions,
can be found on its project page on Meta. [1] A big thanks to everyone who
contributed to this development, by voting, testing, giving feedback or
else. Comments and questions are welcome on this talk page. [4]
Best,
Johanna
[1] Reference Previews:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
[2] Page Previews: https://www.mediawiki.org/wiki/Page_Previews
[3] Changes during the beta phase:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews#Bet…
[4] talk page:
https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/ReferencePreviews
[5] Phab: https://phabricator.wikimedia.org/T271206
--
Johanna Strodt
Project manager community communications Technical Wishes
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
======
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
======
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello,
TLDR: Mailman3 is now available for general use, all mailing lists will be
migrated in the next couple of weeks, providing everyone with a much better
mailing list experience. You will notice some changes, let us know if you
run into issues.
Long version:
We're happy to announce that Mailman3 is available for general use and some
have already been migrated. You can find the current mailing lists that
have been migrated at [1] and their archives in "hyperkitty"[2].
Mailman3 is a full rewrite of our previous mailing list software
(Mailman2), and the migration is long overdue. Some key new features that
we want to highlight:
* One user account (no more monthly password reminder emails or list
passwords)
* Ability to search through archives
* Posting through a web interface
* A web interface that doesn't look like its from the early 2000s
* Better security of accounts and messages
The first mailing list migrated was LGBT@ and you can see its mailing list
page in [3]. We are going to slowly migrate the rest of mailing lists (all
+700 of them), you can track the work in [4]. All new mailing lists from
now on will be only on Mailman3.
This means:
* We will send an email to admins of any mailing list right before
starting the upgrade process, and once it's finished.
* The link to subscribe to lists will change, please update your wiki
pages, documentation, etc. We will provide redirects though.
* Links to old archives for public mailing lists won't break. It will
stay at it is now and will become redirects shortly. But URLs of archived
emails of private mailing lists will break. This is necessary for improving
security of mailing lists. Keep it in mind that in the new system you can
easily search in the archives.
Given that in Mailman3, you can simply have one central account for all of
your mailing lists. We highly encourage you to make one [1], that way, you
can easily control what mailing lists you are subscribed to, easily join
new mailing lists and much more. This also makes administrating and
moderating mailing lists much easier.
If you have any questions or you encounter any issues, let us know! You can
create a Phabricator ticket ("Wikimedia-Mailing-lists" project) or ping us
on IRC in #wikimedia-tech.
We hope that Mailman3 brings much needed love to our mailing lists without
breaking your workflows (like reading mails by piping telnet into less or
something like that).
The umbrella ticket for the work: https://phabricator.wikimedia.org/T52864
[1] https://lists.wikimedia.org/postorius/lists/
[2] https://lists.wikimedia.org/hyperkitty/
[3] https://lists.wikimedia.org/postorius/lists/lgbt.lists.wikimedia.org/
[4] https://phabricator.wikimedia.org/T280322
Best,
Kunal (Legoktm) and Amir (Ladsgroup)