Page MenuHomePhabricator

MUL - Language fallback not applied to item/property heading after editing terms
Closed, ResolvedPublic8 Estimated Story PointsBUG REPORT

Description

Problem:
When displaying an Item or Property page, the page heading usually applies language fallback to the label and description. The problem is that doing anything with the termbox which causes the heading to update causes the language fallback to no longer be applied

Examples:
e.g.

Steps to reproduce:
Case A

  • Make any change in the termbox and save it.
  • After saving the heading is refreshed and no longer applies language fallback

Case B

  • Make any change to the language current set as the interface language and then cancel editing.
  • The heading updates when making the changes, the changes are reverted after cancelling, but language fallback is no longer applied

Notes:

Acceptance criteria:
The page title is always up-to date with the rest of the Item:

  • The language fallback of the page title is respected in both cases A and B (this can be the usual live update while typing, but it does not have to, one update when the edit is actually published is also fine).
  • The language fallback is respected in the <title> for both cases A and B (please make sure that we make only one update -- when the edit is actually published).

Original:
This is a side-effect of T98014. PHP does language fallback in the header section, but JS does not. So, if you edit the terms of an entity which doesn't have terms in the UI language, after leaving edit mode the header section might look different than it does after a reload.

SP - 5-8

Related Objects

Event Timeline

Manuel renamed this task from [Bug] JS does no fallback for terms in header section to Language fallback not applied to item/property heading after editing terms.Apr 26 2022, 4:45 PM
Manuel updated the task description. (Show Details)
Manuel subscribed.

Added info from T267131.

Manuel raised the priority of this task from Low to Needs Triage.Jul 5 2022, 9:50 PM
Manuel added a project: Wikidata Dev Team.

Hi @Nikki, I have removed the following case that originally came from T267131:

  • Make any change to the language currently set as the interface language, no save needed.
  • The heading updates immediately, no longer applying language fallback

My reason is that the interface language is likely factored in by design. The problematic part as I see it is that language fallback doesn't come back after one cancels the action (should be fully covered by case B). Please let me know in case you have any objections.

karapayneWMDE set the point value for this task to 8.
Manuel changed the subtype of this task from "Task" to "Bug Report".Jul 12 2022, 11:09 AM
Manuel renamed this task from Language fallback not applied to item/property heading after editing terms to MUL - Language fallback not applied to item/property heading after editing terms.Sep 13 2022, 10:56 AM

Task breakdown notes: We’re not sure which approach is best to implement this; it could be:

  • send the language fallback chain to the client (if we don’t already have it) and implement the fallback logic in JS; or
  • make a separate API request after an edit (wbgetentities with languagefallback parameter) to get the terms with language fallback

Either of these would require non-trivial changes to the legacy jQuery UI code, so this should be balanced against the possibility to:

  • use the new / mobile termbox on desktop as well
Manuel renamed this task from MUL - Language fallback not applied to item/property heading after editing terms to Language fallback not applied to item/property heading after editing terms.Nov 2 2022, 7:28 PM
Manuel removed a project: Wikidata Dev Team.
Manuel moved this task from Ready to estimate to Task with Epic on the Wikidata-Campsite board.

Hi @Nikki, I have removed the following case that originally came from T267131:

  • Make any change to the language currently set as the interface language, no save needed.
  • The heading updates immediately, no longer applying language fallback

My reason is that the interface language is likely factored in by design. The problematic part as I see it is that language fallback doesn't come back after one cancels the action (should be fully covered by case B). Please let me know in case you have any objections.

I only just saw this comment (I still haven't worked out how to get Phabricator's notification system to do anything useful) but I don't think it should have been removed, for two reasons:

  • I don't think the page title should be updated while editing, because the changes haven't actually been saved and I find that misleading and unhelpful. When looking at my open tabs (the main reason I look at page titles), I can't tell which ones are using the actual label and which are showing an unsaved edit that will be lost I close the browser/tab without saving. If I do close the tab without saving, it will be saved in the tab history with a page title based on a label it never had.
  • If that behaviour is kept anyway, language fallback should be applied when editing and after saving/cancelling (which is not clear from the current description). It's weird if it shows "English label" before editing, "Q12345" after you type something in the description field (because there's no label in your current interface language) and then "English label" again after saving/cancelling.

I don't think the page title should be updated while editing

Thank you, @Nikki! I think this is a convincing argument, and it might even make the development easier.

@Sarai-WMDE could you please add this to our list of known issues with the editing UI?

Manuel renamed this task from Language fallback not applied to item/property heading after editing terms to MUL - Language fallback not applied to item/property heading after editing terms.Jan 31 2024, 11:06 AM
Manuel updated the task description. (Show Details)

Task breakdown notes: We’re not sure which approach is best to implement this; it could be:

  • send the language fallback chain to the client (if we don’t already have it) and implement the fallback logic in JS; or
  • make a separate API request after an edit (wbgetentities with languagefallback parameter) to get the terms with language fallback

Either of these would require non-trivial changes to the legacy jQuery UI code, so this should be balanced against the possibility to:

  • use the new / mobile termbox on desktop as well

Note: since then, we already started sending the language fallback chain to the client (T340832, wikibase.fallbackchains ResourceLoader module), so this task should be relatively doable now.

I’m assuming we should also add fallback indicators in JS, under the same conditions as in PHP (i.e. not for variants of the same base language, and also not for mul).

Screenshot from 2024-03-05 14-56-22.png (98×288 px, 9 KB)

Screenshot from 2024-03-05 14-56-24.png (98×288 px, 7 KB)

(The required language names are already available, see wb.getLanguageNameByCodeForTerms().)

Also, I just remembered that language fallback in PHP includes automatic transliteration; I don’t think we can do that in JS, so that part will just be missing.

I don't think the page title should be updated while editing

Thank you, @Nikki! I think this is a convincing argument, and it might even make the development easier.

It doesn’t (automatic updating of the title is what currently happens), but I agree that the page title shouldn’t be updated while editing, it’s quite distracting.

But apart from that, I have something that seems to work well for this change (see above video :)), I’ll upload it soon.

Change 1008878 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] WIP: Improve entity header label/description language fallback

https://gerrit.wikimedia.org/r/1008878

Change #1018226 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Don’t modify original fallback chains in _getPlaceholderLabel()

https://gerrit.wikimedia.org/r/1018226

Change #1018226 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Don’t modify original fallback chains in _getPlaceholderLabel()

https://gerrit.wikimedia.org/r/1018226

Change #1008878 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Improve entity header label/description language fallback

https://gerrit.wikimedia.org/r/1008878

Arian_Bozorg claimed this task.
Arian_Bozorg subscribed.

This is working for me now :)

Thanks so much