It's highly unlikely that you get 3.1.1 using git. That's just the reported version because the maintainer did not update the version number to something like 3.1.2-dev, or whatever, before starting to fix stuff.
If you want to use composer, I would suggest to install dev-master. Alternatively (or additionally) you could get in touch with the maintainer and ask them to release a new version.

If it helps, I am the previous maintainer and I am happy with the request.
I am also available to discuss the design, if needed. Whatever I remember, anyway.

@Krinkle, If you want to change the description like that, I think you should include a definition of what exactly you mean by "installation". Otherwise this might come off as an attempt to obfuscate the obvious drawbacks of using only extension.json without composer.json. I think most people would understand downloading an extension and putting the wfLoadExtension into LocalSettings as "installation".

Yes. :)

Reopening: Lingo uses compatibility policy master. Current supported MW versions are 1.31+.

Problem is that Lingo 3.1 uses getText(), which is not available in MW 1.31 yet. Your best bet right now is to downgrade to Lingo 3.0 (or upgrade MW)

Thanks to everybody who helped to solve this issue. Much appreciated!

Nice catch!
I don't think a config option is necessary, but if you could provide a patch implementing the first proposal, that would be really appreciated.

We have a second issue now: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4330
It's reported in SMW, but really breaks in Lingo.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/533559 would probably also solve the issue, although I am not sure I like this kind of special value. I think introducing a hasTitle() method would be preferable.
In any case, also this would need changes in extensions that currently rely on an is_null() check, so also for this I would request a deprecation period.

What about checking for $mTitle === null and issuing a deprecation warning?

This is about page names that contain slashes, e.g. any sub-page. Something like https://www.mediawiki.org/wiki/Extension:Page_Forms/Linking_to_forms

So, not deprecated and you don't care.

Could you provide information on where/when this was deprecated?

Thanks! Much appreciated!

Thanks. Indeed, the author has volunteered to take care of the extension, but that usually means "as time permits" and does not mean that they are responsible for every bug and that nobody else is allowed to contribute. There are more than 100 bugs currently open on PF, so I would expect that any help is very much appreciated and for an edge case like yours the best way of getting it fixed may indeed be to do it yourself.

Well, if the author says it is not a bug and you insist that it is, I would suggest you assign it not to the author (which is bad form anyway, usually tasks are claimed) but to yourself and provide a patch.

Hmm, fair point. It's an extension by @Nischayn22 , who is active here. Don't know. Maybe he has an opinion.
If he wants to follow bugs here, that'd be great. Otherwise feel free to close. Or I will do it.

I used urldecode. Not sure if that's the correct way to do it, but it cures the symptom for this particular case.

CI tests for Lingo are run on Travis. The build script for Travis is at https://github.com/wikimedia/mediawiki-extensions-Lingo/blob/master/build/travis/script.sh

I had a look at your site. If you want you could put

mainpage

as content into the page MediaWiki:Skin-chameleon-navmenu-flatten which should result in the link to the Main Page being directly available on the navbar instead of in a dropdown menu.
It's not a terribly well documented feature, but have a look at the description of the flatten attribute here: https://github.com/cmln/chameleon/blob/master/docs/components.md#attributes-13

Good to hear. And thanks! :-)

I just tried it here and it works without problems. Here is a transcript: https://pastebin.com/w6256fgH
(The file structure is a bit different on Ubuntu than on RHEL and the www user is www-data instead of apache, but that should not make a difference.)

It's odd. Normally the composer package type should tell composer to put the skin into the skins directory and the extension into extensions.
It looks like for some reason composer is ignoring the type. The only other idea I have for the moment would be to delete the /vendor/mediawiki folder with all its contents and then try running composer update again.

Could you try also adding

		"composer/installers": "^1.0.12",

to your composer.local.json, then running composer update "composer/installers" and finally composer update "mediawiki/chameleon-skin" again?

Not observed anymore in latest master. Pages in the Special namespace, incl. Special:Preferences are not annotated anymore.

Fixed in 841b7d4

