When viewing an item like Q23 in a variant language like de-ch, properties that do not have a label set explicitly in that variant are shown using their ID plus "no label defined" in some cases (i.e. language fallback is not applied).
Fallback works for property labels on the statement level.
It does not work on qualifiers or in references.
With JS disabled, it works correctly for qualifiers and references too.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use API for formatting in JS | mediawiki/extensions/Wikibase | master | +368 -414 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T124286 [Epic] Wikidata language support | |||
| Open | None | T76216 [Epic] Language fallback | |||
| Resolved | • adrianheine | T88275 [Bug] No language fallback applied for property labels on qualifiers and references in JS UI. | |||
| Resolved | • adrianheine | T88426 Server-side rendering for all property links in the JS UI | |||
| Resolved | daniel | T94563 Support language fallbacks in wbformatvalue |
Currently, at least regarding displaying the Property label, the snakview redraws its DOM on initialization--regardless of any existing DOM. On main Snak level, the Property label DOM is not visible since it is overlayed by the statemengroupview Property label. Some notes on the issue:
Adrian pointed out that even the labels of top-level properties are rendered incorrectly by JS, when they get re-rendered upon editing.
Ideally, links to properties would always be rendered on the backend.
Note: fixing T88425 would reduce the visibility of this issue to newly added resp edited statements.
My proposal:
I realized that we probably can skip step 3. (and remove most of wbUsedEntities right now) since we don't re-render anything anymore :) I'll try that out.
We can indeed skip 3. I removed wbUsedEntities in https://gerrit.wikimedia.org/r/#/c/197290/.
Change 201182 had a related patch set uploaded (by Adrian Lang):
Use API for formatting in JS