[bug][34041] JToolbar Popup button modal icon class not customizable. Fixes #4075
[imp][34026] Improved search functionality in list views. Closes #4051
[cs] Use $this->params instead $app->getTemplate(true)->params at the templates. Closes #3930
Revert "[cs] Use $this->params instead $app->getTemplate(true)->params at the templates. Closes #3930"

This reverts commit fe2509e1eb1fcf053fcd958392e447ee3b5d1ef2.

For some reason, this doesn't work in the error page.
Missing icons
code style
Merge pull request #4077 from losedk/icon

Missing icons
Update en-GB.com_categories.ini
Update en-GB.com_content.ini
[bug] Correcting missing Hathor css after previous PRs. Fixes #4078
[bug][33932] SQL schemas updates are not applied if previous component
version didn't have schemas declaration. Fixes #3869
[bug][33930] Smart Search indexer must not replace underscore from taxonomy title. Fixes #3865
[imp][33831] Show and improve the precheck description. Closes #3742
JRoute::_() $ssl parameter doesn't work with "1" passed as string

# Executive summary

See Joomla! forum post on [SSL issues with Joomla! 3.1](http://forum.joomla.org/viewtopic.php?f=710&t=847483) The same issue was verified by my client Ryan H. who has also confirmed the fix. Due to the way mod_login works when you have an HTTPS site and enabled mod_login's "Encrypt login form" most browsers will refuse to proceed (posting to unencrypted page from an encrypted page) and those which do allow you to proceed land you in potentially hot water as it's now possible for an intruder to perform a man-in-the-middle attack, completely negating the benefits of using HTTPS on your site. Furthermore, it's a low security issue of its own right as an HTTP site with optional HTTPS and mod_login's "Encrypt login form" set to Yes will result in the form being posted to an unencrypted (HTTP) URL, leaving the login form open to man-in-the-middle attacks.

# Explanation

JRoute::_() has a third parameter $ssl which determines how JRoute should handle the resulting URL's protocol. 1 forces HTTPS, 2 forces HTTP and 0 leaves the protocol as it is. However, it doesn't recognise "1" passed as a string parameter. Coincidentally, mod_login passes this parameter as string when you set "Encrypt login form" to Yes. Due to this discrepancy in the code, if you have an HTTPS site *and* set mod_login's "Encrypt login form" to Yes then JRoute tries to submit the login form to the unencrypted (HTTP) site as $ssl === 1 returns false, making JRoute treat the parameter as if it were 2 (force unencrypted). Big whoops!
Merge pull request #4082 from nikosdion/patch-2

JRoute::_() $ssl parameter doesn't work with "1" passed as string
Merge pull request #4080 from zero-24/patch-3

[#33201] Missing language strings
Adapating installation language files to PR #3742
cs
Update categoryedit.php
Update contact.php