**Motivation**
- Termbox is showing languages considered "preferred by the user" (T213720) in the "more languages" sections. These languages are sourced from their babel box and can, apparently, contain language codes that //do// exist but are not considered to be full fledged MediaWikiContentLanguages (wb terminology) but [[ https://github.com/wikimedia/jquery.uls/blame/master/src/jquery.uls.data.js#L1051 | delegate ]] to another language code instead. However, it is not possible to add anything to these languages or save them on the wiki, since the language is not an official project language, and the display is broken.
Termbox is showing languages considered "preferred by the user" (T213720) in the "more languages" sections. These languages are sourced from their babel box and can, apparently, contain language codes that //do// exist but are not considered to be full fledged MediaWikiContentLanguages (wb terminology) but [[ https://github.com/wikimedia/jquery.uls/blame/master/src/jquery.uls.data.js#L1051 | delegate ]] to another language code instead. - There are fingerprints of languages that used to be part of the accepted language setHowever, it is not possible to add anything to these languages or save them on the wiki, since the language is not an official project language, but whose languages are not part of it anymore.
**Example for babel and the display is broken. Currently, the desktop termbox languages**
{F28469501}fails when saving.
Originally submitted attachment was {F28336153}
While testing we experienced an empty language field which caused a shift in the label and description columns (see screenshot below)
The language code for which this happened in this particular example was **fil**.
I couldn't replicate this bug but FWIW: the user has been in the phillipines (what is the ULS for this region?) and had uselang=en**Example for bug appearing (in new termbox layout)**
**Behavior of desktop implementation of the termbox****Example for babel box languages**
- (Old) Termbox v1 is also [[ https://www.wikidata.org/wiki/Q49?uselang=fil | trying its best to show (in likelyhood always w/o associated data) this language when using `uselang=fil` ]] but then fails when saving because the backend does not consider the language code valid.The language code for which this happened was **fil**, resulting in a weird looking and behaving first line
- When it comes to fingerprints of languages that used to be accepted, the v1 version shows them, but does not allow edits on them.{F28469501}
**Acceptance Criteria**
[] The termbox only displays language codes that are allowed on the wiki, no matter if there is information related to this language in the Entity or not
**Notes**
* we estimated this based on the proposed approach to only ever initialize entities with valid language code information
* product acknowledges that this will effectively render historic revision containing information in languages that are no longer "valid" in a potentially confusing manner => T219375doeas not display "delegating" language codes in the termbox