Page MenuHomePhabricator

Mockup for indicating language fallbacks for labels of referenced entities
Closed, ResolvedPublic

Event Timeline

Tobi_WMDE_SW raised the priority of this task from to Medium.
Tobi_WMDE_SW updated the task description. (Show Details)
Tobi_WMDE_SW added subscribers: Aklapper, Tobi_WMDE_SW.

Adding the language name in superscript was proposed already and we even had some mock-up way back. It would tie in with what we do with the calendar names as those are, in a way, some kind of "language" as well. It would be nice to be able to use the language name to directly allow translating the label into the user's language. Could also imagine some setting to display the language name every time a translation is missing in one of my languages.

I agree that it should be handled similar to the calendar model. I worry that what we're doing there is not distinct enough from the language label for monolingual text (and multilingual text in the future) and therefor making it hard for a new user to understand which is which. Do we need to rethink either of them?

I had that in mind and, yes, there should be some concept covering all those cases. Regarding multilingual value: In my opinion, I could very well imagine that working just the same, as the label acts (and, basically, is), in fact, a multilingual value. The superscript of monolingual value could be styled in a slightly different way signaling the language being a fixed property of that value. I am not sure whether it makes sense to create a more global concept right now because there are other pressing tasks. Technically, showing the language will surely remain a prerequisite in any case.

Ok then let's go for this now and make sure we have a good concept for all those cases when we add the multilingual text datatype.

@Lydia_Pintscher: Do you think we should omit the indicator in case of a fallback from a variant? Users with their UI set to de-ch will see fallback indicators nearly everywhere otherwise. For now, I'd use a css class do indicate whether it's a transcription, variant fallback, or fallback to a different language.

@Snaterlicious: what HTML structure would you prefer for this? Should the indicator be inside the <a> tag or after the <a> tag? If after, should there be a wrapper <span>?

The reason to show them is to get users to show labels. So I'd say we also want to show it for variants. Adding css classes to differentiate and to allow individual users to not show them sounds fine to me.

@Lydia_Pintscher: I understand, but do we *want* separate labels for de-ch for everything, even if they are only different from de labels in 1% of the cases? That just makes maintenance harder, with no benefit I can see.

I guess this isn't true for all variants. But it's true for de-ch, de-at, en-gb, etc: for these, labels in the variant are going to be the same nearly always, and should thus be omitted.

I'd say we want it at least until the entity selector works with fallbacks.

Tobi_WMDE_SW claimed this task.

Ok then let's go for this now and make sure we have a good concept for all those cases when we add the multilingual text datatype.

Mockup accepted by PO, so closing this task. The implementation task for this is T86179.