Aug 17 2021
May 26 2021
Jun 3 2020
@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".
Feb 26 2020
Nov 11 2019
Reopening: Lingo uses compatibility policy master. Current supported MW versions are 1.31+.
Nov 10 2019
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)
Oct 21 2019
Oct 18 2019
Thanks to everybody who helped to solve this issue. Much appreciated!
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.
Oct 16 2019
We have a second issue now: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4330
It's reported in SMW, but really breaks in Lingo.
Oct 15 2019
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.
Oct 14 2019
What about checking for $mTitle === null and issuing a deprecation warning?
Oct 13 2019
Aug 25 2019
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
Jul 16 2019
So, not deprecated and you don't care.
Could you provide information on where/when this was deprecated?
May 23 2019
Thanks! Much appreciated!
Apr 21 2019
Apr 3 2019
Sep 25 2018
Jun 22 2018
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.
Jun 9 2018
Jun 8 2018
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.
Jun 5 2018
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
Jun 4 2018
I had a look at your site. If you want you could put
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
Jun 2 2018
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
to your composer.local.json, then running composer update "composer/installers" and finally composer update "mediawiki/chameleon-skin" again?
May 19 2018
Mar 30 2018
Mar 24 2018
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.
Mar 23 2018
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
Mar 22 2018
Mar 15 2018
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.
Mar 9 2018
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.
Mar 8 2018
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 );
Jan 16 2018
Dec 17 2017
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.
Dec 16 2017
No idea. Is this on a public wiki?
Dec 12 2017
Interesting. Is there more documentation available? A quick search on mw.o didn't find anything.
Dec 11 2017
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.
Dec 10 2017
Dec 6 2017
Without additional term in the text (Should read "FTP 1", "File Transfer Protocol" belonging in the tooltip):
Dec 1 2017
Nov 20 2017
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.
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
Nov 10 2017
Thanks for the quick fix!
Nov 9 2017
Aug 12 2017
Jun 14 2017
Jun 12 2017
Jun 2 2017
That's a problem in Lingo that should be fixed in the latest version. Please update.
If the problem remains, please re-open.
May 15 2017
Apr 21 2017
Nov 9 2016
Oct 25 2016
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.