Thanks for all the feedback!
I'll try to respond below to some of the issues raised:
*Which is the problem?*
As it has been mentioned, one of the most effective ways of hiding
something is to surround it in the middle of a long list. This produces two
- *Lack of discoverability.* users may be not aware that the content is
available in their language (which goes against our goal of providing
access to knowledge). Speakers of small languages that access the English
Wikipedia because it has more content, are forced to make an effort each
time to check if each article is also available in their language.
- *Problems for multi-lingual exploration.* It is hard to switch between
multiple language versions since the users has to look for his languages
each time in the whole list.
The fact that some Wikipedias adjust the order of the languages, the
existence of user scripts and an Opera
solve the issue, is an indicator of the existence of such problem.
We support lots of languages (+300) but users are normally interested in a
small (1-8) subset of those. We need to make these subset easily
discoverable for our users, and providing them in the middle of a list with
200 items is not the best way to do it in my opinion.
*Possible cultural and value problems*
As it was commented, the multilingual nature of Wikipedia is a strong held
value. However, currently it is hard to know in how many languages an
article is available since you need to count the links. With the proposed
approach we provide a number which helps to communicate that. So I think we
are not going against that value.
I think that concerns about the imposition of languages per region are not
a big issue when the previous user choices and the browser accept language
are considered with more priority than Geo-IP. Users just need to select
their language once and it will be appearing in the short list the next
times. These concerns should be more relevant with the current situation
where some Wikis put some languages on top regardless user choices (for
some work 100% of the time, for others they fail 100% of the time).
I also don't think that we should prioritise the need to hide "languages
that users somehow dislikes" over making it easy to access the languages
that the user wants. In any case, the former is also not supported with the
*Why to hide?*
I understand the problems commented when language links were initially
hidden in Vector, since uses were required to make an additional step to
get into the same long list of links we currently have. With the proposed
approach, the extra step is only taken in exceptional cases (e.g., a user
in a foreign country accessing from a public pc), and this is made only
once (not for each language change), and aids such as search are provided
to make it really quick.
The reordering alternative has some problems compared with the proposed
approach. For example, when a language does not appear on top, it is hard
to determine whether the current article is not provided in that language
or it is in the middle of the list. In addition, with reordering, you
cannot rely on alphabetical order (while you can present the short list
*Considering size and quality of the article*
It can be a factor to consider since communicating that an article has good
versions in other languages is a good thing. But I think it is a low
priority one, since I find hard to imagine a user selecting a language
which she does not understand (otherwise will be already in the short list)
just because the article is of good quality. In any case, users normally
speak 1-8 languages, so even in a relatively short list there is still room
for other criteria.
*The way to access more*
We choose the "..." so that the label could work across languages. So that
you can go back to your language if you arrive by accident to a foreign
Wikipedia (or you are an advanced user curious to check if web fonts were
enabled in Javanese wikipedia). However, the visual execution needs some
work still to make it more touch friendly among other things.
*Details on the language list UI*
The interactive prototype was created to communicate the main idea and most
details are still lacking.
Thanks for pointing layout and navigation problems. The layout of the list
is one of the aspects that needs more work: currently we group the
languages by script to help the user to recognise their familiar scripts,
and the algorithm also makes some control of orphan/widow items. That works
well for very long lists of languages, but needs further tuning when the
number of elements is reduced. An algorithm that presents the list
optimally for all possible lengths is something to be done.
On Thu, Apr 18, 2013 at 6:50 PM, Pau Giner <pginer(a)wikimedia.org> wrote:
As multilingual content grows, interlanguage links
become longer on
Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more
200 links, and that becomes a problem for users that often switch among
As part of the future plans for the Universal Language Selector, we were
- Show only a short list of the relevant languages for the user based
on geo-IP, previous choices and browser settings of the current user. The
language the users are looking for will be there most of the times.
- Include a "more" option to access the rest of the languages for
which the content exists with an indicator of the number of languages.
- Provide a list of the rest of the languages that users can easily
scan (grouped by script and region ao that alphabetical ordering is
possible), and search (allowing users to search a language name in another
language, using ISO codes or even making typos).
I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to
illustrate the idea. Since this is not connected to the MediaWiki backend,
it lacks the advanced capabilities commented above but you can get the idea.
If you are interested in the missing parts, you can check the flexible
search and the list of likely languages ("common languages" section) on the
language selector used at http://translatewiki.net/
which is connected to
As part of the testing process for the ULS language settings, I included a
task to test also the compact interlanguage designs. Users seem to
understand their use (view
but I wanted to get some feedback for changes affecting such an important
Please let me know if you see any possible concern with this approach.