Toby Zerner 8b162344cd Lay the groundwork for translation & refactor asset compilation ... 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.		2015-06-10 14:23:56 +09:30
..
en	Lay the groundwork for translation & refactor asset compilation	2015-06-10 14:23:56 +09:30