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:
-
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.
-
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.
-
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 |
