Extension talk:Lingo

Previous page history was archived for backup purposes at Extension talk:Lingo/LQT Archive 1 on 2015-07-10.

I have been searching and cannot figure this one out. Lingo is operational but when I run update.php I get this:

PHP Deprecated:  Use of Hooks::register was deprecated in MediaWiki 1.35. [Called from Lingo\BasicBackend::registerHooks in /var/www/mediawiki/extensions/Lingo/src/BasicBackend.php at line 58] in /var/www/mediawiki/includes/debug/MWDebug.php on line 386

Any idea?

SG

It is just a PHP warning that gets thrown if your current version of MediaWiki is v1.35 or over but your version of Lingo lingers behind. Your best bet is to upgrade Lingo.

I am at the latest.

Tried 3.2.1 also...

To judge by https://github.com/wikimedia/mediawiki-extensions-Lingo/blob/master/src/BasicBackend.php, the extension uses hooks correctly. The change hasn't been backported to the 1.36-1.38 branches though, maybe because it is only a deprecation warning, not an error. Or maybe it was just an oversight.

It is fixed in REL1_39 (LTS) according to the extension compatibility policy (ltsrel): https://github.com/wikimedia/mediawiki-extensions-Lingo/blob/c88549b25caa48012b915c150115c7100ded82be/src/BasicBackend.php#L56C1-L60C3

If you are on MW 1.39, please checkout REL1_39 branch, rather than a tag.

If you are running MW < 1.39, just ignore the message, as mentioned by @Cavila, it is just a deprecation warning and will go away with the upgrade to 1.39.

As for MW 1.35, it went end-of-life on December 21, 2023.

It actually only pops this error when I use VisualEditor. I disable Lingo when I need to use that extension and then have no issues.

@GobleStL Please, make sure that you have PHP error reporting off in your LocalSettings.php and repeat testing. In case of failure, please share your current MW version number + PHP version, so that we could try to reproduce the error. A link to your LocalSettings.php will also be very helpful (just wipe the sensitive info out).

With error reporting on: "[58a6c0d657e09eaaaf0dc77c] Exception caught: Typed property Parser::$mOutput must not be accessed before initialization"

With error reporting off: "[addf778021d79e091496ce38] Caught exception of type Error"

This only pops up when I attempt to use VisualEditor. Lingo works just fine.

If I disable Lingo extension, VisualEditor opens without an error. I believe it is related to https://phabricator.wikimedia.org/T357686

In troubleshooting this I upgraded everything. I even started using dev branches. (The error started when on stable branch). Currently I am:

Product	Version
MediaWiki	1.41.1
PHP	8.3.7 (fpm-fcgi)
ICU	66.1
MariaDB	10.5.23-MariaDB-0+deb11u1
Lua	5.1.5
Pygments	2.16.1

VisualEditor

0.1.2 (6f30783) 16:34, 10 May 2024

Lingo

3.2.1

<?php

#To suppress error messages uncomment the next two lines

error_reporting( 0 );

ini_set( 'display_errors', 0);

#To turn on error reporting uncomment the next four lines

#error_reporting( -1 );

#ini_set( 'display_errors', 1 );

#$wgShowExceptionDetails = true;

#$wgShowDBErrorBacktrace = true;

# This file was automatically generated by the MediaWiki 1.41.1

# installer. If you make manual changes, please keep track in case you

# need to recreate them later.

#

# See includes/MainConfigSchema.php for all configurable settings

# and their default values, but don't forget to make changes in _this_

# file, not there.

#

# Further documentation for configuration settings may be found at:

# https://www.mediawiki.org/wiki/Manual:Configuration_settings

# Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) {

        exit;

}

## Uncomment this to disable output compression

# $wgDisableOutputCompression = true;

$wgSitename = "This_Wiki";

## The URL base path to the directory containing the wiki;

## defaults for all runtime URL paths are based off of this.

## For more information on customizing the URLs

## (like /w/index.php/Page_title to /wiki/Page_title) please see:

## https://www.mediawiki.org/wiki/Manual:Short_URL

$wgScriptPath = "/mediawiki";

## The protocol and server name to use in fully-qualified URLs

$wgServer = "https://wiki.com";

