@Pablo-WMDE and I looked at it and here is what we found so far:

• The difference for someone with a Babel box is likely due to the fact that with a Babel box the language is put into the preferred languages and gets rendered server-side. Else it falls into the "in other languages" section and gets rendered client-side.
• The difference in spelling/capitalization seems to come from a mismatch in use of CLDR and ULS. We want it to use the data from https://github.com/wikimedia/mediawiki-extensions-cldr/blob/bdb642e46abe38ee198eeb12994f8ce177054425/LocalNames/LocalNamesEn.php#L45 but it is using the data from https://github.com/wikimedia/jquery.uls/blob/master/src/jquery.uls.data.js#L860 We could reproduce similar behaviour for fkv. Potentially also relevant is the place where we define these special languages: https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/lib/includes/WikibaseContentLanguages.php

The wikibase client side code to render the "termbox v1" aka entitytermsview uses wb.getLanguageNameByCode() which in turn

1. refers to ULS' $.fn.uls.defaults.languages
2. alternatively falls back to the ULS autonym of the language from $.uls.data.languages
3. alternatively falls back to the language code

We seem to witness #2 as #1 does not find a result (one can try $.fn.uls.defaults.languages.dag in the browser). I did not research much further what the difference is between $.fn.uls.defaults.languages & $.uls.data.languages and if we are (still?) using them correctly and if they are (still?) doing what they are supposed to do or what their individual expected results are. Given how wikibase' code currently reaches into ULS it would not be surprising if it is using ULS internals which are not considered part of its public API and the usage of which, as a consequence, is prone for breakages and/or does not automatically benefit from improvements/fixes had inside of ULS - I think it would be good to look into this integration in general once more (should be fairly contained) and tend to some of the concerns which existed from day 1 in the process.

FWIW while $.fn.uls.defaults.languages initially gets created from $.uls.data.getAutonyms() (so it contains "dag", albeit as "dagbanli"), UniversalLanguageSelector seems to "extend" $.fn.uls.defaults (incl the languages key) by mw.config.get( 'wgULSLanguages' ) (which does not contain "dag"), so it does not only not add a translation for "dag" in user language but actually strips "dag" as an option. It is only because of the fallbacks in wikibase code that "dagbanli" (by referring to $.uls.data.languages directly) can be displayed at all. WikibaseContentLanguages does not seem to come into play when shaping the value of mw.config.get( 'wgULSLanguages' ).

Maybe T283168 solves this

Language name is correct in CLDR (in LocalNamesEn.php).

If this is for another issue that should be solved, then the description should be updated and/or a new parent task created.

Change 833397 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Send language names to wikibase.getLanguageNameByCode()

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

Change 833397 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Send language names to wikibase.getLanguageNameByCode()

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

Pulling this into the sprint verification, since it should have been fixed by the above change (as part of work on T311626).