Hi @Janezdrilc, thanks for taking the time to report this!

I never know if this is Wikidata or ULS territory... :-/

Well, Wikidata was unable to fix it, so it must be ULS ;-) (Have no idea what that is - United Lua States???)

"In other projects" section is also missing ... (just for note).

@Janezdrilc: See the project tag I added. :) https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector

It is not ULS either. It's coming (or rather no language links are coming) from PHP side. It seems Wiktionary main pages usually manage their language links manually (the few ones I checked).

I believe the interwiki links still have to be added in the page text for this page

I think the cause is that, unlike in every other project, Wikidata interwikis are not enabled in the main namespace in Wiktionary (main space interlanguage links are provided by Cognate rather than Wikidata). The same issue is present on srwiktionary (except for that 50 interlanguage links are shown using the good old [[en:]] syntax, but WD has 162 pages apart from the Serbian one), but not on enwiktionary; slwiktionary and srwiktionary have their main pages in main namespace, enwiktionary has in project namespace. Either main page should be special-cased, or a parser function (opposite of noexternallanglinks) should be created to force showing the interwiki links in namespaces where it wouldn’t show up otherwise.

In lmo.wiktionary.org the section "in other language" does't work. The reason could be the same.

I don’t think this bug has much to do with Cognate other than the fact that Wikibase interlanguage links are disabled in mainspace because Cognate provides the required functionality.

As I understand it, what @Tacsipacsi writes is correct. Wikidata sitelinks are disabled on the main namespace of Wiktionary wikis, because that namespace is intended for the actual entries (words), not for things like the main page of a wiki. Typically that main page is in the Wiktionary: namespace (or a localized variant). See for example https://en.wiktionary.org/wiki/Wiktionary:Main_Page

As I understand it (please verify!), all that is needed to change what the main page of a Wiki is:

1. to move the actual main page to the Wiktionary namespace if it exists or its localized variant
2. to edit the page MediaWiki:Mainpage to the name/location of the new main page, including the namespace. See for example: https://en.wiktionary.org/wiki/MediaWiki:Mainpage
3. to make sure the correct page is linked on https://www.wikidata.org/wiki/Q5296#sitelinks-wiktionary

Given that this seems to affect a lot of wiktionaries, this should probably be documented properly somewhere.

@Tacsipacsi please find here a Guide based on the information provided above by @Michael
https://meta.wikimedia.org/wiki/WIT/Resources/Wiktionary-missing_Wikidata_sitelinks

We would be very interested to hear about successful page moves, or any problems encountered.

In T210784#9602604, @Michael wrote:

As I understand it, what @Tacsipacsi writes is correct. Wikidata sitelinks are disabled on the main namespace of Wiktionary wikis, because that namespace is intended for the actual entries (words), not for things like the main page of a wiki.

The project namespace is for internal stuff like discussions and policies for editors. Reader-facing stuff like entries and the main page is best placed in a content namespace like the mainspace. As noted on https://meta.wikimedia.org/wiki/WIT/Resources/Wiktionary-missing_Wikidata_sitelinks, the main page being in project space is the exception, not the rule (approximately one third of main pages are in the project namespace, and probably quite a few of these are precisely to work this bug around).

In T210784#9739993, @Danny_Benjafield_WMDE wrote:

@Tacsipacsi please find here a Guide based on the information provided above by @Michael
https://meta.wikimedia.org/wiki/WIT/Resources/Wiktionary-missing_Wikidata_sitelinks

Apart from it being a workaround rather than a solution IMO, please don’t encourage people to put random stuff in Common.js. It’s not necessary either – just allow Wikidata do its job: remove {{noexternallanglinks}} if it’s present. This hack is a remnant from times before Wikidata and compact language links, when maintaining language links was a pain, and displaying all language links resulted in a mess. It’s no longer necessary.