Commit Graph

6 Commits

Author SHA1 Message Date
Toby Zerner
53c621d999 Update event post API
- Use more appropriate component class name
- Allow username to be moved in translation
2015-07-20 18:12:08 +09:30
Toby Zerner
82f1daeef4 Change discussion list sorting labels 2015-07-20 18:11:04 +09:30
Toby Zerner
4a271dd11d Fix HTML entity 2015-07-17 17:52:45 +09:30
Toby Zerner
6ae270db95 Remove duplicates; replace missing commas 2015-07-17 17:47:53 +09:30
Toby Zerner
f93ff7cb3f Make front-end localizable 2015-07-17 17:43:28 +09:30
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