Wikimore

This page used the LiquidThreads extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.

Error: Lingo break external link, problem with encoding

Hi, when I add a Link to an external destination containing german “umlaute” then the link doesn’t work if I save the page.
In preview-mode everything works correct, only after saving the page the link is broken.

The Link showing in the text looks ok, it shows me: /Preisübersicht but the link behind the text is broken: /PreisÃ¼bersicht/

If I make a internal link to a page with “umlaute”, this works.

Example:
This works fine: <html><a href="file://folderA\Preisübersicht\">Preisübersicht</a><html>, the generated code by the page is: <a class="external text" href="file:///FolderABC\Preisübersicht\" rel="nofollow"> Preisübersicht</a>

Doesn't work: [file:///folderAB\Preisübersicht\ Preisübersicht]
The code generated by the preview function is: <a class="external text" href="file:///folderABC\Preisübersicht\" rel="nofollow">Preisübersicht</a>
The code generated by the "normal" page (after save) is: <a class="external text" href="file:///folderABC%5CPreis%C3%BCbersicht%5C" rel="nofollow">Preisübersicht</a> this is wrong, the code %C3 + %BC are Ã + ¼

This Error occur only when on the page is also a word from my Glossary. So the complete page text is only:

[file:///folderAB\Preisübersicht\ Preisübersicht]
HTML

(HTML is defined on my glossary Page)
If i delete the HTML-string from the page, everything works fine. So my Problem is the Lingo extension.

Software	Version
MediaWiki	1.21.3
PHP	5.3.27 (cgi-fcgi)
MySQL	5.1.42-community
Lingo	0.4.2

see also: Project:Support_desk#x.5BSolved.5D_Problem_with_Encoding_only_in_external_links_39254 TomyLee (talk) 08:14, 24 February 2014 (UTC)

Noted as bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=62040

You can leave your mail there to follow progress. F.trott (talk) 09:10, 28 February 2014 (UTC)

Using Lingo 0.4.2 (cool extension, thanks ;-) with DocExport extension (tested with Revision 32 and 42 - latest).

When exporting a page containing Lingo highlighted terms (Tooltip), the tooltips text become normal text on export, added to the document's content, i.e. "SMW" becomes "SMWSemantic MediaWiki".

Export is done via the normal GUI interface: "Toolbox" -> "→M$WORD". The "downloaded" file has .doc extension, but its content is .html, as you can check with your favorite text editor.

The solution could be within DocExport extension too (?), but a priori I guess some CSS may be modified on Lingo content.

Thanks, Pierre Pierre66K (talk) 11:27, 10 March 2014 (UTC)

"Export is done via the normal GUI interface"? There is no such thing, and especially not one that exports into M$ Word format. Do you mean Collection (which exports to odt), or which other extension? Nemo 08:16, 11 March 2014 (UTC)

Pierre is using the third-party "DocExport" extension, see the above links. Ricordi samoa 17:12, 11 March 2014 (UTC)

I never used DocExport, so the following is speculation. Right now the tooltips are hidden by CSS. It might work to add a specific style rule for media print. On the other hand the existing rules are not media-specific hence should be applicable to all media. Alas the tooltips can not just be removed from where they are as that would make the extension unusable for JavaScript-disabled browsers.

Any ideas? F.trott (talk) 17:20, 11 March 2014 (UTC)

How to make a link in the tooltip?

In your example screenshot of NORA there is a link in the tooltip to the wiki page NORA. How do I do that? 79.218.108.254 08:34, 27 March 2014 (UTC)

You need Extension:Semantic Glossary for that.

I guess the picture is misleading for a bare Lingo installation without Semantic Glossary. I should probably replace it. F.trott (talk) 08:58, 27 March 2014 (UTC)

Thanks for the answer! Karsten 79.218.111.172 09:51, 28 March 2014 (UTC)

not working with MobileFrontend

Hi,

I discovered that when using the famous extension MobileFrontend, that Lingo displays the Terms followed by the explanation. See the attached Screenshots.

desktop: http://imgur.com/DdmO9B1,FlzrKxT#0

mobile: http://imgur.com/DdmO9B1,FlzrKxT#1

Greetings,

Karsten Koemski (talk) 11:17, 28 March 2014 (UTC)

Hmm, I can not see any difference, seems to be the same screenshot both times.

Also, which versions of MW and Lingo are you using?

Cheers, F.trott (talk) 12:45, 28 March 2014 (UTC)

Oops, sorry, I see the difference now. I had Javascript deactivated. F.trott (talk) 12:47, 28 March 2014 (UTC)

Add in LocalSettings.php:

$wgMFRemovableClasses['HTML'][] = '.tooltip_tip'; StasR (talk) 18:38, 28 March 2014 (UTC)

works with (hypen instead of underline) - tooltips get removed

$wgMFRemovableClasses['HTML'][] = '.tooltip-tip';

thanks! Koemski (talk) 10:52, 29 March 2014 (UTC)

does not work here. Any other hints? Special:Contributions/anon 17:28, 12 August 2014 (UTC)

See https://phabricator.wikimedia.org/T123962#3080840.

tl;dr, use $wgMFRemovableClasses = [ 'base' => [ '.tooltip-tip' ] ]; Dan.mulholland (talk) 17:21, 7 March 2017 (UTC)

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. F.trott (talk) 00:50, 24 March 2018 (UTC)

I installed git commit 6d86e76ee41349d90be947ee9181a7f6b1b8327a from master on mediawiki 1.30 and none of these things work. The tooltips render as separate lines at the bottom of the page. I have not been able to suppress them. VictorClaessen (talk) 22:00, 30 August 2018 (UTC)

Oh wait you can suppress them with: $wgMFRemovableClasses = [ 'base' => [ '.mw-lingo-tooltip' ] ]; VictorClaessen (talk) 22:02, 30 August 2018 (UTC)

Thanks for the update, Victor. I'll add it to the config instructions. F.trott (talk) 05:51, 31 August 2018 (UTC)

Undefined Offset Notice after Update

Since an update, I get <pre>Notice: Undefined offset: 4 in [...]/extensions/Lingo/LingoElement.php on line 116 Notice: Undefined offset: 4 in [...]/extensions/Lingo/LingoElement.php on line 127</pre> on every page that has a Tooltip. Heinrich krebs (talk) 11:06, 15 May 2014 (UTC)

I guess it will be good to also provide information about your environment and about what exactly was updated. Since this very much sounds like a bug anyway you may want to report it at bugzilla [[kgh]] (talk) 11:20, 15 May 2014 (UTC)

Thanks for the Bugzilla link. I was browsing through help files and read, that I should report bugs and errors somewhere else, but didn't quite find out how...

Basically I updated everything. I had the SemanticBundle updated, but after that, nothing worked. So I deleted everything besides /images/ and my LocalSettings.php and started from scratch. Everything I could find using composer, I downloaded with composer.

Lingo being downloaded with this require-Statement: "mediawiki/lingo": "*".

Since then, my wiki works fine, again, more or less. I saw the notice, not just on the webinterface, but also when running runjobs.php (to repopulate the SMW-Tables).

However, since than, the notices have slowly begun to disappear. Mostly if I force Firefox to do a complete reload of the page, via Shift+'Click on Reload-Button'.

Since both instances of the notice have to do with html-classes, I guess there was a problem with caching of css-elements (probably through the database). Heinrich krebs (talk) 11:40, 15 May 2014 (UTC)

I'm guessing that at some point the "ELEMENT_STYLE" was added. $this->mDefinitions[0][self::ELEMENT_STYLE] requires that newly created as well as cached items have an array entry for "ELEMENT_STYLE" in order to work without notices.

It could be that some old cache elements do not contain the "ELEMENT_STYLE" which will lead to an "Notice: Undefined offset" output.

If you purge your Lingo/SG cache (see $GLOBAL['wgexLingoCacheType']) those notices should disappear as the glossary generator is ought to create a valid null entry for the "ELEMENT_STYLE". MWJames (talk) 18:29, 15 May 2014 (UTC)

Thanks for the info.

Is there a script to simply purge all the cache?

I mean I can set $wgexLingoCacheType to CACHE_NONE; but I guess to have it set to NULL, which is standard cache, makes sense, so I'd rather purge the whole cache once... Heinrich krebs (talk) 11:33, 16 May 2014 (UTC)

As for SG (SemanticGlossary) once 1.1 is released, you can rebuild your cache by executing php rebuildGlossaryCache.php [0].

[0] https://gerrit.wikimedia.org/r/#/c/133659/ MWJames (talk) 01:46, 18 May 2014 (UTC)

Thanks. Good to know. Heinrich krebs (talk) 08:12, 19 May 2014 (UTC)

Not Processing Output of Custom Tag Extension

I have a custom tag extension that is returning WikiText like so:

 return $parser->recursiveTagParse($wikitext);

Terms in $wikitext are not being marked up by Lingo. PDugas (talk) 15:57, 20 June 2014 (UTC)

https://bugzilla.wikimedia.org/show_bug.cgi?id=66915 PDugas (talk) 12:15, 7 July 2014 (UTC)

Thanks for the bug report. I'll look into it.

Cheers. F.trott (talk) 15:24, 15 July 2014 (UTC)

Not working with Mediawiki 1.23?

Hi. I've got this installed with a MW 1.23 instance using the composer method.

It shows in the version page and also the link to the terminology page takes me to my terms. However, terms in pages do not have a hover link.

Any ideas?

Thanks. Mitchelln (talk) 10:00, 7 July 2014 (UTC)

Just a thought (I'm no expert) but I think pages need to be recached/regenerated to get the term markup to work. Tried adding ?action=purge or just editing the page? PDugas (talk) 12:17, 7 July 2014 (UTC)

Aha! Purging it and re-creating the glossary definition page worked. Just editing and saving did not though.

Thanks for the suggestion :) Mitchelln (talk) 15:21, 15 July 2014 (UTC)

It's messing with HTML?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I am using MediaWiki 1.22.

With the extension enabled, it somehow takes this code:

</div id="sectionblock1">

And turns it into this code:

</div>id="sectionblock1"&gt;

Which of course displays id="sectionblock1"> in the text of the page. I have such a div for every section on the page, and if there is a glossary term on the page, then it will display this code for EVERY section, no matter which section the glossary term is in.

If I delete the glossary term on the page, the page displays like it's supposed to.

If I disable Lingo, the page displays like it's supposed to.

Why does Lingo break the div coding in this way when it's enabled? The section divs are labeled like this because of the SectionHide extension, and Lingo does not break any other divs, so I'm guessing it's some kind of interaction. Is there anything I can do to fix this? Thanks. Natrashafierce (talk) 23:56, 21 August 2014 (UTC)

Your HTML is invalid, attributes are not defined for closing tags. So the HTML parser has to do some error handling which in this case means inserting the closing > at the appropriate spot. This in turn leads to the id=... being rendered as normal text. Nothing I can do about it, you'd have to change the PHP HTML parser. F.trott (talk) 07:53, 22 August 2014 (UTC)

Thank you! Natrashafierce (talk) 19:19, 23 August 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Composer fails

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I just tried installing this extension through Composer, but every attempt fails with "UnexpectedValueException" ("Could not parse version constraint *", likewise for dev-master).

Some alternative syntax I tried

Putting a double colon between package and version (per instructions for the Chameleon skin), but no luck: [Invalid Argument Exception] ("could not find package * with any version for your minimum stability (stable)").
Likewise, ":~". No luck.
replacing single quotes with double quotes. To no avail.
Using quotes around the package as well. Again, no luck.

I'm at a loss here. Could there be something wrong with the download location? Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 14:37, 20 November 2014 (UTC)

Does the following work: composer require "mediawiki/lingo:*"? F.trott (talk) 14:45, 20 November 2014 (UTC)

That was quick, and yes, it does! Many thanks for that! Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 14:47, 20 November 2014 (UTC)

Thanks for the report! I changed the installation instructions. F.trott (talk) 15:03, 20 November 2014 (UTC)

Thanks, I updated the instructions for Extension:Semantic Glossary accordingly. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 19:56, 20 November 2014 (UTC)

Thanks! F.trott (talk) 20:01, 20 November 2014 (UTC)

Besides, this seems to be an breaking change in Composer or is this just another way to use it. Something like "mediawiki/semantic-media-wiki": "dev-uri-output" still works for me on SMW. If it is not Composer but extension specific I would rather prefer to keep things consistent to other exensions, i.e. as it was before. I guess it is a bit confusing for people to figure out which syntax to use for what extension. I am not saying that I do not like this shorter syntax, in contrary. [[kgh]] (talk) 20:02, 20 November 2014 (UTC)

Ah, there is probably a difference now between using the json file and the require command?! This I do not like at all. :( Still like the new syntax :) [[kgh]] (talk) 20:05, 20 November 2014 (UTC)

That's a complete mess, isn't it? Does that mean that all instructions on how to install via Composer on command line have to be changed? [[kgh]] (talk) 20:08, 20 November 2014 (UTC)

There has been no breaking change in how Composer uses boundary operators, the usage of @dev or dev-master has the same meaning as before. MWJames (talk) 13:23, 23 November 2014 (UTC)

"mediawiki/semantic-media-wiki": "dev-uri-output" should also still work.

This is basically a problem of the shell you use. It will transform strings with quotation marks and hand the result down to the program. So, in essence, Composer has never seen and will never see any of your quotation marks, regardless of which form you use. There are other transformations done by the shell, e.g. * is replaced by a list of files in the current directory if not correctly escaped.

I am still not completely sure why the old form did not work for cavila. Just tried it and it worked like a charm. Could be that it depends on the shell you use, e.g. Windows CLI might work different than Bash. F.trott (talk) 20:17, 20 November 2014 (UTC)

Thank you so much for explaining the details! I am somewhat reassured. However I still see a risk in having the "new" syntax in the docu since it differs to the json. Rather have a note that if this does not work on shell do that. I think this will confuse people like it confused me for a moment. [[kgh]] (talk) 20:28, 20 November 2014 (UTC)

It's only confusing if you assume the shell to understand JSON syntax? Uhm, JSON fragment syntax, that is. :)

Ideally it should not be necessary for a user to ever open composer.json. F.trott (talk) 20:31, 20 November 2014 (UTC)

True, but I personally think it much more convenient to edit composer.json and to have a copy of this. MW 1.24 is dreading. ;) [[kgh]] (talk) 20:40, 20 November 2014 (UTC)

