The solution on github seems to be Javascript-reliant, which can run into
script-blocking issues.
First, I want to clarify that the prototype was made just to communicate
the idea in terms of interaction. The The implementation is just a quick
hack to simulate this interaction.
For a production implementation I can image the whole list of languages to
be sent to the client, and then, the list being shortened by Javascript.
For those users without Javascript (from screen-readers, to Search engine
crawlers) the same list of links they receive now will be available for
them.
For a GeoIP solution, this relies on good information about what languages
are relevant to GeoIPs. Do we have such a good set of
data?
When we tested language selection on
translatewiki.net, which uses the
combination of browser accept language + previous choices + geo-ip, it
worked well. Our data may not be perfect but it can be improved over time
as we notice that some suggestions are missing.
In my opinion the critical points to verify are that:
- *Our predictions work most of the time.* We try to include minority
languages at their region. This is something that some speakers of major
languages may complain
about<http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#x.2…10>,
but I agree with you that we still need to make them easily findable.
- *For the cases when predictions fail, they fail only once* (the new
language selected is considered for the suggestions in the future).
- *It is clear that the suggested languages are not the only ones.* So
that the user does not get the wrong impression that his language is
lacking when it is not. Verifying this point is essential to ensure that
some languages not appearing initially are not affected negatively.
I think that even in the edge cases (first-time users, with an
misconfigured browser, accessing from a region where a language is not
commonly spoken), it is easier to find it using the proposed language
selector with the help of search than locating it in a plain list with 200
items. In any case, we need to keep verifying with users that the above
premises hold true.
On Sat, Apr 20, 2013 at 9:58 AM, Shimmin <suburbanpanther(a)yahoo.co.uk>wrote;wrote:
A couple of thoughts occur to me.
The solution on github seems to be Javascript-reliant, which can run into
script-blocking issues. I don't know what proportion of visitors might be
using computers with script-blocking, and what proportion of those would
think/know how to/have permissions to overcome it. Or using
computers/browsers where JS is inclined to break. It might be completely
minimal, but I thought it was worth mentioning.
For a GeoIP solution, this relies on good information about what languages
are relevant to GeoIPs. Do we have such a good set of data? I'm thinking
particularly of language communities outside their traditional homelands,
Cantonese in Liverpool for example. Also, language density is a
complicating factor. If you use a list of 10 languages based on GeoIP,
then in some areas it's more than enough, while in others it's a fraction
of the local languages. I'm not sure what the best way to overcome that
one is.
I'm also concerned that a measure like this will tend to reinforce the
dominance of major languages on the net. People will not necessarily take
that extra step to check the language list just in case their language is
on it, especially for lesser-wikified languages; adding an extra step
always pretty much makes things more unlikely. I wonder whether the huge
list we see at present encourages people to search for their own language,
while a small list that doesn't immediately show it is less encouraging.
The many wiki-readers who don't edit will presumably not have any
preferences saved, so would potentially have to set their language choices
every visit - or might simply not bother if it's unlikely to offer many
articles anyway. So they would simply read the English/French/Russian
articles, and the minority wikis would be further neglected and the
language further undermined. This is obviously all speculation; I'd be
interested to see any hard information on this. It's a different set of
problems from those of interlang editors but one worth considering,
particularly as you're talking about making this the default. Minority
languages have a hard enough time as it is...
In terms of link ordering, it would perhaps make sense for articles
related to a particular language to emphasise those links (either in a
"Relevant to this article" section, or by formatting of some kind)? So
articles on French people, things and places might highlight French -
although of course there's other French languages to consider so that could
get complicated.
--Shimmin
On 19/04/2013 10:05, സുനിൽ (Sunil) wrote:
I suggest the list of languages should be displayed according to the
size/quality also
On Fri, Apr 19, 2013 at 3:43 AM, Yuri Astrakhan <yastrakhan(a)wikimedia.org>wrote;wrote:
There are a few things (IMO) that should be done
to langlist ordering:
* Group by alphabet
People who understand latin alphabet should get a list of all latin-using
languages listed/sorted together. Cyrillic is a separate group, and so are
various asian and middle-eastern languages. I have seen other sites do this
(e.g. Google, but I can't quickly locate an example right now). Having all
languages bunched up together make going through them extremely painful -
one has to skip all the scripts not understood.
* Each wiki site has different ordering requirements - like Hebrew and
Hungarian wikis want English as the first link, or 'nn' uses
'no','sv','da'
before all others. See
pywiki<http://svn.wikimedia.org/svnroot/pywikipedia/trunk/pywikipedia/fa…
interwiki_putfirst
* Lastly, but IMO - most importantly, we should honor user settings or
browser settings. If my browser sends *Accept Language:
en-US,en;q=0.8,ru;q=0.6*, it would be good to show english & russian at
the top, followed by others.
All this can (and should) be done in javascript, without affecting
servers.
And for historical reasons: bug
2867<https://bugzilla.wikimedia.org/show_bug.cgi?id=2867>67>...
i filed it in 2005, it has over 60 votes (highest count in bugzilla if i'm
not mistaken)...
--Yuri
On Thu, Apr 18, 2013 at 9:57 PM, Brion Vibber <brion(a)pobox.com> wrote:
I was traditionally in favor of keeping the full
language list visible,
but.... it's just too damn big in many cases and is hard to search
through
on any device. On touch devices it's difficult to pick a correct item
from
the list as all the links are adjacent (though if you zoom it's ok).
Definitely we need something improved, and if we're going to improve it
we
need to do it for the default or we're failing to serve 99% of our
readers...
I'm not sure about the current demo; one thing that bugs me is that
there's
a very small tap/click target for getting the full language list
call-out.
Clicking on "Language" just hides/shows the short list, it doesn't do
anything. Clicking the "settings" gear icon next to "Languages"
brings
up a
call-out with language-related settings.... none of which help you get to
another language version of the wiki.
On the mobile site we've collapsed the whole thing to an "Other
languages"
section or button (depending on if you're in beta mode) at the bottom of
the article, and this seems to have gotten good usability responses from
mobile users.
On Thu, Apr 18, 2013 at 12:47 PM, David Gerard <dgerard(a)gmail.com>
wrote:
On 18 April 2013 20:43, David Gerard
<dgerard(a)gmail.com> wrote:
> On 18 April 2013 17:50, Pau Giner <pginer(a)wikimedia.org> wrote:
>> Please let me know if you see any possible concern with this
approach.
> My first thought is of how upset people were when the first version
of
> Vector hid the language links by default. I
would suggest being sure
> there will be little or no similar objection.
(hit send too soon, sorry)
A simple solution that would avoid a similar reaction is: do not do
this by default - make it only for logged-in users who want it that
way.
Possibly for default users, you could put the heuristically-calculated
likely preferred languages at the top. But keeping the rest of the
list below, right there on display, will (I predict) be favoured, as
advertising the many languages of Wikipedia is a strongly-held value
of many Wikimedians.
- d.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Mediawiki-i18n mailing list
Mediawiki-i18n(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
_______________________________________________
Mediawiki-i18n mailing
listMediawiki-i18n@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
_______________________________________________
Mediawiki-i18n mailing list
Mediawiki-i18n(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
--
Pau Giner
Interaction Designer
Wikimedia Foundation