Open main menu

Extension talk:Lingo

About this board

Edit and save a Header section caused popup to fail in all other letters (header sections) until full page was saved

5
WikimeSteve (talkcontribs)

We have 800 items in our list. We have headers for each letter so users can jump down the list. I had the Edit source showing next to each header. First person to edited the "P" section. When they saved their work only the "P's" where showing the popups. All other items failed to show the underlining or mouse over effect at all. I placed the whole page in Edit and saved it without making any change. All popups began working again. I tested this myself with the "H" section and got the same result.

I have included __NOEDITSECTION__ on the page. I did try to read through this discussion page but found nothing about this. I looked over the main page and then this discussion but see no one else talking about this. Is this expected?

MediaWiki 1.31.0

Lingo 3.0.0

F.trott (talkcontribs)

No, it is clearly a bug.

Normally marking up a page consists of reading the glossary page and using it to do the mark-up whenever a page is saved. Obviously this poses problems for the glossary page itself, as the new glossary does not really exist yet when the page is saved and you do not want to use the old one. So it takes a special hack, where the glossary is built directly from the saved text instead of from the saved page. My guess right now is that Lingo only ever sees the part that has changed on section edit.

Your workaround with __NOEDITSECTION__ is probably the best solution for the moment. Or you could disable the popups on the glossary page.

WikimeSteve (talkcontribs)
F.trott (talkcontribs)
WikimeSteve (talkcontribs)
Reply to "Edit and save a Header section caused popup to fail in all other letters (header sections) until full page was saved"
Koemski (talkcontribs)
F.trott (talkcontribs)

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 (talkcontribs)

Oops, sorry, I see the difference now. I had Javascript deactivated.

StasR (talkcontribs)

Add in LocalSettings.php:

$wgMFRemovableClasses['HTML'][] = '.tooltip_tip';
Koemski (talkcontribs)

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

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

thanks!

89.13.133.169 (talkcontribs)

does not work here. Any other hints?

This post was posted by 89.13.133.169, but signed as anon.

Dan.mulholland (talkcontribs)
F.trott (talkcontribs)

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.

VictorClaessen (talkcontribs)

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 (talkcontribs)

Oh wait you can suppress them with: $wgMFRemovableClasses = [ 'base' => [ '.mw-lingo-tooltip' ] ];

F.trott (talkcontribs)

Thanks for the update, Victor. I'll add it to the config instructions.

Reply to "not working with MobileFrontend"
Mmiller0712 (talkcontribs)

There is an issue rendering inside lists with VE

Reply to "lists"

Can not save user options when i use Lingo 2.0.2

13
Fiedwhs (talkcontribs)

Hallo.

I have a problem with saving my account user options when the extension Lingo is enable. I have updated my Mediawiki on 1.27.1. Additionally i have updated all used extension's also Lingo.

So i will edit my account user option and click to save all Parameters go back to the default value. If Lingo disable in the LocalSettings.php i can save every changes i've made. I've also tested Lingo 2.0.0 but it's the same effect.

I've tested the old Version 1.2.0 of Lingo and the user option works properly.

All other function's like browse pages, edit pages, view special pages and so on are okay.

My environment:

PHP 5.6.3

MySQL 5.6.21

Mediawiki 1.27.1

used extension's:

Lingo 2.0.2

Cite (bundled)

ImageMap (bundled)

pChart4mw 1.4.0

SyntaxHighlight 1.0.8.11

F.trott (talkcontribs)

Thanks for the report. I'll have a look.

Sophivorus (talkcontribs)

I had this problem too and it took me a long time to figure out. Please fix!

F.trott (talkcontribs)

Sorry about this and I'm afraid I don't have enough time to investigate this right now.

As an interim solution you could try to exclude the NS_SPECIAL namespace. See Extension:Lingo#Customization ($wgexLingoUseNamespaces).

F.trott (talkcontribs)

Just tried this with MW 1.27.1 and Lingo 2.0.2-dev (latest master actually). No problems.

Egel (talkcontribs)

We have the same problem with Lingo 2.0.1 and setting $GLOBALS['wgexLingoUseNamespaces'][NS_SPECIAL] = false; didn't solve it. Putting __NOGLOSSARY__ in MediaWiki:Preferences-summary didn't fix it either.

F.trott (talkcontribs)

Do you get any JavaScript errors?

5.97.176.194 (talkcontribs)

No JavaScript errors or other error messages are displayed.

F.trott (talkcontribs)

You could try getting more error messages by turning error reporting on: Manual:How_to_debug#PHP_errors.

Also, is this on a public wiki where I could get an account and see the problem myself?

