Turns out Container::call() does not work with invokable classes.
Thus, we need to wrap callables in a custom extender class to
support injecting any resolvable type-hint automatically.
Refs #851.
This simplifies the API and gives extension developers more
flexibility, for a) maintaining backwards compatibility, and
b) doing advanced stuff that extenders do not allow.
Note that only extenders are guaranteed to work across
different versions of Flarum (once the API surface is stable).
See the discussion in https://github.com/flarum/core/pull/1335.
Ditched the idea of having language packs as extensions. Reasoning:
1. Because we use machine keys for translations (rather than English
keys), extensions need to be able to define default translations. If
English translations are to be included in extensions and not in a
language pack extension, then it doesn’t make sense to have other
languages as language pack extensions. Inconsistency → complexity.
2. Translations should maintain version parity with their respective
extensions. There’s no way to do this if extension translations are
external to the extension.
Instead, localisation will be a core effort, as well as a per-extension
effort. Translators will be encouraged to send PRs to core + extensions.
In core, each locale has a directory containing three files:
- translations.yml
- config.js: contains pluralisation logic for the JS app, as well as
moment.js localisation if necessary
- config.php: contains pluralisation logic for the PHP app
Extensions can use the Flarum\Extend\Locale extender to add/override
translations/config to a locale.
Asset compilation has been completely refactored with a better
architecture. Translations + config.js are compiled and cached for the
currently active locale.