I reworked the structure and styles of Lingo. It would be great if somebody could install the latest master and give me an update on this bug.

This may or may not be fixed with bee2f0a, but I don't have PageSchemas installed. Please check.

Fixed in bee2f0a. Tooltips outside the main content (including all Special pages) is now disabled.

Should be fixed in bee2f0a provided that the parserfunction is called from the main article text (i.e. not from some UI message or similar).

Fixed in bee2f0a

The original issue was about composing the glossary of templates. This is not possible as Lingo works on the original wikitext, so no expansion of templates is done. A partial fix for this was introduced some time in 2013 I think. Since then Lingo ignores any line not starting with a : or ;, so it is at least possible to use e.g. headlines to structure the glossary a bit.

The call to Hook::run should be no problem. Hooks allow extensions to register functionality. In this case an extension on top of PF could use this hook to modify $free_text before it is added to $wiki_page. If nothing is registered the hook does nothing.

The target content is returned by $wgPageFormsFormPrinter->formHTML in class PFAutoeditAPI, line 933:

			list ( $formHTML, $targetContent, $generatedFormName, $generatedTargetNameFormula ) =
				$wgPageFormsFormPrinter->formHTML( $formContent, $isFormSubmitted, $pageExists, $formArticleId, $preloadContent, $targetName, $targetNameFormula );

The call into MW to store the page is in class PFAutoeditAPI, line 448:

$status = $editor->internalAttemptSave( $resultDetails, $bot );

Seems to be an issue with the dependency handling. I see the issue on https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:AjouterDonn%C3%A9es/20160211/x?debug=true, but not on https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:AjouterDonn%C3%A9es/20160211/x.
It is probably related to 8327fc9c06 only insofar as that patch changed loading times for scripts.

No idea. Is this on a public wiki?

Interesting. Is there more documentation available? A quick search on mw.o didn't find anything.

Depends on what you consider the full suite. After everything is set up on Travis it runs php ../../tests/phpunit/phpunit.php --group extensions-lingo -c phpunit.xml.dist, i.e. everything from the extension-lingo group. This includes integration testing from Lingo\Tests\Integration\ArticleAnnotationTest. See Lingo/build/travis/script.sh for details.

It's doing fine: https://travis-ci.org/wikimedia/mediawiki-extensions-Lingo/builds/314503631

Without additional term in the text (Should read "FTP 1", "File Transfer Protocol" belonging in the tooltip):

Well, yeah, thaks. That was me trying to find a workaround. Problem is it does not work. The package is still installed to the vendor dir.

@Bawolff: Maybe. Then again I never got a single issue with this in the last 4 years.

Done.
Would be great if somebody could suggest a way how the "skin there [can] be fixed somehow to not have web-loaded resources in the vendor directory". Preferably without dumping Composer entirely.

The applied patch also blocks legitimate file access, e.g. to style files, fonts, etc. See https://github.com/cmln/chameleon/issues/55

Thanks for the quick fix!

That's a problem in Lingo that should be fixed in the latest version. Please update.
If the problem remains, please re-open.

In T147683#2783827, @Legoktm wrote:

• https://gerrit.wikimedia.org/r/320655 - readds the getSearchEngine function for 1.28 only
• https://gerrit.wikimedia.org/r/320658 - documents that getSearchEngine is removed in 1.29.

I hope this is an acceptable compromise.

Would be great if you could give it a stab.
I have no idea what's going on here. There is also T123968 which may be related.
First thing I would try to find out is if maybe Lingo at some point accesses or creates a generic User object that lacks permission to do something or other. Another approach might be to find out where exactly the 401 is triggered and go backwards from there.

Fixed in https://github.com/cmln/chameleon/commit/07003af7734fb6ff0161a49a6662b68630c642d2

Moved to https://github.com/cmln/chameleon/issues/9

Fixed in https://github.com/cmln/chameleon/commit/add4fcf23b5cec78aae93869c3bd7eaba37f5c43

Moved to https://github.com/cmln/chameleon/issues/8

Moved to https://github.com/cmln/chameleon/issues/7