## The URL path to static resources (images, scripts, etc.)

$wgResourceBasePath = $wgScriptPath;

## The URL paths to the logo.  Make sure you change this from the default,

## or else you'll overwrite your logo when you upgrade!

$wgLogos = [

        '1x' => "$wgResourceBasePath/resources/assets/wiki.svg",

        'icon' => "$wgResourceBasePath/resources/assets/wiki.svg",

];

$wgFavicon = "$wgResourceBasePath/resources/assets/wiki_icon.svg";

## UPO means: this is also a user preference option

$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "an.email@abc.com";

$wgPasswordSender = "an.email@abc.com";

$wgSMTP = [

    'host'      => 'ssl://smtp.email.com', // could also be an IP address. Where the SMTP server is located. If using SSL or TLS, add the prefix "ssl://" or "tls://".

    'IDHost'    => 'wiki.com',      // Generally this will be the domain name of your website (aka mywiki.org)

    'localhost' => 'wiki.com,

    'port'      => 465,                // Port to use when connecting to the SMTP server

    'auth'      => true,               // Should we use SMTP authentication (true or false)

    'username'  => 'an.email@abc.com',     // Username to use for SMTP authentication (if being used)

    'password'  => 'somethinghere'       // Password to use for SMTP authentication (if being used)

];

$wgEnotifUserTalk = true; # UPO

$wgEnotifWatchlist = true; # UPO

$wgEmailAuthentication = true;

## Database settings

$wgDBtype = "mysql";

$wgDBserver = "localhost";

$wgDBname = "this_wiki";

$wgDBuser = "wiki_dude";

$wgDBpassword = "apassword";

# MySQL specific settings

$wgDBprefix = "";

$wgDBssl = false;

# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

# Shared database table

# This has no effect unless $wgSharedDB is also set.

$wgSharedTables[] = "actor";

## Shared memory settings

$wgMainCacheType = CACHE_ACCEL;

$wgMemCachedServers = [];

## To enable image uploads, make sure the 'images' directory

## is writable, then set this to true:

$wgEnableUploads = true;

$wgUseImageMagick = true;

$wgImageMagickConvertCommand = "/usr/bin/convert";

$wgGenerateThumbnailOnParse = true;

$wgSVGConverter = 'ImageMagick';

# InstantCommons allows wiki to use images from https://commons.wikimedia.org

$wgUseInstantCommons = false;

# Periodically send a pingback to https://www.mediawiki.org/ with basic data

# about this MediaWiki instance. The Wikimedia Foundation shares this data

# with MediaWiki developers to help guide future development efforts.

$wgPingback = false;

# Site language code, should be one of the list in ./includes/languages/data/Names.php

$wgLanguageCode = "en";

# Time zone

#$wgLocaltimezone = "UTC";

$wgLocaltimezone = "America/Chicago";

## Set $wgCacheDirectory to a writable directory on the web server

## to make your wiki go slightly faster. The directory should not

## be publicly accessible from the web.

#$wgCacheDirectory = "$IP/cache";

$wgTmpDirectory = "/var/www/mediawiki/temp";

$wgSecretKey = "abc123";

# Changing this will log out all existing sessions.

$wgAuthenticationTokenVersion = "1";

# Site upgrade key. Must be set to a string (default provided) to turn on the

# web installer while LocalSettings.php is in place

$wgUpgradeKey = "1234567890";

## For attaching licensing metadata to pages, and displaying an

## appropriate copyright notice / icon. GNU Free Documentation

## License and Creative Commons licenses are supported so far.

$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright

$wgRightsUrl = "";

$wgRightsText = "";

$wgRightsIcon = "";

# Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

# The following permissions were set based on your choice in the installer

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['*']['read'] = false;

## Default skin: you can change the default skin. Use the internal symbolic

## names, e.g. 'vector' or 'monobook':

$wgDefaultSkin = "monobook";

# Enabled skins.

# The following skins were automatically enabled:

wfLoadSkin( 'MinervaNeue' );

wfLoadSkin( 'MonoBook' );

wfLoadSkin( 'Timeless' );

wfLoadSkin( 'Vector' );

# Enabled extensions. Most of the extensions are enabled by adding

