remove use of db_prepare_bool
Add function to prepare sql parameters before query use
formatting
Store mantis config settings as an object instead of hundreds of global variables
Phpdoc/Exceptions
fix css property
PHPdoc
phpdoc fixes + exceptions
Abort sets of sql updates if a single query within the set fails
use config_get_global to fetch absolute path
Fix typo introduced by 84017535f8718685d755d58af7a39d80f52ffca8 [dhx - #12013]
Additional Exceptions
The warning message displayed by user_get_field() when called with user
ID '0' (aka NO_USER) was not standard. Throwing Exception instead.
Fix comment
Change Log must consistently rely on fixed_in_version

Change Log used target_version instead of fixed_in_version to manage
issues' parent/child relationships. This caused unexpected behavior when
target version did not match fixed in version.

The SQL which retrieves the changelog issues now relies on
fixed_in_version.

Fixes #14788

Conflicts:

	changelog_page.php
ReAuthor 791fbd93d09b4b5b3f272413e5396d280735dc51
Include additional calls that were missing from original commit
exceptions
Further work on Exceptions
Replace PHP UTF-8 library with PHP's mbstring extension

Git Commit ID: beb4c5b8381c0f0eca99de23e1021fcebdc51c7a

For MantisBT 1.2.x, the PHP UTF-8 library at [1] was selected to provide
proper Unicode support to MantisBT. This library wraps around PHP's
mbstring extension and provides an alternative implemented-in-PHP
approach where the mbstring extension is not available on a server
running MantisBT. mbstring is a PHP extension that is not bundled with
PHP by default. Linux distributions already package the extension and it
is trivial to install. The extension is also bundled with the Windows
.zip distribution of PHP for Windows users and is also trivial to
install.

The need to support platform configurations where mbstring isn't
available and can't be installed stems from the days when shared hosting
was popular. With the popularisation of virtualisation (virtual private
servers) as a cheap replacement to shared hosting, administrators once
again have control over their own platform, allowing them to install PHP
extensions whenever they please. Popular Linux distributions have been
packaging and making the mbstring PHP extension available for a long
time. Installation on Windows platforms is also trivial (relative to the
complexity of Windows platforms due to a lack of software package
management functionality).

Removal of the PHP UTF-8 wrapper simplifies MantisBT's code base and
likely improves performance (no need to wrap function calls and compile
and load an entire UTF-8 library into memory). More importantly,
MantisBT no longer depends on a small library that hasn't seen updates
since 2007. Reliance on mbstring is a less risky option because it is
more widely used and ties in with PHP's official infrastructure and
support/documentation system.

MantisBT's documentation has been updated and expanded to reflect the
new installation requirement. Links to external documentation on php.net
have also been provided to guide new users in performing the simple
action of adding the mbstring extension.

[1] http://sourceforge.net/projects/phputf8/
Add new Locale i18n/l10n API to replace lang_api

Commit: 4deea44ed36cb4dcdd028be3a9f7cf3786e6e741

This is some initial work towards replacing lang_api with a new Locale
API that makes use of PHP's gettext support for translation.

gettext offers the following advantages:
a) Greater performance
b) Better supporting tools for translation work
c) Import/export support at MediaWiki.net that doesn't require
MantisBT-specific hacks
d) Pluralisation (1 thing vs 1 things)
e) en-US language is embedded in the source code and acts as a key --
this makes the source code easier to read and sections of code easier to
find upon searching for UI strings
f) Easy plugin support via loading of new text domains
g) Ability to perform more specific translations (en-US, en-GB,
en-AU...) rather than "one English fits all"
h) Support for context aware translations

There is lot of negativity in the wild regarding gettext and PHP.
Typical arguments include:

1. Lack of thread safety - this is no longer an issue with php-fpm (or
earlier Fast CGI methods) because each script will execute in a separate
process. Threaded execution of PHP under mod_php (Apache) or an IIS
equivalent is thoroughly deprecated and not recommended for numerous
reasons.

2. gettext is difficult to install with PHP - Linux distributions of PHP
will most likely have gettext enabled by default. If not, packages are
readily available in all the major distribution repositories. Windows
users are given php_gettext.dll in the .zip distribution of PHP and
simple instructions at [1] can be followed to get things up and running
quickly.

3. The gettext API is "inconsistent" or doesn't support xyz - it's
trivial to create a new wrapper function around these APIs that allows
us to implement enhanced functionality or make the API easier to use.

Don't be tricked by the outdated negativity from the early 2000's.
gettext is an "industry standard" and is not going away any time soon.

[1] http://php.net/manual/en/install.windows.extensions.php