6

Most answers to this question say that for instance Arabic text should be aligned right-to-left even if the rest of the page is in a left-to-right script such as English.

So, I was surprised to see that the language selector https://www.wikipedia.org shows all languages left-aligned (as seen on Ubuntu in English):

enter image description here

Both Wikipedia and Ubuntu are very international and are driven by very vocal communities so I don't think this choice is random.

My question: Is there something special about language selectors that makes it OK to have alignment ignore language direction?

Related:

6
  • Hi! To be honest I never came across of a dropdown that respects different language directions. I would assume that the UI component it self has limitations that prevent from that happening. Jul 17, 2018 at 6:33
  • @MenandrosApostolidis: Thanks! In my current case we have a language selection UI component that shows each language in its preferred direction, and a developer has identified that as a bug ("it should be aligned to the left side"), full discussion at github.com/commons-app/apps-android-commons/issues/1713 for more background, I have to agree it does not look very good but I have about zero experience with RTL so I can't tell. Jul 17, 2018 at 7:06
  • If the languages are so many. I would suggest instead of a dropdown to use a text field with auto complete functionality. That is based on drop down usability studies. The user know what to look in advance and you will avoid having the cumbersome view of list items aligned left or right. Jul 17, 2018 at 13:14
  • I think you're assuming Wikipedia has an UX department rather than volunteer programmers. Besides that, you're checking a western version, so it aligns to the left . If you check an arabic version such as ar.wikipedia.org you'll see dropdowns are aligned to the right. This is because it's more consistent and it covers user's expectations for both Western and Eastern languages
    – Devin
    Jul 18, 2018 at 2:54
  • 1
    @MenandrosApostolidis: I did not mention dropdown, even though it is a common implementation of language selection lists on some platforms. Also, typing is very inconvenient on many platforms. Jul 18, 2018 at 3:35

2 Answers 2

6

Simple lists need not be like paragraphs.

Suppose we displayed each language name according to its “natural” alignment: Language-Aligned List

Not only would that look wrong, but it would be hard to scan.

Now suppose we aligned the entire list to the right: Right-Aligned List

Sure, you’d think it’s weird, since most of the languages on the list are LTR, but it wouldn’t look wrong, and it would still be easy to scan.

What we can learn from this is that natural alignment isn’t as important in situations such as these. For such a list, it makes more sense to maintain the alignment of its surrounding interface.

However, once we get to longer phrases and sentences (especially anything that spans more than one line), it becomes much more important to display a language with its natural alignment. Just as it would be annoying to read long sentences in English when they’re right-aligned, left-aligned Hebrew and Arabic are also difficult to read.

That said, all this is about alignment. It’s important to be aware that direction should always follow its language. Otherwise, punctuation shows up in the wrong place.

6
  • So, your suggestion is that I chose an alignment and stick to it for all items in the language selection widget, if I understand correctly? Maybe center-aligned would be the less unnatural to both RTL and LTR people? Jul 18, 2018 at 1:58
  • 2
    I would stick to the alignment of the locale the list is embedded in. Center-alignment would create jagged edges on both sides of the list, and that would harder to scan for everyone. Besides, once the user had chosen an RTL language, wouldn’t the entire interface become RTL (including this language selector)? Jul 18, 2018 at 2:02
  • 1
    Good answer. You can probably generalize to all lists including bulleted lists
    – qoba
    Jul 18, 2018 at 3:42
  • 2
    I find the first example amazing, it actually makes scanning much easier due to the fact that certain languages are easier to recognise and "filter" from the list.
    – user68158
    Jul 18, 2018 at 14:37
  • @Levano, that’s a good point for when the list is wide. But then RTL items would stick out too much and look wrong, like in that example. If we decreased the width, then I think the advantage of being able to find your particular RTL language would be lessened. For everyone else, I think having a few items stick out like that would slow down scanning for their particular language. Jul 18, 2018 at 16:41
0

I'm a multi-language user (Arabic, English, French). I would share more about this topic beside what David Regev mention in his answer. From user prospective (I'm not familiar with UX)

  • Alignment is more convenient if following interface current language.

    In this case is Left. Right will be hard to scan for LTR-only users. While most RTL or TTB script users has exposure to LTR language (English is widely used for international communication). Center will be bad for people that scan for letters not the word due to close similarity in some languages name. For example: Arabic & Hebrew have same letters when both presented in Arabic (عربية & عبرية).

  • That bring another issue which is the vertical Sorting

    Most will sort with some Unicode based algorithm, that seems like it is sorting with respect to letter Unicode code or UTF8 length. (Top will be English and European languages using ASCII, Bottom will be Asian languages which using CTL codes like Chinese). Not very good but it is currently the best. Its order is quite expected for user.

    Second method is Popularity, I hate it. It very hard to read through the list.

    I would like to see new order by Unicode organization that based on Phonetics for All scripted languages.

  • There are more about RTL. You may compromise Alignment but don't Direction (multi-word), Bidi-direction and Shaping (multi-letter).

    These are not an issue any more in most Web/Mobile platforms. Only in custom widgets or new GUI frameworks / Rendering engines.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.