# wfLoadExtension( 'ExtensionName' );

# to LocalSettings.php. Check specific extension documentation for more details.

# The following extensions were automatically enabled:

wfLoadExtension( 'AccessControl' );

wfLoadExtension( 'AutoCreateCategoryPages' );

wfLoadExtension( 'CategoryTree' );

wfLoadExtension( 'Cite' );

wfLoadExtension( 'CiteThisPage' );

wfLoadExtension( 'CodeEditor' );

wfLoadExtension( 'ConfirmEdit' );

wfLoadExtension( 'DataDump' );

wfLoadExtension( 'DiscussionTools' );

wfLoadExtension( 'DumpsOnDemand' );

wfLoadExtension( 'Echo' );

wfLoadExtension( 'Gadgets' );

wfLoadExtension( 'ImageMap' );

wfLoadExtension( 'InputBox' );

wfLoadExtension( 'Interwiki' );

#wfLoadExtension( 'LinkTitles' );

wfLoadExtension( 'Linter' );

wfLoadExtension( 'LoginNotify' );

wfLoadExtension( 'Maintenance' );

wfLoadExtension( 'Math' );

wfLoadExtension( 'MultimediaViewer' );

wfLoadExtension( 'Nuke' );

wfLoadExtension( 'OATHAuth' );

wfLoadExtension( 'PageForms' );

wfLoadExtension( 'PageImages' );

wfLoadExtension( 'ParserFunctions' );

wfLoadExtension( 'PdfHandler' );

wfLoadExtension( 'Poem' );

wfLoadExtension( 'Renameuser' );

wfLoadExtension( 'ReplaceText' );

wfLoadExtension( 'Scribunto' );

wfLoadExtension( 'SecureLinkFixer' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'TemplateData' );

wfLoadExtension( 'TextExtracts' );

wfLoadExtension( 'Thanks' );

wfLoadExtension( 'TitleBlacklist' );

wfLoadExtension( 'VisualEditor' );

wfLoadExtension( 'WikiEditor' );

# End of automatically generated settings.

# Add more configuration options below.

//DataDump Configuration

$wgDataDumpDirectory = "<path>${wgDBname}/";

$wgDataDump = [

    'xml' => [

        'file_ending' => '.xml.gz',

        'generate' => [

            'type' => 'mwscript',

            'script' => "$IP/maintenance/dumpBackup.php",

            'options' => [

                '--full',

                '--output',

                "gzip:${wgDataDumpDirectory}" . '${filename}',

            ],

        ],

        'limit' => 1,

        'permissions' => [

            'view' => 'view-dump',

            'generate' => 'generate-dump',

            'delete' => 'delete-dump',

        ],

    ],

    'image' => [

        'file_ending' => '.zip',

        'generate' => [

            'type' => 'script',

            'script' => '/usr/bin/zip',

            'options' => [

                '-r',

                '<path>${filename}',

                "<path>${wgDBname}/"

            ],

        ],

        'limit' => 1,

        'permissions' => [

            'view' => 'view-dump',

            'generate' => 'view-image-dump',

            'delete' => 'delete-dump',

        ],

    ],

];

// create DataDump right

$wgAvailableRights[] = 'view-dump';

$wgAvailableRights[] = 'view-image-dump';

$wgAvailableRights[] = 'generate-dump';

$wgAvailableRights[] = 'delete-dump';

// add DataDump to the user group

$wgGroupPermissions['user']['view-image-dump'] = true;

$wgGroupPermissions['sysop']['view-image-dump'] = true;

$wgGroupPermissions['user']['generate-dump'] = true;

$wgGroupPermissions['sysop']['generate-dump'] = true;

$wgGroupPermissions['sysop']['delete-dump'] = true;

// add DataDump to the 'basic' grant so we can use our DataDump over an API request

$wgGrantPermissions['basic']['view-image-dump'] = true;

$wgGrantPermissions['basic']['generate-dump'] = true;

$wgGrantPermissions['basic']['delete-dump'] = true;

//For mobile adding extension and settings

$wgUrlProtocols[] = "file://";

$wgFileExtensions[] = 'iso';

$wgFileExtensions[] = 'pdf';

$wgFileExtensions[] = 'doc';

