Extension talk:Lingo

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

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

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.

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.

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?

By default, the terminology page is "Terminology" for an English-language wiki, "Terminología" for a Spanish-language wiki. To change this default page, the parameter $wgexLingoPage must be defined in LocalSettings.php and set to the desired page.

I instaled Lingo and added two terms the first time to my Terminology page, and all went fine. But when i tried to add more terms, they don't work, it seems as if the extension just doesn't see them. I tried deleting the content of the page and even removing and reinstalling the extension and nothing happens. What can I do?

Perhaps there is a syntax mistake on the Terminology page? Could you verify? and if you don’t find any error, copy here a minimal Terminology page with the issue and/or give a link if it is a public wiki.

Also, I see Lingo does not support difference of case (see phabricator:T123961), so for instance if you enter the definition

Bug

A default in a software

The word « bug » will not be highlighted by Lingo since the definition has a capital "B".

The terms I entered are always written in lowercase in the articles, that is, exactly as they are in the Terminology page. I followed the syntax as it was on the extension's page here on the MediaWiki. Here's my terminology page.

I was not able to reproduce the issue on a test wiki (MW 1.37.1 + your Lingo version 74e31cc indicated in Special:Version), but given you customized the Lingo terminology page, did you change accordingly the parameter $wgexLingoPage to MediaWiki:Lingo-Terminología (NB the "ex" after "wg", it’s unusual for a MW setting) in LocalSettings.php?

No, I didn't change any parameter. I only checked in MediaWiki:Lingo-terminologypagename to know the name that the page should have, since my wiki's language is Spanish.

This is perhaps the issue: by default the page for terminology is Terminología; if you want to use MediaWiki:Lingo-Terminología instead, it is possible but you have to set $wgexLingoPage = "MediaWiki:Lingo-Terminología"; in the file LocalSettings.php.

You're right!! I moved the content of MediaWiki:Lingo-Terminología to Terminología, and tho it's kind of annoying having that page in the main namespace, it worked! Thank you so much!

I’m glad it works. I close the topic.

This same issue has happened to me.

I am running a local private mediawiki and SOME terms are not "working". i.e. no tool tip is displayed.

Product	Version
MediaWiki	1.37.0
PHP	8.1.2 (apache2handler)
MariaDB	10.4.22-MariaDB
ICU	70.1
Lingo	3.1.2

Tried with Terminology page and specifying a "Glossary" page in settings.

Any ideas?

SG

@GobleStL Please check if this helps Topic:Xb96lwtzsrmne98s

A patch created for and tested on MW 1.39. User successfuly applied the proposed changes on MW 1.38

Implemented Lingo 3.1.2 (836982a) from distributor for 1.38.2. Works fine except cases when the string is followed by a space and a round bracket, such as vl is given tooltip, vl (2) is not. https://www.violinwiki.org/wiki/Musical_instruments_used_in_combination_with_violin

As I can see, "vl (2)" term is not present on https://www.violinwiki.org/mediawiki/index.php?title=Terminology, but "vl" is. Therefore, the tooltip does appear when you are hovering over the "vl" part of the string and does not when you are hovering over the " (2)".

Correct vl (2) is not the term. vl is the term, 2 in brackets is numbering. There is a space between vl and the bracket. But the defect is that the tooltip does not appear when you hover over vl that is followed by the bracket. Examples under heading Examples of standard instrumentations or line "2 fl trans solo, vl (2), vla, b, cor (2)"

The issue looks a bit oscillating, when I checked your page a week ago, I saw the tooltip as expected, I made a screenshot https://drive.google.com/file/d/1DumO8Duo8lP0W90pkH0mGXHeJ8MhKt-r/view?usp=share_link

Quick tests show that the problem perhaps is unrelated to "space+bracket" pattern, look at https://www.violinwiki.org/wiki/User:WikiVisor (only certain terms fail). Will take it for a closer look and update.

You are welcome to do as many tests you need, it might be useful for other users as well. At https://www.violinwiki.org/wiki/User:WikiVisor I see vl (2) and cor (2) as issue but tb (2) shows tooltip correctly.

It seems like it happens where it has a partial match where there is some prefix that would be a match, and there is some additional suffix that would be a match, but the actual text is in the middle, which confuses lingo.

In the particular case - "vl" matches and "vl solo" would also be a match. However, in the case of "vl (2)", lingo matches up to "vl " (vl followed by a space) but after the space, fails to match anything further. Instead of falling back to "vl" it gives up there. So that's why "vl" matches (newline and space are considered differnt) and "vl(2)" would match, but "vl (2)" does not.

Anyways, there is a patch for this issue at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Lingo/+/886439

p.s. I noticed https://www.violinwiki.org/wiki/Terminology has text "This page is not part of main but because of Lingo it has to be in Main.". Just FYI you can change the name of the terminology page by editing the page MediaWiki:lingo-terminologypagename to have whatever name you want.

