Page MenuHomePhabricator

Language in Wikidata termbox shows "dagbanli” instead of “Dagbanli
Open, Needs TriagePublic

Description

Language column in Wikidata termbox shows dagbanli” with a lowercase "d" instead of “Dagbanli with an uppercase "D".

For users who have dag-N in their Babel user information, it appears as “Dagbani with an uppercase "D", as in the second image.



Link to discussion on Wikidata:Contact_the_development_team#Fix_typo_request

Event Timeline

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

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' ).