Page MenuHomePhabricator

Show each alias in a separate line in edit mode
Closed, ResolvedPublic5 Estimated 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


Screenshot 2019-04-08 at 12.44.10.png (972×1 px, 103 KB)

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 triaged this task as Medium priority.Mar 28 2019, 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)

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.


  • 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
Pablo-WMDE set the point value for this task to 5.Apr 3 2019, 3:03 PM

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

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.


@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.

Bildschirmfoto von 2019-04-16 18-14-04.png (1×423 px, 58 KB)


@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

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

Change 504896 merged by jenkins-bot:
[wikibase/termbox@master] MonolingualFingerprintView: grow despite little content

Change 506133 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/Wikibase@master] Update termbox

Change 506133 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Update termbox

@Hanna_Petruschat_WMDE thanks for reporting the missing feature yesterday. There was indeed an accident and our code got rolled back. It's there again, ready to be tested!

Hi @Jakob_WMDE
I tested and found some issues. Some are not 100% related to this task, but I'll note them all here to not forget them.

  1. the border of the alias fields are higher than the other entry fields, probably because there is padding between the entry fields and the outline indicating a fake field. Can we make it work that everything has the same size?
  2. the borders of the entry fields should have a 2px border-radius
  3. when hitting the x to cancel, the entries are being published. This is for all entry fields (label, descriptions, alias)
  4. at breakpoint 3 (all entry fields next to each other), the entry fields are not aligned at the same heights. the description fields are 1 px lower.

I'm not a 100% sure if one of this is related to that ticket. If not, I'm more than happy to put this to done and copy/paste the above to a new "bug" ticket.

Update to the "publish when clicking cancel" issue: It only shows the entry directly after clicking cancel. When reloading, it's gone...

Change 506703 had a related patch set uploaded (by Jakob; owner: Jakob):
[wikibase/termbox@master] Fix input styles

Change 506703 merged by jenkins-bot:
[wikibase/termbox@master] Fix input styles

Change 507025 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/Wikibase@master] Update termbox

Change 507025 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Update termbox

looks perfectly fine to me \o/

Interestingly enough, the OS adjusts some styling (see screenshot).
the label and description boxes haves inside shadows noe and the alias focus field has rounded corner inside the rounded corners of the outline. BUT I think this should not stall this task any further. There might be valid reasons to not totally kill any styling coming from the user(s OS).

IMG_3510.PNG (1×750 px, 180 KB)