$wgFileExtensions[] = 'xls';

$wgMaxShellMemory = 8000000;

$wgMaxShellFileSize = 1000000;

$wgMaxShellTime = 300;

$wgAllowTitlesInSVG = true;

$wgLinkTitlesParseOnEdit = true;

$wgLinkTitlesBlackList[] = 'B6200';

// Add Lingo

wfLoadExtension( 'Lingo' );

#The following hook is needed for Lingo to function

$wgHooks['SetupAfterCache'][] = function() {

    // specify a different name for the terminology page (Default: 'Terminology' (or localised ve>

    $GLOBALS['wgexLingoPage'] = 'Glossary';

    // specify that each term should be annotated only once per page (Default: false)

    //$GLOBALS['wgexLingoDisplayOnce'] = false;

    // specify what namespaces should or should not be used (Default: Empty, i.e. use all namespa>

    //$GLOBALS['wgexLingoUseNamespaces'][NS_SPECIAL] = false;

    // set default cache type (Default: null, i.e. use main cache)

    //$GLOBALS['wgexLingoCacheType'] = CACHE_NONE;

    // use ApprovedRevs extension on the Terminology page (Default: false)

    //$GLOBALS['wgexLingoEnableApprovedRevs'] = true;

};

We only support LTS branches of MediaWiki. You can try the REL1_39 branch's code and it might work with 1.41. Probably unrelated, running MediaWiki with version 8.3 might cause issues.

Thank you. I realize this. This is why I just disable the extension when I want to use VisualEditor.

Lingo REL1_39 is free of this bug. The issue was SemanticGlossary pulling an outdated Lingo version.

MW 1.39, php 8.1, Lingo extension REL1_39 and I'm getting:

Warning: Undefined global variable $wgParser in/var/www/html/extensions/Lingo/src/Lingo.php on line53

Hi @Allanext2, please let me know what installation method did you use (cloning Git repo, composer or something else)?

Hi @Elcapitan68,

I have it installed with a git submodule from the github repo, below the entry in .gitmodules:

[submodule "data/extensions/Lingo"]

path = data/extensions/Lingo

url = https://github.com/wikimedia/mediawiki-extensions-Lingo.git

branch = REL1_39

I then do:

git submodule init

git submodule update

git submodule foreach -q 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; echo "Extension $name:"; git switch $branch'

Thank you !

Please check paths, REL1_39 of Lingo seems to be free of wgParser:

w/extensions/Lingo$ php -v
PHP 8.1.27 (cli) (built: Dec 21 2023 20:19:54) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

w/extensions/Lingo$ git status
On branch REL1_39
Your branch is up to date with 'origin/REL1_39'.

nothing to commit, working tree clean

w/extensions/Lingo$ grep -R wgParser ./
w/extensions/Lingo$ 

See here.

Is there a chance that you mount an outdated branch some way?

What happens if you checkout the tag?

cd extensions/Lingo

git checkout 3.2.0

@Elcapitan68 You're right the REL1_39 branch in clean of wgParser.

The issue is that when Semantic Glossary is installed (dev-master branch) with `composer update --no-dev` it requires the dependency Lingo 3.1.1 which overrides files

https://github.com/SemanticMediaWiki/SemanticGlossary/issues/71

@Allanext2 Got it. As Lingo REL1_39 is just fine, and provided that there is the PR waiting for a merge, I suggest closing this.

Please confirm understanding.

In the meantime, feel free to try the fork from WikiTeq https://github.com/WikiTeq/SemanticGlossary that includes the patch.

@Elcapitan68 yes, makes sense, thank you !!

Sorry for the late reply! Indeed, setting $wgexLingoPage = 'Project:Terminology'; does the trick :)

I'm trying to use Project:Terminology as the terminology page for the extension across an entire wiki, but the extension doesn't seem to recognize that page when I set it in MediaWiki:Lingo-terminologypagename, using either "Project:Terminology" or "Wiki Name:Terminology".

Thank you for asking, @SlyCooperFan1

You are supposed to use a configuration variable in order to change the default page. Please try to add to your LocalSettings.php:

$wgexLingoPage = 'Project:Terminology';