That's right the "normal" user should not nned to edit the composer.json has sh(he) can introduce syntax errors without realizing it.

As for MW 1.24, users have to be aware that an existing composer.json is being overridden and therefore can possibly delete all existing installed extensions if `composer update` is immediately execute after a MW update (because the new composer.json does not contain the extension information and has to be copied by hand or re-added via `composer require`). MWJames (talk) 13:30, 23 November 2014 (UTC)

It's an AMPPS installation of MediaWiki on a local computer with Windows 8.1. Perhaps it's Windows that's behaving differently here. The version of Composer that I'm using is fairly recent (less than two months old). Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:02, 23 November 2014 (UTC)

> Could be that it depends on the shell you use, e.g. Windows CLI might work different than Bash.

I'm using Win and the provided git/bash CLI works in the same way as it does on Linux/Unix. MWJames (talk) 13:32, 23 November 2014 (UTC)

When I use composer require "mediawiki/lingo" "*" the Win Git Bash will expand the "*" with a list of files in the current directory, resulting in the UnexpectedValueException.

composer require "mediawiki/lingo:*" seems to work , so I'll use that for installation instructions. F.trott (talk) 15:00, 23 November 2014 (UTC)

> When I use composer require "mediawiki/lingo" "*"

I think the documentation [0] clearly states on how to use boundary indicators such as `php composer.phar global require fabpot/php-cs-fixer:dev-master` or `php composer.phar require vendor/package:2.* vendor/package2:dev-master`. I'm not sure who introduced the `"mediawiki/lingo" "*"` notion.

Of course the json content is being described by something like `"composer/installers": "1.*,>=1.0.1",` but this relates to the json an not to the CLI usage.

[0] https://getcomposer.org/doc/03-cli.md MWJames (talk) 16:45, 23 November 2014 (UTC)