Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2022.01. This bundle is compatible with '''MediaWiki 1.36''' or
above and requires '''PHP 7.3.19''' 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-2022.01.tar…
* sha256sum: 0cb434980b399f7bac42a92c9f171b6c9041cb998e3b2b0fcf16daf58c43fe61
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.01.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/postorius/lists/mediawiki-i18n.lists.wikimedia.…
* Report bugs to: https://phabricator.wikimedia.org/project/view/1464/
Release notes for each extension are below.
-- Kartik Mistry
== Highlights ==
* '''MLEB now requires MediaWiki 1.36 and PHP 7.3.19'''
== Babel, cldr, CleanChanges and LocalisationUpdate ==
* Localisation and maintenance updates.
== Translate ==
* Fix Special:PageMigration - Page search suggestion does not work
({{phab|T217726}})
* Fix UI issue: the page moves from bottom to top when new messages
are loaded in List tab ({{phab|T295655}}, {{gerrit|738587}})
* Migrate tables to an abstract schema ({{phab|T268576}}, {{gerrit|735613}})
* Improve UX on Special:AggregateGroups and add collapsibility ({{phab|T90511}})
* Feature: Special:Translate: Make the target language visible in the
translation UI ({{phab|T296987}}, {{gerrit|743383}})
* Feature: Special:Translate: Make the target language selector a bit
more prominent ({{phab|T296986}}, {{gerrit|743397}})
* Performance: Special:ActiveLanguages should not perform slow queries
if results are cached ({{phab|T285314}}, {{gerrit|747122}})
* Feature: Add a new Javascript hook,
<code>mw.translate.translationView.stateChange</code>, fired when the
state is updated ({{phab|T297129}}, {{gerrit|745997}})
* Remove unused Configure extension integration ({{gerrit|751382}})
* Feature: Add reason dropdown on PageTranslationDeletePage
({{phab|T153542}}, {{gerrit|754490}})
* Add filters to <code>meta=messagegroupstats</code> API
({{phab|T298736}}, {{gerrit|752000}})
* Allow exporting AggregateMessageGroups in offline format via CLI
({{phab|T299493}}, {{phab|T263268}}, {{gerrit|755356}})
=== Breaking changes ===
* Remove backward compatibility for MW <= 1.35 ({{phab|T298788}},
{{gerrit|752166}})
== UniversalLanguageSelector ==
* Remove backward compatibility for MW <= 1.35
* Localisation and maintenance updates.
=== Font updates ===
* Add Awami Nastaliq font ({{phab|T290510}}, {{gerrit|737206}})
* Update OpenDyslexic ({{gerrit|737207}})
* Update GentiumPlus font ({{phab|T298613}}, {{gerrit|737206}})
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
Hello everyone,
This is a reminder that we will be starting the release process for MediaWiki 1.38 in mid-March. By then, in about 8 weeks from now, a new branch REL1_38 will be cut from the development branch.
If you are an extension developer or otherwise dependent on MediaWiki releases with your code, now it is time to check and fix your compatibility with the development branch, so that by the time the branch is cut, we have a working version of your code in its REL1_38 branch. If you hope to land a breaking change into MediaWiki core for this release, please make sure to do so soon so that extension developers have the time to make their adjustments.
Regards,
Markus
User:Mglaser
MediaWiki Stakeholders' Group
Is there a magic variable {{LOGGED-IN}} or a similar mechanism that
could be used to detected from within the wiki markup, CSS or
Extension:Widgets?
Background:
Creating menus / content which is different for anonymous visitors and
logged in users (mostly wiki administrators).
Cheers,
Patrick
Hello!
Maybe someone has a hint for this problem I have:
I'd like to move an existing wiki to another place in my filestructure.
Used to be:
/pages/wiki
/pages/mainsite (is entry point for 'domain.de')
Should be changed to
/pages/mainsite/wiki
My goal: calling the wiki through 'domain.de/wiki'
Mediawiki Version is 1.31.5.
I copied files and directories to the subdirectory. Copied Database Tables to a new Database. Changed the IP path and database variables in localsettings.
I executed update.php on the new copy.
Now when I use the new url path 'domain.de/wiki' the browser will change the url to http://www.domain.de/index.php?title=Hauptseite <http://www.domain.de/index.php?title=Hauptseite> (removing the subfolder 'wiki' from the path),
and show an error message: "The requested URL was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."
I then created a new subdomain 'wikinew.domain.de' aiming at the path 'domain.de/wiki'
Now when using this subdomain, the copied wiki opens without error, everything looks fine, login works, page editing works, images are correctly displayed.
Maybe someone can explain the behavior when calling domain.de/wiki?
Did I forget some kind of configuration?
Thanks for your help,
Marcus
I have a maaajor issue minor ones sure ALWAYS W/ EVERYTHING I USE TO
TESEAVH PIST TOOLS YEP I COULD NAME A DOZEN DAILY I COULD SUGGEST
IMPROVEMENTS TO… HOW DO I DO THUS EXACTLY?…
BUT THE major ONE IM Ref. to, IF FIXED it will be conducive to ALL SOCIAL
MEDIA USERS.
Please RESPOND, I WILL THEN FURTHER ADDRESS, My Issue w/ The MetaVerse.
* I ACTUALLY CAN PROVIDE MANY IMPROVEMENTS TO BOTH (FB AND IG) AS A DYAD
TEAM AND SUGGESTIONS ADDIND OTHER APPs TO JOIN RELATED TO SOCIAL MEDIA
PLATFORM ITSELF.
~JUST A Question Waiting Patiently TO ASK.
TY,
RaQuelLynn “Amethyst 💜”
If you are not an extension developer, you can safely ignore this message.
I am excited to announce that the Minerva Neue skin will be bundled with
MediaWiki in 1.38 per https://phabricator.wikimedia.org/T191743
The Minerva Neue skin powers the mobile site of Wikimedia projects, so it
makes sense to include this skin for 3rd party MediaWiki instances that
want a responsive but simplified experience.
The implication of this is that extension developers should be making sure
their code compatible with MinervaNeue.
Note, that Minerva Neue operates in two modes (a desktop or mobile mode)
depending on whether MobileFrontend is installed, however, MobileFrontend
is still not part of the MediaWiki bundle so this mode doesn't need to be
tested at this point.
You can tell if you are in Minerva desktop mode by testing in an incognito
window and verifying that you see a more (ellipsis) dropdown in the toolbar.
e.g. Test on https://en.wikipedia.org/wiki/Minerva?useskin=minerva NOT
https://en.m.wikipedia.org/wiki/Minerva?useskin=minerva
if you have any questions or concerns please feel free to reply to this
e-mail or the Phabricator ticket.
Thanks for reading!
Jon
MediaWiki has an experimental configuration flag $wgUseCategoryBrowser that
alters the appearance of categories. If you don't use this flag or are not
aware of it you can safely ignore this message.
We plan to remove this configuration flag and associated code in MediaWiki
1.38 without deprecation warnings given its experimental nature:
https://phabricator.wikimedia.org/T298553
If needed an extension can provide the same functionality, so if anyone
needs this functionality please let us know by replying to this email or
the Phabricator ticket to help guide us better.
Thanks for reading
Jon