Without seeing the problem (or getting any lead) I can't do anything. When I try it on a local wiki I have no problems. :(

F.trott (talkcontribs)

I think I fixed this in Lingo 2.0.3. It would be great if you could check and confirm.

130.76.24.20 (talkcontribs)

I also observed this error running MW 1.27.3, PHP 7.0.11, and a Lingo 2.0.2-version (the one currently provided by the REL1_27 version on the Extension Distributor - commit 66da4b0)

Updating to Lingo 2.0.3 resolves the problem for a test instance of my site. Unfortunately we need a REL1_27 version to go into production. Could you backport the relevant fixes?

F.trott (talkcontribs)

This was fixed 3 months ago in Lingo 2.0.3. Please upgrade. Cheers.

F.trott (talkcontribs)

The extension distributor is more or less useless for any extension not provided by the WMF. Lingo 2.0.3 should be compatible with MediaWiki 1.26 or later.

Is there a way to specify multiple technology pages and have pages in different languages use different pages ?

2
2620:0:1AF0:F100:B9F2:CC22:55FF:AA12 (talkcontribs)

We are using the MediaWiki Language Extension Bundle, and all of our pages are translated using the Translate extension. Is there a way to make Lingo work in that setting, so that pages in French show French terminology, and pages in English show English terminology ?

F.trott (talkcontribs)

That's not foreseen.

Reply to "Is there a way to specify multiple technology pages and have pages in different languages use different pages ?"

Getting ERR_EMPTY_RESPONSE with Lingo 2.0.3 and MW 1.27.4

1
Jlemley (talkcontribs)

Thanks for fixing the issue with Preferences not saving. Using Git, I updated to the master branch and confirmed that the fix is working. However, on save, I am getting ERR_EMPTY_RESPONSE in Chrome and Page Cannot be Displayed in IE. There are no other errors, the debug log shows that the Post is succeeding, but the page is not reloading.

I also got this error when viewing my terms page and attempting to view historical revisions (I am using Approved Revisions, but not sure if this is relevant).

When I check out the specific commit where the preferences fix was done (d03c2d0a00b0b0ad5890eb646fec6567b24edb3f), everything works great. But any commit after that produces the errors.

Edit: After further testing, the error started happening with the above commit, as well. I checked out the commit before it (2cd9912db7d2f782558cbb0918a6c8f47a370068) and now everything appears to be working correctly again - and preferences are saving. I hope you are able to reproduce the issue. It's an odd one.

Thanks!

Reply to "Getting ERR_EMPTY_RESPONSE with Lingo 2.0.3 and MW 1.27.4"

Terminology page does not display markup

6
Kmlancaster (talkcontribs)

I just started using the extension. For a bit my Terminology page showed the correct mouseover. Then, I added __NOGLOSSARY__ to my Terminology page and now mouseover doesn't work anywhere on the wiki. I have refreshed pages and I have also tried removing __NOGLOSSARY__ from the Terminology page and mouseover has not returned.

F.trott (talkcontribs)

That's a new one. I don't think I ever heard of somebody trying __NOGLOSSARY__ on the Glossary page itself.

In any case, with __NOGLOSSARY__ taken off, what happens if you take one of the pages where a tooltip should apear and do a null edit, i.e. go to the edit page and save without a change?

F.trott (talkcontribs)

FWIW, Lingo looks at the raw wikitext of the Glossary page to build it's dictionary, so adding something unexpected will probably derail it. Would be nice of course if it gave at least a warning, but for that I'd need to have a look at the exact failure mode. No time right now, I'm afraid.

Kmlancaster (talkcontribs)

A null edit doesn't cause mouseover to return.

I used __NOGLOSSARY__ on the Terminology page because I figured you didn't need something defined by mouseover on the same page as you're giving the definitions.

Kmlancaster (talkcontribs)

Any further thoughts on this?A

F.trott (talkcontribs)

Unfortunately not. I would have expected the tooltips to reappear once the NOGLOSSARY was out. I will have to try this myself to see what is going on.

Reply to "Terminology page does not display markup"

Lingo breaking formatting when citations at end of line

1
Danny252 (talkcontribs)

We've found an odd formatting issue that pops up when Lingo is enabled. The following code should generate four headings with indented text below them, some with references before the full stop, and some after:

'''Heading 1'''
:Indented text with reference followed by a line break with clear which should clear previous formatting.<ref>Reference1</ref>

'''Heading 2'''
:Indented text with reference followed by blank line only, reference after punctuation.<ref>Reference 2</ref>

'''Heading 3'''
:Indented text with reference followed by blank line only, reference before punctuation<ref>Reference 3</ref>.