Sorry guys, could not give you proper test result yet, implemented Lingo 3.1.2 (836982a) from distributor for 1.38.2, the patch is for 1.39 and production environment will not go to 1.39.

Fwiw, nothing in that patch is 1.39 specific. You could probably just make the same changes to an older version of Lingo

Done. a. 836982a install kept, updated src/Tree.php with 886439. Results so far so good. b. updated MediaWiki:lingo-terminologypagename to a template, good as well (I had some trouble during initial tests, no problems now).

User confirmed that the fix now works.

Turning on error reporting show the below.

Product	Version
MediaWiki	1.39.0
PHP	8.1.13 (apache2handler)
Lingo	3.1.1

PHP Caching

APCu Support	Enabled
Version	5.1.21
APCu Debugging	Disabled
MMAP Support	Enabled
MMAP File Mask	no value
Serialization Support	php
Build Date	Jun 25 2022 07:29:23

MediaViewer also has issues and has been disabled so direct viewing of images is fine. But with Lingo I get this:

[d2bd7de25bc67f629e3a1d49] /mediawiki/index.php?title=Glossary&action=submit Error: Call to undefined function Lingo\wfGetMainCache()

Backtrace:

from /var/www/html/mediawiki/extensions/Lingo/src/LingoParser.php(387)

#0 /var/www/html/mediawiki/extensions/Lingo/src/BasicBackend.php(262): Lingo\LingoParser->purgeGlossaryFromCache()

#1 /var/www/html/mediawiki/includes/HookContainer/HookContainer.php(338): Lingo\BasicBackend->purgeCache()

#2 /var/www/html/mediawiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()

#3 /var/www/html/mediawiki/includes/HookContainer/HookRunner.php(2732): MediaWiki\HookContainer\HookContainer->run()

#4 /var/www/html/mediawiki/includes/Storage/PageUpdater.php(913): MediaWiki\HookContainer\HookRunner->onPageContentSave()

#5 /var/www/html/mediawiki/includes/EditPage.php(2596): MediaWiki\Storage\PageUpdater->saveRevision()

#6 /var/www/html/mediawiki/includes/EditPage.php(1904): EditPage->internalAttemptSave()

#7 /var/www/html/mediawiki/includes/EditPage.php(721): EditPage->attemptSave()

#8 /var/www/html/mediawiki/includes/actions/EditAction.php(73): EditPage->edit()

#9 /var/www/html/mediawiki/includes/actions/SubmitAction.php(38): EditAction->show()

#10 /var/www/html/mediawiki/includes/MediaWiki.php(542): SubmitAction->show()

#11 /var/www/html/mediawiki/includes/MediaWiki.php(322): MediaWiki->performAction()

#12 /var/www/html/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()

#13 /var/www/html/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()

#14 /var/www/html/mediawiki/index.php(50): MediaWiki->run()

#15 /var/www/html/mediawiki/index.php(46): wfIndexMain()

#16 {main}

¯\_(ツ)_/¯

Everything else seems good.

This is a fresh build with the aforementioned versions.

Any ideas?

SG

Thank you for your report, we're working on 1.39 compatibility and the issue should have an update soon.

THANK YOU!

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?

THANKS! I will check as soon as I can.

This works for me. No issues.

Nice! Thanks for reporting the issue. I'll go ahead and resolve this topic now.

Lingo is case-sensitive by design. Its purpose is to set and display definitions for abbreviations and Lingo meets it right way.

Hello,

This extension works great as a form of dictionary for my site. However, is there a way where I can have it work in a way of regardless of how a word is capitalized it only counts that as the "first" instance?

For instance, imagine I have the following:

;Madeupword :This word is made up.

If I wanted this to work on both MadeUpWord and madeupword, I have to add them both as separate words following semicolons. However, this is counter-intuitive to the option for only showing the glossary on the first instance of a word.

@Zaksquatch Please, note the extension description: It lets you define a list of abbreviations and their definitions on a page and then displays these definitions whenever an abbreviation is hovered over in an article.

Since it deals with abbreviations, it is case sensitive and, by design, doesn't expect different letter cases for the same abbreviation.

Simple case shift will not solve the problem universally, as there can exist a mixed case terms (eg. "aBC" and "AbC"), etc.

Also please, look at the comment by the previous maintainer.

In your case, setting $GLOBALS['wgexLingoDisplayOnce'] = true; might help to remove the "counter-intuitive" effect, but of course, would add some clutter.

Yeah, I understand I'm using the extension for something a little different than it was intended to be used for. It was the best tool I could find for the job however! I am fine if there isn't a way around it, it was merely a question of curiosity.

Thank you for the response!

@Zaksquatch you are welcome!

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.