Steps to reproduce:
Open any Entity (e.g. https://test.wikidata.org/wiki/Q172818)
- on desktop
- or mobile
What happens?
- The termbox initially shows the languages sorted in one order (e.g. mul, en, de, pt), but then JS runs and they get reordered into another order (e.g. mul, de, en, pt).
- The behavior changes based on your logged-in state / Babels (de-N, en-4, pt-1 in the example given), and uselang (mul in the example given).
- There is also an accompanying console warning:
Existing entitytermsforlanguagelistview DOM does not match configured languages
Mobile-only:
- On mobile an additional result is that the formatting is off ("No label defined" is bold, "blah" is not).
It looks like this can only be reproduced when not logged in.
What should have happened instead?
- The termbox should show the languages correctly ordered from the start (just like we are used to from Wikidata proper). That is, the languages do not jump around.
- The formatting on mobile is normal again.
Notes:
- Preferred order for the languages is not relevant. This task addresses the jumping of the language.
- We thought we’d fixed this with T307808, but there’s still some remaining issue.
- There is an additional mul task that changes the order: T316767: MUL - Show `mul` as the last language in the "In more languages" section of desktop termbox by default
- At some point mul will be visible for all users by default (see T312176).
Acceptance criteria:
- We understand the problem that leads to this issue.
- The problem is solved (or if solving the problem is out of scope then please create a follow-up task so we can discuss it)
Original:
When I load https://test.wikidata.org/wiki/Q172818?uselang=mul, the termbox initially shows the languages mul, en, de, pt, but then JS runs and they get reordered into mul, de, en, pt – English and German switch places. (My Babel is currently de-N, en-4, pt-1.) There is also an accompanying console warning:
Existing entitytermsforlanguagelistview DOM does not match configured languages
This needs to be looked into. (I thought I’d fixed this with T307808, but clearly there’s still some remaining issue.)