Pablo-WMDE added a comment.

  The wikibase client side code to render the "termbox v1" aka entitytermsview 
uses 
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/bdf4292f2459fe556c535773786087beaff0de77/view/resources/jquery/wikibase/jquery.wikibase.entitytermsforlanguageview.js#L169>
 wb.getLanguageNameByCode() 
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/bdf4292f2459fe556c535773786087beaff0de77/view/resources/wikibase/wikibase.getLanguageNameByCode.js#L47>
 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 
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/3e10675112017f802f3e601eee2d0f8357692434/view/tests/qunit/wikibase/wikibase.getLanguageNameByCode.tests.js#L12>
 in the process.
  
  FWIW while `$.fn.uls.defaults.languages` initially gets created 
<https://github.com/wikimedia/jquery.uls/blob/5165ee117f6903a4a6218e8554392dd04af8cfcf/src/jquery.uls.core.js#L396>
 from `$.uls.data.getAutonyms()` (so it contains "dag", albeit as "dagbanli"), 
UniversalLanguageSelector seems to "extend" 
<https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/678d69747f7f591a5a1f8240343fa0c6ae01ac5a/resources/js/ext.uls.mediawiki.js#L25>
 `$.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 
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/3e10675112017f802f3e601eee2d0f8357692434/lib/includes/WikibaseContentLanguages.php#L64>
 does not seem to come into play when shaping the value of `mw.config.get( 
'wgULSLanguages' )`.

TASK DETAIL
  https://phabricator.wikimedia.org/T261851

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Pablo-WMDE
Cc: Lydia_Pintscher, Pablo-WMDE, Aklapper, Mohammed_Sadat_WMDE, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to