<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">The solution on github seems to be Javascript-reliant, which can run into script-blocking issues.</span></blockquote>
<br><div><div>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.</div><div><br></div><div>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.</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">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? </span></blockquote>
<div><br></div><div style>When we tested language selection on <a href="http://translatewiki.net/">translatewiki.net</a>, 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.</div>
<div style><br></div><div style> In my opinion the critical points to verify are that:</div><div style><ul style><li style><b>Our predictions work most of the time.</b> We try to include minority languages at their region. This is something that <a href="http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#x.22Common_languages.22_19010">some speakers of major languages may complain about</a>, but I agree with you that we still need to make them easily findable.</li>
<li style><b>For the cases when predictions fail, they fail only once</b> (the new language selected is considered for the suggestions in the future).</li><li style><b>It is clear that the suggested languages are not the only ones.</b> 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.</li>
</ul></div><div style><br></div><div style>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.</div>
<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 20, 2013 at 9:58 AM, Shimmin <span dir="ltr"><<a href="mailto:suburbanpanther@yahoo.co.uk" target="_blank">suburbanpanther@yahoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>A couple of thoughts occur to me.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
--Shimmin</font></span><div><div class="h5"><br>
<br>
<br>
On 19/04/2013 10:05, സുനിൽ (Sunil) wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">I suggest the list of languages should be displayed
according to the size/quality also<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 19, 2013 at 3:43 AM, Yuri
Astrakhan <span dir="ltr"><<a href="mailto:yastrakhan@wikimedia.org" target="_blank">yastrakhan@wikimedia.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>There are a few things (IMO) that should be done to
langlist ordering:<br>
</div>
<div><br>
</div>
<div> * Group by alphabet</div>
<div>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.</div>
<div><br>
</div>
<div>* 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 <a href="http://svn.wikimedia.org/svnroot/pywikipedia/trunk/pywikipedia/families/wikipedia_family.py" target="_blank">pywiki</a> - <span style="white-space:pre-wrap">interwiki_putfirst</span></div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">* Lastly, but IMO - most
importantly, we should honor user settings or browser
settings. If my browser sends <b>Accept Language<span style="white-space:pre-wrap">: </span>en-US,en;q=0.8,ru;q=0.6</b>,
it would be good to show english & russian at the
top, followed by others.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">All this can (and should) be done
in javascript, without affecting servers.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">And for historical reasons: <a href="https://bugzilla.wikimedia.org/show_bug.cgi?id=2867" target="_blank">bug 2867</a>... i filed it in 2005, it
has over 60 votes (highest count in bugzilla if i'm not
mistaken)...</div>
<span><font color="#888888">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">--Yuri</div>
</font></span>
<div>
<div>
<div><br>
<br>
<div class="gmail_quote">On Thu, Apr 18, 2013 at
9:57 PM, Brion Vibber <span dir="ltr"><<a href="mailto:brion@pobox.com" target="_blank">brion@pobox.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
was traditionally in favor of keeping the full
language list visible,<br>
but.... it's just too damn big in many cases and
is hard to search through<br>
on any device. On touch devices it's difficult
to pick a correct item from<br>
the list as all the links are adjacent (though
if you zoom it's ok).<br>
<br>
Definitely we need something improved, and if
we're going to improve it we<br>
need to do it for the default or we're failing
to serve 99% of our<br>
readers...<br>
<br>
I'm not sure about the current demo; one thing
that bugs me is that there's<br>
a very small tap/click target for getting the
full language list call-out.<br>
Clicking on "Language" just hides/shows the
short list, it doesn't do<br>
anything. Clicking the "settings" gear icon next
to "Languages" brings up a<br>
call-out with language-related settings.... none
of which help you get to<br>
another language version of the wiki.<br>
<br>
<br>
On the mobile site we've collapsed the whole
thing to an "Other languages"<br>
section or button (depending on if you're in
beta mode) at the bottom of<br>
the article, and this seems to have gotten good
usability responses from<br>
mobile users.<br>
<div>
<div><br>
<br>
<br>
On Thu, Apr 18, 2013 at 12:47 PM, David
Gerard <<a href="mailto:dgerard@gmail.com" target="_blank">dgerard@gmail.com</a>>
wrote:<br>
<br>
> On 18 April 2013 20:43, David Gerard
<<a href="mailto:dgerard@gmail.com" target="_blank">dgerard@gmail.com</a>>
wrote:<br>
> > On 18 April 2013 17:50, Pau Giner
<<a href="mailto:pginer@wikimedia.org" target="_blank">pginer@wikimedia.org</a>>
wrote:<br>
><br>
> >> Please let me know if you see
any possible concern with this approach.<br>
><br>
> > My first thought is of how upset
people were when the first version of<br>
> > Vector hid the language links by
default. I would suggest being sure<br>
> > there will be little or no similar
objection.<br>
><br>
><br>
> (hit send too soon, sorry)<br>
><br>
> A simple solution that would avoid a
similar reaction is: do not do<br>
> this by default - make it only for
logged-in users who want it that<br>
> way.<br>
><br>
> Possibly for default users, you could
put the heuristically-calculated<br>
> likely preferred languages at the top.
But keeping the rest of the<br>
> list below, right there on display,
will (I predict) be favoured, as<br>
> advertising the many languages of
Wikipedia is a strongly-held value<br>
> of many Wikimedians.<br>
><br>
><br>
> - d.<br>
><br>
>
_______________________________________________<br>
> Wikitech-l mailing list<br>
> <a href="mailto:Wikitech-l@lists.wikimedia.org" target="_blank">Wikitech-l@lists.wikimedia.org</a><br>
> <a href="https://lists.wikimedia.org/mailman/listinfo/wikitech-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/wikitech-l</a><br>
><br>
_______________________________________________<br>
Wikitech-l mailing list<br>
<a href="mailto:Wikitech-l@lists.wikimedia.org" target="_blank">Wikitech-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/wikitech-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/wikitech-l</a></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Mediawiki-i18n mailing list<br>
<a href="mailto:Mediawiki-i18n@lists.wikimedia.org" target="_blank">Mediawiki-i18n@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Mediawiki-i18n mailing list
<a href="mailto:Mediawiki-i18n@lists.wikimedia.org" target="_blank">Mediawiki-i18n@lists.wikimedia.org</a>
<a href="https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Mediawiki-i18n mailing list<br>
<a href="mailto:Mediawiki-i18n@lists.wikimedia.org">Mediawiki-i18n@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n" target="_blank">https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Pau Giner</div><div>Interaction Designer</div><div>Wikimedia Foundation</div>
</div>