Page MenuHomePhabricator

[Bug] No language fallback applied for property labels on qualifiers and references in JS UI.
Closed, ResolvedPublic


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.

Event Timeline

daniel raised the priority of this task from to Needs Triage.
daniel updated the task description. (Show Details)
daniel added a subscriber: daniel.
daniel triaged this task as Medium priority.Feb 2 2015, 10:55 AM
Lydia_Pintscher raised the priority of this task from Medium to High.Feb 2 2015, 11:18 AM
Lydia_Pintscher set Security to None.

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:

  • snakview should not redraw the Property label DOM if it is initialized on existing DOM.
  • Regardless of that, there also needs to be a JS mechanism to apply language fall-back: For example, what about entering an Item reference specifying an Item ID? Currently, language fall-back is not applied during this action as it is a JS-only action.
  • snakview should probably not be touched before is merged.
  • Regarding snakview refactoring, see also T88271.

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.

My proposal:

  1. Move the existing formatting JS code into an EntityIdFormatter
  2. Replace usage of the formatting code with usage of EntityIdFormatter
  3. Add pre-formatted EntityIds to parser output (probably replacing most of wbUsedEntities)
  4. Implement API-based EntityIdFormatter (using wbformatvalue)
  5. Remove existing EntityId formatting code from JS

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.

Jonas renamed this task from No language fallback applied for property labels on qualifiers and references in JS UI. to [Bug] No language fallback applied for property labels on qualifiers and references in JS UI..Sep 10 2015, 2:43 PM

Change 201182 had a related patch set uploaded (by Adrian Lang):
Use API for formatting in JS

Change 201182 merged by jenkins-bot:
Use API for formatting in JS

hoo removed a project: Patch-For-Review.
hoo moved this task from Review to Done on the Wikidata-Sprint-2015-09-29 board.