Page MenuHomePhabricator

Show each alias in a separate line in edit mode
Open, NormalPublic5 Story Points


This is also helpful because it resolves the problem of literal pipes in aliases.

As a wikidata editor
I want to see existing aliases in individual lines
so that I can edit them easily without bothering about syntax


Acceptance Criteria

  • When switching to edit mode, each alias gets their own input line
    • The pipes are not visible anymore
    • There is a new empty line below all entered aliases
      • the new line can be reached by either clicking/tapping on the line or using the tab key (this is possible on some mobile keyboards indicated by "up" and "down" arrows in the keyboard area)
      • If users enter info here, it is saved as a new alias
      • Once the user has entered a first character to the line, a new line appears allowing to add yet another alias
      • The empty alias line should not have any effect on saving
    • When the contents of an alias is fully deleted or contains only whitespace and then the line loses focus, the line disappears
  • When the aliases segment is out of focus again, they stay extended, and would only collapse once users click on save or cancel
  • The individual aliases can be navigated with the common tab/shift-tab behavior
  • The individual alias, when focused, are styled as follows
    • the background color set to Accent90 (#EAF3FF)
    • text color set to Base20 (#222)
    • no outline
  • Aliases that are longer than the input field allows are wrapped
  • In reading mode, aliases are still shown right behind each other, separated by the internationalized language separation character

Open questions

  • Is it possible to have multiline aliases?
    • answer: no
  • Will there be the danger of mixing up long wrapped aliases with being two aliases
    • answer: long lines will be wrapped! And it will be clear which are wrapped vs not by the spacing: see here

We are mainly following the paradigm that is currently implemented on desktop.

Event Timeline

Lea_WMDE created this task.Mar 19 2019, 3:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 19 2019, 3:38 PM
Lea_WMDE updated the task description. (Show Details)Wed, Mar 27, 10:27 AM
Tarrow updated the task description. (Show Details)Thu, Mar 28, 2:40 PM
Lea_WMDE triaged this task as Normal priority.Thu, Mar 28, 3:00 PM
Lea_WMDE updated the task description. (Show Details)

Alias editing is under way in T216987. To not fall for recently discovered T219499 we should pick this story up soon.

Three UX specifications came in via figma comments - adding them here to make them searchable (verbatim @Hanna_Petruschat_WMDE):

  • “when entering the alias field, a "new" line with placeholder text will be visible and in focus (a blinking cursor in this position)” (link)
  • "as soon as the user starts typing, a new line appears under the currently typed in alias to allow to add another one" (link)
  • “the new line can be reached by either pressing return, clicking/tapping on the line or using the arrow keys (this is possible on some mobile keyborads as well)” (link)
Jakob_WMDE added a subscriber: Jakob_WMDE.EditedMon, Apr 1, 4:02 PM

I went through this and thought about some possible edge cases and questions.

  • What is the expected backspace behavior? Am I supposed to move to the line above if I press backspace in an empty alias input field? backspace can only remove one line, won't go over one alias
  • Why arrow-keys for navigation? As far as I know the arrow keys on mobile (at least in iOS) function similar to tab / shift-tab and not as arrow keys. tab, not arrows! :)
  • (already in the open questions) What do long aliases / line wrapping look like? solved. See open questions in the ticket.
Jakob_WMDE added a comment.EditedWed, Apr 3, 2:50 PM


  • should the initial bordered box behave like an actual input field or is it ok to just look like one (i.e. give it a border) part of T219997
  • should there be two different input field placeholders - one saying "add another alias" given there are existing aliases, and another saying "add an alias" given there are none? it should always say "enter an alias"

Interpretations / assumptions

  • alias editing happens in two stages: showing an "input" with pipes, then turns into the multi-line text field on click / touch / focus T219997 is a separate story
  • we are not considering wrapping behavior of alias input fields for now
Jakob_WMDE updated the task description. (Show Details)Wed, Apr 3, 2:51 PM
Pablo-WMDE set the point value for this task to 5.Wed, Apr 3, 3:03 PM
Jakob_WMDE updated the task description. (Show Details)Thu, Apr 4, 1:37 PM
Jakob_WMDE updated the task description. (Show Details)Thu, Apr 4, 2:01 PM
Jakob_WMDE updated the task description. (Show Details)Thu, Apr 4, 4:51 PM
Tarrow updated the task description. (Show Details)Mon, Apr 8, 9:24 AM
Lea_WMDE updated the task description. (Show Details)Wed, Apr 10, 9:57 AM

Updated the task description to have all acceptance criteria in there and not also mixed into the comments

Lea_WMDE updated the task description. (Show Details)Wed, Apr 10, 10:10 AM

updated again, removing the mentioning of placeholders, so there is no doubling with T217000: Show placeholders for label, description and alias

Hello @Hanna_Petruschat_WMDE,
one more question about the individual alias input element - given that the focus (blue border) is illustrated "one level up" from the individual alias (on the aliases), should the individual alias really not signal focus at all beyond containing the cursor? Outline comes to mind which, in some browsers (see chrome), is used with e.g. an orange color by default - depending on which browser they use, people may or may not be accustomed to it.
If there is no strong argument against it I'd like if we could - explicitly - add some visual indication.


Jakob_WMDE updated the task description. (Show Details)Mon, Apr 15, 4:30 PM
Jakob_WMDE updated the task description. (Show Details)Mon, Apr 15, 4:44 PM
Jakob_WMDE updated the task description. (Show Details)

@Pablo-WMDE Thanks for the heads up. I totally agree to commit to this especially looking towards accessibility (tab and highlight...)

I'm not 100% sure what it would look like and if it has implications on the label and description being in focus as well? Would you have some way to screenshot an example?

Hello @Hanna_Petruschat_WMDE,

please find a screenshot of what chrome does by default in case of a sneak peek into alias editing. The aliases component has a blue border (as defined) because it has "focus within", the individual alias has the chrome default outline because it has actual focus. So far the individual alias focus style is not explicitly modeled. I advocate to a) explicitly model it [i.e. not leave it up to the browser] b) when modeling it to please consider the previous link.


@Pablo-WMDE I've the following suggestion:
Use the background highlight and define it like this

  • have the background set to Accent90 (#EAF3FF)
  • have the text entry in the focused input set to Base20 (#222)

This will keep up with WCAG color contrast criteria and define the focus independent of browsers and so on.

One question regarding the screenshot: The input field is way narrower than the outline. Does the width automatically adjust to the content? In my understanding the input field should always be almost as wide as the outline surrounding the aliases.

@Lea_WMDE you might want to look at this as well.

@Hanna_Petruschat_WMDE I guess we can do that. The outline helped in bringing individual alias width challenge to light; cool. => T221219

Pablo-WMDE updated the task description. (Show Details)Wed, Apr 17, 10:37 AM

Change 504896 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[wikibase/termbox@master] MonolingualFingerprintView: grow despite little content