Commits on Feb 25, 2012

1. Replace PHP UTF-8 library with PHP's mbstring extension …

   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/

   

   davidhicks committed Feb 25, 2012
   Copy the full SHA

   1b11094 View commit details

   Browse the repository at this point in the history

2. Add missing reference to load/use DatabaseTypeNotSupported

   

   davidhicks committed Feb 25, 2012
   Copy the full SHA

   5ea8ba4 View commit details

   Browse the repository at this point in the history

3. Add new Locale i18n/l10n API to replace lang_api …

   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

   

   davidhicks committed Feb 25, 2012
   Copy the full SHA

   9f7894b View commit details

   Browse the repository at this point in the history

4. Remove ERROR_ constants and ERROR_STRINGS[...] translations …

   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.

   

   davidhicks committed Feb 25, 2012
   Copy the full SHA

   aa3539a View commit details

   Browse the repository at this point in the history