The page you mention (MediaWiki:Lingo-terminologypagename) is used to create localized names for the Lingo page, eg. MediaWiki:Lingo-terminologypagename/fr, see: https://github.com/wikimedia/mediawiki-extensions-Lingo/blob/362618929b946588935d2bd15a94d9d966079481/src/BasicBackend.php#L175

@SlyCooperFan1, did you have a chance to try setting $wgexLingoPage? Did it help?

The bug report is created on Phabricator https://phabricator.wikimedia.org/T348465. In the meanwhile, a CSS workaround is suggested.

I am using the vector 2022 skin and recently installed the Lingo extension, love it but I have this very strange problem, when I have Lingo enabled, I found that the TOC is displayed at the beginning of only some pages.. if I switch to the old vector (2010) skin, the TOC displays at the beginning of all pages (which is expected). Has anyone seen this issue or any idea where could be the problem? Below are the versions:

Product	Version
MediaWiki	1.39.2
PHP	8.1.13 (fpm-fcgi)
MariaDB	10.6.11-MariaDB
ICU	67.1
Lua	5.1.5
Pygments	2.11.2

Hi, @Paulxu20 Please, provide a link to a live page with the described TOC behavior or to a screenshot. Also, make sure your expectations about all pages are correct: by design, a table of contents is automatically generated on a page when more than three section headings are used (Manual:Table of contents)

Hi @Elcapitan68, thanks for the reply! Here is an example: https://papals.org/index.php?title=Test3, you can see on this page the TOC is appearing both at beginning of the page, as well as on the sidebar. And you are right, but I am under the impression that if the skin is vector 2010, the toc only appears at the beginning of the page, but if the skin is vector 2020, the toc only appears on the sidebar, no?

What is happening now is that the toc appears on both the beginning of the page and the sidebar when the skin is vector 2020, I am actually OK with this, but the problem is that it is not consistent, on some page it appears on both places, on some page it only appears on sidebar.

Pretty sure it has something to do with Lingo, because if you look at this test page https://papals.org/index.php?title=Test4, notice that it does not have the word "GU" (which is in the glossary list) on the page, and the toc only appears in sidebar. But on https://papals.org/index.php?title=Test3, it does have "GU" at beginning of the page, which triggered Lingo to render the tooltip, and the toc appears on both places.

@Paulxu20, we should probably call it "vector-2022"? Indeed, it looks strange. The page Reading/Web/Desktop Improvements/Features/Table of contents describes the concept of the new TOC, saying that "We intentionally do not add the old table of contents to the article in addition to the new sidebar location". Please, let me know if you use caching (varnish / redis / cloudflare / file cache / etc.).

Hi @Elcapitan68, for caching APCu is used. In the LocalSettings.php it is set like this: $wgMainCacheType = CACHE_ACCEL;

I am not sure if this is the best caching option performance wise, but it has been working ok to me.

@Paulxu20 I see. It looks like a side effect of the way src/LingoParser.php works. It re-renders the page injecting its elements and is not aware about the latest Vector specifics. I will create a ticket for investigating and fixing this.

In the meanwhile I suggest hiding the in-page TOC with CSS on MediaWiki:Vector-2022.css, like this:

#mw-content-text #toc {

  display: none;

}

I created the bug report https://phabricator.wikimedia.org/T348465

Possibly a caching issue

Whenever i tried to add new terms or making changes in existing lingo terms, those changes are not reflecting on my media wiki pages but i could see the terms i added is reflecting on my terminology page. Can anyone help on this issue ?

@Boopalag, can you share screen shorts of expected and actual behavior and the version of Lingo you're running including the version of MediaWiki?

Hi X-Savitar, Thanks a lot for response, Now the issue is little different.

Actually we are able to see the tooltip but there is a delay for the tooltip to be visible after a new Glossary term is added (approx 4-7 days delay). Sometimes its reflecting within a day and sometimes after a week (there is no uniform pattern).

Any suggestions to make the tooltip visible immediately after a new term is added?

Mediawiki - 1.35.3 with the Lingo version - 3.1.1 (8ae42ff)

We'll see if we can reproduce this.

