There are two mechanisms for providing translations:
- The Symfony Translations component, injected into the Twig instances for HTML and Mail output and used in the Presenters and Controllers
- The raw messages are injected as a global Twig variable and output as JSON in the base template of the laika skin. Currently, the base "messages" files differ between the skins, because laika needs a different placeholder format, different messages and has different wording.
Most of the Symfony Translations will be obsolete once laika is the only skin. To make the application more performant (memory and CPU-wise) we should consolidate the translations as follows:
- Remove the Translator instance from all Presentation and controller classes. The instances translate validation errors but all client-side code ignores the messages and only uses the message keys.
- Replace all calls to transfrom app/mail_templates with simple lookups. The "translations" are mostly conversions of days of the week, payment interval names and payment types. We can reuse the existing translation JSON files as lookup tables.
- Remove Symfony Translation from the application (composer.json, FunFunFactory, delete TranslationFactory, etc)
- Don't assign messages as Twig variable twice (currently the application-vars data attribute contains the contents of messages.json under the messages key)
- Delete messages.json in the fundraising-frontend-content repository, rename messages_laika.json to messages.json
Notes
- messages.json is still used for constructing e-mail subjects in the FunFunFactory::getMailTranslator() method
- Some messages are also used for greetings
- Moving all messages prefixed by mail_ to a new json file should work.
- look for all lines that contain | trans to see which messages are used from which file.
- There is a cli tool (render-mail-templates) for checking how mails are constructed, might be enhanced to output translated messages instead of keys.