The issues seems to be resolved in 1.24wmf3 (test.wiki), so may already have been fixed?

Maybe related: bug 62361 / gerrit 117397.

I can reproduce the issue on beta wikipedia (http://en.wikipedia.beta.wmflabs.org/) but not on my local test wiki.

That suggests some compatibility issue with another extension or maybe config, and not an issue with gadgets, etc.

yep, works for me on test2.wikipedia (e.g. https://test2.wikipedia.org/wiki/0.29259340289161095?useskin=monobook) but concerned about still seeing the issue on beta wikipedia.

• Bug 65131 has been marked as a duplicate of this bug. ***

• Bug 64992 has been marked as a duplicate of this bug. ***

• Bug 65359 has been marked as a duplicate of this bug. ***

Any updates? The issue persists on 1.24wmf4...

Hmm this is weird. I am not seeing the link at all on beta - also with Vector. http://en.wikipedia.beta.wmflabs.org/wiki/Dido_Sotiriou

Config or version difference between beta and test2?

ULS does this (reduced to relevant parts):

$pLang = $( '#p-lang' );
if ( !$pLang.find( 'div ul' ).children().length ) {
if ( mw.config.get( 'skin' ) === 'monobook' ) {

		$pLang.find( 'div.pBody' ).remove();

}
}

There are plenty ways to fix this on both sides, not sure which way we want to have it fixed.

We need to get this fixed in the next deployment. I don't mind which way we fix it. Editors are getting unhappy :(

Change 136453 had a related patch set uploaded by Thiemo Mättig (WMDE):
Keep Monobook skin intact

https://gerrit.wikimedia.org/r/136453

Change 136453 merged by jenkins-bot:
Keep Monobook skin intact

https://gerrit.wikimedia.org/r/136453

It's not really possible to fix this on our side without introducing a really, really ugly hack that re-constructs the removed section of the DOM. ULS removed a vital part of the DOM (thanks Hoo for finding out!).

<div ... id="p-lang" ...>

<h3 ...>(otherlanguages)</h3>
<div class="body">
  <ul>
    <li class="uls-p-lang-dummy"><a href="#"></a></li>
  </ul>
  <div class="after-portlet after-portlet-lang">
    <span class="wb-langlinks-edit ..."><a ...>(wikibase-editlinks)</a></span>
  </div>
</div>

</div>

The "after-portlet" part is a bit newer than the ULS code, see Gerrit I099fb2ff48e02a2e3564a484aea906263e40bb53. Which may be the reason why this broke. Our JavaScript replaces the "edit" link with the "add" widget. Which really is how it should be. Simply adding the link to the remaining "p-lang" as a workaround doesn't work. The CSS would be wrong.

wikirhadamante wrote:

Just a remark, that may be stupid, if so just discard this comment, but there is no such problem on Wikimedia commons, even under monobook. The interface might be slightly different, but pages (at least in the main or in categories) without interwiki offer the possibility to add some (e.g.: https://commons.wikimedia.org/wiki/Beamish_Museum:_Home_Farm).
Clicking on the link "add links" opens a pop-up interface to select a wikipedia version, and then the target page (by the way a similar system was working -under monobook, maybe still working under vector - on fr.wikipedia, better to my mind than the system on en.wikipedia that just sends you directly to the wikidata page).

(In reply to Rhadamante from comment #14)

there is no such problem on Wikimedia commons

Log out first to see the problem.

Please note that the bug is fixed in the software but it takes some time to deploy it to the servers.

Option for adding is now present again, but does not work.
Even if I type langcode and wait for long time, the second field is still grey and is unable to select correct language and all link

Created attachment 15643
screenshot of gray field

Attached:

(In reply to JAn Dudík from comment #16)

Option for adding is now present again, but does not work.
Even if I type langcode and wait for long time, the second field is still
grey and is unable to select correct language and all link

Might be related to bug 66557 instead?

(In reply to Andre Klapper from comment #18)

Might be related to bug 66557 instead?

Indeed, please don't reuse old bugs just because they cover the same component.