Feature/main/i6328 improved localization

[jonasraoni]

Description

• Instead of registering a specific file (e.g. plugin/locale/en/common.po), the code is now expecting a folder (e.g. plugin/locale), which should follow a single rule: its direct sub-folders should refer to locale names (e.g. ./en_US, ./pt_BR, etc.).
• The application keeps track of the paths, but doesn't load anything until a translation is requested.
• When a translation for a specific locale is requested, it tries to find a LocaleBundle (a merged collection with all the translation files found for the given locale), if not found, it will build one.

LocaleBundle

• When a LocaleBundle is requested, the Locale class will pass through the registered folders (it's also possible to register a callback/dynamic file loader), access the sub-folder related to the requested locale (e.g. ./en_US), and retrieve the available .po files recursively. These files will be sent to the newly created LocaleBundle.

Translation

• When a translation is requested, the LocaleBundle will attempt to find the translations (merged .po files) in the disk/cache. The cache key is built using the path + modified date of its locale files + expiration interval. This way, any modification in the expiration, order of files, paths or modification dates will invalidate the cache.
• Since a translation might be requested before the application and all the plugins registered their folders, every different combination of available folders, at the time of the request, will issue a new cache (in my OJS installation, after installing/running some things, I've ended up with 8 cached files for the en_US bundle, each one with around ~450KB).
• If there's no cache, every .po file of the bundle will have to be parsed, transformed into an array, and have its translations merged sequentially into the bundle (there's an optional priority/order argument). This process also has an individual cache for each locale file (invalidated by the modification date).

Merging physically the locale files into a single one would also give a little performance bump.

[asmecher]

@jonasraoni, there are lots of useful clean-ups here, but it's impossible to review the code thoroughly when they're mixed together; could you separate them into individual commits? For example,

• PHP5 compatibility code / shims for missing functions removed
• Constants moved into classes
• Introduced functions in place of named constants for upgrade/install status
• etc.

[asmecher]

One more request: could you document the changes that developers using older versions of OJS will need to know in adapting their code to this? It'll give me something to think about while reviewing, plus @NateWr can collect this for his release notebook. See #6091 (comment) for an example.

[jonasraoni]

Ok! I think I'll create new issues for these extra modifications.