We're guessing that this was caused by the old tooltip being stuck in your parser cache. To avoid this, check Manual:$wgInvalidateCacheOnLocalSettingsChange and Manual:$wgCacheEpoch then touch (save) your LocalSettings.php file. Please let us know if that solves your issue.

Fix was merged

Just wanted to point out that there is an open change regarding an issue with Parser::getOutput being null.

See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Lingo/+/745880

There is a discussion. It would be great if a maintainer could join in.

We'll check.

Issue could not be reproduced.

My previous thread on Support desk: Topic:Xhcx9i52jjtxukye

While operating "Special:Movepage" on my wiki, MediaWiki reports this error output. The version of Lingo is 3.2.0. After disabling Lingo from the LocalSettings.php, the error output disappeared. So I'm pretty sure it's Lingo's bug.

[b3d9824b43681dbc22c65592] /index.php?title=Special:%E7%A7%BB%E5%8A%A8%E9%A1%B5%E9%9D%A2&action=submit   LogicException: This ParserOutput contains no text!
Backtrace:
from /www/wwwroot/sonicwiki/includes/parser/ParserOutput.php(363)
 #0 /www/wwwroot/sonicwiki/includes/parser/ParserOutput.php(412): ParserOutput->getRawText()
 #1 /www/wwwroot/sonicwiki/extensions/Lingo/src/LingoParser.php(182): ParserOutput->getText()
 #2 /www/wwwroot/sonicwiki/extensions/Lingo/src/LingoParser.php(78): Lingo\LingoParser->realParse()
 #3 /www/wwwroot/sonicwiki/extensions/Lingo/src/Lingo.php(61): Lingo\LingoParser->parse()
 #4 /www/wwwroot/sonicwiki/includes/HookContainer/HookContainer.php(338): Lingo\Lingo::Lingo\{closure}()
 #5 /www/wwwroot/sonicwiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
 #6 /www/wwwroot/sonicwiki/includes/HookContainer/HookRunner.php(1201): MediaWiki\HookContainer\HookContainer->run()
 #7 /www/wwwroot/sonicwiki/includes/content/ContentHandler.php(1736): MediaWiki\HookContainer\HookRunner->onContentAlterParserOutput()
 #8 /www/wwwroot/sonicwiki/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput()
 #9 /www/wwwroot/sonicwiki/includes/Revision/RenderedRevision.php(266): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
 #10 /www/wwwroot/sonicwiki/includes/Revision/RenderedRevision.php(237): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
 #11 /www/wwwroot/sonicwiki/includes/Revision/RevisionRenderer.php(221): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
 #12 /www/wwwroot/sonicwiki/includes/Revision/RevisionRenderer.php(158): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
 #13 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
 #14 /www/wwwroot/sonicwiki/includes/Revision/RenderedRevision.php(199): call_user_func()
 #15 /www/wwwroot/sonicwiki/extensions/TemplateData/includes/Hooks.php(99): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
 #16 /www/wwwroot/sonicwiki/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\TemplateData\Hooks::onMultiContentSave()
 #17 /www/wwwroot/sonicwiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
 #18 /www/wwwroot/sonicwiki/includes/HookContainer/HookRunner.php(2613): MediaWiki\HookContainer\HookContainer->run()
 #19 /www/wwwroot/sonicwiki/includes/Storage/PageUpdater.php(901): MediaWiki\HookContainer\HookRunner->onMultiContentSave()
 #20 /www/wwwroot/sonicwiki/includes/MovePage.php(997): MediaWiki\Storage\PageUpdater->saveRevision()
 #21 /www/wwwroot/sonicwiki/includes/MovePage.php(673): MovePage->moveToInternal()
 #22 /www/wwwroot/sonicwiki/includes/MovePage.php(520): MovePage->moveUnsafe()
 #23 /www/wwwroot/sonicwiki/includes/specials/SpecialMovepage.php(737): MovePage->moveIfAllowed()
 #24 /www/wwwroot/sonicwiki/includes/specials/SpecialMovepage.php(216): MovePageForm->doSubmit()
 #25 /www/wwwroot/sonicwiki/extensions/Translate/src/PageTranslation/MoveTranslatableBundleSpecialPage.php(155): MovePageForm->execute()
 #26 /www/wwwroot/sonicwiki/includes/specialpage/SpecialPage.php(701): MediaWiki\Extension\Translate\PageTranslation\MoveTranslatableBundleSpecialPage->execute()
 #27 /www/wwwroot/sonicwiki/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()
 #28 /www/wwwroot/sonicwiki/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
 #29 /www/wwwroot/sonicwiki/includes/MediaWiki.php(904): MediaWiki->performRequest()
 #30 /www/wwwroot/sonicwiki/includes/MediaWiki.php(562): MediaWiki->main()
 #31 /www/wwwroot/sonicwiki/index.php(50): MediaWiki->run()
 #32 /www/wwwroot/sonicwiki/index.php(46): wfIndexMain()
 #33 {main}

