Git Commit ID: beb4c5b

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/

Commit: 4deea44

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

The new Locale API (using gettext) and the new Exception approach to
error handling in MantisBT means that ERROR_ constants are now
unnecessary.

All exceptions have been updated to use gettext for translating error
strings. Because many of the error messages have been rewritten in the
process, translations have been dropped. It is expected that we'll need
to recommence translating MantisBT from scratch after the new Locale API
is fully implemented. Why?

1. We need to support pluralisation.
2. We need to factor in the context of strings that need translating.
3. Many old error messages/strings are confusing and desperately in need
of updating.
4. A move towards modern web standards compliant HTML will greatly
increase the number of strings needing translation: alt and title
attributes on images and hyperlinks being just one example.
5. Huge chunks of MantisBT are likely going to be rewritten or
redesigned, dramatically changing the strings/error messages that need
to be translated.

As part of this change error codes have also been removed from MantisBT
exceptions. These codes do not add any value because exception class
names already provide unique identification (that is superior than just
a random number).

Exception constructors are also heavily simplified -- now containing
just a single argument for the error message.

MantisBT\Error has also been cleaned up further in preparation for
removal/replacement with a modern exception handler/displayer. We no
longer have an error_handler: all errors are converted to exceptions of
type ErrorException and handled by exception_handler. This removes a lot
of duplication and complexity.

related configuration options. They are always global and failure to
treat them as such will cause infinite call loops. These loops occur
when config_get calls authentication_api functions which check for a
user cookie (calling config_get to retrieve settings related to
cookies).

commit 83619f3

…lobal settings

The replacement of lang_get() calls for strings in the 'core' text
domain has mostly been completed. Plugins were calling a separate
function plugin_lang_get() that told lang_api (now deprecated) to use
the plugin-specific "lang" directory for translations specific to
plugins.

This new approach loads a text domain specific to each plugin prior to
plugin initialisation. Just as MantisBT core has a "locale" directory,
each plugin also needs a "locale" directory.

plugin_lang_get(...) has been completely removed and d___(...) and
dn_(...) should be used instead. This new syntax may change to something
simler and easier to handle in the near future.

Commit: d956d32