use same width to trigger mobile template in CSS + JS

Javascript was being told that it should adjust the layout of the app at
410 pixels while CSS was being told to use 460. The result was a garbled
half-state for anything between 410–460. As the search box and other
elements appear to need 460 to layout right, I normalized on that value.
fix CSS parsing oddity for older IE

IE <10 has issues with spaces in between the attribute and value in media
selectors. They are optional according to the spec, but it chokes on
them so I've removed them from all instances of this syntax. This one
got re-introduce in 0651ed7 along with some trailing whitespace.
set min-width for two columns to match mobile

With the current fixed element width system an argument could be made
for increasing this to 680 where everything shows up properly, but the
20 px difference between the mobile layout cutoff and the two column cut
off makes no sense. If nothing else it just makes a broken interface
where one of the major buttons does nothing. If these are to be at
different places, the add column button would also need to be hidden
separately.
Whitespace cleanup.

More whitespace deleted.

Spelling errors.

Test
Merge pull request #44 from alerque/fix-mobile-width

Fix issues with mobile template
Merge pull request #45 from zohma/master

Whitespace cleanup.
remove English strings from language names

Having this string is un-necessary in the case of the default English UI
(if you don't recognize the name of the language, content in that
language is not going to be very useful to you) and outright dead-weight
in the context of a localized UI (if you are using a not-English
version, non-localized strings hard coded in English are not that
useful).

Unless we include a full language name matrix with each language name
localized in each of the languages the site can be localized, it is more
generally useful to just show languages using their localized names (not to
mention easier).

Looking around at major platforms with localization support, this
appears to be the norm now (as opposed to a few years ago when
localization was first rolling out to a few programs and was being
driven by and English-first mindset).

If anything needs a hard-code English fall-back for people to "escape"
from a language they do not understand it would be the name of the
setting and the widget itself. Once they find the widget, having
"English" as a value in the list is enough.