System Versions:

MediaWiki	1.39.3
PHP	8.1.13 (fpm-fcgi)
MySQL	8.0.24
ICU	70.1
Lua	5.1.5
Pygments	2.11.2

I wonder if it's related to PHP 8. We'll see if we can reproduce this.

@WrOffi, I've not been able to reproduce this. Does the page you're moving have translations?

Can you share with me some steps on reproducing?

I've tried moving a regular page without translations and it works well. Looking at the backtrace, I see something related to the translate extension so I want to be sure because this could be affecting translation pages with Lingo.

Possibly related to Extension:SpamBlacklist (There was a somewhat similar issue with a different extension that only showed up when SpamBlacklist was installed).

I've tried to disable SpamBlacklist and reactivate Lingo, but it shows up the error again.

After disabling Lingo, everything works fine

@WrOffi, my suspicion is that this could be related to the Translate extension together with Lingo. When I have Lingo in isolation, it works fine but seems on translation pages, this causes the issue (have not yet reproduced it since I don't have the extension locally).

If you disable the Translate extension, does the "move" action work?

I think the best way to test this is to disable all other extensions and see if the issue still exists. If not, enable extensions one at a time until you find the culprit.

Resolved by installing from archive via ExtensionDistributor. Composer command to override the locked extension version is suggested as well.

Hello,

I would like to install Lingo extension on Mediawiki 1.35.6; however, it seems that Lingo is not compatible anymore with the version I have. Currently I don't want to upgrade to MW 1.39. Is their any solution for that?

Mediawiki: 1.35.6

PHP: 7.4.33

MySQL: 8.0.33-0ubuntu0.20.04.1

Update:

Although it says on the repo https://github.com/wikimedia/mediawiki-extensions-Lingo that the extension requires MW 1.31 or later the extension still does not work in my case. After adding wfLoadExtension( 'Lingo' );

And then updating through php update.php /maintenance/, i get the error below: (Also the webpage turns to blank)

#0 /var/www/html/pmbd/includes/registration/ExtensionRegistry.php(258): ExtensionRegistry->re

#1 /var/www/html/pmbd/includes/Setup.php(161): ExtensionRegistry->loadFromQueue()

#2 /var/www/html/pmbd/maintenance/doMaintenance.php(91): require_once('/var/www/html/p...')

#3 /var/www/html/pmbd/maintenance/update.php(253): require_once('/var/www/html/p...')

#4 {main}

Thanks for the help :)

Please, tell us what version of Lingo are you using. If you installed it from git, what is the branch you are on?

Thank you for your reply.

I am installing Lingo through Composer through adding the following code.

{

"require": {

"mediawiki/lingo": "^3.0",

}

}

Since I am using "^" before the version number I guess then its grabbing any or latest version of Lingo.

You are right, "^3.0" pulls the latest version, which is 1.39 compatible. For MediaWiki 1.35 please try "3.1.1":

{

"require": {

"mediawiki/lingo": "3.1.1",

}

}

Thank you for your reply.

I have added the line you suggested in composer.local.json. Afterwards I use composer.phar to update using the command: sudo php composer.phar update –-no-dev –-prefer-source

and now i am getting a different error proposed by the composer as shown below:

Your requirements could not be resolved to an installable set of packages.

  Problem 1

   - The requested package mediawiki/lingo (locked at 3.2.0, required as 3.1.1) is satisfiable by mediawiki/lingo[3.2.0] but these conflict with your requirements or minimum-stability.

Ill be grateful if you can help me fix this issue, Thank you in advance.

