Handle Comrade languages better about website HOT 1 OPEN

Having the languages in the form caused two problems. One was a usability challenge: finding and selecting the right language in a list of thousands is hard to do. The other was that having four separate language fields led to four copies of the HTML listing all the languages, which added up to something like a megabyte of text and was quite slow for Django to generate.

Working around the usability issue is super easy for visitors who have JavaScript turned on. There are a ton of usable jQuery plugins for enhanced select widgets and we could pick any of them that look good and drop it in without much trouble. Visitors without JavaScript fall back to their standard browser implementation of a select widget, so they can still fill out the form, it's just less convenient.

The "huge page" problem is a little harder, but solvable if we're willing to rely on JavaScript. For that we need something that does an AJAX request to ask the server to search the list of language subtags. This falls under the category of jQuery plugins for autocomplete (some of which are also in the list of enhanced select widgets above). But this doesn't work at all for people who have JavaScript disabled (using NoScript or lynx or whatever), which is a case that we should support.

If we can get a reasonable list of common languages, we could do a hybrid thing: serve the common languages in pure HTML, and use JavaScript to send AJAX queries for uncommon languages as the visitor types. That gives us small HTML and a usable if incomplete list for non-JavaScript visitors, plus full support for languages with as few as a thousand speakers worldwide for people who turn on JavaScript.

from website.