'''Heading 4'''
:And so on. All these display as expected in preview mode, including an extra line between 1 and 2. 

<references />

The expected formatting is shown in this image. However, when Lingo is enabled, the formatting is not correctly cleared at the end of any line where a citation comes after the punctuation - see this image. Inspection of the HTML source shows that various formatting tags are not being closed.

This occurs with Mediawiki 1.28.2 with Lingo 2.0.3, but also occurred on 1.24 with an older version of Lingo. --Danny252 (talk) 20:12, 20 June 2017 (UTC)

Reply to "Lingo breaking formatting when citations at end of line"
Summary by F.trott

Fixed in Lingo 2.0.2

Kae (talkcontribs)

MediaWiki 1.28.1. I did all in accordance with instructions, but I've got:

 Problem 1
   - mediawiki/lingo 2.0.1 requires justinrainbow/json-schema ~1.0 -> satisfiable by justinrainbow/json-schema[1.1.0, 1.2.1, 1.2.3                   , 1.2.4, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.6.1, v1.6.0] but these                    conflict with your requirements or minimum-stability.
   - mediawiki/lingo 2.0.0 requires justinrainbow/json-schema ~1.0 -> satisfiable by justinrainbow/json-schema[1.1.0, 1.2.1, 1.2.3                   , 1.2.4, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.6.1, v1.6.0] but these                    conflict with your requirements or minimum-stability.
   - Installation request for mediawiki/lingo ~2.0 -> satisfiable by mediawiki/lingo[2.0.0, 2.0.1].

How to fix it?

F.trott (talkcontribs)

Yeah, just noticed that today. Sorry about that. As a workaround open the file composer.json in the installation directory of MW and replace the line

"justinrainbow/json-schema": "~3.0",

by

"justinrainbow/json-schema": "*",

I intend to release a fixed version next week.

Kae (talkcontribs)

It does not work. I'll better wait for fixed version :)

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

 Problem 1
   - Conclusion: don't install mediawiki/lingo 2.0.1
   - Installation request for mediawiki/lingo ~2.0 -> satisfiable by mediawiki/lingo[2.0.0, 2.0.1].
   - Conclusion: remove justinrainbow/json-schema 3.0.1
   - mediawiki/lingo 2.0.0 requires justinrainbow/json-schema ~1.0 -> satisfiable by justinrainbow/json-schema[1.1.0, 1.2.1, 1.2.3, 1.2.4, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.6.1, v1.6.0].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.1.0].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.2.1].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.2.3].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.2.4].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.0].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.1].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.2].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.3].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.4].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.5].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.6].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.3.7].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.4.0].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.4.1].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.4.2].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.4.3].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.4.4].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.5.0].
   - Can only install one of: justinrainbow/json-schema[3.0.1, 1.6.1].
   - Can only install one of: justinrainbow/json-schema[v1.6.0, 3.0.1].
   - Installation request for justinrainbow/json-schema (installed at 3.0.1, required as *) -> satisfiable by justinrainbow/json-schema[3.0.1].
F.trott (talkcontribs)

Ok, I released Lingo 2.0.2, which should take any version of justinrainbow/json-schema.

Fatal error: Call to undefined function Lingo\string()

5
Summary by F.trott

Fixed in SG 2.2.0/Lingo 2.0.3.

Kghbln (talkcontribs)

No on every access of a template or form page but quite often I get the following fatal:

Fatal error: Call to undefined function Lingo\string() in /.../w/extensions/Lingo/src/Element.php on line 166
Setup
  • MediaWiki 1.27.2 (1c409c5)01:42, 7 April 2017
  • PHP 5.6.30 (cgi-fcgi)
  • MySQL 5.6.28-76.1-log
  • Semantic MediaWiki 2.5.1 (568d058) 01:52, 22 April 2017
  • Semantic Glossary 2.1.0 (8b99684) 20:37, 27 March 2017
  • Lingo 2.0.2 (fa787aa) 21:30, 3 May 2017
F.trott (talkcontribs)

I'm surprised it does not break all the time. Should be fixed in master now.

Kghbln (talkcontribs)

No it did not and the pages were still accessible. However some regular pages totally fataled. Thanks a lot for the fix! Is there a way to get master in with Composer. @dev for Lingo and Semantic Glossary only gives me 2.0.2

F.trott (talkcontribs)

I think it should be safe to just do a git pull in the Lingo directory.

Kghbln (talkcontribs)

Done and the issue can no longer be observed. Cool! Once the next release is done I can still switch back to Composer.

Return to "Lingo" page.