I think the correct way to overwrite the version locked in your root composer.json would be:

sudo php composer.phar update --no-dev --prefer-source mediawiki/lingo

I think its working now, i just installed the tgz file that is related to REL135. I will test the extension and report back if everything is working normally. Thank you for your support. I will mark this issue as resolved once i test the extension

Any success here @AIDInn - pmbd?

Sorry for the late reply, so far no issues. I will mark this issue as resolved. Thank you so much you for your support.

We'll aim to make sure new versions are properly tagged. MediaWiki version bumps may be only a minor version bump and not a major one.

The description page currently states "3.1.2 (2023-01-06)". But apparently version 3.1.2 is from about 2021-06-21 [1]. Current version 3.2.0 seems to be from 2023-01-26 [2]. Neither 3.1.2 nor 3.2.0 are currently officially tagged [3][4].

Could you please apply the version tags to the repository?

• [1] https://github.com/wikimedia/mediawiki-extensions-Lingo/commit/6899b0fc8e2b6de50a9e55ad845629d052d922f7
• [2] https://github.com/wikimedia/mediawiki-extensions-Lingo/commit/8cf46aa5df030c6bce68015fb305a26f93b9fa6c
• [3] https://github.com/wikimedia/mediawiki-extensions-Lingo/tags
• [4] https://packagist.org/packages/mediawiki/lingo

We're checking on this.

Thanks!

Also, please be aware that the extensions requirement to MediaWiki core got raised from 1.31 to 1.39 in a minor level release. While MediaWiki 1.31 clearly isn't supported anymore, 1.35 is a LTS release.

I believe such changes in the requirements qualify for a major release.

Thanks for the heads up. The extension had been unmaintained for a while and we took over maintenance recently, which is probably why you saw the big version jump.

Note that we don't follow semver. It still might make sense to bump a major version in this case, but my sense is that a major version bump would be done only for major feature changes.

We created the 3.2.0 tag. Please check.

Confirmed. Thank you very much.

Regarding the major version change. Well, one can probably see it this way. And especially in the MediaWiki world it is super hard to maintain compatibility to the different versions out there (two LTS, one current stable).

In my point of view, if the code changes in a way that it breaks in environments that it likely has been running in (like MediaWiki LTS versions, PHP versions, ...) a major version bump should be done, even if the features themselves did not change.

So according to the SemVer spec, this should only be a minor or patch version change not a major one . My understanding of the logic behind that, is a major version change is supposed to signify that how you have to use the extension has changed in some significant way. If someone updates their version of php or MW, having the extension have only a minor version update signifies to users that they can just drop the new version in and expect no user facing changes, where a major version would indicate that they should be prepared to have to change how they use the extension.

On the other hand, lots of people do update major version number for these sorts of things, and versioning always ends up being arbitrary anyhow.

You are probably right. But my case is very simple and I believe I may not be the only one this this case:

1. I run MediaWiki 1.35, which is an LTS and officially supported until end of this year. Therefore even though I am late with updating to MediaWiki 1.39 it is still okay to run it.
2. I am updating Extension:Lingo and expect to get new features (indicated by the minor level version bump)
3. My wiki breaks. I either need to update my wiki as a whole or need to roll back Extension:Lingo. It is hard for me to figure out to which version I can safely update to within my environment.

Hmm, that's a good point.

The obvious solution is that composer should know about the mediawiki version dependency and make smart choices. The SemVer logic only works if composer is aware of all the extensions dependencies. Unfortunately support for that going forward is unclear - https://phabricator.wikimedia.org/T249573 [Edit: I don't like this solution either]

Hmm, i guess we could use conflicts key. That should avoid most of the downsides

Patch is merged.

Deprecated: Use of Parser::$mDoubleUnderscores was deprecated in MediaWiki 1.35. [Called from Lingo\LingoParser::shouldParse in ..\mediawiki\extensions\Lingo\src\LingoParser.php at line 391]

I'm currently upgrading MW from 1.35 to 1.39 and now receive this deprecation notice. Will this be fixed in time for the stable release?

There is a patch in progress to fix this.

The lastest patch has been merged, can you test it with the patch merged (master) and let me know if you still face this issue?